wire 是 go 微服务的默认选择，因其在编译期解析依赖图、零运行时开销、强类型安全和显式构造逻辑；inject 适合原型验证，dig 适合多环境配置，ctxo 补足请求级上下文，三者分工明确不可混用。
Wire 为什么是 Go 微服务的默认选择
因为 Wire 在编译期完成依赖图解析，错误能立刻暴露，不靠反射，没有运行时开销。它不是“加个库就能用”的玩具，而是要求你显式声明每个组件的构造逻辑——这恰恰是微服务需要的可控性。
常见错误现象：wire: injector ... does not return any of the expected types，通常是因为 wire.Build 列表里漏了某个提供者函数，或者返回类型和注入点声明的类型不匹配（比如函数返回 *DB，但结构体字段是 DB 值类型）。
- 必须用函数返回依赖，不能直接传实例（
wire.Provide(NewDB)✅，wire.Provide(&db)❌） - 所有提供者函数必须放在
wire.go所在包内，或通过wire.NewSet显式导入 -
main.go里只保留wire.NewSet和wire.Build，别塞业务逻辑 - 命名依赖（如
redis、mysql）需配合wire.Struct或自定义提供者，不能仅靠参数名推断
inject.Populate 适合什么场景
inject.Populate 是运行时反射注入，启动快、接入成本低，适合原型验证、CLI 工具或小型服务。但它不检查循环依赖，也不做类型安全校验，上线前容易埋雷。
典型误用：把 inject.Populate 当成 Wire 替代品，在微服务里直接注入整个服务树。结果是 panic 出现在运行时，且堆栈里看不到具体哪个字段没注入成功。
- 只用于临时对象填充，比如测试中快速构造带 mock 依赖的 handler
- 字段标签必须严格匹配：
`inject:""`才能匹配单例，`inject:"private"`才会新建实例 - 私有字段（首字母小写）无法被注入，哪怕加了 tag —— 反射不可见
- 接口注入必须确保注册的对象实现了该接口，否则注入失败但无明确提示
Dig 容器在多环境配置中的实际卡点
Dig 的 dig.Container 支持作用域（scope）和命名提供，适合需要按环境（dev/staging/prod）切换依赖实现的微服务。但它的错误信息非常隐晦，dig.Invoke 失败时往往只报 missing type: *redis.Client，而真实原因是某个提供者函数 panic 了但没被捕获。
性能影响：Dig 每次 Provide 都做反射分析，100+ 依赖时初始化耗时明显高于 Wire 生成的静态代码。
- 避免在
Provide函数里做重操作（如连接数据库），应只返回构造函数 - 用
c.Scope("env:prod")隔离不同环境的依赖，但注意 scope 不自动继承，Invoke必须显式指定 - 调试依赖图用
c.DebugGraph()输出 dot 格式，再用 Graphviz 渲染，别靠猜 - 与 Wire 混用风险高：两个容器管理同一类型实例，极易导致状态不一致
Ctxo 不是 DI 工具，但能补上 Wire 的最后一公里
Wire 解决“谁创建谁”，Ctxo 解决“谁持有谁”。比如一个 HTTP handler 需要 requestID、userID、trace.Span，这些是请求级上下文，不该放进全局依赖图，也不该每个函数都传参。
容易踩的坑：把 Ctxo 当成另一个 DI 容器，试图用它注入数据库连接。它只管“运行时上下文”，不负责“应用级依赖”。混用会导致生命周期错乱——DB 连接被当成 request-scoped 对象反复创建。
- Ctxo 实例应作为
context.Context的扩展，随 request 生命周期传递 - 用
ctxo.FromContext(ctx)获取，不是从容器里 Resolve - 字段必须是导出的（首字母大写），否则序列化/调试时不可见
- 和 Wire 配合时，把 Ctxo 实例作为参数传给 handler 构造函数，而不是注入到 service 层
