net.Conn 不可自动重连，因其为一次性接口，断开后必须由业务代码显式管理生命周期；需通过建连→读写→异常判断→关闭→重试闭环实现复用，并配合超时设置、错误分类、退避熔断与连接池健康检查。
为什么不能依赖 net.Conn 自动重连
因为 net.Conn 是一次性接口，断开后不可复用。你看到的“连接保持”，必须由业务代码显式接管生命周期——不是标准库漏功能，而是设计上把控制权交给你。一旦 conn.Close() 被调用，或底层因超时、对端关闭、网络中断而失效，该实例就彻底作废，再读写会返回 io.EOF 或 syscall.ECONNRESET，不会自动重建。
如何实现带健康检查的连接复用循环
核心是把“建连 → 读写 → 异常判断 → 关闭 → 重试”串成可控闭环，而不是扔给 goroutine 后不管。容易忽略的关键点：
-
net.Dialer必须显式设置Timeout（仅控三次握手）和KeepAlive（如30 * time.Second），否则 TCP 探活由系统默认值决定，不可控 - 每次
Read或Write前，务必调用conn.SetReadDeadline()/conn.SetWriteDeadline()，否则丢包或对端静默关闭时会永久阻塞 - 错误要分类处理：
net.ErrClosed和io.EOF可直接重连；context.DeadlineExceeded是本地超时，也应重试；但net.OpError中的DNS lookup failed类错误需降级或告警，盲目重试无意义 - 每次重试前必须
if conn != nil { conn.Close() }，否则 fd 泄漏，跑几小时就触发too many open files
怎么避免重连风暴和无效连接堆积
高频失败后立刻重试，等于向服务端倾泻 SYN 包，可能触发防火墙限速或压垮对方。真实场景中必须引入退避与熔断：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用指数退避：从
1 * time.Second开始，每次失败翻倍，上限设为30 * time.Second，防止雪崩 - 维护连接状态标记，比如记录最近三次建连耗时，若全部 > 2s 且错误率 > 80%，主动暂停重试 5 分钟，写入日志并触发告警
- 空闲连接不放任不管：在
Put()归还连接时，记录time.Now()；Get()时若发现已空闲超60 * time.Second，直接Close()并新建，不塞回池子 - 不要用
sync.Pool存net.Conn：它不保证对象存活期，且无法做健康检查，极易归还失效连接
HTTP 场景下别重复造轮子，但得管住 Transport
HTTP 客户端不用自己写连接池，http.Client 底层的 http.Transport 已内置复用逻辑，但默认配置极易被干扰：
立即学习“go语言免费学习笔记（深入）”；
- 必须复用单例
http.Client，绝不在请求里&http.Client{}—— 它非线程安全，且每次 new 都新建 Transport - 显式配置
Transport.MaxIdleConns和MaxIdleConnsPerHost（如都设为500），默认 100 在高并发下不够用 -
IdleConnTimeout必须设（推荐30 * time.Second），否则空闲连接长期不释放，占满本地端口 - 最隐蔽的坑：
Response.Body不Close()，连接永远无法归还池子——哪怕只读 header 也要defer resp.Body.Close() - 若服务端返回
Connection: close或用 HTTP/1.0，复用直接失效，得查响应头确认
复杂点不在“怎么连”，而在“连上之后怎么知道它还活着”以及“断了以后怎么不拖垮自己”。健康检查不能只靠一次 Write，得结合读超时探测、心跳帧、业务层 ACK 多重验证；而连接池的边界控制，永远比性能优化更优先。
