wire 不是自动注入而是编译期代码生成，通过 wire build 生成 inject.go 实现零运行时开销、编译期检查和 ide 可跳转，但需手动触发且不支持动态替换依赖。
Wire 为什么不是“自动”注入，而是代码生成
Wire 不是运行时反射式 DI 框架（比如 Spring 或 Angular），它在编译前就生成 inject.go 文件，把依赖组装逻辑写死成普通 Go 代码。这意味着：没有运行时开销、IDE 能跳转、报错在编译期暴露——但你也得手动触发生成，且无法动态替换依赖。
常见错误现象：undefined: NewHandler 或 cannot use ... as ... value in return statement，基本都是因为没跑 wire build，或者 wire.Build(...) 里漏写了某个提供者函数。
- 必须在含
wire.go的目录下执行wire build（不是go run） -
wire.go文件需包含// +build wireinject构建标签，否则会被go build忽略 - 所有 provider 函数（如
NewDB、NewCache）必须和wire.Build在同一包内，或显式 import 后用pkg.NewDB引用
Provider 函数怎么写才不被 Wire 报错
Wire 只认“函数签名即契约”。它靠参数类型匹配依赖，靠返回值类型暴露能力。一个 NewHTTPServer 函数如果参数里有 *sql.DB，Wire 就会去找谁提供 *sql.DB；如果返回 http.Handler，那其他函数要 http.Handler 就能直接用。
容易踩的坑：func NewDB() *sql.DB 看似没问题，但如果实际初始化失败（比如连接超时），Wire 生成的代码仍会调用它——而 panic 发生在运行时，不是 Wire 检查范围。
立即学习“go语言免费学习笔记（深入）”；
- Provider 函数应只做构造，不做副作用操作（如连 DB、启 goroutine）。真要初始化，拆成
NewDB+db.Open()两步，后者由业务逻辑控制 - 避免返回接口的 provider 直接 new struct（如
return &myService{}），应确保该 struct 实现了所有返回接口，否则 Wire 推导失败 - 多个同类型 provider（比如两个都返回
*redis.Client）会导致冲突，必须用wire.Struct或wire.Value显式绑定别名
Wire 生成的 inject.go 被 git 忽略后 CI 失败
inject.go 是产物，不该手改，但必须提交到仓库——否则 CI 拉代码后没有它，go build 直接失败。这不是可选优化，是 Wire 工作流的硬性要求。
典型错误：本地开发时 .gitignore 里写了 **/*.go 或 inject*，导致 inject.go 没进 Git；或者团队误以为“生成文件不用提交”，结果新成员 go run main.go 报错找不到 NewApp。
- 务必在
.gitignore中排除具体路径，比如/tmp/、/dist/，而不是模糊匹配*.go - CI 流程中应在
go build前加一步：wire build && go fmt ./... && go vet ./... - 可以用
wire watch（v0.5+）监听变化自动重生成，但仅限开发机，别依赖它替代提交
什么时候不该用 Wire
Wire 适合中大型服务，依赖层级深、启动逻辑固定、对启动性能和可调试性有要求。但它解决不了所有问题，强行套用反而增加心智负担。
常见误用场景：CLI 工具、测试 setup、临时脚本、或只有 2–3 个依赖的小 Web handler。这时候手写 main() 初始化几行更清楚，改起来也快。
- 测试中想替换 mock 依赖？Wire 默认不支持运行时 override。得靠
wire.NewSet拆分 provider 集合，再为 test 单独定义一套TestSet - HTTP handler 里需要 request-scoped 依赖（如
context.Context、*http.Request）？Wire 只处理 application-scoped（整个进程生命周期）依赖，这类必须手动传参 - 项目还在快速原型阶段，结构天天变？先 hand-roll，等接口稳定了再上 Wire，不然每天都在修
wire.Build参数
Wire 的复杂点不在语法，而在你得提前想清楚依赖边界——哪些该由它管，哪些不该。这点容易被忽略，直到某天发现一半 provider 在 inject.go 里，另一半散落在 main() 里，又不敢动。
