go net包无高性能抽象层，需显式控制dialer、listenconfig及连接生命周期；默认net.listen和net.dial易致连接堆积、超时失控、goroutine泄漏、端口耗尽。
Go 的 net 包本身不提供“高性能抽象层”，所谓高性能，全靠你对 Dialer、ListenConfig 和连接生命周期的显式控制。默认写法（比如直接 net.Listen("tcp", ":8080") 或 net.Dial("tcp", "x:80")）在压测或真实流量下大概率会出问题——不是程序崩溃，而是连接堆积、超时不可控、goroutine 泄漏、端口耗尽。
为什么 net.Listen 默认行为扛不住高并发
默认 net.Listen 返回的是 tcpKeepAliveListener，它只启用了固定 timeout 的 TCP keep-alive（Linux 下默认 2 小时），但完全无法干预：accept 队列长度、SO_REUSEPORT、TCP_DEFER_ACCEPT、绑定本地地址策略，也没有 context 支持。结果就是：
- SYN 半连接队列溢出，内核丢包，客户端看到 Connection refused 或超时
- 大量 TIME_WAIT 占满本地端口，新连接失败（错误：
bind: address already in use） -
Accept()调用无法被 cancel，服务重启时卡住，无法优雅退出
正确做法是用 net.ListenConfig 显式构造：
lc := net.ListenConfig{
Control: func(fd uintptr) {
syscall.SetsockoptInt32(int(fd), syscall.SOL_SOCKET, syscall.SO_REUSEPORT, 1)
syscall.SetsockoptInt32(int(fd), syscall.IPPROTO_TCP, syscall.TCP_DEFER_ACCEPT, 1)
},
KeepAlive: 30 * time.Second,
}
ln, err := lc.Listen(context.Background(), "tcp", ":8080")
net.Dialer 必须显式配置，否则等于没调优
出向连接的瓶颈往往不在业务逻辑，而在 DNS 解析、TLS 握手、连接复用和失败重试。全局默认 Dialer（如 net.Dial）不可控、无上下文、不设超时，极易拖垮整个服务。
-
Timeout只管 TCP 连接建立（三次握手），不含 TLS；要覆盖 TLS，必须用DialContext+context.WithTimeout -
KeepAlive设为 0 表示禁用 TCP keep-alive；设为非零才真正启用探测（避免连接假死） -
DualStack: true强制双栈解析，否则 AAAA 缺失时会多等几秒再 fallback 到 IPv4 -
Resolver可替换为带缓存的自定义net.Resolver，避免高频 DNS 查询阻塞 - 绝对不要写
net.Dial("tcp", "host:port")—— 它绕过所有配置，且无法 cancel
goroutine 泄漏比慢更致命，且极难排查
几乎所有新手代码都这么写：go handleConnection(conn)，但只要 handleConnection 内部没处理连接异常关闭、没配合 context 或 sync.WaitGroup 控制生命周期，就一定会泄漏。
- 典型泄漏场景：客户端断连后，
conn.Read返回io.EOF或网络错误，但 handler 没 return，协程永远挂起 - 没有
context传递的 handler，无法响应服务整体 shutdown 信号，导致进程无法退出 - 建议结构：每个 handler 启动时接收一个
context.Context，所有 I/O 都用Read/WriteContext，并在 defer 中 clean up
真正难的不是写个能跑的服务器，而是让百万连接下的每个 conn 都有明确的超时、可 cancel、可追踪、可回收。这些细节不写进代码里，就不存在“高性能”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
