TCP是字节流协议，conn.Read不保证按发送边界返回数据，需用4字节大端长度头+io.ReadFull处理粘包、半包；禁用分隔符法和共享缓冲区。
为什么conn.Read一读就错：TCP根本不管“包”是什么
Go 的 net.Conn 是字节流接口，Read 返回的只是当前缓冲区里凑够的字节数，和你 Write 几次、每次写多少完全无关。客户端连发 "hi" 和 "ok"，服务端一次 Read 可能拿到 "hiok"；或者只拿到 "h"，下一次才读到 "iok"——这不是 bug，是 TCP 的设计使然。
- 别用
time.Sleep或SetReadDeadline“等一会儿再读”，这既不可靠又拖慢吞吐 - 别假设
Read会返回完整业务消息，哪怕你只Write了一次 - 别忽略
Read返回的n值，它可能远小于你申请的 buffer 长度
最稳的方案：用 4 字节大端长度头 + io.ReadFull
在每条消息前加 4 字节 uint32（网络字节序），先读头、再按长度读体，天然兼容粘包、半包、多包合并。比换行符或固定长度更通用，也比自定义分隔符更安全——不用操心业务数据里有没有 "\n" 或 "[END]"。
- 发送端必须用
binary.BigEndian.PutUint32写头，不是LittleEndian，跨语言通信时尤其关键 - 接收端必须用
io.ReadFull读头和读体，它会自动循环调用Read直到填满，避免手动处理EOF或short read - 头部统一用 4 字节（
uint32），覆盖绝大多数场景；8 字节太重，2 字节上限仅 64KB，容易溢出
func readMessage(conn net.Conn) ([]byte, error) {
var header [4]byte
if _, err := io.ReadFull(conn, header[:]); err != nil {
return nil, err
}
msgLen := binary.BigEndian.Uint32(header[:])
data := make([]byte, msgLen)
if _, err := io.ReadFull(conn, data); err != nil {
return nil, err
}
return data, nil
}
别踩这些坑：bufio.Scanner 和 ReadBytes 不是解药
bufio.Scanner 默认按 \n 切分，看起来方便，但只要业务数据含未转义换行（比如用户发的 JSON、带表情的日志、代码块），就会提前截断；ReadBytes 同理，它只找第一个分隔符就停，不保证前面没被截断、后面没多包。
- 用
Scanner必须配SplitFunc自定义逻辑，且要处理缓冲区残留和边界重叠 -
ReadBytes返回的切片仍需校验完整性，它不解决“半包”问题 - 二进制数据、加密 payload、protobuf 序列化结果一律禁用分隔符法
缓冲区管理必须每连接独享，不能全局复用
多个 goroutine 并发读同一连接时，如果共用一个 bytes.Buffer 或切片，会出现数据错乱。常见错误是把 buf 声明在 for 循环外，然后在 handle 中反复 WriteTo 或 Read。
立即学习“go语言免费学习笔记（深入）”；
- 每个连接应持有自己的
bytes.Buffer实例，或至少用局部变量管理未解析完的数据 - 解包逻辑必须循环处理缓冲区：一次
Read可能含多个完整包 + 一个半包，不能读完就丢弃剩余字节 - 遇到半包时，用
buf.Next(n)消费已处理部分，保留尾部供下次续读
真正麻烦的从来不是协议怎么定，而是把长度头读全、把 body 读满、把半包留对——这三个动作必须嵌入 I/O 生命周期，漏掉任意一环，上线后第一条含 emoji 的消息就能让服务开始吐错包。
