企业官网建设流程全解析

毕设选了个仿QQ的通讯系统，三个月从零搭完客户端、服务端、数据库，最后答辩完还被导师留下来问了一小时技术细节。回头整理一下整个项目的思路和踩坑过程，给准备做Qt项目或者想给简历加亮点的人一个完整参考。

这个项目适合两类人：一类是毕业设计还没定题，不想再做增删改查管理系统的；另一类是已经工作但想用业余项目系统提升C++/Qt能力的。整个项目涉及界面开发、TCP网络通信、自定义协议、多线程、SQLite数据库、文件传输、打包发布，几乎把桌面开发的常见环节都过了一遍。做完之后，你对Qt的熟练度、对网络编程的理解，都会上一个台阶。

1. 项目定位：为什么毕业设计选它

1.1 这个项目解决了什么问题

不少同学的毕设是“XX管理系统”，表面上是软件开发，实际是数据库的增删改查套壳。技术上没有深坑，面试时也说不出来什么亮点。仿QQ通讯系统则完全不同，它天然带有多用户、实时通信、在线状态、消息推送这些实时系统的核心元素，每一个模块都能延伸出值得聊的技术问题。

从时间投入来看，这个项目的体量也合适。一个人正常节奏下，客户端加服务端加数据库，三个月可以做出一个能演示的完整版本。如果选音视频、大型分布式这种题目，一个人很难做得深入；如果选管理系统，又太单薄。仿QQ通讯系统属于那种“看起来不难，但做起来有东西”的题目，特别适合作为个人作品。

从简历价值来看，它能同时体现三方面能力：C++/Qt界面开发能力、TCP网络协议设计能力、服务端并发处理能力。这三个方向在桌面开发、嵌入式、后端开发岗位里都能讲出故事。

1.2 技术选型复盘：为什么是Qt而不是其他

第一反应是为什么不用Web前端做，因为Web聊天室确实更常见。但Web前端做聊天，核心逻辑在浏览器和后端接口里，客户端这边只剩下页面渲染，C++相关的亮点基本没有。对计算机专业或者嵌入式方向的学生来说，用C++做客户端更匹配课程知识体系。

选Qt而不是其他C++界面库，理由很实在：

• Qt Widgets控件成熟，QListWidget、QTreeWidget、QTextEdit这些能直接搭出聊天软件的骨架，不必从零写控件。
• Qt的跨平台特性，Windows上写完，Linux环境下编译也能跑。热词里经常有人问“Linux跑Qt还是lvgl”，如果你目标是嵌入式上位机，Qt也是更稳妥的选择。
• Qt的网络模块QTcpSocket、QTcpServer封装得比较好，读写接口清晰，适合在毕设周期内完成。
• 资料多。遇到编译问题、运行崩溃，一搜基本都有答案，不至于卡死。

有人纠结用QML还是Widgets。QML做动画和现代感界面确实强，但这套系统的核心是通信逻辑和C++数据结构，Widgets配合QSS已经能做出很精致的聊天界面，而且调试起来比QML加C++混合模式简单。毕设项目我建议Widgets，稳。

版本选择上，我最后用的Qt 5.15.2配MinGW 8.1.0。原因有两个：Qt 5.15.2是5系列的最终LTS版本之一，稳定且社区资料最全；MinGW版本做离线安装包方便，编译出来的exe依赖相对简单。如果你需要MSVC版本，要注意运行时库和调试器配置，新手容易在这上面折腾很久。

1.3 系统总体架构与功能清单

整体架构分三层：

• 客户端层：登录注册窗口、主窗口、聊天窗口，负责界面展示和用户交互。
• 网络层：客户端网络管理类，持有QTcpSocket，负责收发消息帧；服务端网络层，持有QTcpServer和连接管理对象，负责接入客户端、解析消息、路由分发。
• 数据层：SQLite数据库，存用户、好友关系、聊天记录、离线消息。

客户端和服务端之间通过自定义TCP协议通信。客户端发登录请求、注册请求、聊天消息、心跳包；服务端返回登录结果、好友列表、离线消息、新消息推送。

功能清单大致如下：

如果你时间充裕，还能往里面加语音消息、聊天记录搜索、换肤、国际化（Qt国际化那一套，tr机制加翻译文件）。但先把上面这些做扎实，就已经是一个完整作品了。

