直接用 bufio.reader 会丢包或卡住，因其 readslice/readbytes 在缓冲区满且未匹配分隔符时返回 errbufferfull 并丢弃已读数据，导致协议头被截断、解析错位；它不支持二进制帧长解析，无法保证原子读取固定长度 header，且内部频繁小内存分配加重 gc 压力。
为什么直接用 bufio.Reader 会丢包或卡住？
因为 bufio.Reader 的 ReadSlice 和 ReadBytes 在遇到缓冲区满但未匹配到分隔符时，会返回 bufio.ErrBufferFull，而默认行为是丢弃已读数据重试——这直接导致粘包头被截断、后续解析错位。更麻烦的是，它内部用切片扩容，频繁分配小内存，GC 压力大，且无法控制底层读取边界。
真实场景中，比如自定义协议头为 4 字节长度字段 + 变长 body，必须保证「一次读到完整 header」才能知道 body 多长；若 header 被切在两次 Read 中间，就彻底乱套。
- 别依赖
bufio.Scanner：它只适合行协议，不支持二进制帧长解析 - 别自己用
conn.Read()循环拼接：容易阻塞在 partial read，且没缓冲区管理，写满就 panic - 关键点：header 解析必须原子——要么整 header 都在缓冲区里，要么都不在
环形缓冲区怎么配才不越界也不浪费？
Go 标准库没有现成无锁环形缓冲区，但 ring.Ring 是单向链表，不适合高频读写。实际推荐用 slice + 两个游标（readPos/writePos）手动管理，大小设为 2 的幂次（如 64KB），便于位运算取模提速。
重点不是“无锁”，而是“避免临界区竞争”：让 reader 和 writer 永远不同时改同一段内存。典型做法是——writer 只增 writePos，reader 只增 readPos，两者用 atomic.LoadUint64 读取，用 atomic.CompareAndSwapUint64 更新，不共享写入缓冲区本身。
- 缓冲区大小建议 ≥ 最大单帧长度 × 2（防 burst 流量打满）
-
readPos和writePos必须用uint64，避免溢出回绕误判 - 每次
write后检查(writePos - readPos) > cap，超了就丢弃旧数据（TCP 本就不保序，宁丢勿错）
如何用 io.ReadFull 和 binary.BigEndian.Uint32 安全提取帧长？
粘包处理核心是「先读 header，再读 body」，但不能假设一次 Read 就能拿到完整 header。正确做法是：从环形缓冲区中尝试提取至少 4 字节；不够就等待，够了就用 binary.BigEndian.Uint32 解出 length 字段；再检查缓冲区剩余字节数是否 ≥ length，不够就继续等。
这里最常踩的坑是：把 binary.Read 直接怼到 conn 上——它内部会调 io.ReadFull，但阻塞在 conn 层，绕过了你的环形缓冲区，等于白做。
- 所有解析必须基于环形缓冲区当前可读视图：
buf[readPos%cap:writePos%cap] - 用
io.ReadFull(bytes.NewReader(view), headerBuf)模拟读取，避免副作用 - length 字段校验必须做：比如限制 ≤ 1MB，否则恶意客户端可触发 OOM
分包后怎么把数据安全交给业务 goroutine？
环形缓冲区只是暂存和解析，真正耗时的解码、DB 写入、RPC 调用不能在 reader goroutine 里做，否则拖慢整个 TCP 连接吞吐。常见错误是直接往 channel 里塞原始 buffer slice——因为 slice 底层共用环形缓冲区内存，reader 后续覆盖就会污染业务数据。
解决方法只有一种：深拷贝。但不是 copy(dst, src) 就完事——dst 必须是新分配的底层数组，且长度精确匹配帧长，避免浪费或越界。
- 用
make([]byte, frameLen)分配新 slice，再copy数据过去 - 别用
append([]byte{}, buf...)：底层可能复用底层数组，风险同上 - 如果业务逻辑允许零拷贝（如只读解析 JSON），可传
unsafe.Slice，但必须确保 reader 不再访问该段内存——需用原子标志位同步
真正难的不是实现环形缓冲区，而是确定哪一段内存何时可被覆盖、何时必须保留。很多 bug 都出在“以为数据已移交，其实还在被业务 goroutine 引用”。
