刚开始用 Qt 做 TCP 通信的时候，我和大多数人一样，只盯着readyRead信号，觉得数据到就处理，demo 里跑得很欢。结果一上真实项目，连续几条设备数据同时到，程序就开始乱跳，日志里一堆看不懂的乱码，有时候直接卡死。这就是TCP 粘包拆包的坑，谁踩过都懂。
TCP 是流式协议，不像 UDP 那样一个数据包一个报文边界。你在 demo 里每条命令单独发，可能不会看到问题，但项目里多线程采集或者设备发大块数据时，数据边界就会模糊。readyRead触发时，你拿到的QByteArray可能是一条消息，也可能是半条消息，或者几条消息连在一起。简单处理就是丢包、卡死和逻辑错乱。
项目里我通常会这么处理：维护一个接收缓冲区，每次readyRead先 append 到缓冲区，然后按协议去拆包。比如固定长度协议就直接按长度切，带分隔符协议就找分隔符。像这样：
buffer.append(socket->readAll());while(buffer.contains('\n')){intindex=buffer.indexOf('\n');QByteArray packet=buffer.left(index);buffer.remove(0,index+1);processPacket(packet);}这一段代码解决了半包和粘包问题。短时间看没啥，但长期开机几天，整个工业上位机系统就稳定了。尤其是设备频繁发数据、界面要实时显示的时候，这一步不做，线程和 UI 的同步逻辑就会崩。
为什么推荐这样做？因为 TCP 本质就是字节流，Qt 的readyRead只是告诉你有数据可读，它不会保证消息完整。项目里粘包拆包不处理，后果很容易和以下场景绑定：多线程数据处理、UI 实时刷新、数据库写入。一条半包数据进入数据库，结果就是乱序或者非法条目，排查起来比重写一个线程池还累。
常见坑或者经验提醒：
- 不要以为每次 readyRead 到的数据就是一条完整消息。即便 demo 正常，项目里并发多，包就粘了。
- 不要用信号直接处理业务，先缓冲再拆包。直接处理会导致半包逻辑异常。
- 多设备场景下，每个 socket 都要独立缓冲，不要共用同一个 QByteArray。
- 不要忽视异常数据，拆包逻辑里加判断和日志，出问题能定位。
最后说两句，Qt TCP 的门槛不在 API 本身，而在你能否正确识别和处理消息边界。忽略粘包拆包，短期没事，长期就会掉坑。熟悉了这个逻辑，再复杂的工业数据流也能稳得住。
