go 的 net.conn 不支持自动重连，因其是一次性接口，关闭或异常中断后即不可用；重连必须由业务代码显式实现，包括超时控制、错误分类、资源清理和指数退避等机制。
Go 的 net.Conn 本身不支持断线重连，所有重连逻辑必须由业务代码显式控制；试图复用已关闭或出错的连接会直接 panic 或返回 use of closed network connection。
为什么 dial 后的 conn 不能自动重连
net.Conn 是一次性接口：一旦 Close() 被调用，或底层因网络闪断、对端关闭、超时等异常中断，该实例即进入不可用状态。后续任何 Read() 或 Write() 都会立即报错，无法恢复。
- 错误类型包括：
io.EOF、net.ErrClosed、syscall.ECONNRESET、read: connection reset by peer - 不能靠捕获 error 后“重试当前 conn”，必须新建连接
- 标准库不提供重连封装，这是设计取舍——把连接生命周期完全交还给上层
如何用 net.DialTimeout + 指数退避安全重连
重连不是简单循环 dial，关键在超时控制、错误分类和资源清理。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
net.DialTimeout("tcp", addr, 5*time.Second)防止 DNS 不可达或防火墙丢包导致永久阻塞 - 失败后按指数退避 sleep：
1s → 2s → 4s → 8s，上限建议设为30s，避免重连风暴 - 每次重试前检查旧 conn 是否非 nil，并显式调用
conn.Close()，否则 fd 泄漏 - 连接成功后立刻设置读写 deadline：
conn.SetReadDeadline(time.Now().Add(10 * time.Second))
读写操作中如何触发重连而不卡死
不能把重连逻辑硬塞进 Read/Write 分支里，否则 goroutine 会阻塞、无法响应取消信号。
- 读循环中遇到
io.EOF或net.OpError，应通过 channel 通知主控 goroutine 触发重连 - 写操作建议封装成
Send([]byte)方法，在内部先检查 conn 状态，失效则同步重连再发 - 重连过程必须在独立 goroutine 中执行，并接受
context.Context控制生命周期 - 重连成功后，需重新启动读/写 goroutine，并重置心跳（如
SetPingHandler）
常见坑：重连时忘了关旧连接 or 忘了重建协议状态
很多看似“重连成功”的 bug，其实源于旧资源没清理干净或新连接没初始化到位。
- RabbitMQ 场景下：重连后必须调
conn.Channel()新建 channel，再重新ExchangeDeclare和QueueBind，旧 channel 不可复用 - WebSocket 场景下：重连后要重新注册
SetPongHandler，并启动新的 ping goroutine，否则心跳失效 - TCP 自定义协议：粘包处理 buffer、序列化上下文、会话 ID 等状态需在重连后手动恢复，否则数据错乱
- 所有重连入口点都应有日志输出，比如
"reconnecting after read error: %v"，否则抖动时根本无法定位是哪次断开触发的重连
真正难的不是写一个能重连的函数，而是让重连行为可观察、可中断、不泄漏、不重复——这些细节往往只在压测或弱网环境下才暴露出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
