go的net.conn无缓冲，高频小包读写触发大量系统调用导致cpu高、带宽低；必须用bufio.reader/writer（32kb缓冲）合并i/o，并结合sync.pool复用实例，且setnodelay(true)须在首次读写前设置。
直接上结论：Go 的 net.Conn 是操作系统 TCP/IP 协议栈的封装，不是抽象层，它把 socket fd 暴露给了你——你调用 conn.Read() 就是发一次 read() 系统调用，conn.Write() 就是 write()，中间没加任何缓冲或重试逻辑。想写高性能 TCP 网关，必须亲手补全协议栈本该由应用层承担的职责。
为什么 conn.Read() 和 conn.Write() 一上量就卡住 CPU？
因为它们默认不做合并：每收 1 字节、每发 1 字节都可能触发一次系统调用。strace 里全是 read(12, ...) 和 write(12, ...)，CPU 跑满但带宽压不上去，延迟毛刺明显。
- 必须用
bufio.NewReader(conn)和bufio.NewWriter(conn)包一层，把多次小读写合并成一次系统调用 -
bufio的 buffer 大小建议设为32 * 1024（32KB）：太小起不到合并效果；太大浪费内存且增加拷贝开销 - 不要在每个连接里 new 一个
bufio.Reader后就扔掉——它内部的 buffer 是堆分配的，高频创建会加重 GC；应结合sync.Pool复用整个bufio.Reader实例
如何正确设置 TCP_NODELAY 和 keep-alive？
SetNoDelay(true) 必须在 conn.Read() 或 conn.Write() 之前调用，否则在某些内核或容器环境下会被忽略（比如 Docker + SNAT 场景下 ss -i 显示 nodelay 为 off）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 对服务端：在
listener.Accept()返回的conn上立刻做类型断言：if tcpConn, ok := conn.(*net.TCPConn); ok { tcpConn.SetNoDelay(true) } - 对客户端：在
net.Dial()后、首次 I/O 前设置，同样要断言*net.TCPConn - 启用 TCP keep-alive：
tcpConn.SetKeepAlive(true)并设SetKeepAlivePeriod(30 * time.Second)，比应用层心跳更轻量
为什么不能直接用 io.Copy() 做中继转发？
io.Copy(dst, src) 默认用 32KB buffer，看似够用，但它每次都要 new 一次 slice，高并发下就是 GC 杀手；而且不处理连接异常中断，容易导致 goroutine 泄漏。
- 替换方案：自己管理 buffer，从
sync.Pool获取预分配的[]byte，长度按协议最大包限制（如 64KB） - 必须显式检查
io.EOF和net.ErrClosed，遇到错误立即关闭两端连接，避免泄漏 - 转发时若需修改协议头（如加长度前缀），不能靠
io.Copy一气呵成，得拆成“读→解包→改→封包→写”四步，每步都带超时和边界校验
粘包和二进制协议解析最容易踩哪些坑？
直接用 encoding/binary.Read(conn, ...) 必然出错，因为 net.Conn 是字节流，不是消息流。TCP 不保证一次 Read() 返回一个完整逻辑包——可能少（半包）、可能多（粘包）。
- 正确做法：先读固定头长（如 4 字节
uint32表示 payload 长度），再循环调用io.ReadFull(conn, buf[:n])直到填满 - 不要用
bufio.Reader.ReadBytes()或ReadString()解析二进制协议，它们基于字节匹配，不适用 - 解析前必须校验缓冲区长度：
if len(buf) ，否则 <code>binary.Read会静默错位或 panic
真正难的不是写通逻辑，而是所有这些细节必须同时生效：buffer 复用、nagle 关闭、keep-alive 周期、读写超时动态更新、长度头校验、错误连接立即清理——漏掉任意一环，万级连接下就会在某个时间点突然卡死或内存暴涨。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