2. 环境搭建与工程骨架

2.1 Qt版本和编译器的选择

如果你刚接触Qt，最容易卡在环境上。Qt的安装方式有在线安装包和离线安装包两种。国内网络环境下我建议直接下载离线安装包，版本选5.14或者5.15.2的都行。下载时要勾选对应的编译器组件，比如MinGW 8.1.0 64-bit，以及Qt Charts（如果后面要做统计图可以选上，不用就先不装）。

不要一上来就装多个Qt版本。热词里经常看到“cannot mix incompatible Qt library (5.15.3) with this library (5.15.2)”，这类问题多数就是系统里装了多个版本，某个项目的构建目录没有清理干净，导致编译时链接了不同版本的头文件或库。遇到这种报错，第一步是删除build目录，第二步是确认项目里用的qmake路径指向了正确的Qt版本。

编译器选择上，简单说就是：用MinGW，发布方便，传到别的机器上只要带上对应运行库就能跑；用MSVC，和Windows生态结合更好，某些依赖库（比如OpenSSL）的二进制包更全。毕设自用推荐MinGW，但建议至少知道MSVC怎么切换，因为有些公司面试会问。

2.2 创建客户端与服务端两个工程

在Qt Creator里不要把所有代码堆在一个工程里。我把项目拆成三个部分：

• Client工程：可执行程序，依赖common。
• Server工程：可执行程序，依赖common。
• common模块：不自带可执行文件，只放协议定义、枚举、序列化辅助函数、全局常量。

common模块用pri文件共享。在Client.pro和Server.pro里加上：

include(../common/common.pri)

common.pri里写：

INCLUDEPATH += $$PWD SOURCES += $$PWD/protocol.cpp HEADERS += $$PWD/protocol.h

这样两边的代码能直接用同一套协议结构体，避免客户端定义一遍、服务端又定义一遍，后面改字段时两边不同步，排查半天才发现是协议对不上。

2.3 公共模块：日志、配置与全局常量

开发阶段最容易忽略日志，到了调崩溃的时候才后悔。我用qInstallMessageHandler把qDebug、qWarning、qCritical输出重定向到日志文件，格式带上时间、线程ID、文件行号。这样程序在用户那边跑挂了，能直接拿日志回来看最后几行在干什么，比瞎猜快得多。

配置用QSettings读写ini文件，保存服务器IP、端口、本机用户ID、记住密码的账号信息。开发时服务器IP填127.0.0.1，演示时可能要用到局域网真实IP，做成配置项就不用重新编译。

全局常量和枚举放在common的头文件里。比如：

enum MsgType { MT_UNKNOWN = 0, MT_REGISTER_REQUEST, MT_REGISTER_RESPONSE, MT_LOGIN_REQUEST, MT_LOGIN_RESPONSE, MT_LOGOUT_REQUEST, MT_FRIEND_LIST_REQUEST, MT_FRIEND_LIST_RESPONSE, MT_CHAT_SINGLE, MT_CHAT_GROUP, MT_FILE_TRANSFER, MT_HEARTBEAT, MT_OFFLINE_MESSAGE, MT_FRIEND_STATUS_CHANGE };

以后每新增一种消息类型，只改这个枚举和对应的处理函数，架构上很好扩展。

2.4 高DPI与全局外观修饰

很多时候写完界面在自己电脑上正常，换到高分屏机器上字体发虚、控件错位。解决办法是在main.cpp最前面加：

QApplication::setAttribute(Qt::AA_EnableHighDpiScaling); QApplication::setAttribute(Qt::AA_UseHighDpiPixmaps);

从Qt 6开始高DPI默认开启，但在Qt 5里必须手动设置。这个细节同样值得写进简历的“踩坑记录”里，很多面试官喜欢听这种实际问题。

QSS方面，我给项目写了一套仿QQ的简洁样式：整体白色背景，左侧导航栏深色，消息区域浅灰，在线好友绿色圆点表示。QSS的写法类似CSS，比如给QListWidget设置条目高度和悬浮背景：

