fx不是必须学的di框架，适合中大型go服务且需清晰生命周期管理；默认启动后不阻塞主线程，需注册fx.lifecycle组件（如http server）防止退出；fx.provide注册构造函数，fx.invoke注册一次性副作用函数；自定义logger须用fx.withlogger传入并实现fx.logadapter接口。
fx 不是“必须学”的依赖注入框架，它适合中大型 Go 服务、需要清晰生命周期管理、且团队愿意接受声明式容器配置的场景；小项目或 CLI 工具用 fx.New 反而增加理解成本。
为什么 fx.New 启动后程序就退出了？
这是最常踩的坑：fx 默认启动后只运行 fx.Run 阶段（即执行 invoke 函数），不阻塞主线程。如果你没注册任何长期运行的组件（比如 HTTP server、gRPC server 或 fx.NopLogger 配合 fx.StartTimeout），进程会立刻退出。
- 正确做法是注册一个实现了
fx.Lifecycle的 long-running 组件，例如用fx.Invoke启动http.ListenAndServe，并把它和fx.OnStart/fx.OnStop绑定 - 临时调试可加
fx.NopLogger+fx.SleepFor(10 * time.Second)，但别上线 - 错误写法：
fx.New(...).Run()单独调用 —— 它只执行 invoke，不 hold 住进程
fx.Provide 和 fx.Invoke 的根本区别在哪？
fx.Provide 是注册构造函数，用于生成依赖项（类型实例）；fx.Invoke 是注册一次性执行函数，用于触发副作用（如初始化 DB 连接、启动监听）。
-
fx.Provide(func() *sql.DB { return sql.Open(...) })→ 提供*sql.DB实例，后续构造函数可用它 -
fx.Invoke(func(db *sql.DB) { db.Ping() })→ 拿到*sql.DB后立刻 ping，但不返回任何值，也不参与依赖图构建 - 混淆后果：把连接池初始化逻辑写在
Provide里会导致每次注入都新建连接；写在Invoke里又可能因依赖顺序错乱而 panic - 推荐模式：用
Provide返回带 lazy-init 的 wrapper（如func() DBClient { return &dbClient{} }），再用Invoke显式调用.Connect()
替换默认 Logger 为什么 fx.WithLogger 不生效？
因为 fx.WithLogger 必须在 fx.New 调用时作为选项传入，且必须早于所有 Provide/Invoke；如果在模块内部用 fx.Provide 提供 fx.Logger 类型，fx 会忽略它 —— 默认 logger 是 infra 级别配置，不是普通依赖。
- 生效写法：
fx.New(fx.WithLogger(func() fx.Logger { return &myLogger{} }), ...) - 常见错误：在某个模块里
fx.Provide(func() fx.Logger { ... })→ 容器启动时直接 panic：“duplicate fx.Logger” - 自定义 logger 必须实现
fx.LogAdapter接口（不是fx.Logger），否则日志字段（如 module name、stack trace）会丢失 - 注意：Uber zap logger 要用
fx.ZapLogger而非原生zap.Logger，否则 context 信息无法透传
fx 的复杂度不在语法，而在对“依赖图不可变性”和“生命周期阶段”的隐含约束。很多问题不是代码写错了，而是没意识到 OnStart 函数的执行时机早于所有非-lifecycle 依赖的首次使用 —— 这点连官方示例都容易误导人。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
