Go中最佳依赖注入方式是用高阶函数传构造逻辑而非实例，如handler接收func() UserService参数，生产用真实实现、测试用mock，零反射、零注册、依赖显式可见。
Go 里没有“自动扫描+注解注入”这种魔法，依赖注入不是靠框架猜你要什么，而是靠你明确决定谁来造、什么时候造、造几次。
用高阶函数传构造逻辑，而不是传实例
这是最轻量、最 Go 的 IoC 实现方式。关键不是把 NewUserService 当作工厂注册进容器，而是把它当作参数直接传给需要它的地方。
- handler 不该自己调
&NewUserService(&db)，而应接收一个func() UserService - 测试时传
func() UserService { return &mockUserService{} }，零反射、零注册表 - 生产环境传
func() UserService { return NewUserService(db) }，所有依赖显式可见 - 避免了包级
init()或全局变量带来的并发初始化风险和测试污染
用结构体字段标签 + reflect 实现字段级注入（慎用）
反射注入适合已有结构体但不想改构造函数签名的场景，但它会隐藏依赖来源，且运行时出错难定位。
- 必须为需注入字段加标签，如
Repo UserRepository `inject:""` - 容器遍历字段时只认
reflect.Struct，且要求目标是导出字段（首字母大写） - 自动创建实例仅限无参类型；含依赖的类型仍需提前
Register，否则 panic - 字段注入无法控制生命周期——
Singleton和Transient必须在容器层显式区分，否则每次Inject都新建
别碰“全自动” DI 框架，除非你真需要跨包自动解析
像 github.com/codegangsta/inject 这类库，本质是把类型映射表 + 反射调用封装了一遍，但代价是：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 调用栈深、错误信息模糊（比如
panic: reflect: Call using zero Value往往要追 5 层才定位到哪字段没注册） - 无法静态检查依赖是否完备：编译不报错，运行时才发现
no instance for *sql.DB - 和 Go 的接口即契约哲学冲突——你本可通过函数签名表达依赖，却换成运行时查表
- Wire 这类代码生成工具更安全，但它生成的是普通 Go 代码，不是运行时容器，调试时直接跳转到生成的
newXXX调用即可
HTTP handler 解耦是最典型也最容易踩坑的场景
新手常把 service 初始化硬编码在 handler 包里，导致无法替换实现、无法做集成测试、无法按需切换 DB 实例。
- 错误写法：
func handler(w http.ResponseWriter, r *http.Request) { svc := NewUserService(db) ... } - 正确写法：定义
type Handler struct { NewService func() UserService }，然后http.HandlerFunc(func(w, r) { svc := h.NewService() ... }) - 若 handler 本身要复用，可封装为工厂函数：
MakeHandler(NewService func() UserService) http.Handler - 注意：不要把
http.Handler当作被注入对象，它是组合点，不是被管理的 bean
真正容易被忽略的不是怎么注入，而是谁该负责销毁资源——比如 *sql.DB 的 Close() 必须由构造它的那一层调用，不能交给某个“容器”统一管理，Go 没有析构钩子。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
