bufio.Reader 是热路径首选，因其在用户态缓冲减少系统调用频次，显著降低 CPU 占用；需正确复用 sync.Pool 并调用 Reset，避免 fd 泄漏与数据污染。
直接用 bufio.Reader 包一层 net.Conn，再配合适当的缓冲区大小和读取模式，是热路径下最有效、最低侵入的优化方式。别碰内核 socket 缓冲区（SetReadBuffer），它在大多数场景下不解决根本问题，还容易调错时机或白忙一场。
为什么 bufio.Reader 是热路径首选
Go 的 net.Conn.Read() 每次调用都可能触发系统调用；而热路径（如高频消息解析、代理转发）往往单次只读几十到几百字节，频繁 syscall 会吃掉大量 CPU 时间、拉高延迟毛刺。 bufio.Reader 在用户态维护一块缓冲区（默认 4KB），一次系统调用读多字节，后续从内存取，显著摊薄 syscall 开销。
- 实测常见代理服务中，
bufio.NewReader(conn)可降低 30%~50% 的 CPU 占用，尤其在平均消息 - 它不改变 TCP 流语义，不影响粘包处理逻辑，和你已有的协议解析代码完全兼容
- 相比自己写循环 +
conn.Read()+ 手动拼接，bufio.Reader.Read()更安全（自动处理io.ErrUnexpectedEOF、partial read 等边界）
缓冲区大小设多少才合适
别硬套“越大越好”。缓冲区太小（如 512B）仍需频繁 refill；太大（如 1MB）浪费内存、增加 GC 压力，且对热路径无额外收益——因为数据到达速率远低于 refill 频次。
- 通用推荐值：
bufio.NewReaderSize(conn, 4096)或8192；若业务消息平均在 200–500B（如 JSON RPC、MQTT PUB），4KB 足够覆盖 8–20 条消息 - 若协议固定为“4 字节长度头 + payload”，且 payload 常在 1–16KB，可设为
16384，避免第一次io.ReadFull后立即 refill - 绝对不要用
bufio.NewReaderSize(conn, 1)或动态计算 size ——sync.Pool复用时要求 size 一致，否则 Pool 内存碎片化
Read() 之后必须检查返回的 n 值
bufio.Reader.Read() 不保证填满传入的 []byte，这点和 io.ReadFull 有本质区别。热路径里忽略 n 直接用 buf[:len(buf)] 是典型 panic 来源。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
r.Read(buf); process(buf[:len(buf)])—— 若实际只读了 3 字节，buf[3:]是上一次残留数据 - 正确写法：
n, err := r.Read(buf); if n > 0 { process(buf[:n]) } - 对定长协议（如长度头），优先用
io.ReadFull(r, header)，它内部会循环调用r.Read()直到填满，比手动 while 更简洁可靠
sync.Pool 复用 Reader 时最容易踩的坑
热路径下每连接都 new 一个 bufio.Reader 会抬高 GC 压力，用 sync.Pool 复用能稳住 GC Pause。但复用方式错了，比不用还危险。
- 必须在每次 Get 后调
r.Reset(conn)，不能构造时传conn—— 否则旧连接关闭后，Reader 还持有已释放 fd，下次 Read 触发bad file descriptor - Pool 中的
bufio.Reader绝对不能缓存对net.Conn的引用（比如 embed conn 字段），否则连接无法被 GC，导致 fd 泄漏 - Put 前必须确保已读完当前 buffer 数据（如调过
r.Discard(r.Buffered())），否则下次 Reset 后残留数据会污染新连接
真正卡性能的从来不是内核缓冲区大小，而是 syscall 频次和内存分配节奏。热路径里，bufio.Reader 的缓冲行为、Reset() 的时机、n 的校验，这三处细节没对齐，优化就白做了。
