简介这是一套基于Qt框架开发的Windows平台远程控制软件源码与可执行程序面向具备一定C与Qt基础、希望学习网络通信与远程桌面实现原理的开发者。资源包含服务器端被控端与客户端主控端两部分服务器端以进程形式后台运行客户端为图形界面程序连接时需指定服务器端IP地址及显示画面的宽高且宽高不能超过服务器端屏幕分辨率适合用于局域网远程协助、教学演示或二次开发。压缩包共40个文件以14个.h头文件与14个.cpp源文件为核心另含6个dll运行库、2个exe可执行程序、2个.pro工程文件及2个.user配置整体约6.08MB源码与编译产物齐备可直接运行或对照学习。目前已有5326人学习下载读者可从中掌握Qt网络编程、图像采集与传输、跨进程通信等关键实现思路并借助完整工程结构快速搭建自己的远程控制原型。1. 从零拆解一套 Qt 远程控制双端源码它到底能跑通哪些真实场景如果你手头正缺一套能直接编译、能看懂、能改的远程控制原型这套基于 Qt 的 Windows 双端源码值得花时间拆一遍。它把服务器端和客户端拆成两个独立工程服务器端负责采集屏幕、模拟输入、管理会话客户端负责连接、解码画面、回传键鼠事件。整套东西不依赖第三方远控框架核心通信和图像处理都写在 Qt 的 socket 与 QImage 体系里对想搞明白“远程桌面到底怎么把画面搬过去”的人来说比直接调一个封装库有价值得多。它适合三类人一是做内网运维工具、需要自己掌控通信链路的开发者二是学生或转行者想找一个完整 C/Qt 项目练手而不是写计算器三是已有产品雏形、需要参考屏幕分块传输和输入注入实现细节的工程师。下面按“能跑起来 → 看懂关键路径 → 避开翻车点 → 做进阶改造”的顺序拆每一步都落到具体文件和参数上。2. 双端工程结构与通信链路先搞清楚谁在传什么2.1 服务器端与客户端的职责边界这套源码最容易被误读的地方是很多人以为“服务器端”就是被控端。实际上在这类 Qt 远控实现里命名习惯通常是服务器端 被控主机上运行的程序负责抓屏和注入输入客户端 控制方负责显示画面和发送操作。两个工程各自有独立的main.cpp、.pro文件和一套TcpServer/TcpSocket封装。服务器端核心模块一般包括屏幕采集模块定时抓取桌面位图常见做法是用QScreen::grabWindow(0)或 Windows GDI 的BitBlt前者跨平台但帧率一般后者在 Windows 上更快。图像编码模块把QImage转成QByteArray可选 JPEG 压缩或原始 RGB 分块。网络发送模块基于QTcpServer监听端口接受客户端连接后按协议头发送帧数据。输入注入模块接收客户端发来的鼠标坐标、按键码通过SendInput或mouse_event还原操作。客户端核心模块对应为连接管理QTcpSocket连接指定 IP 和端口处理断线重连。帧解析按协议头读取长度字段拼包后交给解码器。画面渲染QLabel::setPixmap或自绘QWidget::paintEvent显示。事件采集重写mouseMoveEvent、keyPressEvent把本地事件序列化后发回服务器端。理解这个边界之后再看代码就不会把“谁发谁收”搞反。常见做法是在协议头里放一个 4 字节的魔数加 4 字节长度接收端先读 8 字节判断包类型再按长度收完整帧。2.2 一次完整交互的数据流把一次鼠标点击拆开看链路是这样的客户端捕获mousePressEvent拿到相对画面控件的坐标(x, y)。客户端把坐标按当前缩放比例还原成服务器端真实分辨率坐标。序列化成固定结构比如[类型:1字节][x:4字节][y:4字节][按键:1字节]。通过QTcpSocket::write发出。服务器端readyRead触发按同样结构解析。调用SendInput或SetCursorPosmouse_event注入。服务器端下一帧抓屏时画面里就带上了这次点击的效果。这个流程里最容易出问题的是第 2 步的坐标还原。如果客户端显示控件被拉伸过而代码里直接拿控件坐标当屏幕坐标用点上去就会偏。正确做法是记录原始帧的宽高用realX x * frameWidth / widgetWidth换算。2.3 编译前必须确认的环境参数这套工程对 Qt 版本和编译套件有要求踩错版本会直接卡在链接阶段。建议按下面这张表核对项目建议值说明Qt 版本Qt 5.12 及以上低于 5.12 时QScreen相关接口不完整编译套件MSVC 2017/2019 或 MinGW 7.3服务器端输入注入依赖 Windows APIMSVC 更稳模块依赖core gui widgets network.pro里必须带QT network系统Windows 10/11输入注入接口在 Windows 上才有效权限管理员运行否则无法向高权限窗口注入输入.pro文件里典型配置如下QT core gui widgets network CONFIG c11 TARGET RemoteServer TEMPLATE app SOURCES main.cpp \ screenserver.cpp \ inputinjector.cpp HEADERS screenserver.h \ inputinjector.h这段配置里network是必须的漏掉会报QTcpServer未定义。c11是因为源码里用了 lambda 连接信号槽。如果编译时报SendInput找不到检查是否包含了windows.h并且链接了user32.lib。3. 屏幕采集与图像传输帧率、压缩和分块怎么调3.1 抓屏方式的选型与实测差异Qt 里抓屏有两条路QScreen::grabWindow和 Windows 原生BitBlt。前者写起来简单三行代码就能拿到QPixmap后者需要建兼容 DC但速度快不少。源码里如果用的是QScreen在 1080p 下大概能跑到 10 到 15 帧换成BitBlt后同样分辨率能到 25 帧以上。QScreen抓屏的核心代码QScreen *screen QGuiApplication::primaryScreen(); QPixmap pixmap screen-grabWindow(0); QImage image pixmap.toImage(); // 转成 RGB888 便于后续压缩避免带 alpha 通道浪费带宽 QImage rgbImage image.convertToFormat(QImage::Format_RGB888);逻辑说明grabWindow(0)里的 0 表示抓整个桌面。convertToFormat这步不能省默认的Format_ARGB32每像素 4 字节转成RGB888后每像素 3 字节1080p 一帧能省下约 2MB。参数上如果只关心变化区域可以在抓屏前记录上一帧用QImage::operator或逐块比对只发差异块。3.2 JPEG 压缩质量与带宽的平衡原始 RGB 数据太大必须压缩。源码里常见做法是用QImage::save到QBuffer格式选 JPEG质量参数 60 到 80 之间。质量 80 时 1080p 一帧约 150KB质量 60 时约 80KB但文字边缘会发虚。QByteArray ba; QBuffer buffer(ba); buffer.open(QIODevice::WriteOnly); // 质量 70 是清晰度和体积的折中点再低文字就糊了 rgbImage.save(buffer, JPEG, 70); QByteArray frameData ba;参数说明第三个参数是质量范围 0 到 100。内网千兆环境下可以开到 85跨公网或无线环境建议 60 到 70。如果画面以文字为主JPEG 的块效应会很明显这时可以改用 PNG 或分块传输原始数据代价是带宽上升。3.3 协议头设计与粘包处理TCP 是流式协议不处理粘包就会出现“画面撕裂”或“解析错位”。源码里一般会定义一个固定头// 协议头4 字节魔数 4 字节数据长度 QByteArray header; QDataStream stream(header, QIODevice::WriteOnly); stream.setByteOrder(QDataStream::BigEndian); stream (quint32)0x52454D4F; // REMO stream (quint32)frameData.size(); socket-write(header); socket-write(frameData);接收端对应逻辑// 先收 8 字节头再按长度收正文 if (buffer.size() 8) return; QDataStream stream(buffer); stream.setByteOrder(QDataStream::BigEndian); quint32 magic, length; stream magic length; if (magic ! 0x52454D4F) { buffer.clear(); return; } if (buffer.size() 8 length) return; QByteArray frame buffer.mid(8, length); buffer.remove(0, 8 length);这段代码的关键是buffer要作为成员变量跨次readyRead累积不能每次清空。BigEndian要两端一致否则长度字段会解析成天文数字。如果发现客户端画面卡住不动先打印length看是不是异常大通常是字节序反了。4. 输入注入与坐标映射点击不准的根因都在这4.1 Windows 输入注入接口的选择服务器端收到坐标和按键后有两种注入方式mouse_event和SendInput。前者是老接口简单但已被标记为废弃后者是推荐方式支持多屏和更精细的控制。源码里如果用mouse_event在部分高 DPI 场景下会偏移。SendInput的典型用法INPUT input {0}; input.type INPUT_MOUSE; input.mi.dx (LONG)(x * 65535 / screenWidth); // 归一化到 0-65535 input.mi.dy (LONG)(y * 65535 / screenHeight); input.mi.dwFlags MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE; SendInput(1, input, sizeof(INPUT));参数说明MOUSEEVENTF_ABSOLUTE表示使用绝对坐标此时dx、dy需要归一化到 0 到 65535 之间而不是直接填像素值。这是最容易翻车的地方直接填像素会导致鼠标飞到屏幕角落。screenWidth和screenHeight要用GetSystemMetrics(SM_CXSCREEN)获取不能硬编码。4.2 客户端坐标到服务器坐标的换算客户端显示画面时如果控件大小和原始帧不一致必须做比例换算。假设原始帧是 1920x1080客户端控件是 960x540那么// widgetPos 是鼠标在控件内的坐标 double scaleX (double)frameWidth / widget-width(); double scaleY (double)frameHeight / widget-height(); int realX (int)(widgetPos.x() * scaleX); int realY (int)(widgetPos.y() * scaleY);如果控件保持了宽高比scaleX和scaleY相等直接用其中一个即可。如果控件被自由拉伸两个方向比例不同必须分别算。常见错误是只算了一个方向导致横向或纵向点击偏移。另外如果画面有黑边letterbox还要先减去黑边偏移再换算。4.3 键盘事件的序列化与还原键盘比鼠标麻烦因为要处理按下和抬起两个状态还要区分普通键和扩展键。源码里一般用Qt::Key枚举值传输服务器端再映射回虚拟键码。// 客户端发送 QByteArray keyData; QDataStream stream(keyData, QIODevice::WriteOnly); stream (quint8)MSG_KEY; stream (quint32)event-key(); stream (quint8)(event-type() QEvent::KeyPress ? 1 : 0); socket-write(keyData);服务器端还原时Qt::Key_A到Qt::Key_Z可以直接映射到0x41到0x5A但功能键、方向键需要单独查表。KEYEVENTF_KEYUP标志用于抬起事件漏掉会导致按键“卡住”。如果发现远程端一直重复输入某个字符先检查抬起事件有没有发出去。5. 避坑与排查这套源码最容易翻车的五个地方5.1 现象编译通过但运行闪退无任何提示原因服务器端在main里创建QTcpServer前就调用了输入注入相关 API或者.pro里漏了network模块导致运行时找不到符号。另一种常见情况是 Qt 版本和编译器不匹配比如用 MinGW 编译的库去链接 MSVC 编译的 Qt。解决先在main函数第一行加qDebug() start;确认程序能进到主循环。如果连这行都不打印说明是链接期问题检查 Qt 套件是否和编译器一致。如果打印了但后面崩用QApplication::aboutToQuit加日志定位到具体模块。5.2 现象客户端能连上但画面一直黑屏原因服务器端抓屏返回了空QPixmap常见于程序没有以管理员权限运行或者运行在远程桌面会话里被系统限制。另一个原因是抓屏线程和网络发送线程共用了QImage没有做深拷贝数据被下一帧覆盖。解决先判断pixmap.isNull()如果是空就打印错误并跳过这一帧。跨线程传递QImage时用QImage::copy()做深拷贝或者用QMetaObject::invokeMethod切回主线程处理。权限问题就右键以管理员身份运行。5.3 现象鼠标点击位置整体偏移一个固定值原因高 DPI 缩放。Windows 在 125% 或 150% 缩放下GetSystemMetrics返回的是逻辑坐标而抓屏拿到的是物理像素两者不一致。源码里如果没有调用SetProcessDPIAware就会产生固定偏移。解决在main函数最前面调用SetProcessDPIAware()让进程感知真实分辨率。或者在.pro里加QMAKE_LFLAGS /MANIFESTUAC:levelasInvoker uiAccessfalse并配置 DPI 感知清单。调用之后重新获取screenWidth和screenHeight偏移就会消失。5.4 现象传输几帧后连接断开原因单帧数据超过 TCP 缓冲区或者发送频率太高导致对端处理不过来。JPEG 质量开到 95 时1080p 一帧可能超过 500KB连续发送会撑爆缓冲区。另一个原因是write之后没有等待bytesWritten就继续写数据堆积。解决在服务器端加一个发送队列用QTcpSocket::bytesToWrite判断积压量超过阈值就跳过当前帧。质量参数降到 70 以下。客户端接收端用readAll配合累积缓冲区不要假设一次readyRead就是完整一帧。5.5 现象键盘输入乱码或功能键无效原因Qt::Key枚举值和 Windows 虚拟键码不是一一对应直接强转会导致功能键错乱。另外中文输入法状态下keyPressEvent拿到的是拼音字母而不是最终字符。解决建一张映射表把Qt::Key_F1到Qt::Key_F12、方向键、Home、End等单独处理。输入法问题可以在客户端拦截inputMethodEvent或者提示用户在远程操作时切换到英文输入法。如果只是普通字符输入用event-text()拿实际字符比用event-key()更可靠。6. 进阶改造把帧率从 15 提到 30 的两个具体手段第一个手段是改抓屏方式。把QScreen::grabWindow换成 Windows 的BitBlt配合CreateCompatibleDC和CreateCompatibleBitmap在 1080p 下实测能省掉约 40% 的抓屏耗时。核心代码结构是先建内存 DC把屏幕 DC 的内容BitBlt过去再从位图里取像素数据。注意每次抓完要DeleteObject释放位图否则跑几分钟就内存泄漏。第二个手段是只传变化区域。把画面切成 64x64 的块每帧和上一帧做逐块比对只把有差异的块编码发送。客户端维护一份完整的帧缓冲收到差异块后更新对应位置。这样在静态画面下带宽能降到原来的十分之一。代价是实现复杂度上升需要处理块边界和客户端缓冲同步。验证改造效果的方法很简单在服务器端每帧结束时打印抓屏耗时和编码耗时客户端打印接收帧率和解码耗时。如果抓屏耗时占比超过 50%优先换BitBlt如果编码耗时高降 JPEG 质量或改分块。我自己的习惯是每次改完参数都跑一遍 1080p 静态画面和 1080p 视频播放两个场景前者看带宽后者看帧率两个都达标才算调好。从那以后我每次动传输参数都强制走一遍这两个场景省得上线后才发现某一类画面卡成幻灯片。希望帮到你。本文还有配套的精品资源点击获取