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 又面临并发安全与长度越界风险。

• 用 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。