Linux下Qt显示USB摄像头画面：V4L2采集与YUYV转QImage实战

简介：这是一份基于Qt与V4L2的USB摄像头采集显示程序源码包，面向Linux下从事嵌入式或桌面多媒体开发的工程师，解决在Qt界面中实时预览USB摄像头画面的常见需求。资源共7个文件，包含3个cpp源码、2个头文件以及pro与user工程文件，压缩包仅5KB，pro文件用于qmake构建工程，user文件保存Qt Creator配置，整体代码结构精简，便于快速阅读和二次开发。已有582人学习下载。源码围绕V4L2设备打开、帧缓冲处理、图像格式转换到Qt控件显示等关键步骤展开，并涉及摄像头参数调节、视频流实时刷新和线程并发处理逻辑，可帮助理解Qt事件循环与V4L2异步采集的协作方式。通过研读这些代码，读者能够掌握Linux下摄像头采集的基本框架，为编写视频监控、图像识别或嵌入式采集程序打下扎实基础，也适合作为课程设计或入门练手项目。

1. 在 Linux 用 Qt 显示 USB 摄像头画面，最直接的路径是绕开 Qt Multimedia

Qt 做摄像头采集，大多数人第一反应是QCamera+QVideoSink，这套封装在桌面原型上确实好用。但一旦画面需要按帧处理、要指定像素格式、要控制 buffer 数量，或者要在嵌入式板卡上跑，Qt Multimedia 的抽象层会把底层细节吞掉，延迟和拷贝也不好控。qt_v4l2_camera这类项目标题在网络上高频出现，背后对应的其实是一条更底层的技术路径：让 Qt 程序直接读/dev/videoX，用 V4L2 完成采集、把帧转成QImage再显示。USB 摄像头在 Linux 下绝大多数走 UVC 驱动，驱动框架就是标准的 V4L2，所以这条路对所有常见的免驱摄像头都成立。适合的人群是需要在 Linux 桌面或嵌入式 Qt 环境里拿到稳定帧率、能自己控制采集参数的 C++ 工程师，而不是只需要「能出画面」的演示场景。

2. V4L2 采集流程：open、mmap 与 queue/dequeue 的最小实现

V4L2（Video for Linux 2）是 Linux 内核里视频设备的标准接口，USB 摄像头插入后通常被枚举为/dev/video0。应用层的核心动作只有几个：打开设备、查询能力、设置格式、申请缓冲区、把缓冲入队，然后循环出队取帧。

2.1 设备节点与驱动框架的关系

先确认摄像头节点是否可读，ls -l /dev/video*会看到类似crw-rw---- 1 root video的权限。普通用户要加入video组才能直接打开设备，很多「打开失败」的问题根本不是代码问题，而是权限。

一个 USB UVC 摄像头在内核里挂了uvcvideo驱动，它会向 V4L2 核心注册/dev/videoX。对应用层来说，驱动框架的差异是透明的，你只需要通过VIDIOC_QUERYCAP读取struct v4l2_capability，确认device_caps里有没有V4L2_CAP_VIDEO_CAPTURE和V4L2_CAP_STREAMING。前者表示这是一个采集设备，后者表示支持 streaming I/O（也就是 mmap 方式）。

2.2 打开设备并确认采集能力

以下代码打开/dev/video0并打印设备信息，这是任何一个 V4L2 采集程序的起点。

#include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <linux/videodev2.h> #include <cstring> #include <cstdio> int main() { int fd = open("/dev/video0", O_RDWR); if (fd < 0) { perror("open video0"); return -1; } struct v4l2_capability cap{}; if (ioctl(fd, VIDIOC_QUERYCAP, &cap) < 0) { perror("QUERYCAP"); return -1; } printf("driver: %s\n", cap.driver); printf("card: %s\n", cap.card); printf("bus: %s\n", cap.bus_info); if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE)) { fprintf(stderr, "not a capture device\n"); return -1; } int ret = ioctl(fd, VIDIOC_S_FMT, &fmt); ... }

