Wire是Go微服务生产环境更稳的选择，因其在编译期通过代码生成完成依赖图构建与校验，可提前暴露循环依赖、缺失依赖等错误，生成的纯Go代码可读、可调试、零反射开销，契合Go“显式优于隐式”哲学。
Go微服务里不该用运行时DI容器当主干依赖管理器，Wire生成的编译期代码才是生产环境更稳的选择。
为什么Fx/Dig在微服务中容易出问题
它们靠反射解析依赖图，启动时才暴露问题，错误堆栈常指向生成代码而非你写的NewDB或NewCache函数，排查成本高。循环依赖只有到fx.New()才报"cycle detected"，没法静态检查。
微服务需要明确的边界和可预测的初始化顺序，而Fx的模块加载、匿名结构体+tag（如@Provides）会让依赖关系变得隐晦，跟Go“显式优于隐式”的哲学冲突。
- 服务A依赖B，B又间接依赖A → 启动panic，但找不到源头
- 测试时想Mock某个Repo，却要启动整个Fx App → 单元测试变集成测试
- 灰度发布时想换掉
PaymentService实现，得改模块配置+重启 → 不如手动构造来得直接
Wire怎么用才不踩坑
Wire不是“写完就跑”，它要求你提前定义好所有Provider函数，并把它们显式列进wire.Build()调用里。它不支持运行时条件分支，比如根据环境变量选不同DB驱动——这种逻辑得放在NewDB函数内部处理，而不是靠Wire动态决定。
立即学习“go语言免费学习笔记（深入）”；
//+build wireinject必须加在入口文件顶部，且InitializeService()函数不能有实际实现，只留签名；否则wire generate会跳过它。
-
Provider函数返回值类型必须唯一，不能两个函数都返回*sql.DB - 如果依赖链里有
error，Wire不会自动传播，得在Provider里显式return nil, err - 生成的
wire_gen.go要提交进Git，别当成临时文件忽略
ctxport适合什么场景
它不是替代Wire的全局容器，而是为单个请求生命周期服务的轻量工具。当你需要把context.Context里携带的traceID、tenantID、用户权限等，连同临时资源（如一次HTTP调用所需的http.Client）一起注入到下游函数，ctxport比传一堆参数清爽得多。
它的Port本质是类型安全的context.Value封装，避免了类型断言和key冲突。但注意：它不解决服务启动时的依赖组装问题，只管“请求进来后怎么分发”。
- 不适合管理
*sql.DB这种长生命周期资源（该由Wire初始化后注入） - 不能替代接口抽象，仍需先定义
type Logger interface { Info(...)这类契约 - 若滥用
ctxport.Set往context塞大量对象，会拖慢请求性能，毕竟每次Get都要查map
真正难的不是选哪个工具，而是划清边界：Wire管“服务启动时有哪些东西”，ctxport管“这个请求里能拿到哪些东西”，而手动构造管“这个Usecase到底依赖谁”。混用可以，但职责必须分明。
