简介这是一份基于Qt编写的Windows屏幕录制完整C工程源码面向有基础、想学习桌面采集与视频封装的中级开发者解决自定义区域录屏、帧率控制与avi文件生成等常见需求。压缩包共12个文件包含5个cpp源文件、4个头文件、1个界面ui文件以及pro工程文件等整体仅26KB结构精简便于阅读与二次修改。已有3407人学习下载。工程亮点包括支持最高1080P/24帧高清录制、特定区域截取、质量与帧率可调采用多线程分离“桌面截屏”与“文件保存”提升效率并利用Windows设备DC完成快速抓屏还实现了每1分钟自动分割avi文件的功能。通过该工程可快速掌握Win32屏幕捕获、多线程协作、avi格式封装及Qt界面整合技巧对开发录屏工具或理解视频处理流程很有帮助。1. 用 Qt 在 Windows 下做屏幕录制从源码包到可复现的录屏工具手上有教学视频要录、软件演示要抓、或者要做一个带录屏功能的小工具时很多人第一反应是找现成软件。但真到了要定制帧率、要指定区域、要控制文件体积的时候现成软件反而绑手绑脚。这份 Qt 实现的 Windows 屏幕录制源码包走的是完全不同的路线它用 Windows 自带的设备 DC 抓屏配合双线程把截屏和写盘拆开实现了最高 1080P、24 帧率的 AVI 录制还带了自动分片、质量和帧率可调这几个实用功能。对想在公司内部做工具、或者正在学 Qt 多媒体开发的工程师来说这份源码的价值不光是能录屏而是把一套「抓帧—压缩—写盘」的完整链路摊开给你看。适合两类人一是新手想弄明白三大基础模块怎么配合二是熟手想快速改造出一个带区域录制的内部工具。下面我从代码结构拆起逐步讲清楚每条线程、每个参数和每个坑。2. 核心架构DC 抓屏与双线程协作性能瓶颈到底卡在哪2.1 为什么用设备 DC 而不是 DirectX 或 GDI 的 BitBlt 变体在 Windows 上抓屏幕常见方案有 DirectX Desktop Duplication、Windows Graphics Capture以及最朴素的 GetDC(NULL) BitBlt。这份源码选择的是后者即「用 Windows 自带的设备 DC 来截取桌面」。这个选择的理由很实际Desktop Duplication 需要处理 GPU 显存同步代码复杂度高Graphics Capture 在旧系统上兼容性一般。而 GetDC 拿到的设备上下文可以直接配合 BitBlt 把像素拷出来代码路径短、依赖少在当时的 Qt 5 环境下最容易跑通。代价是性能受 GDI 限制帧率上限就落在 24fps 左右。抓帧的具体操作是这样的先 GetDC(NULL) 拿到整个屏幕的设备上下文再创建一个兼容内存 DC 和位图用 BitBlt 把屏幕像素复制到内存位图里。这个内存位图的数据最终会被交给编码线程处理。注意这里的截屏操作发生在 grabscreenthread 线程里它只负责「把像素抓下来放进缓冲区」不负责写文件。这一层解耦非常关键——后续改动分辨率或者换抓屏方案时mainwindow 里的逻辑完全不用动。// grabscreenthread.cpp 核心抓屏伪代码简化自源码 void GrabScreenThread::run() { // 1. 获取屏幕设备上下文 HDC screenDC GetDC(NULL); // 2. 创建兼容内存 DC HDC memDC CreateCompatibleDC(screenDC); // 3. 创建兼容位图宽度和高度由外部传入 HBITMAP bmp CreateCompatibleBitmap(screenDC, width, height); // 4. 每次循环把屏幕像素拷到内存位图 while (m_isRunning) { BitBlt(memDC, 0, 0, width, height, screenDC, offsetX, offsetY, SRCCOPY); // 5. 把位图数据打包成 QImage 或原始 RGB 交给缓冲区 emit frameCaptured(imageData); QThread::msleep(frameIntervalMs); // 按帧率换算的时间间隔 } // 6. 清理资源 DeleteObject(bmp); DeleteDC(memDC); ReleaseDC(NULL, screenDC); }参数说明width 和 height 对应录制区域的宽高区域录制就是靠改这两个值加 offsetX/offsetY 实现的。frameIntervalMs 由 1000 / 帧率算出比如 24 帧就是约 42ms。代码里真正要注意的是 CreateCompatibleBitmap 的位图格式默认是屏幕同格式在 RGB 模式下直接取像素没问题但如果屏幕是 16 位色深后续编码就要做格式转换。2.2 加工线程与缓冲队列为什么保存要单独拆一个线程抓帧线程把数据丢进缓冲区后processorthread 线程立即接手。这个线程负责两件事一是把原始像素压缩成 JPEG 帧二是写入 AVI 容器。为什么必须拆开因为磁盘写入是不稳定操作机械硬盘追求响应延迟差异极大如果抓帧和写入都在一个线程里顺序执行一旦磁盘慢截屏就会卡住帧率直接掉下来。拆成两个线程后抓帧线程只管按帧率把数据塞进队列写盘线程尽力去消费即使磁盘跟不上也只是队列积压不会反过来拖慢截屏。这里有一个缓冲上限的隐性问题。如果内存里攒的帧超过了队列容量要么丢帧要么阻塞等待。这份源码的处理偏向简单可靠队列不设严格上限依赖结束录制后的滞留帧回放。摘要里提到的「如果存图速度比截屏速度慢点击结束按钮后会需要等待一定时间」就是线程设计带来的直接行为——结束信号发出后processor 线程还要把队列里剩余的数据继续消费完消费时长取决于积压了多少帧。2.3 AVI 封装与自动分割133 行代码的 avilib 做了什么源码里出现的 avilib.cpp 和 avilib.h是一个轻量级 AVI 写入库只有一百多行代码却能干完整套 AVI 文件头写入、帧追加、文件头回填的活。AVI 格式本身不复杂关键是帧索引的位置——写完所有帧之后必须回到文件头把时长和帧数更新进去否则播放器会认为文件损坏。avilib 在关闭文件时做这个事所以录制的 AVI 在录制中途断电时大概率无法播放这不算 bug而是该库的设计边界。自动分割的文件逻辑值得注意在 24 帧每秒的设置下每个 AVI 文件时长 1 分钟对应 1440 帧。实现方法不复杂processorthread 内部维护一个帧计数累计到设定值就关掉当前文件、创建新文件继续写。但分割点的选择有讲究如果分割恰好发生在关键帧之间会导致视频尾部有明显的停顿感。这个资源在分割后不做关键帧同步前缀这是一个可以通过扩展代码解决的点。// processorthread.cpp 帧计数与自动分割核心逻辑 void ProcessorThread::run() { AVI* avi nullptr; int frameCount 0; int splitFrameLimit m_fps * 60; // 24fps * 60s 1440 帧 while (m_isRunning) { QImage frame m_bufferDequeue(); // 从队列取帧 if (frame.isNull()) continue; // 1. 每隔 splitFrameLimit 帧关闭旧文件并创建新文件 if (frameCount splitFrameLimit) { AVI_close(avi); QString newFilePath generateFileNameWithTimestamp(); avi AVI_open_write_file(newFilePath.toLocal8Bit()); frameCount 0; } // 2. 将 QImage 转为 JPEG 字节数组 QByteArray jpegData; QBuffer buffer(jpegData); buffer.open(QIODevice::WriteOnly); frame.save(buffer, JPG, m_quality); // 3. 写入 AVI AVI_write_frame(avi, jpegData.constData(), jpegData.size(), 0); frameCount; } if (avi) AVI_close(avi); }参数说明m_quality 对应摘要中「录屏质量修改」是 QImage::save 的 JPEG 压缩质量参数范围 0 到 100越高质量越高、文件越大。m_fps 对应帧率设置工程中只开放到 24。splitFrameLimit 用帧数做单位而不是秒好处是逻辑简单坏处是 CPU 性能波动导致实际帧率掉到 20fps 时分割的文件时长会拉长到 72 秒这是它本身的误差来源。3. 代码级拆解mainwindow、抓帧线程、处理线程各管什么信号槽怎么接3.1 mainwindow界面控制、参数回落与文件命名规则mainwindow.ui 和 mainwindow.cpp 构成了整个工具的控制层。从工程文件推断界面上应该有开始录制、结束录制、帧率选择、质量滑条、区域选择这几组控件。mainwindow 的职责是把这些控件的值收集起来转换成线程参数并在结束录制后做收尾。源码里一个典型的做法是用户在界面设置好参数点开始时mainwindow 先读取当前屏幕尺寸和所选区域然后实例化 GrabScreenThread 和 ProcessorThread把参数传进去启动线程最后把开始按钮 disable 掉。文件命名走时间戳方案。每次开始录制一个文件的名称形如 yyyyMMdd_HHmmss.avi由 mainwindow 生成后传给处理线程。自动分割时新文件名会在原本时间戳基础上加 _001、_002 这样的序号这个逻辑在上述代码里我为了简洁省略了。实践中的经验是文件名不要包含中文或空格否则部分播放器对 AVI 的解析会出问题这个和 Qt 本身无关是多媒体播放器的通病。3.2 抓帧线程的局部刷新逻辑怎样实现特定屏幕区域录制摘要里明确支持「特定屏幕区域录制」这在抓帧线程里的实现方式有两种可能源码用的是「裁剪 BitBlt 区域」还是「全屏截图后裁剪图像」需要看 grabScreenThread.cpp 的具体写法。常规做法是在 BitBlt 前直接指定源区域坐标这样拷出来的位图天然就是目标区域大小不用额外裁剪效率最高。// 区域录制的 BitBlt 参数示意 int x m_region.x(); // 区域左上角 X int y m_region.y(); // 区域左上角 Y int w m_region.width(); // 区域宽 int h m_region.height(); // 区域高 BitBlt(memDC, 0, 0, w, h, screenDC, x, y, SRCCOPY);参数说明把 BitBlt 的源坐标从 (0,0) 换成 (x,y)同时把拷贝宽度高度从全屏换成区域宽高就完成了区域截取。这种做法与先截全屏再裁剪相比少了一次大尺寸像素的内存拷贝CPU 开销更小。实际从文章描述来看「通过使用 windows 自带的设备 DC 来截取桌面提高截屏效率」可以确认抓帧效率的核心在于直接操作 DC而不是后期裁剪。对用户来说区域录制的意义在于录出来的视频体积小、聚焦内容后期不用再剪。3.3 质量与帧率的联动关系为什么质量越高文件越大质量参数直接作用于 JPEG 编码阶段。质量越高每帧 JPEG 尺寸越大但这里有一个易被忽略的事实JPEG 是帧内编码每帧独立压缩所以帧率几乎影响输出文件总大小——同样是 60 秒 1080P 视频24 帧比 12 帧的文件大一倍。摘要里那句「质量越高录制单位时间生成的 avi 文件越大」说的就是这个。很多人调整录屏质量出现「为什么文件还是这么大」的疑惑原因就是没有意识到帧率对文件大小的线性放大作用。另一个关联在编码延迟上。质量设到 100 时1080P 的单帧 JPEG 编码在普通 CPU 上耗时可能超过 100ms这时候如果帧率还是 24处理线程每秒需要编码 24 帧理想耗时要 2.4 秒远超实际可用的 1 秒时间片于是队列积压、录像结束时等待时间拉长。所以质量写 80 到 90 之间的性价比是最高的画面的肉眼损失很小但编码时间可以缩短一半以上。3.4 线程通信模型信号槽、队列还是共享内存从源码文件结构看抓帧线程和处理线程之间传递图像数据用队列和信号槽都行。用 Qt 原生信号槽传递 QImage 有一个隐患QImage 属于可重入类型跨线程传递走的是队列连接会先拷贝再排队一个 1080P 的 QImage 数据量约 8MB24 帧每秒就是约 200MB 的拷贝带宽这还没算编码处理。如果源码里直接 emit frameCaptured(imageData)性能开销会很大而用显式的队列比如 QQueue 加 QMutex传递指针或者传递引用能省掉一次深拷贝。这个资源能在「普通电脑上 1080P 24 帧」跑起来说明作者大概率直接用原始数据RGB24 或者 YUV进队列而不是 QImage。我的建议是不要贸然改成信号槽传 QImage实测这个改动会直接让帧率掉到 12 以下这不是玄学是拷贝带宽占满了。3.5 文件清单快速对照每个文件在工程里扮演什么角色文件角色关键函数或职责mainwindow.ui界面布局录制按钮、质量滑条、帧率选择、区域选择mainwindow.cpp/h控制逻辑参数收集、线程启停、状态切换grabscreenthread.cpp/h抓帧线程GetDC、BitBlt、按帧率定时抓屏processorthread.cpp/h处理线程队列消费、JPEG 编码、AVI 写入、自动分割avilib.cpp/hAVI 封装AVI 文件头写入、帧追加、文件头更新screenshot.proQt 工程文件qmake 配置、源文件列表、库链接这个清单的意义在于快速定位改动点想改抓屏效率只看 grabscreenthread想改文件分割策略只看 processorthread想改界面参数只看 mainwindow。拿到源码包后建议先对照这个清单过一遍把每个文件的编译顺序理顺再开始动手改。4. 编译与运行从下载到跑通全流程绕开 Qt 环境配置的那些坑4.1 环境选择Qt 5.15.2、MSVC2019 64 位与 Windows SDK 的匹配从工程文件中的 .pro.user 路径判断这个资源原本是在 Qt 5.15.2 msvc2019_64 工具链下开发的。Windows 上 Qt 的编译链选择直接决定成败MSVC 套件需要你在系统中安装对应的 Visual Studio 2019 组件和 Windows SDKMinGW 套件则是另一套环境。如果你是新手建议装和你手上源码最接近的组合——Qt 5.15.2 的 msvc2019_64 套件配合 VS2019 的 C 桌面开发组件。注意 Qt 5.15.2 是开源版的最后一代提供离线包的版本后续再往上就要走在线安装。如果安装时选了 MinGW 或者 Qt 6.x打开 .pro 文件大概率会重新构建而你可能会遇到:-1: error: dependent ..\..\..\qt\5.15.2\msvc2019_64\include\qtwidgets ...这类报错这个报错本质是 .pro.user 文件里记录的旧路径失效删掉 .pro.user 让 Qt Creator 重新解析 .pro 文件即可。4.2 三个开启步骤Pro 文件检查、qmake 构建、release 运行拿到源码包后不要急着双击 .pro先做三件事检查。第一确认 screenshot.pro 里 QT 模块列表包含 widgets 和 multimedia如果源码里用了 QBuffer、QImage 等core 和 gui 是自动带上的。第二确认源码里没有使用 Qt 5.15 之后才引入的接口比如 QImageReader 的某些新重载如果有需要降级适配。第三检查代码里的 Windows 头文件是否显式包含了 windows.h这个文件是 GetDC、BitBlt 等 Windows API 的声明来源缺了会在编译时报一堆 C2065 未声明的错误。以下是一个典型的全流程命令# 1. 在 Qt 终端或命令提示符中先切换到工程目录 cd /d D:\code\screenshot # 2. 用 qmake 生成 Makefile qmake screenshot.pro -spec win32-msvc CONFIGrelease # 参数说明-spec 指定编译套件win32-msvc 对应 MSVC 编译链 # CONFIGrelease 直接切到发布版避免 debug 效率问题 # 3. 用 nmake 编译 nmake # 如果 nmake 不是系统命令先调用 vcvarsall.bat 进入 VS 环境逻辑说明这个流程把编译设置一次性固定。如果用 Qt Creator 图形界面通常在「项目 → 构建套件」里选择 msvc2019_64构建步骤选 Release 即可。注意编译完成后生成的可执行文件需要保证 Qt 的 DLL 能被找到最简单的办法是把 Qt 的 bin 目录加进 PATH或者编译时让 windeployqt 自动拷贝依赖 DLL。4.3 为什么强调 release 模式debug 与 release 的帧率差异很大项目摘要里写得很直白「建议使用 release 模式运行 因为 debug 模式下 运行效率会降低 导致保存的 avi 文件实际帧率和你设置的帧率不同 播放的时候感觉就像在快进一样」。这里解释一下原因debug 编译的代码带大量调试符号和运行时检查循环里有额外的边界验证和内存检查截屏加编码这段高频路径的性能会明显下降。同样的 24 帧每秒设定release 模式能稳定跑出来debug 可能实际只有 15 帧——而截屏线程仍按 24 帧的频率投递数据队列就会积压处理线程消费不掉录出的视频按正确的 24fps 时间戳播放时画面动作看起来就像加速了播放时长比真实的录制时段短。这个坑极其隐蔽。很多人录完视频发现播放速度不对先怀疑是不是播放器问题再怀疑是不是代码写错实际上就是编译模式的问题。我的习惯是任何涉及高频循环的 Qt 程序调试的时候用 debug 加日志打印但性能验证和最终交付一定用 release 加外部工具测帧率。4.4 运行参数与日志观察如何确认录制确实在跑程序运行后先在任务管理器观察 CPU 占用。抓屏加编码是个 CPU 密集操作1080P 24 帧条件下 CPU 占用率会在 30% 到 60% 之间波动具体取决于你的机器配置。如果 CPU 占用率恒定在 5% 以下说明录制根本没启动检查线程是不是没有调用 start()。如果 CPU 占用高但录出的文件是黑的检查 BitBlt 的源坐标区域是否合法区域超出屏幕边界会把屏幕外的黑色区域录进去这个是区域录制的常见误操作。录制完成后验证文件不要只看能不能播放。用 PotPlayer 或 VLC 逐帧播放看尾部是否有花屏或者卡顿。花屏多半是 AVI 文件头里的帧索引不正确avilib 在关闭时如果被强制中断索引就写不进去。这属于这个库的边界问题下文避坑章会展开。5. 避坑指南帧率虚标、区域黑屏、文件损坏等 5 个真实踩坑记录5.1 播放时画面快进实际录了 60 秒的视频播放只有 40 秒现象设置 24 帧每秒录制录完一段素材后播放视频播放速度明显比真实动作快总时长也短了。原因录制过程中实际保存到 AVI 里的帧数少于理论值。截屏线程按 24 帧频率投递数据但处理线程来不及消费导致队列溢出或者有帧被丢弃。AVI 文件头里记录的帧数按实际写入帧数算播放器按这个帧数和固定时间基播放于是产生了加速效果。debug 模式下最容易触发release 下如果磁盘较差也会出现。解决先确认用的是 release 模式编译运行。然后降低帧率到 15 帧试试如果问题消失说明磁盘或 CPU 带不动 24 帧。还有一种可能你改了质量参数后发现这个问题那说明编码耗时过高把质量控制在 85 以下。如果以上都不行把抓屏线程里的QThread::msleep(42)改成msleep(50)主动放慢抓帧节奏让处理线程有喘息空间。5.2 录制特定屏幕区域时视频内容是黑的或者只有半边有画面现象区域录制选项选中某个屏幕局部后录出来的 AVI 文件大部分是黑色偶尔有些残影。原因BitBlt 的源区域坐标计算错误。比如屏幕缩放比例不是 100%Windows 的 DPI 缩放就会让逻辑坐标和物理像素不匹配——你选中的区域在逻辑坐标上是 (100,100) 到 (500,400)但物理屏幕上实际内容的位置因为缩放偏移了拷出来的区域不对大部分落在屏幕外面就是黑的。另一个原因你把 offsetX/offsetY 设置成负数BitBlt 会直接失败不再画出内容。解决在 mainwindow 里获取区域坐标时用devicePixelRatioF()乘以逻辑坐标把区域值换算成物理像素。核心代码可以写成这样qreal dpr screen-devicePixelRatio(); int physicalX qRound(m_region.x() * dpr); int physicalY qRound(m_region.y() * dpr); int physicalW qRound(m_region.width() * dpr); int physicalH qRound(m_region.height() * dpr); // 然后把 physicalX/Y/W/H 传给 GrabScreenThread参数说明devicePixelRatio 在 100% 缩放下是 1在 150% 缩放是 1.5在 200% 缩放是 2。不乘这个系数高分屏下区域必然偏。这里也建议把 Git 仓库里的代码改成全屏录制时用一个独立开关让全屏录制不受 DPI 影响。5.3 点击结束录制后界面卡死 5 到 15 秒才弹文件现象录了 10 分钟的视频点击结束按钮后程序失去响应一会儿后恢复正常录像文件正常生成。原因队列里还攒着几百帧等待编码和写盘。结束信号发出后抓帧线程停止投递但处理线程要消费完所有滞留帧才能关闭 AVI 文件这段时间的长短取决于积压的数据量。磁盘写入快、帧率设置合理的机器滞留时间几乎为零机械硬盘加 24 帧录制滞留十几秒很正常。解决这不是死锁不用改逻辑。如果想优化体验可以在界面上加一个「正在处理剩余帧请稍候」的提示或者在处理器线程里加一个drainFrames()方法专门消费剩余帧。最直接的办法是降低录制参数不要同时开最高质量和最高帧率。血泪经验录重要内容前先录个 30 秒测试片段确认结束等待时间在可接受范围再去录正式的内容。5.4 录制中途断电或程序崩溃生成的文件无法播放现象录制过程中程序崩溃或电脑被强制关机重新打开后那个 AVI 文件拖进播放器提示损坏。原因AVI 的文件头需要等所有帧写完后才能回填帧索引avilib 在 AVI_close 时才做这个操作。如果进程在 AVI_close 之前被杀掉文件头里的帧数和文件大小还是初始值播放器无法正确解析。这不是这个资源的独有缺陷几乎所有轻量级 AVI 写入库都有同样的脆弱性。解决从架构层面说应该周期性回写文件头。avilib 没有这个接口需要自己改代码——最简单的做法是每写 100 帧就临时跳到文件头更新一次帧数和文件大小再跳回文件尾部继续写。如果你不想改这个库另一个方案是录制进程中监听系统的关机或注销消息在收到消息时强制走一遍关闭流程。5.5 编译报错 dependent 路径不存在清理 .pro.user 也没用现象打开 .pro 文件后 Qt Creator 报:-1: error: dependent ..\..\..\..\..\..\qt\5.15.2\msvc2019_64\include\qtwidgets 不存在清理 .pro.user 重开工程仍然报同样的错。原因这个错误信息的本质是 qmake 生成 Makefile 时引用了一个不存在或不完整的 Qt 安装路径。通常是对应套件的 Qt 版本没装全比如只装了 Sources 包没装编译好的库文件或者路径里有中文导致解析异常。解决先确认机器上 Qt 5.15.2 msvc2019_64 套件确实存在且路径正确不行就换成 Qt 6.x 套件重新打开工程。如果必须留在 5.15.2可以把 .pro 文件里的QT widgets multimedia换成更基础的组合消除对多媒体模块的依赖然后在自己工程里额外引入需要的头文件。这里要注意改动 .pro 文件后执行 qmake 重新构建的快捷键是 CtrlShiftB 或qmake nmakeQt Creator 有时候不会自动重新解析需要手动触发。6. 进阶技巧验证帧率准确性、开启更高帧率以及给录屏工具加上自动命名和音频6.1 客观验证录制的帧率是否达标很多人在这个点翻车录完感觉视频流畅度不对却说不出哪里不对。最可信的验证方式不是肉眼而是数帧。用 PotPlayer 打开视频逐帧步进数 10 秒内有几帧。如果设置 24 帧10 秒应该有 240 帧允许误差 2 到 3 帧。另一个方式是看文件的播放总时长和录制实际时长是否一致——打开秒表在旁边计时录完 60 秒的视频播放器显示时长应该在 60 到 63 秒之间超过这个范围说明帧率虚标。如果发现帧率始终不达标最有效的调整是给抓帧线程加一个自适应睡眠// 抓帧线程自适应帧率控制按实际耗时调整睡眠时间 qint64 startTime QDateTime::currentMSecsSinceEpoch(); // 抓屏 发送数据 qint64 elapsed QDateTime::currentMSecsSinceEpoch() - startTime; int sleepMs (1000 / m_targetFps) - elapsed; if (sleepMs 0) { QThread::msleep(sleepMs); }参数说明这个写法让线程每帧的实际耗时稳定在目标帧率对应的间隔附近不会因为某帧编码慢而累积延迟。相比固定QThread::msleep(42)它让帧率更平稳。如果你录制的动作包含大量快速变化的画面这种稳定帧率的做法明显比固定 sleep 更不容易掉帧。6.2 把帧率上限从 24 提到 30 或 60这个资源默认上限 24 帧原因是 avilib 的写入耗时和 DC 抓屏效率决定的保守值。现代 CPU 性能远高于当时开发环境可以试试放开帧率。实现方式在 mainwindow 的界面上把帧率选项扩展给抓帧线程的frameIntervalMs传 3330fps或 1660fps同时给处理线程的编码逻辑增加异常保护避免某帧编码超时卡死。这里最可能遇到的瓶颈是 JPEG 编码把质量降到 75 左右再观察队列积压情况。如果你要用 60 帧录制动态桌面比如游戏画面建议更换抓屏方案为 DXGI Desktop Duplication但那是另一个工程级改造这就不展开了。6.3 文件自动命名升级按录制内容主题加标签默认名是纯时间戳录了 N 段素材后很难找。可以加一个内容主题输入框在生成文件名时拼接QString fileName QString(%1_%2_%3.avi) .arg(m_topic, QDateTime::currentDateTime().toString(HHmmss)) .arg(QString::number(m_splitIndex).rightJustified(3, 0)); // 例如 Qt教程_143025_001.avi参数说明m_topic 是用户在界面上输入的主题词m_splitIndex 是自动分割的序号。这样每段录像的文件名自带语义不用事后重命名。注意文件名里放在末尾的序号用 3 位补零超过 999 段流水会出现排序问题但录到 999 段的概率极小这里自动分割默认 1 分钟一个文件录 16 小时才会用到第 1000 段。6.4 要不要加音频AVI 加音轨的代价与方案这个资源只做画面不做音频这是它的设计边界。加音轨会让 AVI 变得复杂很多需要引入音频采集线程、音频编码器、音视频交错写入逻辑以及时间戳对齐代码量至少翻一倍。如果你的需求里有同步录制系统声音建议视频部分继续沿用这套源码音频用 Windows 的 WASAPI 采集然后录制完成后用 FFmpeg 做音视频合并。这套方案比直接在工程里加音频省心很多毕竟现有的 AVI 写入逻辑是纯视频的硬改容易出音画不同步问题。从那以后我每次拿到这种录屏源码都会强制先跑一遍「release 模式 15 帧率 中等质量」的组合确认帧率符合预期再逐步往上调参。这能帮我快速区分是环境问题还是代码问题避免一上来就最高参数配置然后什么都调不清楚。希望这份拆解和实战笔记能帮你在拿到这个资源后少走一些弯路。本文还有配套的精品资源点击获取