qt聊天客户端核心是理清用户身份链与消息生命周期：注册登录需服务端鉴权对齐，好友关系须sqlite与mysql双向同步，消息发送/送达/已读依赖msg_id等协议字段驱动；tcp通信须处理粘包（如4字节包头）、避免readall()误吞数据；sqlite搜索应建索引或用fts5；多线程中qtcpsocket和ui更新须严格遵循线程归属与信号槽机制。
Qt开发聊天交友客户端，核心不是堆控件，而是理清「用户身份链」和「消息生命周期」——注册/登录必须和服务端鉴权对齐，好友关系必须在本地 SQLite 和服务端 MySQL 之间做状态同步，而每条消息的发送、送达、已读，得靠协议字段（比如 msg_id、status、ack_seq）驱动，不能只靠 UI 点击事件。
QTcpSocket 连接服务端时收不到响应？检查协议头和缓冲区处理
很多初学者用 QTcpSocket::write() 发完 JSON 或二进制包就等着 readyRead()，结果服务端明明回了数据，客户端却卡住。根本原因是没处理 TCP 粘包/半包：服务端一次 send() 可能被拆成多次到达，或多个小包被合并成一个 pendingDatagramSize() 返回。
- 必须自己定义协议头（比如前 4 字节是包总长度），在
readyRead()中循环读取，直到凑够完整一帧 - 别用
readAll()直接取全部缓冲区——它会把下一条消息也吞进来 - 调试时用
qDebug() bytesAvailable();看当前缓存字节数，确认是否真有数据可读 - 服务端若用
QDataStream写入，客户端必须用相同字节序和版本反序列化，否则stream >> type会失败静默跳过
SQLite 存好友列表但搜索/排序变慢？避免 SELECT * + LIKE 全表扫
当好友数超 200 人，用 SELECT * FROM friend WHERE name LIKE '%关键词%' 会导致 UI 卡顿甚至假死——LIKE 前导通配符无法走索引，每次搜索都全表扫描。
- 建复合索引：
CREATE INDEX idx_friend_name ON friend(name)（仅对name LIKE '张%'有效） - 模糊搜索改用 FTS5 全文检索：
CREATE VIRTUAL TABLE friend_fts USING fts5(name, remark)，插入时同步写入 - 本地搜索逻辑放到 Worker 线程，用
moveToThread()+ 信号传递结果，别堵主线程 - 不要把头像路径、签名等大字段塞进主表，单独建
friend_profile表用friend_id关联
点击好友按钮后聊天窗口空白？检查 QThread 与 QObject 的父子关系
常见错误是把 QTcpSocket 或数据库查询对象直接 new 在子线程里，却不显式设置 parent，导致对象析构时机错乱、信号无法跨线程 emit、甚至 crash。
- Worker 对象必须继承自
QObject，且在子线程中调用moveToThread()后，再 connect 信号槽 -
QTcpSocket必须在创建它的线程中 delete，不能在主线程 delete 子线程创建的 socket - UI 更新（如
ui->chatBrowser->append()）必须通过信号触发，禁止在子线程里直接调用 - 调试时加断点看
this->thread() == QThread::currentThread()，确保操作在所属线程内
最易被忽略的是离线消息同步时机：用户登录成功后，服务端发来的离线消息包如果在 UI 初始化完成前到达，readyRead() 信号可能被丢弃——因为槽函数还没 connect。必须确保网络模块早于界面构建启动，并用队列暂存未处理消息，等聊天窗口 ready 后再 flush。
