wire 是编译期依赖注入工具，通过 wire.build 在编译前生成纯 go 初始化代码，杜绝运行时反射开销与类型错误；它要求 provider 函数首字母大写、injector 字段类型严格匹配、所有依赖显式声明，生成的 wire_gen.go 需提交至版本库。
Wire 是什么，为什么不用反射
Wire 不是运行时框架，它在编译前就把依赖图展开、生成纯 Go 代码。这意味着：wire.Build 调用最终会被替换成一堆 newXXX() 和参数传递语句，没有接口断言、没有 reflect.Value.Call、也没有 interface{} 类型擦除开销。
你遇到的 panic: interface conversion: interface {} is nil, not *xxx.Service 这类运行时注入失败，Wire 根本不会让它发生——类型不匹配、构造函数缺失、循环依赖，全在 wire build 阶段报错，错误信息直接指向 provider 函数签名或 injector 结构体字段。
怎么写一个最简可用的 wire.go
别从文档抄模板，先跑通一个能生成代码的最小闭环。关键就三样东西：提供者（Provider）、注入器（Injector）、构建入口（wire.Build）。
-
Provider是普通函数，返回你要注入的类型，比如func NewDB() *sql.DB或func NewCache(cfg Config) cache.Store -
Injector是一个空结构体，字段名必须和要注入的类型完全一致（支持指针、接口、值类型），比如DB *sql.DB、Cache cache.Store -
wire.Build列出所有Provider和Injector，顺序无关，但必须全部显式写出；不能靠包导入自动发现
示例：
// wire.go
package main
import "github.com/google/wire"
func InitializeApp() *App {
wire.Build(NewApp, NewDB, NewCache)
return &App{}
}
type App struct {
DB *sql.DB
Cache cache.Store
}
wire build 报错常见原因和修复方式
报错不是 Wire 的问题，而是依赖图没描述清楚。最常卡在这几个点：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 字段类型和
Provider返回类型不严格一致：比如字段是cache.Store，但Provider返回*redis.Cache，且没声明var _ cache.Store = (*redis.Cache)(nil)实现关系 - 缺少中间 provider：比如
App依赖Cache，Cache依赖Config，但只写了NewApp和NewCache，漏了NewConfig或没把它加进wire.Build - 循环依赖隐含发生：A 的
Provider调用了 B，B 的Provider又间接依赖 A（比如通过全局变量、init 函数），Wire 会报cycle detected，但不会告诉你哪条路径 - 使用了未导出类型：Wire 只处理首字母大写的标识符，
func newDB()（小写）不会被识别，必须是func NewDB()
生成的代码怎么用，要不要 commit
执行 wire build 后，会在同目录生成 wire_gen.go，里面全是手动写也写得出来的初始化逻辑，比如：
func injectApp(db *sql.DB, cache cache.Store) *App {
return &App{
DB: db,
Cache: cache,
}
}
这个文件要 git add 进仓库。不是“临时产物”，而是构建结果的一部分——CI 编译时也要用它，否则就是“本地能跑，CI 报错”。
更新依赖后，必须重新运行 wire build；如果忘了，Go 编译器会立刻报错：找不到 InitializeApp 函数，因为旧的 wire_gen.go 没同步变更。
容易忽略的是：Wire 不处理生命周期（比如 Close 方法调用）、不管理单例复用策略（它只是按需 new）、也不支持条件注入（比如根据环境变量选不同实现）。这些都得靠你自己在 Provider 里写清楚逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
