简介：一份基于Qt的局域网通信项目源码，面向Qt网络编程学习者与毕业设计参考者，系统解决局域网环境下的用户注册登录、文字聊天、文件传输和视频通信四大需求。zip压缩包共二十四个文件，包含五个cpp与四个头文件构成的客户端/服务端源码、四个ui界面文件、七个png图标资源，以及pro/qrc工程配置和一份完整的毕业设计说明书文档，整包约五百二十九KB，模块划分清晰、便于按需查阅。实现上，以MySQL支撑账号注册与登录，用OpenCV完成视频采集与显示，UDP协议承担即时消息转发，TCP/IP协议负责可靠文件传输，覆盖了从界面设计、数据库操作到网络协议落地的完整链路，同时客户端与服务端分离的结构也便于二次开发。目前已有一千零九十七人学习下载，尤其适合课程设计、毕业设计及希望快速掌握Qt网络编程的读者参考使用。通过包内源码与文档，可直观对照账号注册、即时通信、音视频传输的代码组织方式，为独立实现类似功能提供扎实参考。 做这个项目的念头其实特别朴素：实验室几台电脑离得不远，但联调程序时要么靠喊，要么靠U盘拷文件，群里传消息还得时不时起身确认对方看到没有。于是就想自己写一套基于Qt的局域网通信工具，顺手把数据库和视频通信一起做进去。当时觉得也就是个练手项目，真做起来才发现，Qt的网络模块、数据库模块、多媒体模块全被这一条线串起来了，踩坑记录也攒了一堆。
这套东西能做什么？一句话概括：在一个局域网内，实现用户注册登录、好友列表、文本消息收发，以及两个人之间的实时视频画面传输，聊天记录落到本地数据库里。听起来像一个简化版QQ，但正因为简化，反而很适合用来吃透Qt的核心机制——信号槽、事件循环、多线程、TCP/UDP、数据库连接管理，基本一个不落。如果你在准备课程设计、毕业设计，或者想系统性地锻炼一遍Qt工程能力，这个项目是个相当好的抓手。
1. 项目定位与整体思路
1.1 要做的到底是什么样的应用
在动手写代码之前，我先把需求拆成了三块，每一块对应Qt里的一组类库。
第一块是通信底座。用户要能登录、能看到谁在线、能发消息，这就需要一个稳定的连接通道。Qt提供了QTcpServer和QTcpSocket，适合做需要可靠送达的文本消息；而视频画面实时性要求高、允许少量丢帧，走QUdpSocket更合理。这两套东西组合起来，一个完整的“TCP管控制、UDP管视频”的通信链路就出来了。
第二块是数据层。用户账号、离线消息、聊天记录这些需要持久化，Qt的QtSql模块把QSqlDatabase、QSqlQuery封装得很顺手，配上SQLite这种零配置的嵌入式数据库，一个自包含的数据库文件就能把整个应用的状态存下来。
第三块是音视频。Qt Multimedia模块负责打开摄像头、读取视频帧，采集到的QImage图像压缩成JPEG之后，再通过UDP分包发出去，对方收到后重组、解码、显示。这个链路虽然简单，但把“采集—编码—传输—解码—显示”这套流程跑通之后，后续再上真正的H.264硬编码或者WebRTC，思路是完全一致的。
1.2 技术选型：为什么是Qt这组模块
很多人问过我，局域网通信为什么不用Web技术去做，用浏览器加WebSocket不也能实现？选择Qt，是因为这个场景里“原生桌面应用”的优势很明显：不依赖浏览器环境，双击就能跑；QJsonDocument、QImage、QSqlDatabase这些类本身就是为桌面级应用设计的，链路上不需要任何中间层；最重要的是，Qt的信号槽机制天然适合处理网络异步事件——数据到了、连接断了、摄像头上线了，都能以信号的形式驱动界面更新，开发体验非常直接。
我当时的选型结论是：Qt 5.15 + Qt Network + Qt SQL(SQLite) + Qt Multimedia。这四样东西全是Qt自带的，不需要引入第三方库就能完成整个闭环。如果你在Windows上开发，直接从官网下载Qt在线安装包，或者用国内镜像源加速，把这几项勾上就行。后面发布的时候用windeployqt一把梭打依赖，也省心。
2. 总体架构与数据层设计
2.1 通信架构：服务器中转还是P2P直连
这一步是很多第一次做通信项目的同学最容易纠结的地方。我一开始也想过两台客户端之间直接连，也就是P2P，服务器逻辑全省了。但在局域网场景下，P2P有一个非常实际的麻烦：你怎么知道对方在线？你怎么拿到对方的IP和端口？你发过去的连接请求怎么跟对方的防火墙规则共存？
所以我最后选的是“轻量服务器中转”的架构：一个中心服务器进程，负责账号校验、在线状态管理、消息转发；客户端之间确实有直达的视频流，但信令和文本消息全部走服务器。这样设计的另一个好处是消息可以落库——比如对方不在线时，消息先存进数据库，对方上线后再拉取，这就是离线消息的雏形。
模块划分上，整个工程分成了三个可独立编译的部分：server（服务器）、client（客户端）、common（共享协议定义）。common里放消息头结构体、枚举类型、工具函数，两边都引用同一份定义，从根上避免通信格式对不上。
2.2 数据库选型与核心表结构
数据库我直接用SQLite，原因很现实：服务器和客户端都不需要单独装数据库服务，文件即数据库。如果你打算把这个项目扩展成多用户的大型服务端，换成MySQL或者企业要求的其他数据库也只是改一行QSqlDatabase::addDatabase的驱动名和连接参数，表结构基本不用动。
放一张当时设计的核心表结构，直接照抄就能用：
CREATE TABLE user ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT NOT NULL UNIQUE, password_hash TEXT NOT NULL, nickname TEXT, avatar BLOB, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE message ( id INTEGER PRIMARY KEY AUTOINCREMENT, sender_id INTEGER NOT NULL, receiver_id INTEGER NOT NULL, msg_type INTEGER DEFAULT 0, -- 0文本 1图片 2文件 3视频邀请 content TEXT, timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, is_read INTEGER DEFAULT 0 );这里的password_hash我用的是QCryptographicHash算出来的SHA-256字符串，不要明文存密码，这是做数据库设计时最基础的安全底线。头像字段用BLOB直接存图片二进制，开发期图省事够用，生产环境还是建议存文件路径。消息表里加一个msg_type字段很重要，后续扩展图片、文件、视频邀请都靠它区分，不用再改表结构。
3. 局域网通信核心链路实现
3.1 TCP与UDP的职责分工
通信模块一开始最容易犯的错误是“一个TCP搞定所有事情”。我也踩过这个坑：用TCP传视频，画面稍微大一点，TCP的拥塞控制和重传机制就会让延时明显拉高，而且TCP的流式特性要求你处理粘包和半包，视频每帧到了接收端得先拆包对齐，非常痛苦。
正确的分工应该是：TCP负责所有必须可靠送达的数据——登录请求、好友列表、文本消息、视频通话控制信令（比如“邀请”“挂断”）；UDP负责大流量、可容忍丢失的数据——视频帧。UDP的不可靠在这里不是缺点，视频画面丢一两帧人眼根本感知不到，但一旦用到TCP，重传机制可能把后续所有帧都拖住，画面反而更卡。
QTcpServer的用法比较固定：listen监听端口，newConnection信号里通过nextPendingConnection取出已经建立的socket，再连一下readyRead信号处理收数据。需要注意的一点是，服务器管理多客户端时，每个客户端对应一个QTcpSocket实例，退出时要记得把socket从容器里移除，不然很容易内存泄漏。
3.2 自定义协议与粘包半包处理
TCP是流式传输，你写一次write，对端readyRead信号触发时读到的数据可能只是半截，也可能是两次写拼在了一起。解决思路就是自定义应用层协议，每次发送时带上固定长度的消息头。
这是我的消息头定义：
struct MsgHeader { quint32 magic; // 魔数，固定为0x5A5A，用于校验 quint16 version; // 协议版本 quint16 type; // 消息类型，1001文本、1002登录... quint32 length; // 消息体长度 quint32 seq; // 序列号，用于应答匹配 };发送端组装完头部和JSON体之后，一次性把完整数据块写进socket。接收端维护一个QByteArray接收缓冲区，每次触发readyRead先把数据追加到缓冲区末尾，然后进入循环解析：缓冲区长度够一个sizeof(MsgHeader)，先取头部校验魔数，再根据length判断消息体是否齐了；齐了就截取整条消息，触发自定义信号交给上层处理；不齐就等下一次readyRead。这套“缓冲区+循环解析”的模板，写一次之后所有TCP消息类型都能复用。
3.3 数据库操作与多线程的注意事项
项目里数据库最容易出的问题，是“跨线程使用同一个数据库连接”。QSqlDatabase的连接对象是绑定到创建它的线程的，如果主线程创建了连接，子线程里直接拿这个连接去查询，轻则报QSqlDatabasePrivate::database: requested database does not belong to the calling thread，重则直接崩溃。
我的处理办法是每个线程维护自己的连接。简单来说，线程内需要访问数据库时，用QSqlDatabase::addDatabase指定一个该线程独享的连接名（比如“conn_thread1”“conn_thread2”），拿到QSqlQuery执行完就释放。如果是客户端，数据量不大，更省事的做法是把所有数据库操作都集中在同一个工作线程里，其他线程通过信号槽把“查询请求”抛给它，由它统一执行并回发结果，从设计上根除跨线程问题。
4. 视频通信：从摄像头到对方屏幕
4.1 视频采集与压缩方案
Qt做视频采集有两条路：一条是正统的QCamera加QAbstractVideoSurface，优点是完全依赖官方API、跨平台稳定；另一条是绕开Qt，直接用OpenCV的VideoCapture读取摄像头帧，再转成QImage显示。我开发期用的第一条，因为不需要额外装OpenCV，但你要想后面做图像处理，直接用OpenCV反而更顺。
摄像头帧拿回来是QVideoFrame格式，要送到网络上传，必须先转成QImage再转成QByteArray。压缩我用的是JPEG，代码很简短：
QByteArray bytes; QBuffer buffer(&bytes); buffer.open(QIODevice::WriteOnly); frameImage.save(&buffer, "JPG", 75); // 质量75，兼顾画质和大小JPEG压缩最大的好处是“无脑”：Qt自带编码器，不必引入FFmpeg，一张320x240的图压缩后通常只有8到15KB，正好适合UDP分片传输。缺点是CPU编码开销比H.264大，但局域网测试一两路视频完全扛得住。
4.2 UDP分包传输与重组显示
UDP单包最大是64KB，但考虑到网络MTU，超过1472字节就可能触发IP分片，所以我习惯把每片控制在1200字节以内。一帧JPEG数据被切成多个分片，每个分片报文里带上帧序号、分片索引、总分片数。
int chunkSize = 1200; int total = (bytes.size() + chunkSize - 1) / chunkSize; for (int i = 0; i < total; ++i) { QByteArray chunk = bytes.mid(i * chunkSize, chunkSize); sendFrameChunk(frameSeq, i, total, chunk); }接收端用一个QHash<int, FrameBuffer>缓存正在组装的帧，key是帧序号。拿到一片就往对应的缓存里填充，等到分片数量齐了，把整个字节数组丢给QImage::fromData解出图像，再刷新画面。关键细节是清理超时缓存——UDP会丢包，如果某一帧的分片永远等不齐，缓存就会越积越多，所以每次接收时顺带清理超过500毫秒没凑齐的旧帧。
4.3 画质与实时性的平衡经验
视频通信的体验就是一场“分辨率、帧率、画质”的三角博弈，这三者相互制约，不可能全都要。我实测下来，局域网场景下分辨率320x240到640x480之间体验最好；720P不是不行，但JPEG编码延迟和带宽占用会明显上去，不值当。
帧率控制在15到20帧每秒是比较合理的中间值，用QTimer定时采集可以实现简单的帧率钳制。JPEG质量参数压缩到65到75就好，70以上人眼看不出明显差异，文件体积却差别很大。另外务必要做“静帧跳过”优化：摄像头画面几乎没有变化时（比如对着桌面），连续采集得到的图像帧完全一样，白白浪费带宽和CPU。做一个简单的字节比较触发重传机制，画面变化超过阈值才发送新帧，这是性价比最高的一步优化。
5. 界面交互与线程模型
5.1 主窗口的组织方式
界面做得好不好用，直接决定这个工具会不会真的被团队用起来。我的设计分三个窗口：登录/注册页、主聊天页、视频通话页。
登录页比较简单，一个用户名输入框、一个密码框、两个按钮。注册时直接向后端发TCP请求，服务器收到后往user表插一条记录。主聊天页是核心，左侧一个QListWidget展示在线好友，右侧一个QTextBrowser显示聊天记录，底部QLineEdit和发送按钮组成输入区。视频通话页则是一大一小两个画面：大画面显示对方摄像头，小画面显示本机摄像头预览，这已经是视频软件的标准交互了。
5.2 信号槽与异步刷新：界面卡顿的解药
新手做Qt网络程序最容易犯的错，是在readyRead信号槽里直接做耗时操作，比如写数据库、解析图片，结果UI线程被堵住，窗口拖不动。解决的办法是把网络收发、数据库访问全部从UI线程剥离。
我的客户端里跑着几个QThread：一个负责TCP收发和协议解析，一个负责UDP视频收发和图像重组，主线程只干界面的事。子线程数据准备好了，通过信号槽发到主线程更新界面，连接方式用默认的Qt::AutoConnection，跨线程时会自动转为排队连接，安全又方便。这里有个我自己摸索出来的经验：不要把QThread的子类写得过于“大而全”，最好是每个线程只做一件事，职责单一，出了问题也好定位。
6. 常见问题与排查速查
6.1 网络通信类问题
客户端连不上服务器，但地址端口明明没错。先去看服务器是不是只监听了127.0.0.1，这是最常见的低级错误。QTcpServer::listen时如果传的是QHostAddress::LocalHost，那局域网里其他机器当然连不上，要改成QHostAddress::Any。
TCP收到乱码或者数据总是不对。八成是没处理粘包半包，直接用readAll把缓冲区的零散数据当完整消息解析了。回到3.2节的缓冲区+循环解析方案，一切以消息头里的length字段为准。
UDP视频花屏。优先怀疑MTU分片问题，把分片大小改到1200以内；其次是接收端重组逻辑不完整，确认一下分片索引是否写对、超时清理有没有生效。
6.2 数据库与中文乱码类问题
SQLite中文乱码。大概率是连接建立后没有执行SET NAMES UTF8。SQLite本身是UTF-8存储，但如果你在Windows下用系统默认编码去写入，就会乱。统一用QString和QSqlQuery::bindValue传参，让Qt自己完成编码转换，不要手动拼SQL字符串带中文。
database is locked。这是SQLite的经典问题，多线程同时写同一个库文件导致的。规避方法就是前面说的“数据库操作集中在单一线程”，并且把写操作用事务包起来，减少锁竞争。
6.3 打包发布与环境问题
运行exe提示“no qt platform plugin could be initialized”。这是Qt程序发布时最经典的报错，十有八九是platforms目录缺失或者没有qwindows.dll。解决方式是在编译好的exe同目录下执行一次：
windeployqt --release your_app.exe它会自动把Qt的依赖dll、插件、翻译文件拷贝到exe目录。再不行，检查一下exe目录下有没有qt.conf文件，确保Platforms路径指向插件目录。
摄像头打不开。先确认是不是别的软件占用了摄像头，再确认QCameraInfo::defaultCamera()有没有正确返回设备。开发调试时多打印error()和status()信号，大部分是权限问题。
7. 经验与扩展方向
做完这个项目，我最深的体会是：Qt最难的不是某个API不会用，而是模块之间的配合。通信模块要跟数据库模块联动，数据库模块要跟界面线程解耦，视频模块又牵扯性能优化——每一块单看都简单，合在一起才考验工程能力。如果你正在做类似的项目，我强烈建议不要在写代码前把方案定太死，先把文本聊天跑通，再逐步加数据库、加视频，每加一层都保持程序可运行，这样的节奏会舒服很多。
后续想在这个基础上扩展，可以试试这么几条路：把QCustomPlot画出来的波形图通过这套消息链路传给另一端，做一个远程实时图表显示；引入OpenCV或HALCON对视频流做实时处理，为人脸检测、图像识别这些功能留好接口；再加上文件传输、群聊、离线消息推送，一个局域网内的企业级协作工具就这么成型了。这个项目的上限，远比你想象中高。
本文还有配套的精品资源，点击获取
