InitializeApp 是 wire build 生成的函数，未执行该命令则不存在，编译直接失败；最常见原因是 wire.go 缺失首行 // +build wireinject 标签或位置/格式错误，导致构建系统跳过该文件，wire build 静默无输出。
InitializeApp 函数不是你写的，是 wire 生成的；没跑 wire build，它就不存在，编译直接失败。
为什么 wire build 后找不到 InitializeApp
最常见原因是 wire.go 文件被构建系统跳过了。Go 构建工具只认带 // +build wireinject 标签的文件，且该行必须是文件第一行、前面不能有空格、不能加逗号或额外单词。漏掉这个标签，wire build 就扫不到 wire.Build() 调用，静默无输出，也不报错。
还要确认：wire.go 和目标包（比如 cmd/myapp 或 internal/app）同级；里面只放 injector 函数（如 InitializeApp）和 wire.Build() 调用；不 import 业务包、不写逻辑、不调用 log.Println 这类副作用代码。
-
wire.go放在根目录或pkg/下？→ 不行，必须和 main 包或目标初始化包同级 - 用了
//go:build wireinject？→ 不行，Wire 只识别旧式// +build wireinject - injector 函数返回类型是
(*Application, error)，但wire.Build()里漏了NewApplication？→ 编译时报错位置会误导，实际缺的是 provider，不是 injector
NewDB 和 ProvideDB 的签名为什么总不匹配
Wire 不看函数名，只严格比对类型：参数类型决定“要什么”，返回类型决定“给什么”。*sql.DB 和 database/sql.DB 是不同类型；未导出别名 type DB *sql.DB 也不能替代；接口类型（如 cache.Cache）必须只有一个 concrete 实现，否则报 multiple providers。
带 error 返回是允许的（func() (*sql.DB, error)），但 injector 函数签名里不能省略接收 error——如果 InitializeApp 声明返回 (*Application, error)，那整个链上所有带 error 的 provider 都会被自动传播；反之，若某个 provider 返回 error 但 injector 没声明，编译会失败。
- Provider 返回
*redis.Client，但项目里有两个地方都这么返回？→ Wire 拒绝，得用wire.Value或wire.Struct显式区分用途 - 在
NewDB里调了db.Ping()？→ Wire 不校验，但生成代码会在启动时无条件执行，失败即 panic - 参数是
cfg Config，但没提供Config类型的 provider？→ 得补一个func() Config，或用wire.Value(Config{...})
生成的 wire_gen.go 为什么必须提交到 Git
它不是临时文件，而是构建链的硬依赖。CI 流水线里漏掉 wire build，或本地 .gitignore 误写了 **/wire_*.go，新同事拉完代码后 go run main.go 就会报 undefined: InitializeApp。
生成文件开头有明确注释：// Code generated，时间戳也会更新（比如 2026年4月26日）。这意味着每次改了 provider 签名或 wire.Build() 列表，都必须重新运行 wire build 并提交新版本 —— IDE 插件或 //go:generate 可辅助，但不能替代这一步。
- CI 中只跑
go test，没跑wire build？→ 测试可能通过，但构建产物缺失，上线失败 - 本地开发时改了
NewService参数，但忘了wire build？→ 编译错误指向“找不到 NewRepository”，实际是NewService调用不匹配，依赖图断裂 - 多个环境（dev/staging/prod）共用一个 injector？→ 应拆成
InitializeAppDev/InitializeAppProd，各自wire.Build()列出对应 provider
如何避免 wire 在复杂依赖中“悄无声息地失效”
Wire 不扫描全项目，只处理 wire.Build() 显式列出的函数。漏传中间 provider、类型别名混淆、字段未导出、interface 多实现……这些都不会在 wire build 阶段报错，而是在生成后的 wire_gen.go 编译时才暴露，且错误位置往往离真实问题很远。
真正关键的检查点只有三个：// +build wireinject 是否存在且正确、所有依赖类型是否都有且仅有一个 provider、生成文件是否已提交并参与构建。其余都是“看起来能跑，其实链断了”的陷阱。
尤其注意：Wire 不管理生命周期，不保证单例，不做运行时校验。它只是把一堆 NewXXX 函数按类型拼起来——拼错了，编译失败；拼对了，就是纯 Go 代码，快且确定。
