企业官网建设流程全解析

简介：这是一款基于QT开发的网络聊天室项目源码，服务端与客户端相互配合，可完成实时文字交流、在线状态管理以及文件发送接收，涵盖TCP通信、多线程并发、界面绘制与数据序列化等核心知识点。资源包共54个文件，约388KB；其中cpp、h与ui文件构成服务端和客户端主体程序，png、jpg图片用于界面素材，整体目录划分清楚，便于直接导入查看。目前已有1864人浏览学习。通过阅读服务端与客户端两侧代码，可以理清服务器监听端口、接收连接请求，客户端发起连接、发送消息并接收文件的完整流程；聊天窗口中的菜单按钮、快捷键和表情图标设计，也展示了控件布局与信号槽机制的实际用法。项目还体现了多线程下保持界面流畅、文件分块传输时校验进度的常见处理思路，适合正在学习C++与QT网络编程的读者，也可作为课程设计、毕业设计或项目实训的参考资料。

1. 基于Qt的网络聊天室：先别急着写界面，把收发数据及文件的传输路径跑通

拿到“基于QT的网络聊天室+收发数据及文件”这个课题，大部分人去布置 QListWidget、气泡和头像，真正到了联调才发现，自己天天避开的网络问题根本绕不过去：readyRead 信号来了不代表一条完整消息到了，文件的字节流更是会被拆成好几段送达。与其从界面出发，不如先把协议帧、文本消息和文件分块的骨架在代码里跑通，再回来补 UI。按这个顺序，你会一步步接触到底层选型、帧格式、文本收发、文件传输和运行时排错，最终搭起一个能持续演进的最小工程；新手跟着能复现，熟手可以直接跳到第 5 章看那些最容易翻车的现场。

2. 网络骨架：TCP 选型、帧格式与最小可运行连接

2.1 为什么聊天室连接优先选 TCP，而不是 UDP 或 HTTP

聊天室是持续、双向、对顺序敏感的通信场景，TCP 在应用层几乎不用额外补东西。Qt 里QTcpServer和QTcpSocket在 Windows、Linux、macOS 上接口完全一致，不需要自己处理底层套接字。UDP 虽然更轻，但文本消息只要丢一个包，用户看到的就是一句残缺不清的话；要做可靠聊天，就得在应用层自己补确认、重传、乱序重组，这部分代码量足以超过聊天室本身。HTTP 适合请求-响应，服务端要主动推送给所有客户端时，轮询不仅延迟高，服务器压力也大。换成 WebSocket 又等于回到长连接，业务模型绕了一圈，底层弹性和 TCP 差不多。

在这个需求里，文件传输更需要可靠性和顺序性，TCP 的流控制能避免发送端把对端网络瞬间打爆。我做网络聊天室选型时基本不犹豫：文本、文件统一走 TCP 长连接。唯一例外是后续要做音视频实时通话，可以单独开一条 UDP 通道承载低延迟数据，但聊天室核心控制面仍然走 TCP。

2.2 帧设计：给字节流“划出消息边界”

选好 TCP 之后，马上要面对一个事实：TCP 是字节流，不是消息流。socket->write()写完一条消息，对端可能分两次收到，也可能两条消息一次读完。如果没有边界约定，接收端根本不知道从哪里切开。常见做法是自定义帧头：固定几个字节描述消息类型和负载长度，后面接负载数据。

我把帧设计成二字节类型再加四字节长度，统一网络字节序。

帧头采用 BigEndian，是为了避免客户端和服务端在不同 CPU 字节序上解析出错。负载长度用 quint32，单条帧最大能到 4GB 左右；如果明确要传数 GB 的单个文件，长度字段应该升到 quint64，但在聊天室场景里，quint32 够用了。消息类型字段不用留太多位，数量大概在 20 个以内，quint16 足够未来扩展。

2.3 帧头写读代码：发送端和接收端各留一个函数

发送端把类型和负载打包成帧，写进 socket：

