Go net包无需优化协议栈，真正需调优的是连接生命周期、IO模式、超时控制及是否绕过内核；http.Transport应设MaxIdleConns≥100、MaxIdleConnsPerHost≥20、IdleConnTimeout为30–90秒，禁用http.DefaultClient复用，并确保resp.Body.Close()调用。
Go 的 net 包本身不需“优化协议栈”，它早已绑定 epoll/kqueue/iocp，真正要调的是你用连接的方式：连接生命周期、IO 模式、超时控制和是否绕过内核。直接上实操点。
http.Transport 连接池参数怎么设才不打满端口
默认 http.DefaultClient 在高并发下会快速触发 too many open files 或耗尽本地端口（65535 个）。根本原因是空闲连接池为 0，每个请求都新建 TCP 连接。
-
MaxIdleConns必须显式设为 ≥ 100（全局总空闲连接上限） -
MaxIdleConnsPerHost建议 ≥ 20，否则单域名最多只缓存 2 个空闲连接 -
IdleConnTimeout设为 30–90 秒：太短导致频繁重连；太长则空闲连接堆积，且可能被服务端主动断开 - 永远不要复用
http.DefaultClient，每次 new&http.Client{Transport: tr}，避免跨业务污染 - 必须调用
resp.Body.Close()，否则连接永不归还池中
net.Conn 的 SetNoDelay 和 SetKeepAlive 到底什么时候该开
SetNoDelay(true) 禁用 Nagle 算法，SetKeepAlive(true) 启用 TCP 层保活探测——两者解决完全不同的问题，常被混用。
- 低延迟场景（如游戏信令、行情推送）必须开
SetNoDelay(true)，否则小包会被合并，引入毫秒级延迟 -
SetKeepAlive(true)只防中间设备（NAT、防火墙）静默断连，不保证对端进程存活；设SetKeepAlivePeriod(30 * time.Second)前，确认系统内核参数net.ipv4.tcp_keepalive_time≤ 30 秒，否则内核忽略该值 - 不要在 Accept 后立刻调
SetReadBuffer或SetWriteBuffer：连接可能尚未完成三次握手，macOS 下会静默失败 - 长连接服务建议设
SetReadDeadline+ 应用层心跳双保险，仅靠 TCP KeepAlive 不足以发现对端崩溃
sync.Pool 缓存 bufio.Reader/Writer 的坑在哪
用 sync.Pool 复用 bufio.Reader 能显著降低 GC 压力，但极易因引用残留或复用错位导致 panic 或数据错乱。
立即学习“go语言免费学习笔记（深入）”；
- Pool 中对象不能持有对
net.Conn的强引用，否则连接关闭后 Reader 无法回收，内存泄漏 - 必须在每次使用前调
r.Reset(conn)，而不是构造时传入 conn —— 否则底层 reader 可能仍指向已关闭连接 - 缓冲区大小统一设为固定值（如 4096），不同 size 会导致 Pool 内存碎片化，抵消复用收益
- Reader/Writer 必须在同 goroutine 内 Get → Reset → Use → Put，严禁跨连接复用
什么时候该考虑绕过内核协议栈（KCP/QUIC）
TCP 协议栈在公网弱网下表现差，不是 Go 的问题，而是 TCP 自身重传与拥塞控制机制在高丢包、高 RTT 场景下的固有缺陷。
- 移动端或 CDN 边缘通信：用
quic-go替换 HTTP/1.1 → HTTP/3，服务端需支持 ALPN 和 QUIC - 游戏/音视频信令通道：用
kcp-go，开启SetStreamMode(true)后行为接近 TCP，但容忍丢包、重传更激进 - KCP/QUIC 不是银弹：CPU 开销上升 20–40%，调试链路变长（抓包失效），服务端兼容性远不如 TCP
- 先确认瓶颈真在协议层：pprof 看 CPU 是否集中在
runtime.syscall或net.(*conn).read，再决定是否切换
最容易被忽略的点是：所有 socket 级调优（TFO、缓冲区、keepalive）都依赖操作系统配置生效。没改 /etc/sysctl.conf 就调 SetKeepAlivePeriod，等于白设。
