Go语言中conn.Read返回不完整或多余数据，是因为TCP是字节流协议，Read仅反映内核缓冲区当前就绪字节，与业务消息边界无关，可能一次读到半包、粘包或拆包，属协议本质而非异常。
Go 语言处理多路复用下的网络连接，核心不是“手动实现 epoll/kqueue”，而是信任 runtime 的 netpoll 封装，并在应用层用对的方式组织 I/O——尤其当面对 TCP 字节流时，conn.Read 返回半包/粘包是常态，不是异常。
为什么 conn.Read 总是返回不完整或多余的数据？
TCP 是字节流协议，conn.Read 只反映内核缓冲区当前就绪字节，和你的业务消息边界无关。一次调用可能只读到 4 字节长度头中的 2 字节（半包），也可能读到两个完整消息拼在一起（粘包），甚至一个消息被拆成三次返回。
这不是 Go 的问题，是协议本质。你不能靠循环 conn.Read 补齐数据，必须用更稳的方式：
- 固定长度头（如 4 字节 msgLen）必须用
io.ReadFull(conn, header[:])，它要么填满，要么明确返回io.ErrUnexpectedEOF - 别用
binary.BigEndian.Uint32(header[:])前不检查错误，否则会把部分头解析成垃圾值（比如0xffffffff） - 后续按错误长度分配内存，轻则 panic，重则 OOM
如何安全累积和消费粘包/半包？
真实网络中，一次 conn.Read 可能含 0 个完整包 + 半包、1 个完整包 + 半包、或多个完整包 + 半包。必须用缓冲区持续累积、滚动消费：
立即学习“go语言免费学习笔记（深入）”；
- 每个连接独享一个
*bytes.Buffer，禁止全局复用或跨 goroutine 共享 - 读 goroutine 每次
conn.Read(buf)后立即buffer.Write(buf) - 解包逻辑循环检查：
buffer.Len() >= 4→ 提取头 →buffer.Len() >= 4 + msgLen→buffer.Next(4 + msgLen)提取完整包 - 不满足条件时直接
break，等下次数据到达；绝不丢弃、不阻塞、不假设 - 别在
buffer上调Read()取头——它会移动内部 offset，破坏后续判断
能不能用 gob.Decoder 省事？
gob.Decoder.Decode() 看似“自动”处理粘包，实际靠其原子性隐式缓冲：每次调用都阻塞等待一个完整 gob 值，多余字节留在内部 bufio.Reader 缓冲区供下次复用。但它有硬约束：
- 不能在同一个
conn上混用gob.Decoder和原始conn.Read()—— 缓冲区状态立刻错乱 - 每个连接必须独占一个
gob.Decoder实例，禁止多个 goroutine 共用 - 无法插入心跳帧或控制指令，
gob没扩展字段机制 - 若需自定义协议（如加长度头），必须绕过
gob.Codec，自己实现ServerCodec
HTTP 场景下多路复用的真正开关在哪？
HTTP/2 的多路复用不是靠服务端代码“开启”的，而是 TLS 协商结果。Go 的 http.Server 默认支持 HTTP/2，但仅限于 ListenAndServeTLS 场景，且需满足：
- 必须用
http.ListenAndServeTLS或配置了有效TLSConfig的 server -
TLSConfig.NextProtos显式设为[]string{"h2"}，若含"http/1.1"可能干扰协商 - 证书文件可读，自签名也可，但客户端得信任
- 客户端必须发起 ALPN 协商（如
openssl s_client -alpn h2 -connect localhost:8080验证） - 纯 HTTP（
http.ListenAndServe）不会触发 HTTP/2，h2c升级在 Go 1.19+ 已禁用
handler 完全感知不到多路复用——每个 stream 被映射为独立 http.Request，但 handler 内部若阻塞（如没设 timeout 的 http.Get），会拖慢整个连接上的所有流。
