wire 是静态依赖注入工具，不运行时注入；需用 // +build wireinject 标签标记 wire.go，provider 函数须导出、无副作用、签名可推导，inject.go 必须提交至 git 并在 ci 中生成。
Wire 不是运行时框架，它不“自动注入”，也不拦截 go run 或 go build。你看到的 NewApp、InitializeServer 全是生成出来的普通函数——和手写初始化代码一模一样，只是由工具帮你写了。
wire.go 文件必须带 // +build wireinject 标签
这个注释不是可选的，是硬性开关。没有它，go build 会直接跳过 wire.go，导致 wire build 扫不到 wire.Build() 调用。
常见错误现象：wire build 运行后没输出、没生成 inject.go，或者报 no injector found。
- 确保第一行是
// +build wireinject（注意前面不能有空格，不能写成// +build wireinject,ignore） - 该文件必须和
main.go或目标包同级，或放在internal/di/这类约定路径下 - 不要在
wire.go里写业务逻辑，只放wire.Build()和 injector 函数签名
provider 函数签名必须“可推导”，且不能有副作用
Wire 只看类型，不执行函数。它靠参数类型决定“要什么”，靠返回类型决定“给什么”。一旦签名模糊，就报 no provider found for *sql.DB 或 multiple providers。
- 返回值必须是具体类型，比如
*sql.DB，不能是未导出别名type DB *sql.DB（除非用wire.Bind显式绑定） - 如果两个 provider 都返回
*redis.Client，Wire 直接报错；解决方式：用wire.Value绑定具体实例，或用wire.Struct+ 字段标签区分用途 - 避免在
NewDB()里调db.Ping()、启 goroutine、读配置文件——这些会在生成代码中无条件执行，失败就 panic，且 Wire 查不到 - 带
error返回的 provider（如func() (*sql.DB, error)）会被自动处理，但整个初始化链会因 error 中断
生成的 inject.go 必须提交到 Git，CI 里必须先跑 wire build
inject.go（或 wire_gen.go）不是缓存文件，是构建依赖。漏掉它，go build 就会报 undefined: InitializeApp。
- 检查
.gitignore是否误写了**/*.go或inject*，导致文件没进仓库 - CI 流程中必须包含
wire build && go fmt ./ && go vet ./，否则格式和生成逻辑脱节，容易引入隐性 bug - 本地开发时，每次改了 provider 函数或
wire.Build()列表，都要手动运行wire build；IDE 插件或go:generate可辅助，但不能替代显式触发
wire build 报 no provider found？检查这三件事
这是最常卡住人的地方。报错本身不说明缺哪个函数，只说“推导失败”。得自己顺藤摸瓜。
- 所有 provider 函数必须导出（首字母大写），比如
NewDB✅，newDB❌ -
wire.Build()第一个参数是 injector（目标函数），后面全是它依赖的 provider；漏传任意一个，就会断链 - provider 的参数如果是接口（如
logger Logger），必须确保该接口在整个依赖图中只被一个 concrete type 实现；否则报multiple providers
Wire 的复杂点不在语法，而在“静态推导”这个前提——它不执行、不猜测、不 fallback。你写的每条类型链，都得能从 injector 入口一路无歧义地走到叶子节点。稍有环、稍有重名、稍有别名伪装，它就停住不动。所以与其反复试错，不如一开始就让类型干净、函数职责单一、依赖关系扁平。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
