go处理tcp粘包的核心是识别消息边界，必须用4字节大端序长度头协议：先读4字节得长度n，再用io.readfull读满n字节，循环解析缓冲区，每连接独享buffer，严格校验长度防oom。
go 高级工程师网络编程面试中，tcp 粘包问题不是“会不会写解包逻辑”的问题，而是“是否理解协议层与应用层边界被打破的根本原因”。只套用 binary.read 或拼接 bufio.reader 而不处理分片/合并的完整性校验，线上必出故障。
为什么 conn.Read 会读到半条消息？
TCP 不保证应用层消息边界。一次 conn.Read 返回的字节数完全取决于内核 TCP 接收缓冲区当前可用数据量，可能：
- 刚收到一个完整包，但还没来得及发第二个，
Read只返回第一个包的全部 - 两个小包被内核合并进同一缓冲区，
Read一次性返回两包数据 - 一个大包被 IP 层分片，或 TCP 自身因 MSS 限制拆成多个段，
Read可能只拿到前半截
这不是 Go 的 bug，是所有基于 TCP 的应用层协议都必须面对的事实。忽略这点直接对 buf 做 json.Unmarshal，十有八九 panic: invalid character 或解析出错。
bufio.Reader 能不能直接解决粘包？
不能。它只是封装了缓冲读取，但不提供消息定界能力。常见误用：
reader := bufio.NewReader(conn)
line, _ := reader.ReadString('\n') // 仅适用于行协议
问题在于：
-
ReadString和ReadBytes依赖特定分隔符，而二进制协议通常不用换行符 - 如果分隔符本身是 payload 的一部分（比如日志内容含
\n），就会错切 - 没有超时控制，遇到坏连接可能永久阻塞
真正安全的做法是：自己管理读缓冲区，用状态机判断消息头是否收全、消息体是否收全，再交给业务逻辑。
消息头 + 消息体方案里，binary.BigEndian.Uint32 为什么必须用大端？
因为网络字节序（Network Byte Order）就是大端序。如果你用 Uint32LE 解析，而发送方按标准网络序写入，结果必然错乱——比如本该是 1024 字节的消息体，你解析成 0x00000400（大端）→ 1024，但用小端会变成 0x00040000 → 262144，直接导致后续 Read 阻塞或越界 panic。
实操要点：
- 发送端务必用
binary.BigEndian.PutUint32(headerBuf, uint32(len(body))) - 接收端必须用
binary.BigEndian.Uint32(headerBuf) - 头长度固定为 4 字节是工业级底线，别为了省 2 字节改用
uint16——单条消息上限 64KB 够用吗？
真实服务中，比解包更难的是连接生命周期管理
高级岗位不会只问“怎么读”，而是追问：“当客户端突然断开，你的读循环卡在 conn.Read 上，怎么及时感知并释放 goroutine？” 这涉及三个常被忽略的点：
-
SetReadDeadline必须每次读之前设置，不能只设一次——超时时间要覆盖整个消息（头+体）的接收窗口 - 错误判断不能只看
err != nil，要区分net.ErrClosed、io.EOF、os.SyscallError{Syscall:"read", Err:0x68}（即 connection reset） - goroutine 泄露风险：没用
context.WithTimeout包裹 handler，或没在 defer 里显式conn.Close()，连接数涨到几千后内存就爆了
最易被跳过的细节：消息体长度字段本身也可能被截断。4 字节头若只收到 2 字节，Read 返回 n=2, err=nil，此时必须继续读剩余 2 字节，而不是直接解析——否则 Uint32 会读到脏数据。
