直接用conn.read()会读不全一帧数据，因其仅返回内核缓冲区当前就绪字节，不保证整帧对齐，易导致半包或粘包；必须用固定长度头（如4字节大端uint32）配合缓冲区循环解析，并设长度上限防内存暴涨。
为什么直接用 conn.Read() 会读不全一帧数据
Go 的 net.Conn.Read() 是底层 syscall 的封装，它只保证「至少读一个字节」，不保证读完你期望的整帧。比如你协议是「4 字节长度 + N 字节载荷」，但 Read() 可能只返回前 2 个长度字节，或者把两帧粘在一起返回。这不是 bug，是 TCP 流式特性的必然表现。
必须自己做缓冲和分帧。核心思路：维护一个字节切片作为接收缓冲区，不断 Read() 追加，然后循环检查是否有完整帧（即缓冲区开头的长度字段是否 ≤ 剩余可用字节数）。
- 别用
bufio.Reader的ReadSlice('\n')或ReadBytes()—— 它们依赖分隔符，不适用于定长头+变长体的二进制协议 - 长度字段建议用
uint32（大端），兼容性好、不易溢出；避免用int（平台相关）或uint64（浪费带宽） - 单帧最大长度必须设上限（如 1MB），否则恶意客户端发个超大长度会导致内存暴涨
如何安全解析帧头里的长度字段
假设协议头是固定 4 字节大端 uint32，那么解析逻辑必须严格检查缓冲区长度是否 ≥ 4，再用 binary.BigEndian.Uint32() 提取。不能跳过校验直接解包，否则 panic 或读越界。
示例关键片段：
if len(buf) 1024*1024 { // 长度超限，丢弃整帧并清空缓冲区
buf = buf[4:] // 跳过非法头
return nil, errors.New("frame length too large")
}
if uint32(len(buf))
- 注意
frameLen是uint32，和len(buf)（int）比较前要显式转换，否则 32 位系统可能溢出 - 不要用
unsafe.Slice()或指针运算替代切片操作——可读性和安全性远不如原生切片 - 如果协议要求校验和（如 CRC32），应在提取
payload后立即验证，失败则丢弃该帧
写入时怎么确保长度字段和 payload 原子写入
TCP 层本身不保证「一次 Write() 对应一个接收方 Read()」，但 Go 的 Write() 在用户态是原子的（内核会尽量合并小包）。真正要防的是：长度字段写了一半连接断了，或者 payload 写到一半被中断。
正确做法是把整个帧（头+体）拼成一个 []byte 再一次性 Write()：
func writeFrame(conn net.Conn, payload []byte) error {
if len(payload) > 1024*1024 {
return errors.New("payload too large")
}
header := make([]byte, 4)
binary.BigEndian.PutUint32(header, uint32(len(payload)))
frame := append(header, payload...)
_, err := conn.Write(frame)
return err
}
- 不要分两次
Write()（先写头再写体）——中间若发生错误或超时，对方会收到残帧 - 如果 payload 很大（接近上限），考虑复用
sync.Pool分配frame切片，避免频繁堆分配 - 生产环境建议包装
writeFrame加超时控制，例如用conn.SetWriteDeadline()
粘包和半包问题在真实连接中有多常见
不是“偶尔出现”，而是只要网络有延迟、吞吐高、或对端发送节奏不规则，就一定会发生。本地 loopback 测试常看不到，一上公网或压测立刻暴露。很多开发者误以为是“连接不稳定”，其实是没做分帧。
- Wireshark 抓包看 TCP Stream 里连续多个
ACK后才来一个PUSH，大概率就是 Nagle 算法把小包合并了——这正是粘包的物理根源 - 移动网络下 RTT 波动大，半包更频繁；服务端用
epoll/kqueue多路复用时，一次事件触发可能带多帧数据 - 唯一能绕过这个问题的方式是改用 UDP + 自定义重传（代价极高），对绝大多数业务，老老实实做缓冲分帧是最稳的
最易被忽略的一点：缓冲区清理逻辑必须覆盖所有分支——包括错误返回、长度非法、IO 中断。漏掉一次 buf = buf[n:]，后续所有帧都会错位，且极难定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
