Go高并发下fd耗尽主因是未及时释放或复用，关键在“别漏关、别早关、别乱复用”：HTTP客户端需确保resp.Body.Close()，TCP服务端须defer conn.Close()，连接池参数需匹配服务端keepalive超时，sync.Pool不可直接缓存裸conn而应缓存拨号逻辑，系统级需调优ulimit、TIME_WAIT及内核参数。
Go 程序在高并发 TCP 或 HTTP 场景下，文件描述符（fd）耗尽是典型瓶颈，根本原因不是连接数不够，而是 fd 没被及时释放或复用。关键不在于“开更多”，而在于“别漏关、别早关、别乱复用”。
为什么 net.Conn 会泄漏 fd？
最常见的泄漏点是：没调用 conn.Close()，或在错误分支里跳过了关闭；更隐蔽的是，对 http.Response.Body 忘记 resp.Body.Close() —— 这会导致底层 net.Conn 无法归还到连接池，fd 就卡住了。
- HTTP 客户端：即使请求失败（如
err != nil），只要resp非 nil，就必须resp.Body.Close() - TCP 服务端：
handleConn函数必须确保defer conn.Close()在最外层，且不能被return或 panic 绕过 - 使用
bufio.Reader包装conn时，Close()仍要作用于原始conn，而非 reader
http.Transport 的连接池参数怎么设才不浪费 fd？
连接池不是越大越好。设得过大，fd 占用高；设得太小，又频繁建连。关键是让 IdleConnTimeout 略小于服务端的 keepalive 超时，避免客户端保留已失效连接。
-
MaxIdleConns：全局最大空闲连接数，建议设为 100–500（取决于总并发量） -
MaxIdleConnsPerHost：单 host 限制，避免某接口吃光全部连接，建议设为 20–100 -
IdleConnTimeout：必须比服务端keepalive_timeout小（例如 Nginx 默认 75s，这里设 60s） -
KeepAlive：TCP 层心跳间隔，设为 30s 即可，需系统内核net.ipv4.tcp_keepalive_time支持
自建 net.Conn 池时，sync.Pool 不能直接缓存 *net.TCPConn
把裸连接塞进 sync.Pool 是危险操作：连接可能已被远端关闭、超时、或处于半关闭状态，下次取出直接读写会 panic 或返回 io.EOF。
立即学习“go语言免费学习笔记（深入）”；
- 从池中取连接后，必须先做轻量探测：调用
conn.SetReadDeadline(time.Now().Add(100 * time.Millisecond))，再尝试一次非阻塞conn.Read()或conn.Write() - 探测失败则丢弃该连接，新建并放入池；成功则重置超时（
conn.SetReadDeadline(time.Time{})）再使用 -
Put前务必确保连接未关闭，且无 pending read/write；否则可能复用已关闭连接，触发 “use of closed network connection” - 更稳妥的做法是缓存连接的初始化逻辑（如
net.Dial参数），而非连接本身
系统级 fd 限制和 TIME_WAIT 问题怎么配合调优？
Go 程序能打开的 fd 上限由系统 ulimit -n 决定，但真正卡住你的，往往是 TIME_WAIT 状态连接堆积 —— 它们占着 fd 不放，却无法复用。
- 服务端：启用
SO_REUSEADDR（Go 默认已设），允许bind()重用处于TIME_WAIT的端口 - 客户端：避免短连接高频调用；若必须短连，可通过
net.ListenConfig{Control: setSockopt}设置SO_LINGER缩短TIME_WAIT时间（需 root 权限） - 内核调优：增大
net.ipv4.ip_local_port_range（如 1024–65535），减少端口耗尽风险；调小net.ipv4.tcp_fin_timeout（谨慎，影响稳定性） - 监控手段：用
lsof -p PID | wc -l查实时 fd 数，ss -tan state time-wait | wc -l查TIME_WAIT连接数
fd 复用真正的难点不在代码怎么写，而在生命周期边界是否清晰：每个连接从哪来、谁负责关、何时能复用、失效了怎么清理。漏掉任意一环，都可能让 fd 在某个角落静默堆积，直到 too many open files 报错才被发现。