cap.driver对 UVC 摄像头通常是uvcvideo，cap.card一般是摄像头型号字符串。这里检查V4L2_CAP_VIDEO_CAPTURE是为了防止拿到/dev/video0实际是 TV tuner 或 video output 设备。注意cap.capabilities和cap.device_caps的区别，前者是设备整体能力，后者是当前节点能力，判断采集能力以device_caps为准，因为一个物理设备可能同时有 capture 和 output 两个节点。

2.3 设置采集格式：VIDIOC_S_FMT

设置格式是决定摄像头输出什么像素格式的关键一步。USB 摄像头默认通常输出V4L2_PIX_FMT_YUYV（YUYV 4:2:2）或V4L2_PIX_FMT_MJPEG。对桌面级 UVC 摄像头，YUYV 在 640×480@30fps 下需要约 18MB/s 的 USB 带宽，而 MJPEG 可能只需要不到一半，很多百元级摄像头在 1080p 下强制走 MJPEG。

#include <linux/videodev2.h> struct v4l2_format fmt; memset(&fmt, 0, sizeof(fmt)); fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; fmt.fmt.pix.width = 640; fmt.fmt.pix.height = 480; fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; // 请求 YUYV fmt.fmt.pix.field = V4L2_FIELD_NONE; // 逐行 if (ioctl(fd, VIDIOC_S_FMT, &fmt) < 0) { perror("S_FMT"); return -1; } // 实际生效的格式，摄像头可能会改分辨率或帧格式 printf("w=%u h=%u fourcc=%c%c%c%c\n", fmt.fmt.pix.width, fmt.fmt.pix.height, fmt.fmt.pix.pixelformat & 0xFF, (fmt.fmt.pix.pixelformat >> 8) & 0xFF, (fmt.fmt.pix.pixelformat >> 16) & 0xFF, (fmt.fmt.pix.pixelformat >> 24) & 0xFF);

VIDIOC_S_FMT是 set format，内核会调用摄像头驱动的vidioc_s_fmt回调去和硬件协商。UVC 驱动会查询设备支持的格式集合，如果请求的格式不支持会返回错误或静默换成默认格式。所以打印fmt.fmt.pix的实际值非常关键——你请求 YUYV，但摄像头可能只支持 MJPEG，这时pixelformat字段会被内核改成它支持的格式。

这里有一个容易被新手忽略的点：VIDIOC_S_FMT的pixelformat是 little-endian fourcc，V4L2_PIX_FMT_YUYV的宏定义已经按内存字节序处理，直接赋值即可。但打印时如果按字符强转会看到字节序颠倒的样子，上面的代码做了四位移位，就是为了看清 fourcc 的实际字符。

2.4 申请 mmap 缓冲区并进入采集循环

V4L2 的 streaming 模式有几种 buffer 方式：mmap、userptr、DMABUF。对 USB 摄像头和普通 Qt 桌面应用，mmap 最简单稳定，内核分配物理上连续的帧缓冲，应用层通过mmap映射到用户空间地址，零拷贝程度最高。申请 4 个缓冲区是常用值，太少容易丢帧，太多增加内存占用和延迟。

#include <sys/mman.h> #include <linux/videodev2.h> struct v4l2_requestbuffers req; memset(&req, 0, sizeof(req)); req.count = 4; req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; req.memory = V4L2_MEMORY_MMAP; if (ioctl(fd, VIDIOC_REQBUFS, &req) < 0) { perror("REQBUFS"); return -1; } // 每个 buffer 的 mmap 地址和长度 void* buffers[4]; size_t buf_len[4]; for (unsigned i = 0; i < req.count; ++i) { struct v4l2_buffer buf; memset(&buf, 0, sizeof(buf)); buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory = V4L2_MEMORY_MMAP; buf.index = i; if (ioctl(fd, VIDIOC_QUERYBUF, &buf) < 0) { perror("QUERYBUF"); return -1; } buffers[i] = mmap(nullptr, buf.length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, buf.m.offset); buf_len[i] = buf.length; // 入队 if (ioctl(fd, VIDIOC_QBUF, &buf) < 0) { perror("QBUF"); return -1; } } // 开始采集 enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE; ioctl(fd, VIDIOC_STREAMON, &type); // 取帧循环 for (int frame = 0; frame < 100; ++frame) { struct v4l2_buffer buf; memset(&buf, 0, sizeof(buf)); buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory = V4L2_MEMORY_MMAP; if (ioctl(fd, VIDIOC_DQBUF, &buf) < 0) { perror("DQBUF"); break; } // 此时的 buffers[buf.index] 就是这一帧 YUYV 数据，长度 buf.bytesused uint8_t* frame_ptr = static_cast<uint8_t*>(buffers[buf.index]); // 用完先入队，再处理数据，这样摄像头可以继续填 buffer ioctl(fd, VIDIOC_QBUF, &buf); }

