wire 是编译期代码生成器，不能省掉 new 函数，而是自动生成调用这些函数的初始化逻辑；必须显式声明 provider 和 injector，类型严格匹配，不支持运行时反射或动态注入。
Wire 是什么，它真能省掉 New 函数吗
能，但不是自动魔法。Wire 本质是编译期代码生成器，它把手动写的依赖注入逻辑（比如一堆 NewUserService、NewDBClient 这类函数调用链）替换成自动生成的初始化函数。它不运行时反射，也不改你的结构体或接口定义——你得先写好构造函数和依赖关系，Wire 才能“看懂”并拼出来。
常见误解是以为加个注释就能全自动解耦。实际必须显式声明哪些类型要提供、哪些要注入，否则生成失败或运行时报 nil pointer dereference。
怎么写一个可用的 Wire Set
核心是定义一个返回根对象（如 *App）的函数，并用 //+build wireinject 标记，再在 wire.Build() 中列出所有必要构造函数和提供者。
- 每个构造函数必须是公开函数，参数全是依赖项，返回值是你要构建的类型（或
error） - 避免在构造函数里做副作用操作（比如连接数据库），Wire 只负责“组装”，不保证调用时机
- 如果某依赖有多种实现（如测试用内存版
*InMemoryCache、生产用*RedisCache），得用wire.Value或wire.Struct显式指定，不能靠名字猜 - 别把
context.Context当普通依赖传进构造函数——它应该由业务逻辑层传入，Wire 不处理生命周期上下文
示例片段：
//+build wireinject
package main
func InitializeApp() (*App, error) {
wire.Build(
NewApp,
NewUserService,
NewDBClient,
NewRedisCache,
)
return nil, nil
}
Wire generate 失败的典型错误
最常卡在“missing type”或“cannot find provider for …”，本质是 Wire 找不到某个依赖类型的构造路径。
-
cannot find provider for *sql.DB：你没提供NewDBClient，或它返回的是db *sql.DB但签名写成了func() *sql.DB（缺少error返回） -
duplicate binding for type *cache.RedisCache：两个函数都返回相同类型，Wire 不知道选哪个，得用wire.InterfaceValue或重命名函数加注释排除 - 修改了构造函数签名但忘了
wire generate：生成的wire_gen.go不会自动更新，必须手动触发，否则跑的是旧依赖图 - 循环依赖（A 依赖 B，B 又依赖 A）：Wire 会直接报错，没法绕过，得拆出中间接口或用
wire.Bind解耦实现与抽象
微服务场景下 Wire 和其他方案的边界在哪
Wire 适合中等复杂度、强调编译安全和可读性的 Go 微服务。但它不解决跨进程通信、配置热加载、运行时动态替换这些事。
- 配置解析（如从 YAML 加载
DBConfig）仍需手写，Wire 只管“把 config 塞进NewDBClient(config)”，不负责读配置 - 健康检查、指标上报这类需要全局单例的组件，建议用
wire.Value注入，而不是每个服务都重新 new 一份 - 如果你用 gRPC Server，
grpc.NewServer()这种带选项的初始化，要用wire.Struct包装，不然 Wire 不认识grpc.ServerOption类型 - 测试时想 mock 某个依赖？Wire 不阻止你手动传参，但生成代码默认走完整链路——推荐在
test_wire.go里另建一套轻量 Set，只包含 mock 提供者
Wire 的生成结果就是普通 Go 代码，没有运行时开销，但这也意味着——一旦依赖图太深或构造逻辑含条件分支，维护成本反而比手写高。别为了用而用，先画清模块边界再说。
