Go 中可用高阶函数实现轻量级 IoC：将依赖构造逻辑作为参数传入，如 handler 通过 func() Service 注入，生产用真实实现、测试用 mock，避免全局变量与隐式依赖，且签名即契约。
Go 里没有“IoC 容器”这种黑盒机制，但用高阶函数实现控制反转既轻量又自然——关键不是套概念，而是把依赖的创建时机和决策权交出去。
为什么不用框架也能做 IoC：高阶函数就是天然的注入点
框架型 IoC（比如 berkaroad/ioc）适合大型服务，但日常开发中，一个 func() Service 就足以解耦。它不藏逻辑、不反射、不注册，只暴露「谁来造」这个选择权。
- 构造函数本身是第一类值，可传、可存、可测试
- 调用方不关心
Service怎么初始化，只管用；测试时直接传个 mock 函数就行 - 避免了包级 init 或全局变量带来的隐式依赖和并发风险
典型场景：HTTP handler 与 service 的解耦
常见错误是 handler 直接 new 一个 service 实例，导致无法替换实现、难测、难 stub。
正确做法是把 service 构造逻辑作为参数传入：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
func NewHandler(newService func() UserService) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
svc := newService() // 控制权在这里反转：由调用方决定造什么
data, err := svc.GetUser(r.URL.Query().Get("id"))
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
json.NewEncoder(w).Encode(data)
}
}
- 生产环境传
func() UserService { return &realUserService{} } - 测试时传
func() UserService { return &mockUserService{} } - 甚至可动态切换：按 header 决定用缓存版还是直连版
newService
容易踩的坑：闭包捕获与生命周期错位
高阶函数注入看似简单，但若构造函数返回的对象依赖外部变量，极易引入隐式状态泄漏。
- 错误写法：
func() Service { return &Service{db: globalDB} }—— 仍绑定全局变量，没真正解耦 - 更隐蔽的坑：
func(cfg Config) func() Service { return func() Service { return &Service{cfg: cfg} } }，如果cfg是指针且被外部修改，所有后续newService()调用都共享同一份 cfg - 正确姿势：构造函数内完成全部依赖装配，参数尽量传值或不可变结构；若必须传指针，明确文档其生命周期约束
和接口嵌入组合的区别在哪
嵌入 Undo 这类结构体是「横向能力复用」，而高阶函数注入是「纵向依赖解耦」。两者不冲突，但目标不同：
- 嵌入解决的是「这个类型要不要支持 undo」的问题，属于功能扩展
- 高阶函数解决的是「这个 handler 用哪个 user service 实现」的问题，属于依赖来源控制
- 实际项目中常共存：handler 用高阶函数注入 service，service 内部再嵌入 logger、retry 等可组合组件
最易被忽略的一点：高阶函数的签名本身就是契约。一旦你定义了 func() Repository，就等于承诺所有实现都满足该构造协议——比运行时反射注册更早暴露不兼容问题。