QListWidget::item { height: 56px; border-radius: 8px; } QListWidget::item:hover { background-color: #f0f0f0; }

一开始不要追求花哨，先把布局和交互逻辑跑通，最后再统一美化。

3. 核心底层：通信协议与数据库设计

3.1 自定义TCP消息帧：粘包半包彻底解决

TCP是流式协议，没有消息边界。连续发两条消息，接收方可能一次性收到两段数据，也可能收到半段数据。这就是粘包和半包，凡是用TCP做应用层通信，必定会遇到。

解决办法是自定义消息帧。我定义的消息帧结构如下：

| 4字节 消息总长 | 4字节 消息类型 | N字节 JSON数据 |

也就是每个消息前面加一个定长头部，头部里记录整个消息的长度。接收方先收满8字节头部，解析出长度，再继续接收对应长度的数据，直到一条完整消息到达。之后循环处理下一条。

在Qt里，我封装一个RecvBuffer类来处理这个过程。核心逻辑是先判断缓冲区里有没有8字节头部，没有就等数据；有就取出len字段，再判断剩余数据长度是否达到len，不够继续等，够就切出完整一条消息并emit信号。用状态机方式逐字节推进，逻辑清晰，不容易出错。

发送方则简单一些，用QByteArray拼接头部和JSON数据，一次write发出。网络底层会保证数据不丢，但应用层必须自己做组装。

提示：关于消息类型，我只在头部存了数字类型，JSON里不再重复放消息类型，避免冗余和歧义。解析时先用头部确认类型，再按类型解析JSON负载。

3.2 消息JSON负载设计

消息体用JSON序列化，主要是看中它的可读性。直接抓包或者打日志就能看到内容，调试效率高。如果是高性能场景可能用protobuf更省带宽，但毕设阶段JSON完全够用。

一个聊天消息的负载长这样：

{ "from": 10001, "to": 10002, "type": 1, "content": "你好，我是测试消息", "time": "2025-05-18 10:30:00", "extra": "" }

字段不要乱定义，一定要集中管理。我在common里写了一个ProtocolHelper类，封装消息的打包和解析函数，比如：

QByteArray ProtocolHelper::packMessage(int msgType, const QJsonObject &payload); bool ProtocolHelper::unpackMessage(const QByteArray &block, int &msgType, QJsonObject &payload);

这样客户端和服务端调同一个函数，不会出现服务端期望的字段名和客户端发的不一致。这个问题非常隐蔽，我踩过一次，JSON里拼错了一个字段名，服务端拿到的是空值，查了很久才通过日志发现。

3.3 数据库表设计：用SQLite搞定存储

数据库选了SQLite，因为它是文件型数据库，不用额外装服务，部署简单。毕设数据量一般几百个用户、几万条消息，SQLite完全能扛住。如果以后要换成MySQL，只要把数据库访问层单独封装，改动范围可控。

建表SQL如下：

CREATE TABLE IF NOT EXISTS user ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT UNIQUE NOT NULL, password_hash TEXT NOT NULL, nickname TEXT NOT NULL, avatar_path TEXT, signature TEXT, created_at TEXT DEFAULT (datetime('now', 'localtime')) ); CREATE TABLE IF NOT EXISTS friend ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, friend_id INTEGER NOT NULL, group_name TEXT DEFAULT '我的好友', remark TEXT, UNIQUE(user_id, friend_id) ); CREATE TABLE IF NOT EXISTS message ( id INTEGER PRIMARY KEY AUTOINCREMENT, from_id INTEGER NOT NULL, to_id INTEGER NOT NULL, msg_type INTEGER NOT NULL, content TEXT, create_time TEXT DEFAULT (datetime('now', 'localtime')) ); CREATE TABLE IF NOT EXISTS offline_message ( id INTEGER PRIMARY KEY AUTOINCREMENT, to_id INTEGER NOT NULL, from_id INTEGER NOT NULL, msg_type INTEGER NOT NULL, content TEXT, create_time TEXT DEFAULT (datetime('now', 'localtime')) );

密码不能明文存储，我用QCryptographicHash加盐做哈希，盐值取用户名。虽然SHA系列不算最安全的方案，但比明文强太多了，也足够应对答辩提问。回答“为什么不用明文”时，可以提一下哈希不可逆和防撞库的基本原理。

3.4 心跳机制与会话保活

用户如果直接拔网线或者断电，TCP连接不一定立刻断掉。如果服务端不主动清理，连接池里会堆一堆不可用连接，在线状态也不准确。

