简介：本资源是一套基于Qt框架开发的局域网聊天室完整项目源码，面向计算机相关专业学生、Qt初学者及需要完成课程设计或毕业设计的开发者，帮助解决局域网内即时通信与文件传输的实践需求。压缩包共87个文件，约6.54MB，包含16个cpp源文件、14个头文件、7个ui界面文件及9张jpg图片等，涵盖聊天界面、用户选择、权限管理、消息撤回等模块，结构完整便于二次开发。项目支持私聊与文件传输，普通消息走UDP协议，文件传输走TCP协议，通过身份切换实现点对点通信；管理员可进行权限管理，并借助定时器轮询数据库标志位实时判断在线状态。数据库采用MySQL，需提前安装5.7.31版本，包内附有详细帮助文档说明数据库访问要点。目前已有4108人学习下载，适合作为毕设参考或Qt网络编程练手项目。
1. 局域网聊天室这个毕设选题，为什么每年都有人栽在“能跑但没法演示”上
每年到了毕设季，基于 Qt 实现局域网聊天室都是高频选题。原因很直接：它同时踩中了 GUI 编程、网络通信、多线程、协议设计四个技术点，工作量看起来饱满，答辩时也好讲。但真正动手做过的人都知道，这个项目的分水岭不在“能不能编译通过”，而在“能不能在答辩现场稳定演示”。我见过太多案例：本机双开客户端聊得飞起，换两台电脑就搜不到彼此；文字消息正常，一传文件就卡死界面；更玄学的是，明明代码没改，第二天重启路由器后广播就失效了。
这份毕设资源包的核心价值，就是帮你跨过“能跑”到“能演示”之间的那道坎。它提供了一套完整的 Qt 局域网聊天室实现，覆盖用户上线广播、在线列表同步、群聊与私聊、文件传输、心跳保活这几个答辩必问模块。适合两类人：一是刚接触 Qt 网络编程、需要一份可运行参考实现来拆解学习的同学；二是已经写了一版但卡在跨机通信或界面卡顿上、需要对照排查的开发者。下面我按实际复现顺序，把这份资源拆开讲清楚。
2. 先搞懂 UDP 广播发现 + TCP 可靠传输的混合架构：为什么不能全用 TCP
2.1 局域网节点发现为什么选 UDP 广播而不是组播
局域网聊天室第一个要解决的问题是：客户端启动后，怎么知道网段里还有谁在线。常见做法有三种：手动填 IP、UDP 广播、UDP 组播。这份资源用的是 UDP 广播，端口固定为 45454。选它的理由很实际——广播实现最简单，不需要配置组播地址和 TTL，在宿舍或实验室这种单网段环境里命中率最高。
核心逻辑是：每个客户端启动时绑定 45454 端口，向广播地址 255.255.255.255 发送一条上线通知，同时监听该端口接收别人的通知。收到通知后，把对方 IP、昵称、监听 TCP 端口记进本地在线列表。这里有个关键细节：UDP 广播包必须设置SO_BROADCAST选项，否则系统会直接丢弃。Qt 里通过QUdpSocket的writeDatagram发送到QHostAddress::Broadcast即可，但绑定端口时要选ShareAddress模式，允许多个客户端同时监听同一端口。
// 初始化 UDP 发现模块 udpSocket = new QUdpSocket(this); // ShareAddress 允许多个客户端绑定同一端口，缺一不可 udpSocket->bind(45454, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint); connect(udpSocket, &QUdpSocket::readyRead, this, &ChatWidget::processPendingDatagrams); // 发送上线广播 QByteArray datagram; QDataStream out(&datagram, QIODevice::WriteOnly); out << MessageType::Online << userName << tcpServerPort; udpSocket->writeDatagram(datagram, QHostAddress::Broadcast, 45454);参数说明：MessageType是自定义枚举，用来区分上线、下线、心跳三种广播类型；userName是用户昵称，用于在线列表显示；tcpServerPort是每个客户端 TCP 服务端监听的端口，默认从 5555 开始递增，避免端口冲突。逻辑上，广播包只负责“通知存在”，不承载聊天数据，这样设计的好处是 UDP 丢包不会影响消息可靠性。
2.2 TCP 长连接怎么管理多客户端并发
聊天消息和文件传输走 TCP，因为需要可靠有序。服务端模型有两种选择：一客户端一线程，或者单线程 +QTcpServer事件驱动。这份资源用的是后者，更轻量，也避免线程同步的麻烦。QTcpServer监听 5555 端口，每当有客户端连接进来，nextPendingConnection()返回一个QTcpSocket指针，把它存进QList<QTcpSocket*>统一管理。
消息收发采用“长度前缀 + JSON 体”的格式。先读 4 字节表示后续数据长度，再按长度读完整包，避免 TCP 粘包。JSON 体里包含消息类型、发送者、接收者、内容、时间戳。转发逻辑很简单：群聊消息遍历所有 socket 发送，私聊消息只发给目标 socket。这里要注意，服务端不做消息持久化，纯内存转发，所以客户端掉线重连后看不到历史消息——这是毕设场景下的合理取舍，答辩时如果被问到，可以解释为“降低实现复杂度，聚焦通信机制本身”。
// 服务端转发消息核心逻辑 void ChatServer::broadcastMessage(const QJsonObject &msg, QTcpSocket *exclude) { QByteArray body = QJsonDocument(msg).toJson(QJsonDocument::Compact); QByteArray packet; QDataStream out(&packet, QIODevice::WriteOnly); out << (quint32)body.size(); // 长度前缀，解决粘包 packet.append(body); for (QTcpSocket *client : qAsConst(clientList)) { if (client != exclude && client->state() == QAbstractSocket::ConnectedState) { client->write(packet); } } }参数说明：exclude用于私聊时排除发送者自己；QJsonDocument::Compact去掉多余空格，减小包体；quint32长度前缀最大支持 4GB 单包，实际场景远够用。常见坑是忘记处理bytesWritten信号，导致大文件传输时发送缓冲区堆积，内存暴涨。
2.3 在线列表同步与心跳保活怎么配合
在线列表不是静态的。用户上线要广播，下线要广播，异常断线还得靠心跳检测。这份资源的心跳策略是：客户端每 5 秒向服务端发一个心跳包，服务端 15 秒没收到就判定掉线，从列表移除并广播下线通知。同时，UDP 广播也承担一部分发现职责——新客户端上线时广播，老客户端收到后主动发起 TCP 连接。
这里有个容易翻车的点：UDP 广播和 TCP 连接是两条独立通道，可能出现“广播收到了但 TCP 连不上”的情况。常见原因是防火墙拦截了 TCP 5555 端口，而 UDP 45454 放行了。排查时先看服务端newConnection信号有没有触发，没有就是防火墙问题；触发了但列表没更新，就是 JSON 解析字段对不上。我一般会在客户端加一个“手动刷新”按钮，重新发一次广播，答辩现场万一自动发现失败，点一下就能救场。
3. 从零复现：Qt 工程配置、界面搭建与核心模块编码
3.1 .pro 文件与 Qt 版本选择
这份资源基于 Qt 5.15 + Qt Creator 开发，也兼容 Qt 6，但 Qt 6 的QTextCodec被移到了核心模块外，需要额外处理编码。如果你用的是 Qt 6，建议在.pro里加上core5compat模块，或者直接用QString::fromUtf8替代。工程文件关键配置如下：
QT += core gui network widgets greaterThan(QT_MAJOR_VERSION, 4): QT += widgets TARGET = LanChat TEMPLATE = app CONFIG += c++11 SOURCES += main.cpp chatwidget.cpp chatserver.cpp chatclient.cpp HEADERS += chatwidget.h chatserver.h chatclient.h参数说明：network模块必须加，否则QTcpSocket和QUdpSocket找不到；c++11是为了用 lambda 连接信号槽，写起来更简洁。常见错误是只加了network没加widgets，编译时报QApplication未定义。
3.2 界面布局：用 QSplitter 做可拖拽的三栏结构
界面部分不复杂，但布局方式影响后续扩展。推荐用QSplitter做三栏：左侧在线列表QListWidget，中间消息显示区QTextBrowser，右侧输入区QTextEdit+ 发送按钮。QSplitter的好处是用户可以拖拽调整比例，答辩演示时把消息区拉大，看起来更舒服。
// 三栏布局初始化 QSplitter *mainSplitter = new QSplitter(Qt::Horizontal, this); mainSplitter->addWidget(userListWidget); // 在线用户 mainSplitter->addWidget(messageBrowser); // 消息记录 mainSplitter->addWidget(inputWidget); // 输入区 mainSplitter->setStretchFactor(1, 1); // 中间栏可伸缩 setCentralWidget(mainSplitter);参数说明：setStretchFactor(1, 1)让中间消息区占据多余空间，左右两侧保持固定宽度。消息显示用QTextBrowser而不是QTextEdit，因为前者默认只读，避免用户误编辑历史消息。每条消息用 HTML 格式插入，方便区分昵称颜色和时间戳。
3.3 消息协议设计：JSON 字段与类型枚举
协议设计是这份资源的骨架。所有消息统一用 JSON 对象，字段包括type、from、to、content、timestamp。type用枚举区分：Chat普通消息、File文件传输、Heartbeat心跳、Online上线、Offline下线。这样设计的好处是扩展性强，后续加表情、加图片，只需新增 type 和对应字段。
// 消息封装函数 QJsonObject buildMessage(MsgType type, const QString &from, const QString &to, const QString &content) { QJsonObject obj; obj["type"] = static_cast<int>(type); obj["from"] = from; obj["to"] = to; obj["content"] = content; obj["timestamp"] = QDateTime::currentDateTime().toString("hh:mm:ss"); return obj; }参数说明：to字段为空字符串时表示群发；timestamp用字符串而非时间戳，方便直接显示。常见坑是 JSON 里的中文编码问题，Qt 5 默认用 UTF-8，但如果你在 Windows 下用 MSVC 编译器，源文件编码要设成 UTF-8 with BOM，否则中文昵称会乱码。
3.4 文件传输：分块发送与进度条联动
文件传输是答辩加分项，也是翻车重灾区。这份资源的做法是：发送方先发一个File类型的元数据包，包含文件名、大小、接收者；接收方确认后，发送方按 64KB 分块发送二进制数据，每发一块更新进度条。接收方边收边写文件，收完后校验大小。
// 文件分块发送 void ChatClient::sendFile(const QString &filePath, const QString &receiver) { QFile file(filePath); if (!file.open(QIODevice::ReadOnly)) return; qint64 totalSize = file.size(); qint64 sentSize = 0; const qint64 chunkSize = 64 * 1024; while (!file.atEnd()) { QByteArray chunk = file.read(chunkSize); QByteArray packet; QDataStream out(&packet, QIODevice::WriteOnly); out << (quint32)chunk.size(); packet.append(chunk); tcpSocket->write(packet); sentSize += chunk.size(); emit fileProgress(sentSize * 100 / totalSize); // 更新进度条 } file.close(); }参数说明：chunkSize设为 64KB 是经验值，太小导致包数量多、开销大，太大则进度条更新不及时。fileProgress信号连接到界面进度条，实现可视化。注意发送文件时不要阻塞 UI 线程，建议放到独立线程或用QTimer分片发送，否则界面会卡成“未响应”。
4. 跨机通信避坑：广播失效、端口占用、中文乱码的排查手册
4.1 广播发出去但收不到：先查防火墙和网段
现象：本机双开能互相发现，换两台电脑后在线列表始终为空。原因通常是 Windows 防火墙默认拦截了 UDP 45454 入站，或者两台电脑不在同一网段（比如一个连 WiFi 一个连有线）。解决步骤：先在控制面板临时关闭防火墙测试，如果能通，就为程序添加例外规则；如果还不通，用ipconfig确认两台机器 IP 前三段一致。注意，有些公司或学校网络开启了 AP 隔离，客户端之间根本不能直接通信，这种情况换手机热点即可。
4.2 TCP 端口被占用：5555 起监听失败的连锁反应
现象：第二个客户端启动时报“Address already in use”，或者服务端listen返回 false。原因是 5555 端口被上一个未正常退出的进程占用了。解决：在QTcpServer::listen之前先调用close()，或者把端口改成 0 让系统自动分配，再通过 UDP 广播把实际端口告诉别人。我一般会在客户端启动时从 5555 开始递增尝试，直到listen成功，这样多开也不会冲突。
4.3 中文昵称乱码：编码不一致的三种表现
现象：在线列表里昵称显示为“???”或“测试”。原因是发送端和接收端的字符串编码不一致。Qt 5 默认 UTF-8，但如果你在源文件里直接写中文字面量，MSVC 可能按 GBK 解析。解决：统一在.pro里加QMAKE_CXXFLAGS += /utf-8（MSVC）或-finput-charset=UTF-8（GCC），并且所有网络传输的字符串都用QString::toUtf8()转成字节数组再发。
4.4 界面卡死：文件传输阻塞事件循环
现象：传大文件时界面完全点不动，进度条也不更新。原因是文件读写和 socket 发送都在 UI 线程里同步执行。解决：把文件发送逻辑放到QThread里，或者用QTimer::singleShot分片发送，每发一块就返回事件循环。更简单的做法是限制单次发送块大小为 16KB，并在每块之间调用QCoreApplication::processEvents()，但这不是长久之计，正式项目还是建议独立线程。
4.5 心跳误判掉线：网络抖动与超时阈值
现象：明明客户端还在线，服务端却广播了下线通知。原因是心跳超时设得太短，网络稍微抖动就触发。解决：把超时阈值从 15 秒放宽到 30 秒，并且连续两次心跳丢失才判定掉线。另外，心跳包不要和聊天消息共用一个 socket 写操作，避免大文件传输时心跳被阻塞导致误判。
5. 答辩演示前的稳定性加固：三个我每次都会走的检查项
到了这里，功能基本齐了，但能不能在答辩现场稳住，还得看最后这几步。我自己的习惯是，演示前一天晚上一定做三件事：第一，把两台演示电脑的防火墙全部关闭，并且用网线直连而不是走 WiFi，排除无线干扰；第二，提前在每台机器上跑一遍“上线-群聊-私聊-传文件-下线”全流程，确认没有端口残留；第三，准备一个“手动刷新在线列表”的按钮，万一自动发现失败，点一下重新广播，给自己留条后路。
还有一个容易被忽略的细节：Qt 程序默认的工作目录是构建目录，如果你在代码里用相对路径读写配置文件，换台机器就找不到文件。建议所有路径都用QCoreApplication::applicationDirPath()拼接绝对路径。另外，答辩时如果老师问“为什么不用 WebSocket 或 MQTT”，你可以回答：局域网场景下 UDP 广播 + TCP 直连的延迟最低，且不依赖外部 Broker，部署最简单——这个理由足够站得住。
最后分享一个我踩过的坑：有一次演示前一切正常，到了现场发现两台电脑的网卡一个千兆一个百兆，自动协商失败导致链路不通。从那以后我每次演示都强制走一遍ping对测，确认底层连通再启动程序。希望这份拆解能帮你把毕设稳稳落地，少走点弯路。
本文还有配套的精品资源，点击获取
