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 会自动排序；但跨模块时要注意模块加载顺序，避免nilpanic
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 管理，也很难测，得先把它揪出来改掉。
