宁要 Wire 编译期挨骂，不要 Fx 运行时 Panic：聊聊高可用系统的 DI 架构选型

聊聊 Go 里面的 DI（依赖注入）选型：Wire 还是 Uber-Fx？

当年做聚合支付网关，组里有位从 Java 转过来的同学迷恋 Spring 那套“全自动”，力推了 Uber-Fx。结果上线第二个月就踩了个大坑：

一个非核心旁路监控的 Provider 依赖了某个未初始化的配置项 -> 编译期完全正常 -> 运行时容器延迟加载组装失败触发 panic -> 灰度环境刚好没覆盖那条冷门链路 -> 生产发布直接打崩核心支付 Pod。

那次复盘之后，我们把交易链路的工程全切回了 Google 的 Wire。核心因果逻辑其实很简单： 反射容器 + 隐式装配 = 隐藏的运行时炸弹；静态代码生成 + 显式传参 = 编译期强阻断。 Wire 生成的代码就是普通 Go 代码，Trace 栈一拉到底，对排查线上故障极其友好。

但平心而论，Uber-Fx 并非一无是处，它的 fx.Lifecycle 在搞 MySQL 连接池预热、MQ 消费者优雅停机（Graceful Shutdown）时确实顺手；而 Wire 虽然纯粹，但在大工程里遇到复杂组件的生命周期管理，往往需要自己手写一堆胶水代码去编排 Start / Stop。

我的个人倾向：涉及资金、交易的核心系统，选 Wire 保平安；中后台或生命周期极其繁杂的微服务，Fx 可以提升开发效率。

大家在生产环境是怎么选的？坚持用 Wire 的团队，你们又是怎么优雅解决平滑上下线生命周期的？欢迎聊聊。