这个循环的顺序是：DQBUF拿一帧，处理，QBUF归还。注意到我故意把QBUF放在数据处理之前，这是一个实际项目里的常见优化。如果先花 10ms 转换再归还 buffer，摄像头在等待期间没有空 buffer 可用，就会丢帧。先归还能保证驱动侧始终有空闲缓冲区，代价是数据在frame_ptr上只保证本次循环内有效，所以如果你要把帧交给 Qt 主线程显示，必须在归还前拷贝或者做完转换。

参数说明：DQBUF是 dequeue buffer，阻塞等待一帧数据到达或有错误返回EAGAIN（非阻塞模式）。buf.bytesused是这一帧的实际字节数，对 YUYV 640×480 是 614400 字节，等于width * height * 2。buf.sequence字段可以拿到帧序号，用于判断是否丢帧，如果相邻两帧的sequence差值大于 1，说明中间丢了帧。

3. YUYV 转 RGB 与 QImage 显示：帧数据怎么送进界面

从DQBUF拿到的原始帧是 YUYV 格式，Qt 的QImage原生不认这种 fourcc，所以必须做一次 YUV 到 RGB 的颜色空间转换。这个环节是 CPU 占用的大头，代码质量直接影响帧率和 CPU 温度。

3.1 为什么 UVC 摄像头默认给 YUYV 而不是 RGB

USB 摄像头的传感器原生输出一般是 Bayer 或 YUV，UVC 协议把 YUV 4:2:2 作为默认传输格式，因为人眼对亮度敏感、对色度不敏感。YUYV 每个像素用 16 bit，两个像素共享一对 CbCr，比 RGB24 每个像素 24 bit 少 1/3 带宽。这是 USB 2.0 时代定下的规矩，今天 1080p@30 的 YUYV 流约需要 124MB/s，已经超过 USB 2.0 的实际有效带宽，所以 1080p 摄像头普遍默认输出 MJPEG。你需要清楚这一点：如果请求V4L2_PIX_FMT_YUYV在 1080p 下失败或帧率上不去，不是代码有问题，是硬件带宽不够。

3.2 YUYV 4:2:2 的内存布局

一行 YUYV 数据在内存里的排列是 Y0 U0 Y1 V0 Y2 U2 Y3 V2，也就是说每 4 个字节描述 2 个像素。偶数像素取 Y0 + U0 + V0，奇数像素取 Y1 + U0 + V0（色度共用）。这个交错关系是新手最容易算错的地方。

展开之后是这样的：

offset 0: Y0 U0 Y1 V0 offset 4: Y2 U2 Y3 V2

像素 0 的色度来自 U0、V0，像素 1 的色度也来自 U0、V0；像素 2 和 3 共用 U2、V2。转换时每读 4 个字节可产出 2 个 RGB888 像素。

3.3 YUYV 转 RGB888 的最小实现

转换用标准 BT.601 公式即可，针对 UVC 摄像头不要用 BT.709，那是高清视频的标准，桌面摄像头按 BT.601 色域更准。实际写代码时，尽量把转换封装成一行宽、一帧行的循环，方便编译器做向量化。最简单的可运行版本如下。