客户端开一个定时器，每60秒发送一个心跳消息，消息类型为MT_HEARTBEAT，负载里带一个随机数或者当前时间戳。服务端收到心跳后，更新这个连接的最后活跃时间。

服务端启动一个定时清理任务，每30秒扫一次所有连接，如果某个连接的最后活跃时间超过90秒，就判定掉线，关闭socket并且清理用户会话。每次收到普通消息也刷新最后活跃时间，避免活跃用户还要额外发心跳。

心跳设计里有一个细节：心跳消息不需要业务响应，服务端收到后什么都不用回，减少无效流量。服务端只负责更新时间和感知连接存活。

4. 客户端实操：从登录窗口到聊天界面

4.1 登录注册模块与头像处理

登录窗口是用户看到的第一个界面，也是整个客户端流程的入口。在构造函数里做三件事：加载配置里的服务器IP和端口、初始化网络管理器对象、连接业务信号槽。登录按钮点击后，把用户名密码打包成JSON，经网络层发给服务端，等待响应。

登录窗口布局用QWidget加垂直布局，加一个Logo QLabel，下面两个QLineEdit，再加登录和注册两个按钮。密码框设置EchoMode为Password，同时加一个“显示密码”的勾选框。回车发送操作通过事件过滤器实现，重写eventFilter，检测到回车键时触发登录逻辑，这个小细节在演示时很加分。

注册流程里最绕的是头像。步骤是：用户点击头像区域 → 弹QFileDialog选择图片 → 把图片缩放到128x128正方形并居中裁剪 → 保存到本地临时目录 → 注册请求里附带头像文件路径或二进制数据。如果走二进制传输，服务端保存文件并记录路径，注册响应里带回头像URL；如果头像比较大，可以优化成先传文件再注册，这个阶段可以简化。

缩略代码示例：

QImage image(filePath); QImage scaled = image.scaled(128, 128, Qt::KeepAspectRatioByExpanding, Qt::SmoothTransformation); int x = (scaled.width() - 128) / 2; int y = (scaled.height() - 128) / 2; QImage crop = scaled.copy(x, y, 128, 128);

4.2 主窗口框架：左侧导航与消息列表

登录成功之后进入主窗口。主窗口布局我采用左右结构：左侧是一个固定的导航栏，宽度80像素，放三个图标按钮（消息、联系人、设置）；中间是会话或联系人列表；右边是聊天区域。

中间列表用QListWidget，每个item用setItemWidget嵌入自定义的会话条目widget。这个widget里左边是一个圆形头像QLabel，中间竖排两行文字（昵称加最后一条消息），右上角是一个未读消息角标。未读角标是自己绘制的QLabel，圆形红底白字，数字超过99显示99+。

会话列表的数据结构是QMap<int, SessionItem*>，以好友ID为键。收到新消息时，如果会话不存在就新建一条，存在就更新最后一条消息预览并把会话顶到列表最上方。最近会话排序是聊天软件的核心交互体验，一定要实现。

联系人列表用QTreeWidget按分组展示，分组名来自数据库里的group_name字段。双击联系人或点击右键菜单里的“发送消息”都能打开聊天窗口。好友上线、下线状态通过服务端推送的MT_FRIEND_STATUS_CHANGE消息更新，在头像左下角画一个绿色或灰色圆点。

4.3 聊天窗口与消息气泡自绘

聊天区是整个项目里UI最花心思的地方。我选QListWidget做消息列表容器，每一条消息是一个item，item里嵌一个自己绘制的气泡widget。为什么不用QTextEdit？因为QTextEdit做富文本流式布局虽然方便，但要对齐左右两侧、显示头像和状态，控制起来不如自绘灵活。

气泡widget重写paintEvent，根据消息方向绘制圆角矩形。自己发的消息靠右，背景浅蓝色，好友发的靠左，背景白色。气泡一角画一个小三角箭头，指向头像方向。

绘制逻辑要注意：

• 先用QFontMetrics计算文本换行后的高度，再决定气泡高度。
• 每条消息item宽度固定，高度根据文本动态计算。
• 图片消息直接嵌入QLabel，按固定最大宽度等比缩放。
• 发送状态：消息先在UI里显示为“发送中”，收到服务端确认后改为正常状态，失败显示红色感叹号。

