简介：这是一套面向高校计算机相关专业学生的视频监控系统毕业设计源码包，基于Qt框架并结合V4L2、OpenCV、SQLite实现，涵盖客户端与服务端完整工程，适合用于课程设计、毕业设计或Qt/OpenCV项目实战练习。压缩包共含51个文件，以C++源码（.h/.cpp）、Qt界面文件（.ui）、工程配置（.pro/.qrc）及项目说明（.txt）为主，另有登录注册、主监控界面等截图，便于快速了解系统功能与界面结构，整体体积仅2.14MB，轻量易部署。资源内提供登录系统、主窗口、视频监控客户端/服务端等多个模块实现，包含V4L2视频采集封装、SQLite数据库单例、图像资源与libjpeg相关库文件，并附项目说明文档，可直接导入Qt Creator运行，也可在此基础上扩展报警、存储、远程访问等功能。目前已有83人学习/下载，适合需要完整参考方案的学生与开发者借鉴学习。
1. 视频监控系统：Qt、V4L2、OpenCV、SQLite 这套组合拳到底怎么打
拿到“基于 Qt+V4L2+OpenCV+SQLite 的视频监控系统”这个题目，很多人的第一反应是“这不就是个摄像头显示程序吗”。实际做下来你会发现，真正耗时间的不是界面，而是 V4L2 的参数调优、帧同步、OpenCV 处理链路的延迟控制，以及 SQLite 在持续写入下的性能衰减。这个方案之所以在毕业设计和轻量级桌面监控里被反复选用，是因为它在“能跑”和“能讲清原理”之间找到了一个平衡点：每个组件都有明确的边界，组合起来正好覆盖采集、处理、显示、存储一条完整链路。这篇文章就把每个环节怎么选型、怎么调参、踩过哪些坑一次讲透，给正在做这套题目的你一条能直接落地的路径。
2. 拆解四个核心组件：先知道谁干什么，踩坑时才知道怪谁
2.1 Qt 在整个系统里的真实职责：不只是画界面
很多人以为 Qt 在这个项目里就是窗口和按钮，其实它的职责要重得多。它负责三件事：一是主事件循环，所有采集、处理、显示都要挂在这个循环上，不能自己开线程死循环去读摄像头；二是定时器驱动采集节奏，常见做法是 QTimer 每 33ms 或 40ms 触发一次帧采集，对应 30fps 或 25fps；三是跨线程的信号槽通信，采集线程把帧交给处理线程，处理完再扔回 UI 线程刷新，这套流程必须通过信号槽或队列连接，否则界面会卡死或崩溃。
我一般会拆三个线程：采集线程只做 V4L2 的 read 或 mmap 取帧，处理线程做 OpenCV 的检测和画框，UI 线程只负责显示和响应按钮。别把采集和处理塞一个线程，否则 CPU 占用率会很难看。线程间传帧用 Qt 的 QImage 而不是 cv::Mat 的裸指针，因为 QImage 是隐式共享的，跨线程传递时引用计数是安全的，直接传 cv::Mat 指针很容易出现悬垂。
2.2 V4L2 是 Linux 下绕不开的采集口：为什么不用 OpenCV 的 VideoCapture
如果用 OpenCV 的 VideoCapture 打开 /dev/video0，三行代码就能出画面，但这套方案有个致命伤：你没法精细控制缓冲区数量和像素格式。VideoCapture 拿到的是已经转换好的 BGR 帧，中间丢了 YUYV 到 BGR 的转换控制权，而且延迟不稳定。V4L2 直接操作的是驱动层的缓冲区，你可以选择 mmap 零拷贝映射，也可以选择 read 方式让内核帮你拷贝，还能精准设置 v4l2_format 的像素格式和分辨率。
这里有个关键选择：像素格式用 YUYV 还是 MJPG。USB 摄像头通常两种都支持，但 MJPG 是压缩格式，需要 CPU 解码；YUYV 是原始格式，占用带宽大但省解码步骤。我的建议是优先 YUYV，因为 V4L2 采集到 YUYV 后转 OpenCV 的 BGR 只做一次内存拷贝，开销可控。如果摄像头分辨率超过 1280x720，YUYV 的带宽占用会让 USB 2.0 吃紧，此时再切 MJPG 加 libjpeg 解码。
2.3 OpenCV 在这条链路里做的是“加工”：不是采集，也不是存储
OpenCV 在这个系统里的定位是帧处理工厂。它负责把 V4L2 交上来的 YUYV 帧转成 cv::Mat，然后跑运动检测、人脸检测或区域入侵检测，最后把检测结果画框叠加到帧上，交给 Qt 显示。很多人会把 OpenCV 和摄像头采集混为一谈，实际上在这个架构里，OpenCV 不碰 /dev/video0，它只消费处理线程里已经转好的 Mat。
处理链路的性能瓶颈通常不在检测算法本身，而在格式转换。cvtColor 从 YUV 转 BGR 是必经之路，这一步在 640x480 下几乎无感，但到 1920x1080 时单帧转换就要 3-5ms，如果再加上高斯模糊、帧差法、轮廓查找，一帧的处理时间很容易突破 40ms 的预算。常见做法是用 Libyuv 替代 OpenCV 的 cvtColor，同样的 YUYV 转 BGR 能快 2-3 倍，而且 CPU 占用更平稳。
2.4 SQLite 在视频监控里的角色：存的是“元数据”，不是视频流
这是整个方案最容易跑偏的地方。有人会把视频帧直接塞 SQLite，几秒钟就能把数据库撑到几百 MB，而且写入速度断崖式下跌。正确的姿势是：SQLite 只存告警记录、检测事件、抓拍图片路径、时间戳、检测类型，视频流本身要么不录，要么用 MJPG 或 H.264 写文件后，把文件路径存进数据库。
SQLite 在嵌入式监控场景有天然优势：零配置、单文件、支持事务，比 MySQL 轻得多。但它的写入性能有一个规律：单条 INSERT 很慢，批量事务很快。实测下来，100 条一批提交和逐条提交，性能差距能到 10 倍以上。在监控系统里，告警本身是稀疏事件，正常情况几分钟才一条记录，配合批量提交完全够用。千万别为了图省事把图片二进制直接写进 BLOB 字段，文件路径+文件系统才是正解。
2.5 四个组件的协作时序：从摄像头到数据库的完整数据流
把四个组件串起来看，数据流是这样的：V4L2 从驱动层拿到一帧 YUYV 原始数据，放到 mmap 缓冲区；采集线程把这份数据拷贝出来，通过队列交给处理线程；处理线程用 OpenCV 转成 BGR Mat，进行运动检测或人脸检测，检测到目标就用矩形框标记，并把这一帧转成 QImage；QImage 通过信号槽发给 UI 线程刷新画面；同时，处理线程把告警时间、告警类型、抓图路径组装成一条记录，交给一个独立的数据库线程，批量写入 SQLite。
这个时序里最容易被忽略的是“数据库线程要独立”。如果直接在处理线程里写 SQLite，一帧的耗时会被磁盘 IO 拖住，导致画面掉帧甚至事件堆积。单独开一个写库线程，接收处理线程抛来的告警结构体，攒够一批或超过一定时间再统一提交，才能把处理链路的耗时控制在稳定区间。
3. 从零搭建工程：环境准备与最小可运行架构
3.1 环境清单与依赖安装
这套方案要求 Linux 环境，因为 V4L2 本身就是 Linux 内核的 video4linux 子系统。Windows 下没有 V4L2，摄像头采集要用 DirectShow 或 Media Foundation，整个架构要换掉一半，所以毕设题目里写了 V4L2 就一定是在 Linux 或嵌入式板子上跑的。
# Ubuntu 20.04 / 22.04 下安装依赖 sudo apt update sudo apt install -y qtbase5-dev libopencv-dev libv4l-dev v4l-utils sqlite3 libsqlite3-dev安装完验证两件事：一是检查摄像头节点是否存在，ls /dev/video0 有输出说明驱动正常；二是用 v4l2-ctl 确认摄像头支持的像素格式和分辨率，这决定了后面代码里的参数设置。v4l2-ctl --list-formats-ext -d /dev/video0 能看到完整的格式列表，比如 YUYV 4:2:2 支持的最大分辨率是多少，MJPG 支持到多少。这个输出非常关键，因为它告诉你“摄像头宣称支持的分辨率”和“驱动实际给得出来的帧”之间有没有差距。
3.2 QMake 工程的最小结构
我习惯用 qmake 而不是 CMake，不是因为 CMake 不好，而是这套题目的目标平台通常就是本地 Linux，qmake 配置更直白，答辩时讲起来也更顺。
# 监控系统.pro QT += core gui sql greaterThan(QT_MAJOR_VERSION, 4): QT += widgets CONFIG += c++11 TARGET = monitor TEMPLATE = app SOURCES += main.cpp mainwindow.cpp camera_thread.cpp \ process_thread.cpp database_thread.cpp HEADERS += mainwindow.h camera_thread.h \ process_thread.h database_thread.h LIBS += -lopencv_core -lopencv_imgproc -lopencv_imgcodecs -lv4l2 -lsqlite3LIBS 里的 -lopencv_core 要和你系统里实际装的版本对应，如果你装的是 OpenCV 4.x，这些库名都是对的；但如果是 3.x 时代的老环境，可能需要拆成 opencv_core3 之类的名字。还有个容易踩的坑：-lv4l2 是 V4L2 API 的库，但真正操作设备节点时，ioctl 系统调用在 libc 里就有，不需要额外链接；这个库主要是给 libv4l2 的转换函数用的。
3.3 启动即显示：最小闭环代码
先写一个能打开摄像头、显示画面的最小版本，把整条链路跑通，再往里面加检测和存储。
// main.cpp - 最简启动逻辑 #include <QApplication> #include "mainwindow.h" int main(int argc, char *argv[]) { QApplication a(argc, argv); MainWindow w; w.show(); return a.exec(); }MainWindow 构造函数里做三件事：初始化摄像头线程、连接信号槽、启动采集。这里先不贴完整实现，重点看信号槽的连接方式：采集线程的 frameReady(cv::Mat) 信号连到处理线程的 addFrame 槽，处理线程的 displayReady(QImage) 连到 MainWindow 的 updateFrame 槽。跨线程连接必须用 Qt::QueuedConnection，否则帧数据会在错误的线程里被访问。
// mainwindow.cpp 构造函数核心代码 cameraThread = new CameraThread(this); processThread = new ProcessThread(this); connect(cameraThread, &CameraThread::frameReady, processThread, &ProcessThread::addFrame, Qt::QueuedConnection); connect(processThread, &ProcessThread::displayReady, this, &MainWindow::updateFrame, Qt::QueuedConnection); cameraThread->start(); processThread->start();这段代码的关键在 QueuedConnection 上。如果不写这个参数，默认的 AutoConnection 在多线程环境下会自动切换成 QueuedConnection，看起来没问题，但一旦你把处理逻辑移到和 UI 同一个线程，AutoConnection 会退化成 DirectConnection，原来的异步队列没了，处理耗时直接堵住 UI 刷新。所以显式声明 QueuedConnection 是保证跨线程安全的最低要求。采集线程的 start 要放在信号槽连接之后，防止先跑起来的线程发信号时槽还没注册，丢掉最初几帧问题不大，但如果一开始就丢关键事件，排查起来很头痛。
3.4 看到画面后再加“退出清理”的规范姿势
程序退出是另一个高频崩盘点：直接关窗口，采集线程还阻塞在 read 或 mmap 上，线程对象被销毁，段错误就来了。规范做法是先停采集、再回收线程、最后退出应用。
// MainWindow 析构函数 ~MainWindow() { cameraThread->stop(); processThread->stop(); cameraThread->wait(); processThread->wait(); }stop 函数内部要做两件事：置 running 标志为 false，然后调用 QThread 的 quit 或直接唤醒阻塞中的读取操作。V4L2 的 read 调用在无帧时是阻塞的，要让它立刻退出，通常是在 stop 里调用 VIDIOC_STREAMOFF 停止采集，这样 read 会立刻返回错误码，线程就能跳出循环。只改标志位不关流，线程会在 read 上卡到永远，这是初学 QThread+V4L2 最常见的翻车点。
4. 把 V4L2 参数调到稳妥：mmap 缓冲区与像素格式的真问题
4.1 为什么选 mmap 而不是 read
read 方式每次调用要从内核态把一整帧数据拷贝到用户态缓冲区，一帧 640x480x2 字节（YUYV）大约 600KB，30fps 就是 18MB/s 的拷贝流量，CPU 占用高且延迟抖动大。mmap 方式是让内核把缓冲区映射到用户空间，采集线程拿到的是指针，少了拷贝这一步，延迟和 CPU 占用都明显下降。虽然第一次配置步骤多一点，但稳定性和性能都好得多，值得。
你还得知道 mmap 的额外约束：缓冲区数量至少要请求 4 个，只申请 2 个时部分驱动会表现异常，比如画面撕裂、帧率减半。常见驱动下 4 个缓冲区已经够用，再多不会提升性能，反而增加内存占用。
4.2 初始化序列的完整代码与每个 ioctl 的含意
V4L2 初始化的标准序列是：打开设备 → 查询能力 → 设置格式 → 请求缓冲区 → mmap → 入队所有缓冲区 → 开始采集。每一步对应一个 ioctl 调用，调用的顺序错了，驱动会直接报错。
int init_v4l2(const char *dev_path, int width, int height) { int fd = open(dev_path, O_RDWR); struct v4l2_capability cap; ioctl(fd, VIDIOC_QUERYCAP, &cap); // 确认设备是视频采集设备 struct v4l2_format fmt; memset(&fmt, 0, sizeof(fmt)); fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; fmt.fmt.pix.width = width; fmt.fmt.pix.height = height; fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; fmt.fmt.pix.field = V4L2_FIELD_NONE; ioctl(fd, VIDIOC_S_FMT, &fmt); // 设置采集格式 return fd; }这里面最深的坑是 VIDIOC_S_FMT 并不保证设置成功。驱动可能默默修改你的分辨率或像素格式，比如你请求 1280x720 YUYV，驱动实际给的是 640x480 YUYV，因为它内部做了限制。所以 S_FMT 之后必须再调一次 VIDIOC_G_FMT 读回实际格式，如果和请求不一致，后面的代码全部基于错误假设运行，画面错乱、大小不对都是这个原因。我见过太多人在这里摔跟头：S_FMT 设置完成后直接进入 REQBUFS，结果驱动返回的缓冲区大小和预期不符，mmap 出来的图像全是花的。
4.3 循环取帧的正确姿势：一分钟也不能漏的处理框架
取帧循环不能用 read，要用 DQBUF 从队列里拿一个缓冲区，处理完再 QBUF 还回去。这个“取出-返还”的模型是 V4L2 性能和稳定性的核心。
// 采集线程主循环 while (running) { struct v4l2_buffer buf; memset(&buf, 0, sizeof(buf)); buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory = V4L2_MEMORY_MMAP; ioctl(fd, VIDIOC_DQBUF, &buf); // 拿出一个已填充的缓冲区 // 处理 buf.index 指向的帧 process_frame(buffers[buf.index].start, buffers[buf.index].length); ioctl(fd, VIDIOC_QBUF, &buf); // 用完还回去，驱动才能重新填充 }DQBUF 在无帧时会阻塞，这是正常的。但有个边界情况：如果你调了 VIDIOC_STREAMOFF，DQBUF 会立刻返回 EINVAL 错误。所以 stop 函数里要先 STREAMOFF，再发信号唤醒线程退出，顺序反了线程就会卡死在 DQBUF 上。
缓冲区队列还有一个隐藏性能点：DQBUF 返回的 buf.field 字段会告诉你这是奇偶场还是逐行帧。USB 摄像头基本都是渐进扫描，V4L2_FIELD_NONE 才正常；如果出现 V4L2_FIELD_INTERLACED，说明你接到的是模拟采集卡，这时画面会有锯齿，需要在 OpenCV 里做去隔行处理。
4.4 YUYV 到 BGR 的颜色转换与内存对齐问题
V4L2 出来的 YUYV 数据是紧凑排列的，但 OpenCV 的 cv::Mat 有行对齐要求，默认 4 字节对齐。直接 Mat(height, width, CV_8UC2, raw_ptr) 构造出来的视图，行大小是 width*2，和 OpenCV 期望的行步长可能不一致，cvtColor 时会读到错位数据，颜色发绿或图像错位就来了。
// 正确的 YUYV 转 BGR 做法 cv::Mat yuyv(height, width, CV_8UC2, raw_ptr); cv::Mat bgr; cv::cvtColor(yuyv, bgr, cv::COLOR_YUV2BGR_YUYV);如果你的摄像头支持 V4L2_PIX_FMT_YUV420P，用 COLOR_YUV2BGR_I420 转换比 YUYV 的转换更快，因为 YUV420 的数据量比 YUYV 少四分之一，内存拷贝量更小。但要注意，不是所有摄像头都支持 YUV420P，必须在 3.1 节列格式那一步就确认。
5. 综合应用的最优分割：运动检测、Qt 显示与 SQLite 存储的正确拼接
5.1 开源方案中常见的“检测+存储”对称设计
在这个系统里，检测和存储是两个进程，也有人在一个进程里用两个线程实现。对称设计的好处是逻辑非常清晰，两边都可以独立替换，这篇方案里比较倾向用两线程解耦：处理线程专心做帧分析，数据库线程专心做磁盘写入，中间用 Qt 信号连接。
实际做下来，两线程和两进程的区别在于故障隔离：线程方案好写、资源开销小，但检测线程卡死会拖垮整个进程；进程方案要用 IPC 传帧，帧率高了带宽压力很大。毕设场景选线程就够了，代码量小一倍，踩坑也少。
5.2 帧差法运动检测：参数到底怎么设
帧差法是计算量最小的运动检测方案，适合硬件资源有限的场景（比如树莓派或旧笔记本）。原理是把当前帧和上一帧做差，取绝对值，然后阈值化、腐蚀膨胀、找轮廓。
// 帧差法检测 + Qt 显示 + SQLite 联动 void ProcessThread::addFrame(const cv::Mat &frame) { cv::Mat gray, diff, thresh; cv::cvtColor(frame, gray, cv::COLOR_BGR2GRAY); if (!prevGray.empty()) { cv::absdiff(gray, prevGray, diff); cv::threshold(diff, thresh, 30, 255, cv::THRESH_BINARY); cv::erode(thresh, thresh, cv::Mat()); cv::dilate(thresh, thresh, cv::Mat()); std::vector<std::vector<cv::Point>> contours; cv::findContours(thresh, contours, cv::RETR_EXTERNAL, cv::CHAIN_APPROX_SIMPLE); // 面积过滤，太小的轮廓是噪点 for (auto &c : contours) { double area = cv::contourArea(c); if (area > 500) { cv::Rect box = cv::boundingRect(c); cv::rectangle(frame, box, cv::Scalar(0, 0, 255), 2); // 记录告警 emit alarmTriggered(QDateTime::currentDateTime().toString(), box.x, box.y); } } } prevGray = gray.clone(); emit displayReady(QImage(frame.data, frame.cols, frame.rows, frame.step, QImage::Format_BGR888).copy()); }几个参数的坑要讲清楚：
threshold 的 30 是灰度差阈值。光线稳定的室内，30 已经能过滤大部分噪点；如果画面里有很多阴影，调到 50 以上，否则影子移动就能触发告警。area 500 的判断阈值是像素面积，640x480 下这个值合适，1080p 下要按比例放大到 3000 左右，因为同样一个物体在高分辨率下轮廓面积大好几倍，不放大阈值会误报。
prevGray 的 clone 是必须的。如果直接 prevGray = gray，两个 Mat 共享同一块内存，下一帧的 cvtColor 会原地覆盖 gray，而 prevGray 拿到的其实是已经改了的这一帧，帧差永远为 0，检测直接失效。这个 bug 我见过无数人踩，症状是画面正常、阈值也调了，但就是检测不到任何运动，排查到最后看 Mat 头信息才反应过来。
5.3 Qt 显示的性能边界：QImage 的零拷贝构造与 copy 的代价
上面代码里 emit displayReady 时用到了 QImage(...).copy()。copy 的作用是把 cv::Mat 的数据拷贝到 QImage 管理的缓冲区里，这么做的原因是 Mat 的内存在处理线程下一次循环时会被覆盖，而 QImage 是隐式共享的，如果不 copy，UI 线程拿到的 QImage 指向的内存可能已经在写新帧了，画面会出现闪烁或撕裂。
代价是每次显示都多一次整帧拷贝。640x480x3 的 RGB888 一帧约 900KB，30fps 下就是 27MB/s 的拷贝量，现代 CPU 扛得住，但你要知道这个开销在哪里。如果帧率要求更高，可以提前用 QImage 的构造方式直接基于 Mat 数据创建，然后用 QPixmap 的 fromImage 转换，这样省掉一次中间拷贝，但代码会多一层生命周期管理，风险也相应增加。对毕设来说，copy 是稳妥的选择。
5.4 SQLite 的存储表结构与批量提交策略
告警记录表设计要轻、要能支撑查询。时间戳存 TEXT（ISO 格式），检测类型存 INTEGER 或 TEXT 都可以，抓图路径存 TEXT，外加一个自增主键。不要索引建太多，告警表一天几千条记录，全表扫描都够快。
// 数据库线程批量写入 void DatabaseThread::run() { QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE", "alert_conn"); db.setDatabaseName("/data/monitor.db"); db.open(); QSqlQuery query(db); QList<AlertRecord> buffer; QElapsedTimer timer; timer.start(); while (running) { // 从队列取数据 buffer = alertQueue.popAll(); if (buffer.isEmpty()) { msleep(50); continue; } db.transaction(); foreach (auto rec, buffer) { query.prepare("INSERT INTO alerts(time, type, image_path, x, y) " "VALUES(?, ?, ?, ?, ?)"); query.addBindValue(rec.time); query.addBindValue(rec.type); query.addBindValue(rec.imagePath); query.addBindValue(rec.x); query.addBindValue(rec.y); query.exec(); } db.commit(); buffer.clear(); } }这个实现里有三个关键细节。第一，数据库连接必须是线程内创建的，不能在主线程创建好连接然后传给子线程用，SQLite 驱动在跨线程使用连接时会有未定义行为，现象时好时坏，最难排查。第二，QSqlDatabase::addDatabase 的第二个参数是连接名，每个线程要有独立的连接名，默认连接名是分号开头，两个线程共用时第二个会拿不到连接。第三，事务提交周期由两个条件触发：攒够一定条数或时间超时，代码里用了 msleep(50) 作为兜底，50ms 内没有新告警就继续睡，有的话立即处理，这个组合保证了低延迟和高吞吐。
这里我用的是 50ms 的轮询配合事务批量提交，比单条 INSERT 性能稳定性高出不止一个量级。对毕设场景来说，这个数据库线程的逻辑就足够健壮了，不需要再引入 Redis 或消息队列，答辩时能讲清楚“批量提交降低磁盘 fsync 频率”这个点就是加分项。
6. 常见问题与避坑指南：采集、显示、存储的 5 个高频翻车点
6.1 摄像头打开失败：设备权限与占用冲突
现象：open("/dev/video0") 返回 -1，perror 显示 Permission denied 或 Device or resource busy。
原因排查：前者是当前用户不在 video 组，后者是摄像头被其他进程占用了，比如 Cheese 或另一个调试程序还开着设备。还有可能是设备节点本身不存在，你的摄像头插在了 USB 3.0 口而驱动把它识别成了 video1 而不是 video0。解决方式：临时用 sudo chmod 666 /dev/video0 验证权限问题，长期方案是把当前用户加入 video 组；占用问题用 fuser -v /dev/video0 找到占用进程并杀掉；设备节点不对就用 v4l2-ctl --list-devices 看摄像头映射到哪个节点，代码里改成参数可配置就行。
6.2 画面全绿或颜色错乱：YUYV 数据没正确转 BGR
现象：画面能显示但颜色整体偏绿、红蓝通道互换，或者出现明显的横向条纹。
原因：像素格式设置和转换函数不匹配。最常见的是 V4L2 实际返回的是 MJPG，但代码里按 YUYV 转 BGR 处理，解出来的数据自然全是乱的。还有一种情况是 V4L2_PIX_FMT_YUYV 和 OpenCV 的 COLOR_YUV2BGR_YUYV 匹配没错，但色彩空间标准不一致，部分摄像头实现的 YUYV 微有偏差。解决方式：S_FMT 后打印 driver 里实际的 fmt.fmt.pix.pixelformat 值，和代码里的常量比对；转换时换一下 COLOR_YUV2RGB_YUYV 试试，如果 RGB 正常说明色空间偏置有问题，在预处理里做通道交换即可。
6.3 SQLite 数据库文件无限膨胀：忘了清理抓拍图片
现象：运行几天后磁盘被占满，数据库文件本身只有几 MB，但同目录下的 images 文件夹已经几个 GB。
原因：告警记录只存了图片路径，但项目里没有实现图片文件的定期清理。每触发一次告警就存一张 JPG，一天几百次告警就是几百张照片，积累速度远超预期。解决方式：加一个定时清理任务，保留最近 7 天的抓拍图片，删除更早的文件，同时把数据库里对应的记录一并清掉。可以用 Qt 的 QTimer 每天触发一次，遍历 images 目录，用文件的 lastModified 判断是否过期。
6.4 UI 卡顿但 CPU 不高：帧队列堆积问题
现象：实时画面延迟越来越严重，像在看慢放，CPU 占用却只有 20% 左右。
原因：处理线程处理速度跟不上采集线程的帧率，帧队列越长延迟越大，但处理线程已经满负荷在工作，所以 CPU 不会飙到 100%。本质上是队列积压导致的内存堆积和时间延迟，不是信号阻塞。解决方式：在采集线程里做帧率控制，用 QTimer 的 interval 控制采集频率而不是靠驱动自由跑；同时给帧队列加上限，超过 5 帧就丢弃新帧，保证处理线程永远追赶的是最近的数据而不是积压的老数据。这个丢帧策略在监控系统里完全可行，因为连续两帧画面差异极小，丢一帧无感知。
6.5 运动检测在夜间或灯光闪烁时疯狂误报：灵敏度要分级
现象：白天正常，到了傍晚或灯光下，误报率飙升，几乎每隔几秒就告警一次。
原因：帧差法对光照变化极其敏感，灯的频闪、阴影移动、显示器屏幕刷新都会造成大范围像素差。阈值固定在一个值上不可能同时适应白天和夜间。解决方式：把检测灵敏度做成动态的，白天用高阈值，夜间用低阈值，切换条件可以根据灰度图的全图平均亮度来判断。更进一步的方案是用背景减除代替帧差法，MOG2 背景模型对光照变化鲁棒得多，代价是内存更高、每帧耗时多一点，在 640x480 下完全可接受。
7. 进阶验证与调试技巧：把系统调到稳定运行的三个关键习惯
系统能跑通只是及格线，稳定运行才算真的做完。我建议你做三件事来验证系统的可靠性，这三件事在答辩和实践里都能直接派上用场。
第一，连续运行 72 小时，观察内存和线程状态。用 htop 看进程内存变化，应该是一条水平的直线，如果有缓慢爬升，说明某个地方在泄漏内存，最常见的原因是 Mat 在跨线程传递时没有被正确释放，或者队列的 pop 操作没有 delete 已经取出的对象。再用 top 看三个线程的 CPU 占用，采集线程和处理线程应该在 20%-50% 之间平稳波动，数据库线程平时应该是 0%，一到批量写入就短暂冲到 60% 以上，这是合理的。
第二，验证告警时间戳精度。在界面上放一个毫秒级时钟，肉眼对比实际触发动作和告警记录的 time 字段，偏差应该在 100ms 以内。如果偏差超过 300ms，说明帧队列里有积压，按 6.4 的排查方法走一遍。这个细微的参数调整需要启动参数配置或者条件编译，让演示时可以根据现场光源情况切换灵敏度。
第三，数据库性能退化测试。往表里插入 1 万条记录，然后查询最近一小时的数据，SQLite 的响应时间应该仍在毫秒级。如果超过 1 秒，检查是否缺索引，或者表结构里有无用的大字段。另外，定期跑 VACUUM 回收数据库碎片，在监控系统这种高频insert+pdelete混合场景里，文件体积会虚高，VACUUM 能恢复正常状态。
做完这些，你就有底气回答评审老师“系统稳不稳定”的问题了。最后说一个我自己的血泪习惯：每次改完 V4L2 相关代码，先在命令行用 v4l2-ctl --set-fmt-video=width=640,height=480,pixelformat=YUYV 手动设置一次，再用程序打开，能快速区分是驱动问题还是代码问题。希望帮到你。
本文还有配套的精品资源，点击获取