// 将一条消息打包成帧并写入 socket void ChatPeer::writeFrame(quint16 type, const QByteArray &payload) { QByteArray frame; QDataStream out(&frame, QIODevice::WriteOnly); out.setByteOrder(QDataStream::BigEndian); out << type; out << static_cast<quint32>(payload.size()); frame.append(payload); m_socket->write(frame); }

这里用QDataStream写整数，比手动拼字节更安全，字节序也明确设置了。payload.size()返回 int，先转成 quint32 再写入，保证长度字段正好占四字节。m_socket->write()只是把数据交给 Qt 的写缓冲，真正发出去由底层网络事件驱动，不阻塞调用方。

接收端不能一句readAll()就当一条消息处理，需要先把数据追加到接收缓冲区，再按帧头长度循环切帧：

void ChatPeer::onReadyRead() { m_recvBuf.append(m_socket->readAll()); while (m_recvBuf.size() >= 6) { QDataStream head(m_recvBuf); head.setByteOrder(QDataStream::BigEndian); quint16 type = 0; quint32 payloadSize = 0; head >> type >> payloadSize; if (m_recvBuf.size() < static_cast<int>(6 + payloadSize)) { return; // 负载还没有完整到达，留到下一次 readyRead } m_recvBuf.remove(0, 6); QByteArray payload = m_recvBuf.left(payloadSize); m_recvBuf.remove(0, payloadSize); handleFrame(type, payload); } }

这段代码的关键在while循环和两个remove。缓冲区里可能堆积多条消息，所以要循环解析完整帧；如果负载长度不够，就直接返回，等下次网络事件触发。每次取完帧头，先移除头部，再取 payload，保证缓冲区开头永远是一个新帧的起点。

这里提醒一点：onReadyRead()可能在一次事件循环里被触发多次，m_recvBuf必须作为成员变量保存，不能每次新建临时变量。否则前一次没取完的数据会丢失。

2.4 客户端与服务端的最小连接建立

服务端监听端口，接受新连接后把 socket 保存到集合里：

void ChatServer::handleNewConnection() { while (m_server->hasPendingConnections()) { QTcpSocket *s = m_server->nextPendingConnection(); m_clients.insert(s); connect(s, &QTcpSocket::readyRead, this, &ChatServer::onReadyRead); connect(s, &QTcpSocket::disconnected, this, &ChatServer::onDisconnected); s->setSocketOption(QAbstractSocket::KeepAliveOption, 1); s->setSocketOption(QAbstractSocket::LowDelayOption, 1); } }

KeepAliveOption让内核定期探测连接是否还在，减少无人说话时连接被静默断开的情况。LowDelayOption对应 TCP_NODELAY，关闭 Nagle 算法，让聊天消息能更及时发出；如果同时发送大量文件块，这个选项会稍微增加小包数量，但聊天室交互场景优先保证延迟。

客户端连接代码更短：

m_socket = new QTcpSocket(this); connect(m_socket, &QTcpSocket::connected, this, &ChatClient::onConnected); connect(m_socket, &QTcpSocket::readyRead, this, &ChatClient::onReadyRead); connect(m_socket, &QTcpSocket::disconnected, this, &ChatClient::onDisconnected); m_socket->connectToHost("127.0.0.1", 9000);

connectToHost是异步的，连接成功后触发connected信号，这时候才能安全地发送第一条消息。不要把write放在connectToHost后面立刻执行，因为此时连接还没有建立，数据只会积压在缓冲区里。服务端收到newConnection后，每个 socket 的readyRead都要连接到同一个onReadyRead槽函数，通过sender()区分是哪个客户端发来的数据。

3. 文本消息收发：信号槽、JSON 与线程模型

3.1 用消息类型扩展帧，把文本帧跑通

帧头设计好之后，第一步先让文本消息跑通。先给消息类型定义一个枚举，避免魔法数字到处飞：

enum FrameType : quint16 { kText = 1, kFileMeta = 2, kFileBlock = 3, kFileEnd = 4, kPing = 5, kPong = 6 };

文本帧的 payload 用 JSON 组织，里面至少带发送者、文本内容、发送时间和房间号：

void ChatClient::sendTextMessage(const QString &room, const QString &from, const QString &text) { QJsonObject obj; obj.insert("room", room); obj.insert("from", from); obj.insert("text", text); obj.insert("time", QDateTime::currentDateTime().toString(Qt::ISODate)); QByteArray payload = QJsonDocument(obj).toJson(QJsonDocument::Compact); writeFrame(kText, payload); }

用 JSON 而不是自定义字符串拼接，好处是字段扩展时不用改帧协议。比如后续要加@someone的 at 标记，直接在 JSON 里加一个"at": ["alice"]字段即可，旧客户端解析时忽略未知字段也不会崩溃。toJson(QJsonDocument::Compact)去掉多余空白，减少网络传输的体积。

接收端解析 JSON：

void ChatClient::handleFrame(quint16 type, const QByteArray &payload) { if (type == kText) { QJsonParseError err; QJsonDocument doc = QJsonDocument::fromJson(payload, &err); if (err.error != QJsonParseError::NoError) return; QJsonObject obj = doc.object(); emit messageReceived(obj.value("room").toString(), obj.value("from").toString(), obj.value("text").toString()); // 只在这里处理文本消息，不要直接操作 UI，原因见 3.3 return; } }

解析时如果遇到坏 JSON 帧，直接丢弃或者打印日志，不能让程序崩溃。注意这里有个隐蔽的坑：JSON 解析失败不一定说明网络有问题，可能是前一帧解析顺序错了。所以帧头解析一定要严格，否则会把前后两个包的字节拼在一起，fromJson必然报错。

3.2 半包的根源与接收缓冲区的写法

很多初学者会在槽函数里这样写：

void onReadyRead() { QByteArray data = m_socket->readAll(); handleFrame(1, data); }

这在局域网小流量下测试没问题，但只要消息稍微大一点，readAll()返回的内容就可能不完整。readyRead只是告诉你“缓冲区有数据”，不是“一条完整消息到了”。文件块、长文本、并发消息，都会产生半包和多包。

前面 2.3 节的onReadyRead写法已经正确处理了这个场景，但有一个细节要特别强调：while条件里判断的是缓冲区大小是否够一个帧头，不够就直接返回。如果一条完整消息恰好等于 6 字节帧头加 500 字节负载，第一次readyRead只给了 400 字节，那么循环会在m_recvBuf.size() < 6 + payloadSize处返回；第二次readyRead把剩下 106 字节补齐，才继续走完之前那条消息。这套逻辑的可靠性，完全建立在“缓冲区持久保存不清理”的基础上。

还有一版容易出错的写法是在while循环里重新创建QDataStream指向m_socket：

QDataStream in(m_socket); in.setByteOrder(QDataStream::BigEndian); while (!in.atEnd()) { in >> type; in >> payloadSize; ... }

QDataStream直接绑定到QTcpSocket时，一旦数据没读完整，atEnd()判断和下一次读取之间容易出问题，处理半包特别别扭。我一般不用这种写法，而是让所有数据先进QByteArray缓冲区，再独立解析，逻辑更直观，也方便调试时把缓冲区内容 dump 出来看。

3.3 网络层与 UI 层分离：信号槽跨线程边界

聊天室项目常见的架构是把ChatClient类单独放一个线程，这样可以避免网络收发影响界面渲染。Qt 网络通信本身是事件驱动的，socket 在主线程也能工作，但一旦文件传输较大，主线程要频繁读取文件、写入 socket，UI 操作就会被挤到后面。

我的习惯是做一个网络线程对象，主线程只负责 UI。ChatClient继承QObject，创建后调用moveToThread移动到网络线程，再通过信号槽与主线程交换数据：

ChatClient *client = new ChatClient; QThread *netThread = new QThread; client->moveToThread(netThread); netThread->start(); connect(client, &ChatClient::messageReceived, this, &MainWindow::appendMessage, Qt::QueuedConnection);

Qt::QueuedConnection保证messageReceived信号跨线程时排进主线程事件循环，appendMessage里可以安全操作 QListWidget。反过来，主线程需要发消息时，把文本内容作为参数传给sendTextMessage，它内部调用writeFrame，由网络线程执行 socket 写入。

这个设计能避开一个经典问题：直接在网络线程里更新 UI 控件，轻则界面卡顿，重则崩溃。如果只是本机跑的演示项目，网络层放主线程问题不大；但如果想做成一个可以长期运行的服务端程序，线程隔离能从根上避免界面假死。

3.4 服务端转发：单聊、群聊怎么区分

服务端收到文本帧后，要根据房间号把消息转发给同房间的客户端。我在服务端维护一个以房间号为键、socket 集合为值的结构：

QHash<QString, QSet<QTcpSocket*>> m_roomClients;

客户端连接成功后，第一条消息建议带一个login帧，说明自己要进哪个房间。服务端拿到后把 socket 加入对应集合；断开时从所有房间里移除。

转发给同房间其他客户端：

void ChatServer::broadcast(const QString &room, quint16 type, const QByteArray &payload, QTcpSocket *except) { QSet<QTcpSocket*> clients = m_roomClients.value(room); for (QTcpSocket *s : clients) { if (s == except) continue; if (s->state() != QAbstractSocket::ConnectedState) continue; writeFrameTo(s, type, payload); } }

except参数用于排除发送者，实现单聊时扫描整个房间集合，再和发送者 socket 对比。群聊则不需要except，直接发给房间里所有人。这里的writeFrameTo和客户端writeFrame功能一模一样，只是把m_socket换成参数传入的 socket。房间数据结构用 QSet 存储指针，每个 socket 只存一次，避免重复发送同一条消息。

4. 文件收发：文件块、落盘与完整性校验

4.1 文件帧的协议设计：元数据、数据块、完成帧

文本消息跑通后，文件传输是第二个硬骨头。文件不能像文本一样整体塞进一个 JSON，因为几十 MB 甚至上百 MB 的二进制数据放到 JSON 里会产生大量转义开销，还可能超过帧负载上限。常见做法是划分成三种帧：

元数据帧的 JSON 结构如下：

{ "fileId": "a3f9c2e0-11b4-4f2e-9c88-6f1b8d0f5a21", "fileName": "report.pdf", "fileSize": 104857600, "fileMd5": "d41d8cd98f00b204e9800998ecf8427e", "blockSize": 65536 }

fileId是本次传输的唯一标识。每个文件用QUuid::createUuid().toString(QUuid::WithoutBraces)生成，接收端根据这个 id 创建临时文件。fileMd5用于最终完整性校验；虽然 MD5 已经不适合做安全校验，但在文件传输场景下检测字节损坏足够用了。

文件块帧不再用 JSON，而是固定二进制布局：前 16 字节是 fileId 的 ASCII 字符串，接着 8 字节是块在文件中的偏移量，后面紧跟原始文件数据。这样每个块都能独立定位，哪怕几个块先后顺序错乱，接收端也能按偏移写回正确位置。

4.2 发送端：分块读取并按信号错开发送

发送文件前先发元数据：

void FileSender::startSendingFile(const QString &path) { QFileInfo info(path); QByteArray id = QUuid::createUuid() .toString(QUuid::WithoutBraces).toLatin1(); m_file.setFileName(path); m_file.open(QIODevice::ReadOnly); m_fileId = id; m_totalSize = info.size(); QJsonObject meta; meta.insert("fileId", QString::fromLatin1(id)); meta.insert("fileName", info.fileName()); meta.insert("fileSize", static_cast<double>(info.size())); meta.insert("blockSize", static_cast<double>(m_blockSize)); sendFrame(kFileMeta, QJsonDocument(meta).toJson(QJsonDocument::Compact)); sendNextBlock(); }

关键技巧是发送第一个块之后不要循环发送全部，而是要等 socket 发出bytesWritten信号再发下一块：

void FileSender::sendNextBlock() { if (m_file.atEnd()) { if (!m_endFrameSent) { QJsonObject end; end.insert("fileId", QString::fromLatin1(m_fileId)); sendFrame(kFileEnd, QJsonDocument(end).toJson(QJsonDocument::Compact)); m_endFrameSent = true; } m_file.close(); return; } QByteArray block = m_file.read(m_blockSize); qint64 offset = m_file.pos() - block.size(); QByteArray payload; QDataStream out(&payload, QIODevice::WriteOnly); out.setByteOrder(QDataStream::BigEndian); out.writeRawData(m_fileId.constData(), 16); out << offset; payload.append(block); sendFrame(kFileBlock, payload); emit fileProgress(m_file.pos(), m_totalSize); }

offset的计算是整段代码最容易错的地方：read之后m_file.pos()已经指向读到的数据末尾，所以要减掉block.size()才能得到当前块的起始偏移。blockSize我习惯设置为 64KB。太小会增大帧头和 socket 写入的系统调用次数，吞吐量上不去；太大又容易在一次事件循环里占用太长时间，界面进度条更新会变得一卡一卡。

连接bytesWritten信号：

connect(m_socket, &QTcpSocket::bytesWritten, this, &FileSender::onBytesWritten); void FileSender::onBytesWritten(qint64) { if (!m_sendingFile) return; sendNextBlock(); }

这里不关心bytesWritten(qint64)的参数具体写了多少字节，只要知道“缓冲区有空位了”就继续发下一块。这比在循环里连续write整个文件要稳得多，既不会瞬间堆积几十 MB 到 socket 写缓冲，也不会因为一次写入过多导致内存飙升。

4.3 接收端：按块写临时文件并校验

接收端在handleFrame里识别kFileMeta、kFileBlock和kFileEnd。收到元数据后先打开临时文件：

QFile *FileReceiver::ensureFile(const QByteArray &fileId) { QString path = m_saveDir + "/" + QString::fromLatin1(fileId) + ".part"; QFile *f = new QFile(path, this); f->open(QIODevice::ReadWrite | QIODevice::Append); m_files.insert(fileId, f); return f; }

临时文件用.part后缀，全部接收完整并校验通过后，再改成真实文件名。这样即使传了一半就断开，下次启动也能根据.part文件判断是否可续传。

接收文件块：

void FileReceiver::handleFileBlock(const QByteArray &payload) { QByteArray fileId = payload.left(16); QByteArray remain = payload.mid(16); QDataStream in(remain); in.setByteOrder(QDataStream::BigEndian); qint64 offset; in >> offset; QByteArray block = remain.mid(8); QFile *file = m_files.value(fileId); if (!file || !file->seek(offset)) { emit fileError(QString("seek failed: %1").arg(fileId.constData())); return; } qint64 written = file->write(block); if (written != block.size()) { emit fileError("short write"); return; } m_receivedSize[fileId] += block.size(); emit fileProgress(fileId, m_receivedSize[fileId], m_totalSize[fileId]); if (m_receivedSize[fileId] >= m_totalSize[fileId]) { verifyFile(fileId); } }

seek到块对应的偏移处直接写入，天然支持乱序到达。写完之后累计已接收字节数，等于总大小就触发校验。有些实现会老老实实按顺序等待每个块，但网络层面并不能保证块到达顺序，一旦乱序就卡住，体验很差。按偏移写是更稳健的方案。

校验函数读取整个临时文件计算 MD5：

void FileReceiver::verifyFile(const QByteArray &fileId) { QFile *file = m_files.value(fileId); file->flush(); QCryptographicHash hash(QCryptographicHash::Md5); file->seek(0); while (!file->atEnd()) { hash.addData(file->read(1024 * 1024)); } if (hash.result().toHex() == m_md5[fileId]) { QString finalPath = QString::fromUtf8(m_finalName[fileId]); file->rename(finalPath); emit fileFinished(finalPath); } else { emit fileError(QString("md5 mismatch: %1").arg(fileId.constData())); } }

这里不要用file->readAll()一次性加载上百 MB，而是分 1MB 一块循环读，避免内存峰值太高。校验失败只能说明链路有逻辑问题，比如块重复写入或偏移算错；重新协商续传时，一定要让接收端先把已有临时文件大小告诉发送端，而不是直接整传。

4.4 文件传输的四个实战参数与反直觉教训

第一个反直觉教训是：块大小不是越大越好。64KB 已经很合适，升到 1MB 对局域网吞吐量的提升非常有限，但接收端seek加write一次要做的事明显变多，UI 更新频率也变得更难控制。第二个教训是：不要依赖write()一次写完。QFile::write在磁盘繁忙时可能只写入一部分字节，返回值小于block.size()时必须按“半写”处理，常见做法是记录剩余字节再循环写，或者直接报错触发重传。第三个教训是：进度信号不要每发送一个字节就emit一次，按块发射就够了，否则主线程会被事件风暴淹没。第四个教训是：临时目录不要和程序运行目录混在一起，最好放到独立的tmp/目录，清理旧.part文件时不会误删正式文件。

5. 避坑特辑：Qt 网络编程最容易翻车的五个细节

5.1 消息传来少半截，或者两条消息挤在一帧里

现象：客户端发一句“你好”，服务端收到时只有“你”，或者回显出来“你好”紧跟下一条消息，中间没有分隔。原因：TCP 是字节流，readyRead只是“有数据可读”，不保证一次读完一条消息。解决：所有消息统一走 2.3 节的帧缓冲解析逻辑，遇到负载不完整就留在缓冲区，等下一次readyRead继续。千万不要在onReadyRead里直接readAll()当一条消息处理。我刚开始实现时偷懒，测试 5 条短消息没问题，文件一传就崩，排查半天才发现是半包。

5.2 文件传一半断了，重连后又从头开始

现象：500MB 文件传到 300MB 时网络断了，重新连接后，发送端又从第 0 字节开始发，接收端已经存在的前半段全被覆盖。原因：传输状态没有持久化，接收端临时文件没有记录已接收区间，发送端也没有保存发送进度。解决：在kFileMeta中带上fileId和fileSize，接收端把.part文件的当前大小记录下来；重连后客户端发送一个恢复请求帧，里面带上 fileId 和已有字节数，发送端调用m_file.seek(resumeOffset)从断点继续发。恢复请求至少要覆盖到“已校验过的完整块”边界，否则可能把不完整的块当作已完成。

5.3 大文件没传完，界面已经“未响应”

现象：鼠标点击窗口没反应，任务管理器显示程序 CPU 占用不高但一直阻塞。原因：在文件发送槽函数里循环读文件写 socket，比如一口气write(file.readAll())，整个事件循环被占住，UI 消息排不上队。解决：用bytesWritten信号驱动发送，发送端一次只读 64KB，写完后立即返回事件循环。接收端同理，不要在一个槽函数里处理所有文件块，解析完当前帧就返回，让 Qt 继续派发 UI 更新事件。

5.4 中文昵称和消息乱码，跨平台后表现不一致

现象：Windows 客户端发的“你好”，Linux 服务端收到后显示成乱码；反过来也出现过服务端正常，Windows 客户端乱码。原因：发送端用了toLocal8Bit()，接收端用QString::fromUtf8()解码，两边编码不一致。解决：网络负载里统一用 UTF-8。发送文本时用toUtf8()，接收 JSON 时QJsonDocument::fromJson默认按 UTF-8 解析，解析出来的QString是纯 Unicode，交给 Qt UI 显示即可。不要手动转换本地编码，除非你要处理的是来自旧系统的 GBK 文件。

5.5 断开连接后程序崩溃或提示 double delete

现象：客户端强行关闭窗口，服务端日志显示“QObject: Cannot delete children for object that is in different thread”，或者程序直接崩在disconnected槽里。原因：在disconnected槽里直接delete socket，删除后又收到一次disconnected，导致二次释放；或者 socket 属于某个网络线程，却在主线程里被删除。解决：统一用s->deleteLater()，并且从m_clients、m_roomClients等容器中彻底移除。在移除前先断开所有信号：

void ChatServer::onDisconnected() { QTcpSocket *s = qobject_cast<QTcpSocket *>(sender()); if (!s) return; s->disconnect(s, nullptr, this, nullptr); for (auto it = m_roomClients.begin(); it != m_roomClients.end(); ++it) { it.value().remove(s); } m_clients.remove(s); s->deleteLater(); }

disconnect这一步非常关键，能防止容器遍历过程中又触发新的 readyRead 回调。多线程场景下，还要保证删除动作发生在 socket 所属线程里，一个简单做法是把deleteLater也通过事件队列投递到目标线程。

6. 让聊天室更抗用：心跳保活、断点续传与自动回归验证

6.1 心跳保活：30 秒一次，解决静默掉线

聊天室长时间不说话时，中间网络设备可能把空闲连接回收，客户端却不知道。常见做法是每 30 秒发送一个kPing帧，对端收到后回kPong。连续三次未收到kPong就主动断开连接并尝试重连。

void ChatClient::startHeartbeat() { m_heartbeatTimer->start(30000); connect(m_heartbeatTimer, &QTimer::timeout, this, [this]() { if (m_socket->state() != QAbstractSocket::ConnectedState) return; writeFrame(kPing, QByteArray()); }); }

收到kPong时重置连续丢失计数。心跳帧负载为空，不要把它混进文本业务逻辑里。我见过一个项目把 ping 做成普通文本消息，结果服务端把“ping”显示在聊天框里，很尴尬。

6.2 断点续传：恢复请求从文件头楔入

在文件接收端，临时文件已经存在时，启动程序后自动扫描.part文件，把它的大小记下来。客户端重连后如果检测到某个fileId的临时文件大小为 300MB，就发恢复帧：

void FileReceiver::requestResume(const QByteArray &fileId) { QJsonObject obj; obj.insert("fileId", QString::fromLatin1(fileId)); obj.insert("resumeOffset", static_cast<double>(m_receivedSize[fileId])); writeFrame(kFileResume, QJsonDocument(obj).toJson(QJsonDocument::Compact)); }

发送端在kFileResume里m_file.seek(resumeOffset)，然后从sendNextBlock()继续。注意恢复点必须对齐块边界，否则最后一个数据块会被切成两半写入。实际操作中，我一般让恢复点向下取整到blockSize的整数倍，宁可多传一个块，也不要因为偏移错位损坏文件。

6.3 自动回归验证：让通信链路可持续测试

每次改动协议后，重新手动测试很费时间。我的习惯是写一个不依赖 UI 的自动化测试脚本：启动服务端，启动两个测试客户端，一个发文本、一个发文件，最后比较文件 MD5 和服务端日志里的消息计数。

验证一个聊天室方向值不值得继续投入，关键要看“断网重连后是否能恢复”，而不是“局域网内能不能跑通”。如果断点续传、心跳、完整帧解析这三条链路都稳定，基本就具备做成产品的基础了。只有 UI 没有这些能力，换个网络环境就会被打回原形。我曾经在某聊天室项目里调了整整两天音视频卡顿，最后发现是心跳间隔太长导致连接经常被中间设备回收，数据通路断了却不自知。从那以后，我把网络编程当成状态机来写，所有超时、重连、恢复都在状态里显式表达，不再依赖“看起来还能跑”的实测结果。希望这一篇能帮你在做网络聊天室时少走几步弯路。

本文还有配套的精品资源，点击获取