wire 是静态依赖注入工具，要求 inject 函数零参数、小写开头、返回顶层对象；provider 必须类型精确匹配、无副作用、依赖显式传入；生成代码需提交，不处理循环依赖。
Wire 本身不“优雅”，它只是把依赖关系显式写出来；所谓优雅，其实是你用它时避免了反射、运行时 panic 和隐式耦合——前提是别把它当 Spring 用。
Wire 的 inject 函数必须是空参数、非导出函数
Wire 不会扫描代码，只认你显式声明的 inject 函数。它必须满足两个硬性条件：参数为空、返回值是你要构造的顶层对象（比如 *App），且函数名不能以大写字母开头（即非导出）。
常见错误是写成：
func NewApp(cfg Config) *App { ... } // ❌ Wire 看不见
正确写法是：
func initializeApp() *App { // ✅ 小写开头，无参数
return &App{}
}
然后在 wire.go 中调用 wire.Build(...) 并标记该函数为入口。
- 函数签名必须严格匹配：零参数，返回你要启动的对象
- 不能有中间参数（比如传
context.Context或配置结构体），所有依赖必须通过 provider 链提供 - 如果需要多入口（如测试 vs 生产），就写多个小写函数，各自配独立的
wire.Build
provider 函数的返回值类型必须精确匹配依赖需求
Wire 是静态分析工具，靠类型推导依赖链。哪怕只差一个指针层级（DB vs *DB），或者接口实现漏了某个方法，都会报 no provider found for ...。
例如你定义了：
type Repository interface { Save() error }
但 provider 返回的是 *UserRepo，而 UserRepo 没实现 Save 方法，Wire 在生成代码前就失败，不会等到运行时报错。
- 每个 provider 函数必须有明确的返回类型，不能是
interface{} - 如果依赖是接口，provider 必须返回实现了该接口的具体类型（或指针）
- 构造函数里不要做副作用操作（如连接 DB），Wire 可能多次调用 provider（尤其在 debug 模式下）
避免在 provider 中使用全局变量或 init 函数
Wire 生成的代码本质是一段普通 Go 初始化逻辑，不是魔法。如果你在某个 provider 里读了全局变量 config，而这个 config 是靠 init() 初始化的，那 Wire 无法感知它的依赖顺序——它只看函数签名和返回类型。
结果就是：生成的代码可能在 config 还没初始化完时就调用了你的 provider，导致 panic。
- 所有依赖必须显式作为参数传入 provider（哪怕只是
Config结构体） - 不要把配置解析塞进
init()；应作为一个 provider：func loadConfig() (Config, error) - 如果必须复用已有全局实例（比如 logrus.StandardLogger），用
wire.Value显式注入，而不是靠 package 级变量
Wire 生成的代码要 commit，别忽略它
wire gen 输出的是真实 Go 文件，不是临时缓存。它包含所有 new 调用、参数传递和类型断言——一旦你改了 provider 签名或依赖结构，就必须重新生成并提交。
常见疏忽是：
- 忘记
go run github.com/google/wire/cmd/wire就直接跑程序，结果用的是旧注入逻辑 - 把生成文件加到
.gitignore，CI 构建时缺失依赖树，编译失败 - 手改生成代码（比如加日志），下次
wire gen直接覆盖，白忙活
Wire 的“静态”优势全建立在生成代码可读、可查、可 diff 的基础上。跳过这步，就退化成黑盒反射框架了。
最易被忽略的点：Wire 不处理循环依赖，也不会告诉你哪两个 provider 形成了环——它只会报“no path found”，得自己顺着类型链往上翻 provider 定义。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
