wire 是编译期依赖注入工具，通过生成硬编码初始化代码避免运行时类型断言失败、循环依赖延迟报错等问题，解决手写构造函数冗余和测试 mock 困难的痛点。
Wire 是什么，为什么非用不可
Wire 不是运行时反射容器，它在编译期生成硬编码的初始化代码。这意味着你不会遇到 interface{} → concrete type 类型断言失败、依赖循环检测延迟到启动时报错、或者生产环境因 DI 框架 bug 导致 panic 的问题。
它解决的是 Go 项目里最实际的痛点：手写 NewService 套娃函数越写越多，改一个参数要顺藤摸瓜改七八个构造函数，测试时还得手动 mock 所有上游依赖。
常见错误现象：panic: interface conversion: interface {} is nil, not *service.UserRepository —— 这往往是因为某层 New 函数漏传了依赖，而 Wire 能在 go run wire.go 阶段就报出 missing binding for type *repository.UserRepository，提前拦截。
怎么写 wire.go 文件才不翻车
别把它当成配置文件，它本质是一组 Go 函数调用链的声明式描述。核心就三样：Provider（返回具体类型的函数）、Inject（入口函数）、Build（触发生成）。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
-
wire.go必须放在和main.go同一包下（通常是main包），否则wire gen找不到入口 - 每个
Provider函数必须是公开的（首字母大写），且不能带接收者（不是方法） - 避免在
Provider里做耗时操作（比如连数据库），Wire 只管“怎么造”，不管“什么时候造” - 如果依赖树里有可选配置（比如日志级别、超时时间），用结构体封装后作为参数传入
Provider，别硬编码
示例片段：
func initApp(cfg Config) (*App, error) {
wire.Build(
NewHTTPServer,
NewUserService,
NewUserRepository,
wire.Struct(new(Config), "*"),
)
return nil, nil
}
Provider 函数签名怎么设计才好维护
Go 的依赖注入没有“自动绑定”概念，所有类型都得显式声明。Provider 的参数顺序决定了初始化顺序，但 Wire 不会帮你检查逻辑依赖闭环 —— 它只看类型能否被满足。
容易踩的坑：
- 两个
Provider返回同一种接口类型（比如都返回logger.Logger），Wire 会报multiple bindings for logger.Logger—— 必须用wire.InterfaceValue或拆成不同包/别名区分 - 把
*sql.DB和driver.Conn当作等价依赖传入，结果运行时报cannot use *sql.DB as driver.Conn—— Provider 输出类型必须和下游期望的输入类型严格一致 - 用指针接收者方法实现接口，却在 Provider 里返回值类型（如
return Service{}），导致接口无法赋值 —— 记住：只有*Service才能实现ServiceInterface
Wire 生成的代码要不要提交进 Git
要。生成的 wire_gen.go 是构建链条中确定的一环，不是临时产物。CI 流程里跑 wire gen 再提交，等于把依赖图“快照”下来，避免本地环境和 CI 环境因 Wire 版本差异导致初始化行为不一致。
性能与兼容性影响：
- 生成的代码无反射、无 panic、无 interface{}，和手写初始化函数性能完全一致
- Wire v0.5+ 对 Go 1.21+ 的泛型支持仍有限，如果 Provider 返回泛型类型（如
Cache[string]），目前需先实例化具体类型再提供 - 不支持跨 module 自动发现 Provider，
wire.Build引用的函数必须已导入（import _ "xxx/internal/di"不行，得真 import）
真正复杂的地方在于：当服务之间存在隐式生命周期耦合（比如 A 需要监听 B 的 shutdown 信号），Wire 只管创建，不管销毁 —— 你得自己在 App.Run() 或 App.Close() 里组织释放顺序，这部分没法靠工具推导。
