Wire 是编译前生成 inject.go 的依赖注入工具，不运行时反射，需手动执行 wire build 生成代码；provider 函数只看签名，不执行逻辑；inject.go 必须提交 Git；适合中大型项目依赖管理。
Wire 不是“自动注入”，而是编译前生成 inject.go
Wire 从不运行时查找或装配依赖，它只是读你的 wire.go 文件，调用你写的 provider 函数签名，然后生成一段纯手工风格的 Go 初始化代码（比如 inject.go）。这段代码会被 go build 直接编译进去，没有反射、没有接口断言开销、IDE 点击能跳转到 NewDB 或 NewHandler 的定义处。
所以你必须在含 wire.go 的目录下手动执行：wire build
而不是 go run main.go —— 后者根本不会触发 Wire，也就不会有 inject.go，自然报 undefined: NewApp。
-
wire.go必须以// +build wireinject开头，否则go build会忽略它，wire build也找不到入口 - 所有 provider 函数（如
NewDB、NewCache）必须和wire.Build(...)在同一包内，或显式用pkg.NewDB引用 - 生成的
inject.go是构建产物，但必须提交进 Git；CI 拉代码后若缺失，go build直接失败
Provider 函数怎么写才不被 Wire 报错
Wire 只看函数签名：参数类型决定它需要什么依赖，返回类型决定它提供什么能力。它不执行函数体，也不检查初始化逻辑是否成功——哪怕 NewDB() 里写了 panic("connect failed")，Wire 仍会把它塞进生成代码里，错误只在运行时爆发。
- provider 应只做构造，不做副作用：不要在
NewDB()里调db.Open()，拆成NewDB()+ 后续db.Open()两步更安全 - 避免
func() interface{}这类宽泛返回，要明确返回具体实现指针，并用wire.Bind声明可转换为某接口，例如：wire.Bind(new(Logger), new(*ConsoleLogger)) - 两个 provider 都返回
*redis.Client？Wire 无法区分，必须用wire.Struct或wire.Value显式绑定别名，或改用不同返回类型（如type CacheClient *redis.Client）
常见错误现象及对应解法
本地能跑、CI 失败，或 go run 报错找不到函数，90% 是 Wire 工作流没对齐。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
undefined: NewHandler→ 没运行wire build，或wire.Build()里漏了NewHandler，或它不在同一包 -
cannot use ... as ... value in return statement→ 返回值类型和 injector 声明的类型不匹配，比如 injector 要*PostHandler，但 provider 返回了PostHandler（少了个*） - Git 提交后别人拉代码编译失败 →
inject.go被.gitignore误删，检查是否写了模糊规则如**/*.go，应只忽略/tmp/、/dist/等路径 - CI 流程中忘记生成 → 在
go build前加一步：wire build && go fmt ./ && go vet ./
什么时候该用 Wire，什么时候该手写
Wire 适合中大型项目，尤其是依赖链深、环境多（dev/staging/prod）、组件需频繁替换（如换 DB、换缓存）的场景。小项目三四层依赖，手写 NewA(NewB(NewC())) 更快更直观。
但一旦出现以下情况，就该考虑 Wire：
- main 初始化逻辑超过 20 行，且每次加个新组件就要改一堆
new调用 - 测试时想 mock 某个底层依赖（如
*sql.DB），但构造链太长，难插桩 - 多个 service 共享同一个配置对象或 logger 实例，靠传参容易漏、难统一
记住一点：Wire 解决的是“构造顺序”和“类型拼接”的机械劳动，不是业务逻辑抽象。它生成的代码就是你本该手写的代码——只是你懒得写，而且容易写错。
