根本原因是系统级文件描述符耗尽，导致内核无法处理TCP ACK、重传或FIN，使net.Conn读写永久阻塞且超时失效；需通过lsof、dmesg和tcpdump三步定位句柄枯竭。
为什么 net.Conn 读写突然卡住，且无超时、无错误？
这不是 Go 程序逻辑 bug，而是系统级资源耗尽的典型表现：当 Linux 的 ulimit -n（进程最大打开文件数）被耗光，新 net.Dial 会失败，但更隐蔽的是——已有连接在内核层面无法完成 TCP ACK、重传或 FIN 处理，表现为 conn.Read() 或 conn.Write() 永久阻塞，ctx.WithTimeout 也失效（因为阻塞发生在 syscall 层，Go runtime 无法介入）。
确认是否真为句柄枯竭：三步定位
别急着改代码，先验证是不是系统瓶颈：
- 查当前进程句柄占用：
ls /proc/$(pidof your-go-binary)/fd | wc -l，对比cat /proc/$(pidof your-go-binary)/limits | grep "Max open files" - 看内核是否已拒绝分配：
dmesg -T | grep -i "too many open files"或grep "file-max" /proc/sys/fs/看全局上限 - 抓包验证异常：用
tcpdump -i any port XXXX观察挂起连接是否还有 TCP 包交互——若完全静默，大概率是 socket 创建失败后连接卡在半开状态
net/http.Transport 默认配置如何悄悄吃掉几千个句柄
Go 的 http.DefaultTransport 默认启用连接复用，但它的 MaxIdleConns 和 MaxIdleConnsPerHost 若未显式设限，会在高并发短连接场景下累积大量 idle socket，每个都占一个 fd。更危险的是 IdleConnTimeout 默认 30s，意味着连接空闲后不会立刻释放。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 必须显式配置：
transport := &http.Transport{ MaxIdleConns: 100, MaxIdleConnsPerHost: 100, IdleConnTimeout: 5 * time.Second, // 强制关闭 keep-alive（适合短生命周期调用） // ForceAttemptHTTP2: false, } - 对长连接服务（如 gRPC），还要关注
http.Client是否被复用——全局单例 client + 默认 transport 是常见句柄泄漏源头 - 注意：
MaxIdleConnsPerHost是 per-host（含端口）限制，https://api.a.com:443和https://api.b.com:443算不同 host
Go runtime 无法捕获的句柄泄漏点
很多 net.Conn 泄漏不是忘了 Close()，而是根本没机会执行：
立即学习“go语言免费学习笔记（深入）”；
- goroutine panic 后未 defer 关闭：
conn, err := net.Dial(...); if err != nil { return }; defer conn.Close()—— 这行defer在 panic 时仍会执行；但若 dial 成功后，在业务逻辑中才conn.Close()，panic 就跳过了 - 使用
io.Copy或io.CopyN时，目标io.Writer写满或出错，源io.Reader（比如conn）可能没被关闭，需手动补conn.Close() - 第三方库（如某些 Redis 客户端）内部连接池未按需收缩，或未响应
context.Context取消信号，导致连接长期 idle 占用 fd
真正棘手的从来不是“怎么关”，而是“什么时候该关”——尤其在流式响应、multipart 上传、WebSocket 等场景里，连接生命周期和业务逻辑耦合紧密，靠静态分析很难全覆盖。
