go中处理半包粘包的核心是协议头定义、缓冲区管理和读取节奏控制，需用bytes.buffer累积字节、循环解析固定长度头、校验消息体大小并及时移除已处理数据，而非依赖语法熟练度或io.readfull等api技巧。
直接说结论：Go 里处理半包和粘包，跟“语言学习技巧”完全无关；它是个协议层+缓冲区管理问题，不是语法或 API 熟练度问题。
别被“技巧”二字带偏——这不是背函数、练语感、搞类比迁移就能解决的。核心就三件事：定协议头、管缓冲区、控读取节奏。
为什么不能靠“学得熟”来解决半包/粘包
很多人以为多写几次 conn.Read、翻几遍文档、记牢 io.ReadFull 的签名就“会了”，结果上线后 json.Unmarshal 报 invalid character 或 goroutine 卡死。根本原因不是不熟 Go，而是没意识到：
– conn.Read 返回的是字节流片段，不是消息
– TCP 不知道你协议里哪是头、哪是 body、哪是结尾
– 没有应用层缓冲区（如 *bytes.Buffer），就等于没有“暂存未拼完的单词”的草稿纸
必须用 bytes.Buffer 做滚动解析，不能靠“反复 Read”硬刚
常见错误是每次 conn.Read(buf) 后，直接拿 buf[:n] 去解析，结果只处理第一个包，剩下几百字节留在 buf 末尾，下次被新数据覆盖——相当于把半句话擦掉重写。
- 每个连接独享一个
*bytes.Buffer，生命周期绑定到 conn -
conn.Read(buf)成功后，无条件调用buffer.Write(buf[:n]) - 解包逻辑写成循环：
for buffer.Len() >= 4 { ... }，不是 if - 提取完整包后，必须用
buffer.Next(4 + int(msgLen))移除已处理字节，不能用buffer.Read()或buffer.ReadBytes()—— 它们会移动内部 offset，破坏后续长度判断
io.ReadFull 只管“填满”，不管“对齐”，别当万能胶
io.ReadFull(conn, header[:]) 看似可靠，但它不会跳过缓冲区里残留的半包字节。比如上一次解析后 buffer 剩 3 字节，下一次 ReadFull 还是从这 3 字节开头读，导致头被截断，binary.BigEndian.Uint32 解出个超大数字，接着 make([]byte, 4GB) 直接 OOM。
- 长度头必须固定（推荐 4 字节
uint32），且用binary.BigEndian编码/解码 - 读到头后，必须校验
msgLen （例如 <code>1024 * 1024），超限立刻丢弃连接 - 发送端写入必须原子：用
conn.Write(append(header, body))或io.MultiWriter，避免只写出 header 就断连 - 接收端不能假设
conn.Read一次返回全部数据——哪怕 buf 是 4096 字节，也可能只读到 17 字节，必须靠缓冲区累积等
别碰 bufio.Scanner / ReadString，它们对二进制协议就是定时炸弹
这些工具本质是分隔符驱动，而真实业务数据里随时可能出现 \n、\0、[END]。一旦用户发一条含换行的 JSON 日志，r.ReadString('\n') 就在中间切开，后面半个包永远等不到下一个 \n，goroutine 卡死。
-
bufio.Scanner默认按\n切，但你的协议可能根本没有换行 -
r.ReadBytes('\n')在遇到恶意构造的长字段时，可能分配超大 slice 导致 OOM - 即使加了超时，也只是让错误暴露更快，不解决粘包本身
- gob.Decoder 虽隐式缓冲，但严禁和原始
conn.Read()混用——缓冲区状态立刻错乱
真正容易被忽略的，不是“怎么写”，而是“谁来管生命周期”：缓冲区必须活在连接 goroutine 里，直到 conn.Close()；conn.SetReadDeadline() 必须设，否则 io.ReadFull 卡住就永远卡住；回调里用到的 data 必须 copy 出来，因为底层数组下一秒就被新 Read() 覆盖。这些不是边缘情况，是每条连接都绕不开的实操细节。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
