bufio.Reader 读不到完整 TCP 包，因 TCP 是流式协议无天然包边界，ReadString() 等方法依赖分隔符，易导致粘包或半包；正确做法是用 io.ReadFull 配合长度头解析应用层协议。
为什么 bufio.Reader 读不到完整 TCP 包
TCP 是流式协议，没有天然的“包边界”，bufio.Reader 的 ReadString() 或 ReadBytes() 依赖分隔符（如 \n），而实际网络数据往往无换行、无固定长度。直接用会导致粘包或半包：一次 ReadString('\n') 可能阻塞等待不存在的换行，或把两个业务消息拼成一个读出来。
- 典型现象：
ReadString('\n')长时间阻塞，或返回内容包含多个逻辑消息 - 根本原因：
bufio.Reader缓冲的是字节流，不是应用层协议单元 - 适用场景：仅当服务端/客户端明确约定每条消息以
\n结尾（如简单 Telnet 协议）时才安全
用 net.Conn.Read() + 自定义解析更可控
绕过 bufio.Reader，直接操作底层 net.Conn，配合预定义协议格式（如头+体、定长头、TLV）做解析，是生产环境主流做法。关键在于：先读够头部，再按头部字段读取有效载荷。
- 常见协议模式：4 字节大端长度头 + N 字节 payload
- 必须处理
io.EOF和io.ErrUnexpectedEOF—— 前者表示连接关闭，后者表示数据不足（如只收到 2 字节长度头） - 不要假设
conn.Read(buf)一次填满buf；它可能只读到部分字节，需循环调用直到满足长度
func readMessage(conn net.Conn) ([]byte, error) {
header := make([]byte, 4)
_, err := io.ReadFull(conn, header) // ReadFull 确保读满 4 字节
if err != nil {
return nil, err
}
length := binary.BigEndian.Uint32(header)
if length > 1024*1024 { // 防止过大内存分配
return nil, fmt.Errorf("payload too large: %d", length)
}
payload := make([]byte, length)
_, err = io.ReadFull(conn, payload)
return payload, err
}
bufio.Reader 的正确用法：仅作缓冲，不解析协议
bufio.Reader 本质是优化小读操作的缓冲层，不是协议解析器。它适合在已知有界输入（如文件、HTTP body）中提升性能，但在裸 TCP 上，应仅用其 Read() 方法配合手动协议解析，而非依赖 ReadLine() 等高层方法。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误用法：
r.ReadString('\n')处理二进制协议（如 Protobuf over TCP） - 合理用法：
r.Read(buf)替代多次conn.Read(buf)减少系统调用，但后续仍需自己拆包 - 注意
bufio.NewReaderSize(conn, 4096)的 size 设置：太小增加拷贝开销，太大浪费内存；一般 2KB–8KB 较平衡
粘包问题必须由应用层解决，Go 没有银弹
Go 的 net 包和 bufio 都不提供自动拆包能力。无论用 conn.Read 还是 bufio.Reader，只要协议没定义边界，就一定面临粘包/半包。唯一可靠方式是设计带长度字段或分隔符的应用层协议，并严格实现读取逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 别指望
SetReadDeadline()能解决粘包——它只控制超时，不识别消息边界 - 测试时务必模拟极端情况：发送 1 字节、跨 TCP 分段、连续快速发多包
- 真实项目中，建议封装一个
PacketConn类型，内部维护读缓冲和状态机，对外暴露RecvMsg()方法
