Go微服务依赖管理应优先手动注入而非第三方容器，推荐用结构体字段传入依赖、Wire生成编译期代码，避免Fx/Dig等运行时框架，并严格隔离服务边界。
Go 本身没有内置的依赖注入容器，微服务场景下必须靠显式构造或第三方库管理依赖，否则容易出现循环引用、测试难、配置分散等问题。
手动传递依赖是最可控也最常用的方式
Go 的惯用法是把依赖作为结构体字段，在初始化时由调用方传入。这种方式清晰、无隐藏行为、便于单元测试。
- 所有依赖（如
*sql.DB、http.Client、自定义的UserService）都应通过构造函数参数注入，而非在结构体内直接new或全局单例 - 避免在
Init()函数或包级变量中隐式初始化依赖，这会让依赖关系不可见且难以替换 - 如果依赖层级深（A→B→C），建议用“依赖分组”方式封装，例如定义
type Dependencies struct { DB *sql.DB; Cache *redis.Client; Logger *zap.Logger }，再统一传入
使用 Wire 实现编译期依赖注入
Wire 是 Google 开发的代码生成型 DI 工具，不引入运行时反射，生成的代码可读、可调试、性能无损。
- 需先定义
Provider函数（返回具体依赖实例），例如func NewDB(cfg Config) (*sql.DB, error) - 用
//+build wireinject标记入口文件，并编写InitializeService()函数，只写类型签名，不实现逻辑 - 执行
wire generate后，会生成完整初始化代码，自动处理依赖顺序和复用 - 注意：Wire 不支持条件注入或运行时动态选择实现，所有路径必须在编译期确定
package main
//+build wireinject
func InitializeService() (*Service, error) {
wire.Build(NewService, NewDB, NewCache, NewLogger)
return nil, nil
}
避免用 Uber-Fx 或 Dig 做微服务主干依赖管理
Fx 和 Dig 属于运行时反射型 DI 框架，虽然写法简洁，但在微服务中易引发问题：
立即学习“go语言免费学习笔记（深入）”；
- 启动时依赖图解析失败会导致整个服务 panic，错误信息常指向生成代码而非原始 provider，排查成本高
- 无法静态检查循环依赖，只有运行到
fx.New()才报错"cycle detected" - 与 Go 的接口即契约理念略有冲突——过度依赖 tag（如
@Provides）和匿名结构体，降低可读性 - 若服务需热重载配置或灰度切换实现（如不同环境用不同
PaymentService），Fx 的模块机制反而比手动构造更难控制
跨服务调用优先走 HTTP/gRPC 客户端，而非共享内存或全局变量
微服务的核心是进程隔离。常见错误是把其他服务的结构体或数据库连接直接 import 进来，导致服务边界模糊。
- 对外部服务的依赖，应封装为 interface + client 实现，例如
type OrderClient interface { GetOrder(ctx context.Context, id string) (*Order, error) } - client 实现内部用
http.DefaultClient或grpc.Dial，不暴露底层连接细节 - 不要在 service 层直接调用另一个 service 的 handler 或 repository，那已不是微服务，只是拆分的单体
- 超时、重试、熔断等策略应在 client 层统一处理，而不是每个调用点重复写
context.WithTimeout
依赖管理真正的难点不在工具选型，而在于每次新增一个外部交互点时，是否坚持把它抽象成 interface 并隔离实现——这点手工做比任何框架都重要。
