net.Conn默认无缓冲，每次读写触发系统调用，高吞吐下引发频繁上下文切换与syscall开销，导致CPU高而带宽未满、延迟毛刺；需用bufio加用户态缓冲，并正确设置TCP_NODELAY、复用UDP buffer或使用sendmmsg优化。
为什么 net.Conn 默认读写缓冲区会成为性能瓶颈
Go 标准库的 net.Conn 接口本身不提供缓冲，每次调用 conn.Read() 或 conn.Write() 都可能触发系统调用。在高吞吐场景下（如代理、实时消息分发），频繁的小包收发会导致大量上下文切换和 syscall 开销。
实际中常见现象：CPU 使用率高但带宽未打满，strace 显示大量 read(12, ...) 和 write(12, ...) 调用，延迟毛刺明显。
- UDP 场景下更隐蔽：即使使用
conn.WriteTo()，若每次只发几十字节，内核仍需反复封装 IP/UDP 头 - TCP 场景下，小包易触发 Nagle 算法（除非已禁用）或延迟 ACK，进一步拉长 RTT
-
bufio.NewReader(conn)和bufio.NewWriter(conn)是最轻量、最直接的缓解方式，但要注意：它们只是用户态缓冲，不改变底层 socket 行为
如何正确禁用 Nagle 算法并控制 TCP_NODELAY
启用 TCP_NODELAY 是低延迟 TCP 通信的刚需，但 Go 中不能仅靠 SetNoDelay(true) 就一劳永逸——它必须在连接建立后、首次读写前设置，否则可能被忽略。
conn, err := net.Dial("tcp", "10.0.0.1:8080")
if err != nil {
log.Fatal(err)
}
// 必须在 conn.Read/Write 之前调用
if tcpConn, ok := conn.(*net.TCPConn); ok {
tcpConn.SetNoDelay(true)
}
- UDP 不受 Nagle 影响，无需此操作
- 某些容器环境（如 Docker + iptables SNAT）可能导致
SetNoDelay返回成功但实际未生效，建议用ss -i检查ts和nodelay字段 - 不要在
Listener.Accept()后对每个新连接都忘记设置——这是线上服务最常见的遗漏点
UDP 场景下如何避免频繁内存分配与系统调用
高频 UDP 收发（如 DNS、监控打点）若每次调用 conn.WriteTo(buf, addr) 都 new 一个 []byte，GC 压力会陡增；而复用 buf 又面临并发安全与长度越界风险。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Pool管理固定大小的 buffer（如 1500 字节 MTU），比全局变量或 channel 更轻量 - 避免在 handler 中直接
append()到池化 buffer——这会破坏 pool 的复用前提，应先copy()再写入 - 对确定长度的协议（如 DNS query），可预分配
[512]byte数组而非 slice，彻底避开堆分配 - 如果需要批量发送多个 UDP 包，优先考虑
sendmmsg（Linux 3.0+），Go 1.21+ 已通过net.BuffConn实验性支持，但目前仍需 syscall 封装
什么时候该绕过 net.Conn 直接用 syscall 或 io_uring
标准 net 包在单连接高吞吐（>50K QPS）或超低延迟（
- Linux 上，用
syscall.Socket+epoll_ctl+syscall.Readv可减少 1–2 次内存拷贝，但失去 Go runtime 网络 poller 的集成，需自行管理 goroutine 生命周期 -
io_uring在 Go 1.22+ 中可通过golang.org/x/sys/unix调用，适合大批量 UDP recv/send，但目前无官方 high-level 封装，错误处理复杂 - 绝大多数业务（API 网关、IM 推送、游戏状态同步）用好
bufio+TCP_NODELAY+sync.Pool已足够，过早优化 syscall 层反而增加稳定性风险
真正卡住性能的，往往不是 Go 的网络栈本身，而是应用层协议解析（如 JSON unmarshal）、锁竞争或 GC pause。上线前务必用 go tool pprof 和 go tool trace 定位真实热点，而不是默认归咎于 TCP/UDP。
