wire是编译期代码生成工具，非运行时框架；它仅通过wire.build显式声明的导出函数静态构建依赖链，要求//+build wireinject标签、同包位置、类型严格匹配，漏标签或签名错误即编译失败。
Wire 不生成运行时容器，也不接管对象生命周期——你写的每个 NewXXX 函数仍是真实调用点，它只负责把参数传对、顺序排好、链路拼全。一旦漏掉 //+build wireinject 或 provider 签名错一个字，wire build 就直接失败，而不是静默出错。
为什么 wire.Build() 报 “could not find provider for *sql.DB”
这不是 Wire 找不到文件，而是它在依赖图里推导不出这个类型该由谁创建。常见原因有三个：
-
*sql.DB类型没对应任何导出的 provider 函数（比如ProvideDB()未导出，或写成了provideDB()） - provider 函数签名不匹配：返回值是
database/sql.DB（接口），但依赖项声明为*sql.DB（指针），二者在 Go 类型系统里完全不兼容 - provider 函数在另一个包里，而
wire.go和 provider 不在同一个包下——Wire 只扫描当前包内导出函数
provider 函数怎么写才不会被 Wire 拒绝
Wire 完全不执行函数体，只靠函数签名做静态分析。所以：
- 参数名可以任意，但类型必须精确一致：
func ProvideDB(dsn string) *sql.DB中的string必须由另一个 provider 返回，或用wire.Value("root:pass@/mydb")显式绑定 - 不能返回未导出类型；如果要提供接口（如
io.Reader），必须确保整个依赖图中只有一个 concrete type 实现它，否则报multiple providers - 带
error返回的 provider（如func() (*sql.DB, error)）是合法的，Wire 会自动生成错误传播逻辑，但函数体内别做db.Ping()这类副作用操作——失败 panic 发生在运行时，编译期查不到
wire.go 文件为什么必须放对位置且带构建标签
//+build wireinject 不是注释，是 Go 构建约束。没有它，go build 会跳过该文件，wire build 就找不到 wire.Build() 调用。更关键的是：
-
wire.go必须和你要生成注入器的包同目录（比如想生成cmd/myapp.InitializeApp()，文件就得放在cmd/myapp/下） - 文件里只能有 injector 声明（如
InitializeApp()）和wire.Build()调用，混入业务逻辑会导致生成代码污染或构建失败 - 生成的
wire_gen.go是硬依赖，必须提交进 Git；CI 流程若跳过wire build，新人拉代码后go run main.go直接报undefined: InitializeApp
最常被忽略的一点：Wire 生成的代码里，所有 provider 调用都是**无条件顺序执行**的。如果你在 NewCache() 里启动了 goroutine 或连接了远程服务，那它一定会在应用启动时立刻触发——没有 lazy init，也没有 scope 控制。这点和运行时 DI 框架完全不同，得靠设计者自己约束 provider 的职责边界。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
