Go模块不提供自动重连能力，需在业务层显式实现；所谓“支持自动恢复”实为封装net.Conn生命周期管理逻辑，模块仅负责依赖组织与版本控制。
Go 模块本身不提供“自动恢复”能力，网络连接的断开重连必须由你显式编码实现。 所谓“支持自动恢复”，本质是封装 net.Conn 生命周期管理逻辑，而非依赖模块系统自带功能。模块只负责依赖组织和版本控制，真正的恢复行为在业务层。
为什么 go mod 不能帮你自动重连
Go 的模块系统（go.mod）只解决代码来源、版本锁定和依赖解析问题，它不干预运行时行为。即使你用 go get github.com/yourname/netutil 引入一个“带重连的库”，其内部也仍是调用 net.Dial + for 循环 + 错误判断 —— 这不是模块特性，而是库作者写的逻辑。
-
net.Conn是一次性接口：一旦Close()或底层出错（如read: connection reset by peer），该实例不可复用 - 标准库中没有
AutoReconnectConn类型，也没有RetryDialer默认导出 - 所有“自动恢复”都建立在你对错误分类（超时？拒绝？EOF？）、退避策略（固定间隔 or 指数增长）、最大重试次数的明确控制上
如何用模块结构组织可复用的重连逻辑
把重连能力封装成独立模块，便于跨项目复用。关键不在“多复杂”，而在接口清晰、错误可控、配置外置：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 模块路径必须唯一且可寻址，例如
github.com/yourname/retryconn，初始化时运行go mod init github.com/yourname/retryconn - 导出核心类型
RetryConn和构造函数NewRetryConn，隐藏内部*net.TCPConn和重试状态 - 接受可配置参数：重试次数（
MaxRetries）、初始延迟（BaseDelay）、是否启用指数退避（UseExponentialBackoff） - 错误判断要具体：
net.OpError中的Err字段需区分timeout、connection refused、i/o timeout，避免对 DNS 失败也盲目重试 - 不要在
Write或Read内部静默重连 —— 这会掩盖真实失败点；应让调用方决定是否重试，或提供TryWrite/TryRead显式接口
常见踩坑：重连逻辑被模块缓存干扰
你改了重连策略但行为没变？很可能是本地模块缓存或构建产物没清理干净：
立即学习“go语言免费学习笔记（深入）”；
- 修改
retryconn模块后，在下游项目执行go mod tidy不会自动拉取最新 commit —— 必须显式指定：go get github.com/yourname/retryconn@main或打 tag 后用@v0.2.1 - 如果模块还在本地开发中，建议用
replace直接映射路径：replace github.com/yourname/retryconn => ../retryconn，避免反复 push/tag - 缓存污染会导致旧版二进制残留：执行
go clean -cache -modcache清除全部缓存，再go build确保加载的是最新源码 - IDE（如 VS Code + Go extension）可能缓存分析结果，修改接口后需手动触发 “Reload Window” 或删掉
$HOME/go/pkg/mod/cache/download/下对应模块的 zip 包
最易被忽略的一点：重连不是越快越好，也不是越多越好。真实网络环境中，频繁重试可能触发服务端限流、IP 封禁，或掩盖更深层的问题（如 DNS 配置错误、防火墙策略变更）。把“是否重连”和“重连多久”做成可配置项，比写死逻辑更重要。
