Go的net.Listen本身不慢，但连接卡在三次握手主因是内核TCP栈参数未调优：tcp_max_syn_backlog和somaxconn过小导致SYN队列溢出丢包，而非Go运行时瓶颈。
为什么 Go 的 net.Listen 默认不慢，但连接建立仍卡在三次握手？
Go 本身对 net.Listener 的封装很轻量，net.Listen("tcp", ":8080") 底层调用的是 socket() + bind() + listen()，性能瓶颈几乎不在 Go 运行时，而在于内核 TCP 栈是否准备好快速响应 SYN。常见现象是：压测时大量连接卡在 SYN_SENT → SYN_RECV 阶段，ss -s 显示 synrecv 数持续升高，甚至出现丢包。这不是 Go 写得不好，而是内核的 tcp_max_syn_backlog 和 somaxconn 没跟上。
必须同步调大的两个内核参数：somaxconn 和 tcp_max_syn_backlog
Go 的 net.Listen 接收队列长度由 backlog 参数控制（如 net.ListenTCP 可传 &net.ListenConfig{Control: ...}），但最终受限于系统级上限。若只在 Go 里设 backlog=65535，而内核 net.core.somaxconn = 128，实际生效的仍是 128。
-
net.core.somaxconn：全连接队列最大长度，必须 ≥ Go 中设置的backlog值；建议设为65535 -
net.ipv4.tcp_max_syn_backlog：半连接队列最大长度，应对 SYN 洪峰；也建议设为65535 - 改完后执行
sysctl -p生效，再用cat /proc/sys/net/core/somaxconn确认
Go 侧可做的关键配置：禁用 Nagle、启用 KeepAlive、控制 accept 行为
Go 的 net.Conn 支持细粒度控制，但默认未开启部分高并发必需项。尤其注意：这些必须在 accept() 后立即设置，不能只设 listener。
- 关闭 Nagle 算法：
conn.SetNoDelay(true)，避免小包合并延迟，对 RPC/微服务交互很关键 - 启用 TCP KeepAlive：
conn.SetKeepAlive(true)+conn.SetKeepAlivePeriod(30 * time.Second)，主动探测僵死连接 - 限制单连接读写超时：
conn.SetReadDeadline()/conn.SetWriteDeadline()，防止一个坏连接拖垮整个 goroutine 池 - 避免在
accept后立刻Read()—— 若业务协议头不定长，应先做SetReadBuffer并确保缓冲区够大，否则频繁 syscalls 会放大调度开销
容易被忽略的底层依赖：TIME_WAIT 复用与端口范围
当 Go 作为客户端高频建连（比如调用下游 HTTP 服务），或服务端短连接密集（如健康检查探针），TIME_WAIT 堆积会直接耗尽本地端口。这时仅靠 Go 代码无法解决。
- 必须开启
net.ipv4.tcp_tw_reuse = 1（需同时开启net.ipv4.tcp_timestamps = 1） - 扩大临时端口范围：
net.ipv4.ip_local_port_range = "1024 65535"，避免默认的32768–61000不够用 - 慎用
net.ipv4.tcp_tw_recycle = 0（NAT 环境下会导致连接失败，2026 年仍不建议开启） - Go 本身不管理端口复用逻辑，这部分完全交由内核决定 —— 配置错一条，
dial()就开始报connect: cannot assign requested address
真正卡住高并发建连的，从来不是 Go 的 goroutine 调度，而是内核网络栈那几行 /proc/sys/net/... 配置没对齐。上线前务必用 ss -nti 观察 rtt、cwnd、retrans，而不是只盯着 Go pprof 的 CPU 占比。
