wire适合中大型项目，编译期检查依赖；dig适合快速验证和运行时动态场景；fx是dig增强版但增加理解成本——选型应基于代码实际需求而非框架功能强弱。
wire 更适合追求稳定、可维护和团队协作的中大型项目；dig 适合快速验证、插件化或需要运行时动态能力的场景；fx 是 dig 的增强封装，但额外抽象层会抬高理解成本——别盲目选“强”，要看你正在写的代码是否真的需要它。
编译时注入（wire）：错误在 go build 阶段就报，不是 panic 时才崩
wire 把依赖图分析和初始化代码生成全挪到编译期，生成的 InitializeService() 就是纯 Go 函数，没有反射、不依赖 runtime、Ctrl+点击能直接跳转。这意味着：
- 循环依赖、类型不匹配、provider 缺失等全部在
go build或wire gen时失败，不会等到上线后第一个请求才panic: Interface conversion: interface {} is nil, not *sql.DB - 生成的代码可读、可调、可手动微调（比如加日志或 fallback），不是黑盒
- 不支持运行时注册新 provider —— 这不是缺点，是设计取舍：你要的是确定性，不是灵活性
典型误用：拿 wire 去做 A/B 测试开关、多租户配置切换这类需要运行时决策的场景，反而会绕远路写一堆 wrapper。
运行时注入（dig）：依赖关系在 container.Invoke() 才解析，调试链路变长
dig 在启动时靠反射扫描函数签名、匹配类型、缓存单例、按需调用 provider。好处是灵活：
立即学习“go语言免费学习笔记（深入）”；
- 可以条件性
Provide()（比如只在 dev 环境注入 mock logger） - 支持
dig.In和dig.Out结构体打包参数，避免函数签名过长 - 配合 fx 可以自动管理
OnStart/OnStop生命周期，适合微服务启停编排
但代价明显：IDE 跳转失效、stack trace 里出现大量 dig 内部帧、循环依赖只能靠 dig.CycleError 运行时报错——你得先跑起来才能发现哪两个 Struct 互相引用了。
fx 是 dig 的“开箱即用增强版”，但不是所有项目都需要它的抽象
fx 在 dig 基础上加了模块（fx.Module）、生命周期钩子、http 服务封装（fx.HTTPHandler）、健康检查等。它适合已决定用 dig 且需要统一基建的团队。
- 如果你只是想把 DB、Cache、Config 注入到 handler 里，fx 的
fx.Provide+fx.Invoke写法比裸 dig 简洁 - 但 fx 的 error message 更难懂（比如
fx.Lifecycle is not provided其实只是你漏传了fx.NewLifecycle()） - 它强制你接受它的启动模型（
fx.New→Run），想混用自定义 init 逻辑会别扭
小项目或 CLI 工具直接用 dig 就够了；非要上 fx，请先确认你们真有多个服务要共用同一套启动/关闭流程。
选型关键不是框架功能多寡，而是“谁来负责依赖可见性”
wire 把依赖关系显式写在 wire.Build() 里，谁改了 provider，谁就得更新构建集——责任清晰，适合多人协作；dig 把依赖藏在 Provide() 调用顺序和类型名里，容易漏注册、难追溯来源。
一个真实信号：当你开始为测试写 testwire.go 或反复修改 fx.Options 时，说明框架本身正在成为认知负担。这时候不妨退一步，手写初始化函数，或者用最简 wire 模式（只生成根对象）——依赖注入不是目的，可测、可读、可演进才是。