wire 是编译前生成纯 go 初始化代码的工具，不介入运行时；其依赖注入逻辑通过 // +build wireinject 文件中的 wire.build() 定义，要求 provider 签名精确匹配、不可手改 wire_gen.go，且仅保障依赖图完整性而非运行时连通性。
Wire 不是用来“配置依赖”的运行时框架，而是编译前就生成纯 Go 初始化代码的工具——它不接管运行时，只帮你把 main() 里那堆 new、init、defer 的手动拼接逻辑，变成类型安全、可跳转、无反射的自动生成代码。只要理解这点，你就不会在 runtime panic 里找 Wire 的 bug。
为什么 wire.Build() 必须写在 +build wireinject 文件里
Wire 不扫描整个项目，只解析带有 // +build wireinject 构建标签的 Go 文件。这个标签是硬性开关，缺了就啥都不生成。
- 文件必须以
.go结尾，且包名和 injector 函数所在包一致（通常是main） -
wire.Build()调用必须出现在函数体内，不能放在全局变量或 init 中 - 如果误写成
//go:build wireinject（Go 1.17+ 新语法），而没加// +build wireinject兼容旧版构建系统，wire gen会静默跳过该文件
provider 函数签名写错会导致 wire gen 直接失败
Wire 依赖函数签名推导依赖图，参数和返回值类型必须精确匹配。常见翻车点：
- 传指针却声明值类型：比如 provider 返回
*DB，但 injector 参数写db DB→ 报错cannot assign *DB to DB - 漏传 context：带
context.Context参数的 provider（如数据库连接），若 injector 函数没声明ctx context.Context参数，wire gen会提示no provider found for context.Context - error 类型处理不当：provider 返回
(T, error)时，调用链上所有中间 provider 都得处理这个error，否则生成失败；Wire 不自动 panic 或忽略 error
wire_gen.go 生成后千万别手改
生成的 wire_gen.go 是纯手工风格代码，但它本质是“只读输出”。一旦你手动修改：
- 下次
wire gen会覆盖你的改动，白忙活 - IDE 跳转会指向生成文件，但调试时堆栈显示的是生成代码行号，不是你写的
wire.go行号——容易误判问题位置 - 如果 provider 逻辑变更（比如加了个新参数），但忘了重新
wire gen，程序仍能编译通过，但运行时 panic：因为生成代码没更新，依赖图已失效
最常被忽略的一点：Wire 的“编译时检查”只作用于 provider 图完整性，不校验业务逻辑是否真能连通。比如数据库 DSN 写错、Redis 地址不可达，这些 runtime 错误 Wire 帮不了——它只确保“你声明要 new 一个 *redis.Client，且确实提供了能产出它的函数”，至于那个函数执行时连不连得上，得靠你自己的 if err != nil 和健康检查兜底。
