Fx不管理依赖，仅按声明顺序构造销毁对象；依赖由Go类型系统和构造函数签名决定。fx.Provide传函数比传值更安全，因函数可触发自动依赖解析，而传值不能；函数须可导出，参数须已注册，返回值最多两个。fx.Invoke用于一次性初始化，fx.Supply用于注入固定值，二者不可混用。接口实现需用fx.As或fx.Annotated命名区分，构造函数error必须返回而非panic。
Fx 本身不“管理依赖”，它只负责按声明顺序构造和销毁对象；真正的依赖关系由 Go 类型系统和构造函数签名决定，不是靠字符串或配置注册。
为什么 fx.Provide 传函数比传值更安全
传值（如 fx.Provide(&myDB)）会让 Fx 把该变量当作最终依赖项直接注入，但无法触发其依赖的自动解析；而传函数（如 fx.Provide(newDB)）能让 Fx 检查 newDB 的参数类型，自动把 *sql.DB、config.Config 这类已注册类型按需注入进去。
- 函数必须是可导出的（首字母大写），否则 Fx 在反射时拿不到签名
- 参数不能是未注册的接口或具体类型，否则启动时报错：
no constructor found for ... - 返回值最多两个：主对象 + 可选的
error，多于两个会 panic
fx.Invoke 和 fx.Supply 的典型误用场景
fx.Invoke 是运行一次性初始化逻辑（比如迁移数据库、预热缓存），不是用来“启动服务”的；而 fx.Supply 是把一个固定值强行塞进容器，绕过构造过程——这两者常被新手混用，结果导致依赖链断裂或生命周期错乱。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 想在应用启动后立刻执行某段逻辑？用
fx.Invoke(setupAdminUser)，且setupAdminUser参数应只依赖已提供（Provide）的对象 - 需要传入硬编码配置（如
"prod"环境名）？用fx.Supply("prod")，但注意它不参与依赖解析，后续函数若想用这个字符串，必须显式声明为参数 - 误把 HTTP server 启动逻辑写在
Invoke里，会导致 Fx 认为启动已完成，实际 server 却阻塞主线程——正确做法是用fx.Invoke启动 goroutine 或交由fx.Shutdowner管理
如何让 Fx 正确处理接口实现与多实例
Fx 默认不允许重复提供同一类型（包括接口），除非显式使用 fx.As 或命名构造。例如你有两个 Logger 实现：StdLogger 和 ZapLogger，不能直接 fx.Provide(newStdLogger, newZapLogger)，否则后者会覆盖前者。
- 给接口绑定具体实现：用
fx.Provide(newZapLogger, fx.As(new(zap.Logger))) - 需要多个同类型实例？用
fx.Annotated加命名，比如fx.Annotated{Name: "auth_logger", Key: reflect.TypeOf((*log.Logger)(nil)).Elem(), Value: newAuthLogger} - 接口类型必须是导出的（
type Logger interface{...}），匿名接口（如interface{Print()}}）无法被 Fx 识别
最常被忽略的是构造函数的 error 处理：Fx 在启动阶段遇到任何 error 返回值都会直接 panic 并退出，不会尝试重试或 fallback。这意味着数据库连接失败、配置缺失这类问题必须在 Provide 函数里显式校验并返回错误，而不是用 log.Fatal 或直接 panic —— 否则 Fx 无法统一捕获和报告根因。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
