Golang依赖注入模式：对比手写注入与框架注入的差异

go依赖注入需显式传递依赖，newservice即构造函数，应只组装实例不执行副作用；fx.provide注册构造逻辑，fx.invoke触发使用逻辑；di性能问题多因日志同步io导致。

手写注入时，func NewService 为什么总要传一堆 *DB Logger Config

因为 Go 没有构造函数重载、没有属性注入、也没有运行时反射自动装配——所有依赖必须显式传递。你写的 NewService 实际就是“构造函数”，参数列表直接暴露了它的耦合面。

常见错误是把初始化逻辑塞进结构体字段赋值里，比如在 type Service Struct { db *sql.DB } 中直接 new 出 db，这会让测试无法替换依赖，也违反了依赖倒置原则。

• 每个 NewXXX 函数都该只做一件事：接收依赖 + 组装实例，不执行副作用（如连接 DB、读配置文件）
• 如果多个组件共用同一 *sql.DB，别在每个 NewXXX 里重复 sql.Open，统一由上层创建后传入
• 参数顺序建议按“核心依赖 → 辅助依赖 → 可选配置”排列，比如 NewUserService(db *sql.DB, logger Logger, opts ...UserOption)

用 uber-go/fx 注入时，fx.Provide 和 fx.Invoke 的边界在哪

fx.Provide 是注册构造逻辑，fx.Invoke 是触发使用逻辑——前者定义“能造什么”，后者定义“造完立刻用来干啥”。两者混用会导致启动失败或依赖循环。

典型误用：在 fx.Invoke 里调用需要未就绪依赖的函数，比如 DB 还没 connect 完就去调 userRepo.List()。

立即学习“go语言免费学习笔记（深入）”；

• fx.Provide 的函数不能有副作用；它只应返回实例或 Error，不执行 db.Ping() 这类操作
• fx.Invoke 的函数必须是“一次性执行”的，适合做 migrate、warm-up、信号监听等启动期任务
• 如果某个 Provide 依赖另一个 Provide 的返回值，FX 会自动排序；但跨模块时要注意模块加载顺序，避免 nil panic

DI 容器启动慢？查查是不是 fx.NopLogger 没关，或者 fx.WithLogger 里用了同步写文件

FX 默认日志是同步输出到 os.Stderr，看起来不慢，但一旦加了自定义 logger（比如写本地文件或发 http），每次依赖解析都会卡住主线程。实测开启 trace 日志 + 文件写入后，10 个 Provide 启动耗时可能从 5ms 涨到 300ms+。

• 开发环境用 fx.NopLogger 关掉日志，比用空实现更安全（不会意外漏掉 error）
• 生产环境若需日志，确保 logger 是异步的（比如封装成 channel + goroutine 写入）
• 避免在 Provide 函数里做任何 IO 或网络调用；DB 连接、redis 初始化这些应该放在 Invoke 或单独的 Lifecycle Hook 里

测试时绕过 DI 容器，直接 new 结构体却遇到 nil pointer dereference

不是容器的问题，是你没补全依赖链。比如 UserService 依赖 UserRepo，而 UserRepo 又依赖 *sql.Tx，但你只 mock 了 UserRepo，忘了给它传 tx，结果一调方法就 panic。

• 单元测试永远优先用“手写依赖 + 接口 mock”，而不是启动整个 FX App；否则测试变集成测试，速度慢还难 debug
• 对每个被测对象，只传它直接依赖的接口，不要试图复刻容器里的完整依赖图
• 如果某结构体字段是私有且非接口（比如 cache *ristretto.Cache），说明它不该被外部控制——要么改成接口，要么在测试中允许它真实初始化（加 skipCI 标签隔离）

真正麻烦的是那些隐式依赖：比如通过全局变量、init 函数、或包级变量偷偷拿 logger 或 config。这类代码没法被 DI 管理，也很难测，得先把它揪出来改掉。