go微服务依赖注入核心是解决初始化混乱、测试难mock、隐式耦合三类问题：90%场景用构造函数注入，中大型项目首选wire编译期生成代码，禁用inject/di/gone等运行时反射框架。
Go 微服务项目里依赖注入不是为了用而用，而是为了解决初始化顺序混乱、测试难 mock、模块间隐式耦合这三类实际问题。手动构造函数注入能覆盖 90% 场景，Wire 是唯一值得在中大型服务中引入的编译期工具；运行时反射型 DI 框架（如 inject、di、gone）应避免用于核心服务。
构造函数注入怎么写才不漏依赖
依赖必须显式出现在结构体字段和 NewXXX 函数参数里，不能藏在 init 或全局变量中。
- 字段必须导出（首字母大写），否则
wire无法设置，inject无法反射赋值 - 所有依赖都得是接口类型（如
Database、Logger），而非具体实现（如*sql.DB），否则替换成本高、测试难 - New 函数参数顺序要稳定：先底层依赖（DB、Config），再中间层（Repository），最后上层（Service、Handler）
- 避免在 New 函数里做 I/O（如读 config.yaml、连 Redis），这些该在
main里完成，再把解析好的 struct 传进去
wire 生成代码时常见报错原因
wire 报错基本都源于 provider 函数签名或 injector 声明不合规，不是配置问题。
-
wire: field "xxx" is not settable：结构体字段未导出，或字段类型与 provider 返回类型不匹配（比如 provider 返回*sql.DB，但字段是sql.DB） -
wire: no provider found for xxx：provider 函数没被wire.NewSet包含，或 injector 函数没调用wire.Build -
wire: cycle detected：A 的 provider 依赖 B，B 的 provider 又依赖 A —— 编译期就能发现，但需人工拆解，比如把共享逻辑抽成独立 provider - provider 函数返回接口类型（如
func() Logger）会导致推导失败，必须返回具体类型（func() *zap.Logger），再由 injector 转成接口
Gin 路由 handler 怎么安全接入依赖
handler 本身不该持有业务逻辑，只负责解析请求、调用 service、封装响应。依赖通过闭包或结构体字段注入，而非从全局容器取。
- 推荐方式：定义
type Handler struct { service UserService }，NewHandler 时传入已构建好的 service 实例 - 不要在 handler 方法里调用
service.GetInstance()或container.Get("user")—— 这会让测试时无法替换 mock - Gin 中绑定 handler 时，用闭包捕获依赖：
r.GET("/user/:id", func(c *gin.Context) { h.GetUser(c) })，其中h是已注入依赖的实例 - 避免把 DB、Config 等底层依赖直接塞进 handler 字段，它们应该只出现在 service 层；handler 只依赖 service 接口
为什么 inject/di/gone 在生产微服务里容易翻车
这些运行时反射框架在原型阶段看着快，但上线后调试、排查、协作成本会陡增。
-
inject的inject:"dev logger"这种字符串标识，拼错就静默失败，运行时报panic: no provider found for dev logger -
di的字段注入（DB *sql.DB `di:"inject"`）让 IDE 无法跳转到注入源，重构时字段删了但 provider 没删，启动才暴露 -
gone自动扫描注册依赖，一旦 build tag 写错或包路径变更，依赖就消失，且无编译期提示 - 单例控制靠字符串（
di.Singleton），拼错就变成新实例，可能引发连接泄漏或并发竞争 - 所有这类框架都会拖慢
go test启动速度，因为要反射扫描结构体、解析 tag、构建图
真正麻烦的不是写不出注入逻辑，而是当服务启动失败、测试跑不通、IDE 找不到依赖来源时，你得在一堆反射调用栈和模糊错误里定位问题。构造函数 + Wire 的组合，把绝大多数问题提前到编辑器保存和 go build 阶段暴露出来，这才是微服务长期可维护的关键。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
