Wire 是编译期代码生成器，非运行时 DI 框架，仅串联 NewXXX 函数生成硬编码初始化逻辑，不支持动态注册、条件注入、泛型 provider 或生命周期管理，所有依赖必须显式声明且类型严格匹配。
Wire 不是运行时反射容器，它在编译期生成硬编码的初始化代码——这意味着你没法用它做动态注册、条件注入或热替换。
Wire 为什么不能替代 Go 的原生构造函数？
Wire 的本质是代码生成器，不是 DI 框架。它不拦截 new 或修改类型行为，只是帮你把 NewXXX() 函数按依赖图串联起来，最终输出一个纯 Go 函数（比如 InitializeApp()）。如果你期望类似 Spring 的 @Autowired 或 Dagger 的模块化绑定，会发现 Wire 的“绑定”其实是显式函数调用链。
- 所有 provider 必须是普通函数，返回值类型必须严格匹配依赖需求（不能靠 interface 动态适配）
- 没有生命周期管理（
Singleton只是生成单例调用，不维护实例状态） - 无法注入未导出字段或非公开类型，因为生成的代码要能编译通过
- 错误提示直接来自 Go 编译器：比如
cannot use *db.DB as *sql.DB，不是 Wire 自己报错
provider 函数写法的三个硬约束
Wire 对 provider 函数签名极其敏感，稍有偏差就无法解析依赖。最常见失败点集中在参数顺序、命名和类型精度上。
- 参数名无关紧要，但类型必须完全一致（
*sql.DB≠*DB，即使后者是前者的别名） - 返回值不能多也不能少：需要
*Cache，你就只能返回*Cache；返回*Cache, error是合法的，但返回cache.Cache就会报no provider found for cache.Cache - 不能用泛型函数作为 provider（Go 1.21+ 仍不支持），
func NewClient[T any]() *Client[T]会被 Wire 完全忽略
示例：这个 provider 是有效的：
立即学习“go语言免费学习笔记（深入）”；
func NewDB(cfg Config) (*sql.DB, error) {
return sql.Open("postgres", cfg.DSN)
}
但这个会失败：
func NewDB(cfg Config) (driver.Driver, error) { // 类型不匹配
db, _ := sql.Open("postgres", cfg.DSN)
return db.Driver(), nil
}
wire.Build() 里漏掉依赖会怎样？
Wire 不会扫描整个项目，只看 wire.Build() 显式列出的 provider 和 injector。漏掉中间依赖，生成的代码会直接编译失败，错误信息往往指向缺失类型的构造函数。
- 比如
Service依赖*Repository，而*Repository又依赖*sql.DB，但你只在wire.Build(NewService)里写了NewService，没写NewRepository或NewDB，Wire 就会报cannot find provider for *Repository - 如果某个 provider 返回
error，且你没在 injector 签名中声明接收 error，Wire 会静默跳过该 error 返回值，导致运行时报 panic（比如 DB 连接失败却没被检查） -
wire.Build()中 provider 顺序无关，但 injector 函数签名必须包含所有最终需要的类型（包括 error）
正确写法：
func InitializeApp(cfg Config) (*App, error) {
wire.Build(NewApp, NewService, NewRepository, NewDB)
return &App{}, nil
}
Wire 生成的代码藏在哪？怎么调试？
执行 wire generate 后，它会在同目录下生成 wire_gen.go（默认名），里面全是手动写的等效初始化逻辑。这不是黑盒——你应该打开它看一眼。
- 生成文件开头有
// Code generated by Wire. DO NOT EDIT.，但你可以读它来确认依赖是否按预期串联 - 如果生成失败，先检查
wire:go:generate注释是否在正确位置（必须在go:generate行上方，且与package同文件） - 常见陷阱：
go:generate wire写在main.go，但wire.Build()在app/wire.go，此时wire命令找不到目标函数 - 生成后记得
go fmt ./...，Wire 生成的代码有时缩进不规范，影响 git diff 可读性
真正难的是跨 package 依赖：比如 storage.NewDB() 在 storage/ 下，你必须在 wire.Build() 所在文件 import 该包，并显式写出 storage.NewDB，不能靠路径推断。