自动滚动到底部用QListWidget::scrollToBottom()，但在大量消息初始化的时候会闪烁，可以先用setUpdatesEnabled(false)关闭刷新，批量插入完成后再恢复。

4.4 文件传输与自定义进度条

文件传输我用的是服务端转发模式，客户端A把文件分块发给服务端，服务端再转发给客户端B。这样做的好处是双方不需要建立点对点连接，避免NAT穿透的麻烦，毕设场景足够。

文件传输协议可以复用消息帧，但要把body设计成“文件传输”专用结构：

• 类型字段置为MT_FILE_TRANSFER。
• JSON部分放文件名、文件大小、总块数、当前块序号。
• JSON之后直接追加一块二进制数据。

每块大小设置为1MB。接收方每收到一块，就追加写入本地文件，并更新进度条。最后一块写完后校验文件大小，和发送方声明的大小对比，不一致则提示重传。

自定义进度条直接继承QProgressBar，重写paintEvent。默认的进度条样式比较原始，我把它改造成圆角矩形背景，内部用渐变颜色填充，中央显示百分比文字：

void CustomProgressBar::paintEvent(QPaintEvent *) { QPainter painter(this); painter.setRenderHint(QPainter::Antialiasing); double percent = this->value() / double(this->maximum()); // 绘制背景圆角矩形 // 按 percent 绘制前景 // 绘制百分比文字 }

传输过程中要防止界面卡住。所有文件读写都放到工作线程里，用自定义信号ReportProgress(int percent)更新进度条。最开始的版本直接在UI线程里读文件，大文件一卡就是好几秒，后来改成线程加信号槽才解决。

4.5 多线程网络层与UI刷新

客户端网络层我单独抽出一个ClientNetworkManager类，内部持有一个QThread和QTcpSocket对象。socket创建后moveToThread到工作线程，所有socket读写都在这个线程完成，不占用UI线程。网络层通过信号槽和主窗口通信，比如收到消息时emit messageReceived(QJsonObject)，主窗口在槽函数里刷新UI。

这个设计的原因很简单：QTcpSocket如果放在UI线程，网络阻塞或者大量数据到达时，UI会卡顿，最典型的表现是拖动窗口不流畅、消息延迟显示。用工作线程后，UI线程只负责渲染，网络线程只负责收发。

实现上要小心一个坑：默认情况下信号槽连接类型是AutoConnection，跨线程时会自动变成QueuedConnection，槽函数在接收者所在线程执行。这正好符合我们的需求。但如果是lambda表达式并且直接捕获了UI指针，一定要通过QObject::connect连接，不要手动调用，不然可能跨线程访问控件导致崩溃。

客户端关闭时的清理也容易出问题。在closeEvent里先发送MT_LOGOUT_REQUEST，然后调用socket的disconnectFromHost()，最后等线程退出再关闭窗口。如果直接销毁窗口而不处理socket，可能触发“QThread: Destroyed while thread is still running”的警告。

5. 服务端实操：并发与业务逻辑

5.1 线程模型选择：每连接一线程最直接

服务端我采用“每连接一线程”模型。QTcpServer收到新连接后，创建或者复用ConnectionHandler对象，把它分配到线程池或者放到一个QThread里执行。连接断开时线程可以回收或者销毁。

毕设规模下这样写最直观，每个连接一个独立的处理循环，不存在共享socket的问题。如果追求更高并发，后续可以改成epoll或者事件驱动模型，但这个复杂度不是毕业设计必须的。

所有连接中的socket对象由服务端统一管理。我维护一个Map：

QMap<QTcpSocket*, UserInfo> m_onlineUsers;

同时，为了根据用户ID找到连接，再维护一个：

QMap<int, QTcpSocket*> m_userToSocket;

用户登录成功后，会把userId和socket关联起来。以后给某个用户推送消息，只需要查表拿到socket，再packMessage发送。

5.2 消息路由与在线状态维护

用户发一条单聊消息，流程是这样的：

1. 客户端组装消息帧，发送给服务端。
2. 服务端解析出msgType和JSON负载，拿到fromId和toId。
3. 服务端先落库消息记录，保证聊天记录可追溯。
4. 查m_userToSocket，目标用户是否在线。在线则转发给目标socket；不在线则写入offline_message表。
5. 给发送方回一个ACK，表示消息已到达服务端。

这个流程里最关键的是“先落库再转发”。如果先转发后落库，服务端进程崩溃时消息就丢了。先落库再转发，即使网络异常，离线补发也能把消息补上。

群聊逻辑稍微复杂一点。收到群聊消息后，从group_member表查出所有群成员，再逐个检查在线状态并转发。为了避免群成员收到自己发的消息，需要跳过fromId本身。群聊消息也要落库，落库时toId存group id，业务上通过msg_type区分单聊群聊。

5.3 离线消息与上下线广播

用户登录成功后，服务端除了返回登录结果，还要把离线消息查出来发给客户端。这里有一个细节：先发登录响应，再发离线消息列表，客户端收到登录成功后再进入主窗口，接着处理离线消息，这个顺序不能反。否则主窗口还没初始化完，消息列表就往里塞数据，可能会出现空指针。

上下线广播是仿QQ体验的重要功能。用户A登录成功后，服务端找出A的所有好友，给在线的好友推送一条MT_FRIEND_STATUS_CHANGE消息。这样好友界面上A的头像会立刻变绿。用户A退出时同理，群发下线通知。

在线状态要考虑异常掉线的情况。前面说的心跳超时机制就在这里发挥作用：超过90秒收不到心跳，服务端判定用户掉线，主动清理会话，并广播下线状态。如果客户端还在线但网络中断，服务端可以及时感知，不会出现“明明下线了还显示在线”的尴尬。

数据库并发访问也要注意。多个连接线程同时操作SQLite，不加锁可能出现“database is locked”错误。我在服务端维护一个全局QMutex，所有数据库写操作都加锁。SQLite性能虽然不错，但并发写要串行化，这个锁是必要的。

6. 常见问题与排查实录

6.1 高频编译报错：unknown module与版本冲突

热词里反复出现“unknown module(s) in qt: serialport”，这是因为pro文件里写了QT += serialport，但当前Qt版本没装SerialPort模块，或者模块名拼错了。这个报错和本项目相关的场景是：如果你装了Qt Charts、Qt SerialPort，又没在安装时勾选对应模块，任何工程引入都会报这个错。解决办法是回到Qt安装器，把对应模块补装上。

另一个高频问题是Qt版本混用。常见于电脑上装了Qt 5.15.2和5.15.3，某个项目在旧版本的构建目录里还残留着编译中间文件，新版本编译时报“cannot mix incompatible Qt library”。定位方法是看编译输出的完整路径，确认qmake.exe来自哪个版本目录。然后在Qt Creator里执行“清理项目”，手动删除build目录，重新构建。

还有“error while building/deploying project ... kit desktop qt 5.9.9 mingw”这类问题，通常是选错了Kit。检查一下当前项目使用的Kit是不是和安装的编译器匹配。如果两者版本不一致，重新选择Kit或者重装对应编译器组件。

6.2 运行期崩溃与跨线程访问

客户端最常见的崩溃就是跨线程访问UI。典型场景：网络线程收到数据后直接调用了某个UI控件的setText，导致Qt断言失败或者随机崩溃。解决方法是所有UI更新必须通过信号槽传递到主线程，绝不能在子线程里直接操作QWidget对象。

服务端常见的崩溃是空socket访问。用户断开连接后，如果定时器里还持有这个socket的指针并调用write，很可能产生未定义行为。我的处理是：连接断开时立刻从m_userToSocket移除对应项，所有事件处理器都先检查socket是否为空、是否还在线列表里。

排查崩溃时最有效的工具是日志加退出代码。在main函数里设置：

std::set_terminate([](){ qCritical() << "terminate called"; abort(); });

这样崩溃前会把最后的日志刷到文件里，配合qInstallMessageHandler的输出，能从最后几条日志快速定位崩溃点。

6.3 打包发布与运行库

Qt程序在开发机上能跑，复制到别的电脑上报“缺少Qt5Widgets.dll”或者“0xc000007b错误”，这几乎是每个人都会遇到的。

打包流程很简单，用Qt自带的windeployqt工具：

1. 把编译好的exe单独放在一个目录里。
2. 在命令行运行：windeployqt yourApp.exe。
3. 工具会自动复制Qt运行库、platforms插件、样式插件等到exe同目录。
4. 然后手动加上你的数据库文件、日志目录、配置文件。

特别提醒：platforms目录下的qwindows.dll一定不能少，缺失时程序会启动失败。如果用了MinGW编译器，还要带上libgcc_s_seh-1.dll、libstdc++-6.dll、libwinpthread-1.dll，这几个动态库在Qt安装目录的bin下能找到。

如果想要单文件绿色版，可以给Qt做静态编译，但静态编译Qt本身非常耗时，不推荐新手折腾。用NSIS或者Inno Setup把目录打成安装包是更快的方案。

6.4 实用排查技巧速查表

7. 从项目到简历：如何放大它的价值

7.1 简历上怎么写这个项目

项目描述不能只写“实现了一个聊天软件”。用数据说话，用技术点说话。可以参考这个结构：

项目名称：仿QQ即时通讯系统 技术栈：C++、Qt Widgets、TCP/IP、SQLite、JSON、多线程、自定义协议 项目描述：

• 独立完成客户端与服务端的分布式架构设计，实现用户注册、登录、好友管理、单聊、群聊、文件传输、离线消息、上下线提醒等完整功能。
• 设计基于TCP的自定义消息帧协议，解决粘包半包问题，通过JSON实现可扩展的业务消息结构，字段可动态增减。
• 客户端采用网络层与UI层分离的多线程架构，socket收发在独立线程，通过信号槽机制与主界面通信，保证大量消息刷屏时界面流畅。
• 服务端使用每连接一线程模型，维护在线用户表与用户会话映射，支持多客户端接入，实现心跳超时检测与自动清理僵尸连接。
• 基于SQLite存储用户、好友关系、聊天记录与离线消息，密码使用加盐哈希存储，支持断线重连后的消息补发。
• 自主实现消息气泡自绘、文件传输进度条、未读消息角标、系统托盘提醒等交互细节。

每一条都对应一个可追问的技术点。面试官顺着任何一个点往下问，你都能答出设计原因。

7.2 面试会被问到的技术点

做完这个项目，你去面试时大概率会被问到这些问题：

• 消息怎么保证不丢失？答案围绕ACK机制、落库再转发、离线消息重发展开。
• 怎么解决粘包半包？头部长度字段加缓冲区状态机。
• 好友在线状态是怎么维护的？登录时注册m_userToSocket，心跳超时剔除，广播上下线事件。
• 如果同时一万人在线，你的服务端扛得住吗？主动承认这个模型有瓶颈，然后说明可以怎么优化：线程池、异步IO、多路复用。
• 密码加密方案？加盐哈希，能扯到彩虹表攻击更佳。

这些问题都能从项目的真实代码中找到答案，属于“做过就有底气”的类型。

7.3 后续可以扩展的方向

如果时间允许，我建议在这个版本上加三个功能，简历价值立刻再上一个台阶。

第一个是断线重连与消息确认机制。客户端检测到socket断开后，按指数退避策略自动重连，重连成功后拉取离线消息。这对应更可靠的通信流程，也是生产级IM系统的基础能力。

第二个是消息加密与TLS。Qt的QSslSocket支持TLS，加上自签名证书就能实现加密传输。虽然毕设演示环境用不上，但这个点和上面提到的密码哈希可以直接呼应“安全性设计”，是面试加分项。

第三个是把服务端改造成高并发模型。不做也可以，但你至少要能说出不同方案之间的差异：每连接一线程、线程池、select/poll/epoll、以及libevent/boost.asio这类封装库，各自适用的连接数和CPU要求。

记得微信里那种“对方正在输入…”的提示，在协议上就是客户端定时发送一条状态消息，服务端只透传不下发数据库，实现很简单但很提升完成度。如果你还有余力，加上它。

最后说两句

做完整个项目，我最深的一点体会是：一个看似简单的聊天软件，真从零写一遍，会遇到协议设计、线程安全、界面性能、异常处理一堆实际问题。这些问题恰恰是面试官最想听的，因为它们是教科书之外的东西。

如果你也想做这个方向，我给三个建议：第一天就建Git仓库，每个功能一个分支，别偷懒；日志从写第一行代码就加上，后期调bug事半功倍；功能宁可少做，一定要做完，半成品比没有更可惜。手头有代码，心里才有底气。做完这个项目，再去投简历，你就不是那个只写过课设的人了。