// src: YUYV 数据, dst: RGB888 (3 字节/像素) // width、height 是像素宽高，width * height * 2 = src 字节数 void yuyv_to_rgb24(const uint8_t* src, uint8_t* dst, int width, int height) { int stride_yuyv = width * 2; int stride_rgb = width * 3; for (int y = 0; y < height; ++y) { const uint8_t* src_row = src + y * stride_yuyv; uint8_t* dst_row = dst + y * stride_rgb; for (int x = 0; x < width / 2; ++x) { int i = x * 2; // 两个像素一组 uint8_t y0 = src_row[i * 2 + 0]; uint8_t u = src_row[i * 2 + 1] - 128; uint8_t y1 = src_row[i * 2 + 2]; uint8_t v = src_row[i * 2 + 3] - 128; int c = y0 + 1.772f * u; int d = y0 - 0.344f * u - 0.714f * v; int e = y0 + 1.402f * v; dst_row[x * 6 + 0] = clamp(c); dst_row[x * 6 + 1] = clamp(d); dst_row[x * 6 + 2] = clamp(e); c = y1 + 1.772f * u; d = y1 - 0.344f * u - 0.714f * v; e = y1 + 1.402f * v; dst_row[x * 6 + 3] = clamp(c); dst_row[x * 6 + 4] = clamp(d); dst_row[x * 6 + 5] = clamp(e); } } }

clamp是把计算结果限制到 0～255 的辅助函数，浮点运算虽然在这里可以接受，但 30fps 全高清下每帧 200 万像素，浮点算力消耗不低。实际项目常先把浮点系数放大到整数定点数，系数乘 256 后转整数运算，这样单帧转换耗时大约能降 40%。

参数说明：width/2才是内层循环次数，因为每次处理两个像素。stride_yuyv是 YUYV 的行跨度，stride_rgb是 RGB 输出的行跨度。不要直接用width * 3去索引dst_row然后再乘height，先把行首算出来，避免每像素做一次乘法和加法。这个函数假定宽度是偶数，UVC 摄像头默认支持的分辨率都满足这一点，但如果用v4l2-ctl --set-fmt-video强行设置奇数分辨率，会出现越界读。

3.4 QImage 构造与显示的不变量

转换完的 RGB888 数据可以直接包成QImage。一个关键约束：如果你把转换后的dst存在堆上，QImage默认不拷贝像素数据，它只保存指针。Qt 文档里叫「不拥有数据」，意味着dst必须是生命周期足够长的内存，不能是栈上临时数组。

// dst_buf_ 是一次性分配好的 RGB 缓冲, 大小 w*h*3 QImage img(dst_buf_, width, height, QImage::Format_RGB888); // 显示在 QLabel 上 ui->label->setPixmap(QPixmap::fromImage(img));

QPixmap::fromImage会把QImage拷到 QPainter 能高效绘制的格式，这一步也有开销。如果目标是极限性能，可以在自定义 QWidget 的paintEvent里直接用QPainter::drawImage，避免中间 pixmap；但按 QLabel 的setPixmap做法在 640×480 下完全够用，不要过早优化。

这里的常见问题有两个。第一，QImage::Format_RGB888指定每像素 24 bit，行对齐在 x86 上是 4 字节对齐，但 QImage 内部按 32 位对齐时会自动处理bytesPerLine，你给的dst不需要手动补齐，QImage 的构造函数会用你传的bytesPerLine参数，默认是width * 3。第二，千万不能把QImage的指针临时指向刚DQBUF出来的映射地址，mmap的内存归 V4L2 驱动管理，下一轮QBUF就会覆盖它。要么先把 YUYV 拷贝到自己的缓冲再转换，要么转换输出直接落到dst_buf_，显示逻辑永远不直接碰buffers[i]。

3.5 把 QImage 交给控件前的内存策略

每帧都new一个 RGB 缓冲，靠QImage生命周期去释放，短时间看不出问题，但运行半小时后会看到内存碎片增长和反复分配导致的不稳定帧率。做法是分配一个固定dst_buf_，转换函数往这个固定地址写，然后QImage构造出来交给显示，显示是同步的，QPainter::drawImage返回后这一帧就可以被覆盖。如果需要异步渲染，就必须在QImage创建时用img.copy()显式拷贝一份，或者用 buffer pool 轮转 3 个 QImage 轮流写。

4. 采集线程与主线程同步：双缓冲、信号槽与丢帧策略

