1、课程导论：为什么粘包拆包是网络编程的必修课？从一次线上事故说起

几年前，我负责一个高并发即时通讯服务的核心模块。上线第三天，凌晨两点，告警电话响了。

用户反馈：消息串了。A 用户发的「你好」，B 用户收到的是「你好吃饭了吗」的前半截。更诡异的是，有些消息直接丢了，客户端解析报错，连接断开。

我第一反应是「协议有问题？」。检查了业务逻辑，确认无误。抓包一看，TCP 流里数据整整齐齐，一个字节没丢，一个字节没多。问题出在哪？

嗯，说白了，就是粘包和拆包。

那次事故让我意识到：不懂粘包拆包，你写的网络程序就是一颗定时炸弹。今天这节课，我们就从协议栈的视角，把这个「必修课」彻底讲透。

核心认知：粘包拆包不是 Bug，是 TCP 流式传输的固有特性。你无法消灭它，只能驾驭它。

很多新手会问：我 send 了两次，recv 就应该收到两次，不是吗？

错。

TCP 是流式协议。它不关心你发了几条消息，只关心字节流的顺序和可靠性。底层会把数据切成一个个 segment，经过网络传输，在接收端重组。这个过程中，消息边界完全丢失了。

举个例子：

发送端：
send("Hello")
send("World")

接收端可能收到：
recv("HelloWorld")   // 粘包：两条消息粘在一起
recv("Hel")          // 拆包：一条消息被拆成两半
recv("loWorld")      // 组合：拆了又粘

为什么会这样？

我习惯用「水管」来比喻。TCP 是一条水管，你往里倒水（数据），对端从另一头接水。水管不会记住你倒了几次，它只管把水送过去。你倒两次水，对端可能一次接完，也可能分三次接。

这就是粘包和拆包的根源。

下面这张图展示了三种典型场景。我建议你多看几遍，理解透了再往下走。

我的经验：实际线上环境，混合场景最常见。尤其是高并发下，多条小消息和一条大消息交错发送，接收端收到的数据包往往是「前半条 + 整条 + 后半条」的混乱组合。我曾经在压测时见过一次 recv 返回了 7 个不完整的消息碎片——那场面，啧啧。

你想想看，如果不管粘包拆包，会发生什么？

我见过最严重的案例：某支付系统因为粘包导致订单状态解析错误，重复扣款。那可不是闹着玩的。

解决粘包拆包，业界有四种主流方案。这里先列个表，后续章节会逐个深入。

避坑指南：我曾经在一个项目里选了「分隔符方案」，结果业务数据里偶尔会出现 \r\n 序列，导致解析错乱。后来被迫升级成「长度前缀 + 转义」——早知如此，一开始就该用长度前缀。我的建议是：通用场景无脑选长度前缀，除非你有非常明确的理由选别的。

这门课一共 30 章，我会带你从协议栈底层一路杀到工程实践。具体来说：

每一章我都会结合自己踩过的坑、看过的源码、修过的 Bug 来讲。你跟着走完，不敢说成为专家，但至少遇到粘包拆包问题，心里不慌。

粘包拆包不是洪水猛兽，它是 TCP 流式传输的自然结果。理解它，你才能写出健壮的网络程序。

记住三个核心点：