重连时应避免无限循环 dial，需用指数退避（100ms起，上限30s+抖动）、设总超时/最大重试次数、封装为可取消函数；连接后须启用tcp keepalive或应用层心跳、设读写deadline；写请求需状态机管控与channel协调，非幂等操作不可盲目重发。
重连时别用无限 for 循环套 dial
直接 for { conn, err := net.Dial(...) } 会疯狂建连接，既压垮服务端又耗尽本地 fd。Go 的 net.Dial 默认不带退避，失败后立刻重试，网络分区期间可能每秒试几十次。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用指数退避（exponential backoff），从 100ms 起步，上限控制在 30s 内，避免卡死
- 加随机抖动（jitter），防止多个客户端同步重连形成“重连风暴”
- 设置总超时或最大重试次数，比如连续失败 10 次且累计耗时超 5 分钟就放弃
- 把重连逻辑封装成可取消的函数，接收
context.Context，方便上层统一中断
连接建立后要持续探测活跃性
只靠初始 dial 成功不能说明链路可用——网络分区可能发生在连接建立之后，TCP keepalive 默认间隔太长（Linux 通常 2 小时），根本来不及发现断连。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 启用 TCP keepalive：用
net.Dialer.KeepAlive设为 30s 左右，再通过conn.SetKeepAlive(true)开启 - 对关键长连接（如 gRPC、WebSocket、自定义协议），自己实现应用层心跳：定时发
PING包，收不到PONG就主动关连接 - 读写操作必须设 deadline：
conn.SetReadDeadline和conn.SetWriteDeadline，否则阻塞 I/O 会卡住整个重连流程 - 不要依赖
conn.RemoteAddr()是否为空判断是否断开——它永远不为空，得靠读写错误或心跳失败来判定
重连期间正在写的请求怎么处理
重连不是原子操作，旧连接可能还在写数据，新连接刚建好但还没准备好，此时发请求大概率丢或 panic。
常见错误现象：write: broken pipe、use of closed network connection、协程 panic 报 send on closed channel。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用状态机管理连接生命周期：如
Disconnected → Connecting → Connected → Disconnecting，所有写操作前检查当前状态 - 写请求走 channel + select，配合
ctx.Done()和连接状态信号，避免向已关闭连接写 - 对非幂等请求（如 POST 创建资源），重连后不能盲目重发——需服务端支持去重（如 idempotency key）或客户端缓存待发队列并人工干预
- 如果用
http.Client，注意它的 Transport 默认复用连接，但不会自动重试失败请求；要重试得自己 wrap RoundTrip 并判断url.Error.Err是否是网络类错误
别忽略 DNS 缓存和连接池干扰
看似是网络分区，实际可能是 DNS 解析卡住或旧连接池里混着失效连接，导致重连逻辑误判。
使用场景：K8s 环境下 Service IP 变更、Consul 注册中心临时不可达、云厂商 LB 后端节点漂移。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 禁用 DNS 缓存：设
&net.Resolver{PreferGo: true, Dial: ...}，并缩短net.Dialer.Timeout和KeepAlive，避免卡在解析阶段 - 用
http.Transport.MaxIdleConnsPerHost = 0或定期调transport.CloseIdleConnections()，防止旧连接残留干扰 - 若依赖 etcd/consul，重连逻辑里应包含服务发现刷新步骤，而不是只 retry dial 原地址
- 日志里至少打两件事：当前目标地址、本次 dial 的 error（如
dial tcp 10.2.3.4:8080: i/o timeout），否则根本分不清是 DNS、路由、防火墙还是对方挂了
最麻烦的不是重连本身，是重连时旧连接还没彻底关闭、新连接已建好、应用层请求正并发流向两者——这时候状态同步和错误归因最难做准。宁可让重连慢一点，也别省掉状态隔离和中间缓冲。