V4L2 的DQBUF是阻塞调用，30fps 下平均每 33ms 返回一帧。如果放在 Qt 主线程，每次阻塞都会让界面卡顿；反过来，把 UI 刷新放进采集线程又会触发 Qt 的跨线程绘制警告。所以标准的做法是采集循环单独跑一个线程，帧数据通过信号槽发回主线程。

4.1 用 QThread + worker 模式跑采集循环

不推荐继承QThread然后在run()里写采集逻辑，那样拿不到主线程的信号槽上下文。常见做法是定义一个 worker 对象，moveToThread过去，用信号启动和停止。下面的代码给出采集线程的骨架。

class CaptureWorker : public QObject { Q_OBJECT public slots: void start() { is_running_ = true; while (is_running_) { struct v4l2_buffer buf; memset(&buf, 0, sizeof(buf)); buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory = V4L2_MEMORY_MMAP; if (ioctl(fd_, VIDIOC_DQBUF, &buf) < 0) { if (errno == EAGAIN) { // 非阻塞超时 QThread::msleep(1); continue; } break; } yuyv_to_rgb24(static_cast<uint8_t*>(buffers_[buf.index]), rgb_buf_, width_, height_); // 归还 buffer 要在转换完成后，防止数据被覆盖 ioctl(fd_, VIDIOC_QBUF, &buf); // 发信号给主线程 emit frameReady(rgb_buf_, width_, height_); } } void stop() { is_running_ = false; } signals: void frameReady(uint8_t* data, int w, int h); private: bool running_... }; // 主线程侧 auto worker = new CaptureWorker; auto thread = new QThread; worker->moveToThread(thread); QObject::connect(thread, &QThread::started, worker, &CaptureWorker::start); QObject::connect(worker, &CaptureWorker::frameReady, this, &MainWindow::onFrameReady); thread->start();

信号frameReady带的uint8_t*指针指向worker里的rgb_buf_。这里有个容易踩的坑：跨线程信号槽是排队连接，槽函数onFrameReady在主线程执行时，采集线程可能已经写完下一帧，导致显示跳帧或撕裂。解决办法是双缓冲——rgb_buf_准备两个，QRgbBuf[2]，采集线程轮流写空闲的那个，信号里带上 buffer 序号，主线程槽里先拷贝或直接绘制，绘制完成后再通过另一个信号告诉采集线程该 buffer 已释放。

4.2 丢帧策略：优先保证最新画面而不是全部帧

排队连接的信号槽之间还有一个隐藏缓冲，信号发得比主线程画得快时，Qt 事件循环里会堆积frameReady，表现为画面延迟越来越大。在onFrameReady里检查并清空事件队列不现实，更稳妥的策略是：如果上一帧还没处理完，这一帧直接丢弃。实现方式是在 worker 里用一个原子标志位frame_busy_。

// 采集线程 if (frame_busy_.load()) { // 主线程还没画完上一帧，放弃这帧 ioctl(fd_, VIDIOC_QBUF, &buf); continue; } frame_busy_.store(true); emit frameReady(rgb_buf_, width_, height_); // 主线程槽函数 void MainWindow::onFrameReady(uint8_t* data, int w, int h) { QImage img(data, w, h, w * 3, QImage::Format_RGB888); ui->label->setPixmap(QPixmap::fromImage(img)); worker_->markFrameConsumed(); // frame_busy_ = false }

用markFrameConsumed回写标志位，比在采集线程睡固定时间然后无条件入队更稳。这样在低配设备上画面帧率会掉，但延迟不会随时间累积，这是工业视觉和远程控制场景更在意的指标。有些项目反过来希望「每一帧都不能丢」，那就必须把 RGB 拷贝挪到采集线程完成，emit frameReady带的是QImage值类型，Qt 在跨线程传递时会做隐式共享拷贝，拷贝消耗不小的内存带宽，一般场景不推荐。

4.3 帧率设定与采集参数

V4L2 采集的实际帧率由VIDIOC_S_PARM控制，也可以不设置，直接按摄像头默认走。但很多 USB 摄像头默认在某个分辨率下输出 30fps，对画面精细处理场景，30fps 太高，白白增加转换开销。设置帧率的代码：

struct v4l2_streamparm parm; memset(&parm, 0, sizeof(parm)); parm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; if (ioctl(fd, VIDIOC_G_PARM, &parm) == 0) { parm.parm.capture.timeperframe.numerator = 1; parm.parm.capture.timeperframe.denominator = 15; // 15fps if (ioctl(fd, VIDIOC_S_PARM, &parm) < 0) { perror("S_PARM"); } }

timeperframe的分子分母含义是每帧多少秒，分母 15 就是 15fps。UVC 摄像头不一定支持所有帧率组合，VIDIOC_S_PARM可能静默失败，调用后再VIDIOC_G_PARM回读确认。对确定性的帧率控制，也可以在采集循环里用QElapsedTimer控制「最多每 N 毫秒处理一帧」，超出部分直接归还 buffer，这种方式不依赖驱动对帧率的支持，实现起来更可控。

5. 多摄像头枚举、控制参数与三个实测技巧

前面几章的代码默认只打开/dev/video0，真实项目里往往一个 Qt 程序要接多个 USB 摄像头，或者需要调节亮度、曝光。这一节集中讲实际工程里最常碰到的三个问题。

5.1 枚举所有 video 节点并区分摄像头类型

/dev/video0到/dev/videoN不全是摄像头，采集卡、虚拟设备、HDMI capture 都占一个节点。遍历节点时用VIDIOC_QUERYCAP看device_caps，同时过滤V4L2_CAP_VIDEO_CAPTURE和V4L2_CAP_UVC两个标志（有V4L2_CAP_UVC的是 UVC 规范的 USB 摄像头）。最终把cap.card和节点路径的映射显示在选择列表里，让用户决定打开哪一路。

5.2 V4L2 控制参数的设置方式：亮度、曝光、自动调节

VIDIOC_S_CTRL给了一个通用入口，设置亮度、对比度、曝光时间。v4l2-ctl -L可以列出设备所有支持的控制项，每个控制项的 ID 是固定的，用struct v4l2_control传入即可。

struct v4l2_control ctrl; ctrl.id = V4L2_CID_BRIGHTNESS; ctrl.value = 128; // 范围见 v4l2-ctl -L if (ioctl(fd, VIDIOC_S_CTRL, &ctrl) < 0) { perror("S_CTRL brightness"); } // 曝光调节在 UVC 设备上常用 V4L2_CID_EXPOSURE_AUTO ctrl.id = V4L2_CID_EXPOSURE_AUTO; ctrl.value = V4L2_EXPOSURE_MANUAL; ioctl(fd, VIDIOC_S_CTRL, &ctrl); ctrl.id = V4L2_CID_EXPOSURE_ABSOLUTE; ctrl.value = 300; // 手动曝光值 ioctl(fd, VIDIOC_S_CTRL, &ctrl);

一个容易踩的坑：V4L2_CID_EXPOSURE_ABSOLUTE的单位和范围因摄像头而异。有的摄像头值是 1/10000 秒，300 表示 1/33 秒；有的是 us 级。写代码前先用v4l2-ctl -L看min、max、step的定义。EXPOSURE_AUTO不设回 auto 模式的话，程序退出后摄像头会一直保持手动曝光设置，其他应用再打开也是这个状态，要在退出时恢复默认。

5.3 性能验证的三个落地技巧

perf top -p <pid>观察进程 CPU 分布。YUYV 转 RGB 是纯 CPU 计算，如果转换函数占 CPU 超过 50%，优先做定点优化或 SIMD，而不是优化线程模型。可以用top -H -p <pid>确认采集线程是否频繁锁在ioctl上，如果是，说明 DQBUF 在等帧而不是在忙转换，瓶颈在摄像头帧率而非计算。

最后一个验证手段是v4l2-ctl --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap=4 --stream-count=100。这个命令独立于 Qt 跑一次标准采集流程，可以拿它和 Qt 程序里的帧号buf.sequence做对比。如果v4l2-ctl能稳定 30fps 而 Qt 侧只有 20fps，问题在转换或显示侧；两边都掉帧就说明摄像头或 USB 控制器本身已经到瓶颈。把这个测试挂在每次改完采集代码之后，是判断回归最快的办法。

本文还有配套的精品资源，点击获取