go tcp性能瓶颈在连接建立、复用、超时及系统资源；http.defaultclient默认连接池小易打满；需合理配置dialer超时与keepalive；dns解析需异步+缓存；time_wait过多应启用so_reuseaddr或改长连接。
Go 程序的 TCP 连接性能瓶颈，通常不出现在 net.Conn 本身，而是出在连接建立、复用、超时控制和系统资源约束上。盲目增加 goroutine 数量或调大 SetDeadline 往往适得其反。
为什么 http.DefaultClient 在高并发下容易打满连接数
默认的 http.DefaultClient 使用 http.DefaultTransport，其底层 MaxIdleConns 和 MaxIdleConnsPerHost 默认都是 100，且 IdleConnTimeout 是 30 秒。这意味着：
- 每台后端 host 最多只缓存 100 个空闲连接，超出后新请求会新建 TCP 连接
- 大量短连接场景下，连接反复创建/关闭，触发 TIME_WAIT 堆积
- 若服务端响应慢，空闲连接在 30 秒后被回收，但客户端可能正需要它
实操建议：按实际 QPS 和平均 RT 预估连接池大小，例如 1000 QPS、平均 RT 50ms，理论并发连接约 50，可设 MaxIdleConnsPerHost = 200，IdleConnTimeout = 90 * time.Second；同时务必设置 Response.Body.Close()，否则连接永不归还。
net.Dialer 的 KeepAlive 和 Timeout 怎么配才不踩坑
直接使用 net.Dialer（如构建自定义 http.Transport 或 raw TCP 客户端）时，三个超时参数常被混淆：
立即学习“go语言免费学习笔记（深入）”；
-
Timeout：建立 TCP 连接阶段的总耗时上限（含 DNS 解析、SYN 重试等） -
KeepAlive：TCP 层启用 keepalive 后，空闲连接多久发一次探测包（Linux 默认是 7200 秒，Go 默认 -1 即禁用） -
KeepAlive≠ 应用层心跳；它只防中间设备（如 NAT 网关）断连，不保证对端进程存活
常见错误：设 KeepAlive = 30 * time.Second 但没调大系统 net.ipv4.tcp_keepalive_time，导致内核忽略该值；正确做法是保持 KeepAlive > 0（如 30s），并确保服务端也开启 keepalive 且探测间隔匹配，避免单向断连后连接假死。
如何避免 dial tcp: lookup xxx: no such host 拖垮整体延迟
DNS 解析阻塞在默认 net.Resolver 下是同步且无超时的（Go 1.19+ 才支持 Resolver.LookupHost 的 context 超时）。一旦 DNS 服务器响应慢或丢包，整个 net.Dial 就卡住，goroutine 堆积。
- 强制启用异步解析：用
&net.Resolver{PreferGo: true, Dial: dialContext}，其中dialContext返回带 timeout 的 UDP 连接 - 或更稳妥：在业务层做 DNS 缓存 + 异步刷新，例如用
github.com/miekg/dns自行实现带 TTL 的缓存解析器 - 避免在 hot path 上每次 dial 都解析域名；对固定后端，提前
net.LookupIP并复用 IP 地址
注意：PreferGo: true 会绕过系统 getaddrinfo，在某些容器环境（如 glibc 不全）下更可靠，但需自行处理 /etc/hosts 和 DNS 配置逻辑。
TIME_WAIT 过多导致 socket: too many open files 怎么缓解
主动关闭连接的一方（通常是客户端）进入 TIME_WAIT，Linux 默认持续 60 秒。高频短连接下，netstat -ant | grep TIME_WAIT | wc -l 可能上万，最终耗尽文件描述符。
- 服务端应尽量由 server 主动 close（即 client 设置
Connection: close或用 HTTP/1.0），把 TIME_WAIT 推给服务端承担 - 客户端可设
SyscallConn().Control()调用setsockopt(SO_LINGER)，但风险高（可能丢数据），不推荐 - 更安全的做法：启用端口快速复用 —— 在
net.ListenConfig中设Control: func(fd uintptr) { syscall.SetsockoptInt32(int(fd), syscall.SOL_SOCKET, syscall.SO_REUSEADDR, 1) } - 终极方案：改用连接池 + 长连接（如 HTTP/2、gRPC），从源头减少 connect/close 频次
别忘了检查 ulimit -n，很多线上 Go 服务因没调高这个值，刚到几千并发就报错，其实只是系统限制太保守。
