Go 中应显式依赖注入而非自动DI容器，通过 NewService(repo Repository, logger *log.Logger) 等构造函数传入所有依赖，接口定义在使用方包内，测试时直接替换实现而非mock。
Go 里不用框架也能做依赖注入？
可以，而且应该这么做。Go 没有反射驱动的“自动 DI 容器”，强行套用 Spring 那套会写出难测、难读、启动即崩溃的代码。真正的解耦不靠魔法，靠显式构造和接口隔离。
-
func NewService(repo Repository, logger *log.Logger)是标准起点，不是过渡方案 - 所有依赖都通过参数传入，不从全局变量或单例里偷偷拿
- 接口定义在使用方（consumer）包里，而不是实现方（provider）包里——否则又绑死了
常见错误现象：panic: interface conversion: interface {} is nil, not *sql.DB，往往是因为某层漏传了依赖，但因为用了“自动注入”包装器，报错位置离真实漏点差三层调用栈。
为什么不要用 wire 或 dig 做“自动”注入？
它们确实能生成构造函数，但代价是：编译期隐式依赖、调试时跳转失灵、重构时类型安全形同虚设。
-
wire.Build会让main.go变成一堆Bind和Struct调用，实际依赖关系藏在生成的wire_gen.go里 -
dig.Container.Invoke把函数签名当契约，但参数名/顺序一变就 runtime panic，IDE 无法跳转到具体实现 - 性能影响倒不大，但开发体验断层：写代码时像在配 XML，查 bug 时得切两套上下文
使用场景：只有当项目稳定、依赖树极深、且团队已统一约定构造逻辑时，才考虑 wire；日常开发中，手写 NewXXX 更快、更可控、更易加日志或条件分支。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
接口定义放哪？一个容易被忽略的边界问题
放在调用它的包里，不是实现它的包里。比如 user.Service 用到了存储能力，那它该定义自己的 user.Repository 接口，再让 postgres.UserRepo 去实现它。
- 否则
postgres包为满足多个上层需求，会不断膨胀出无关方法，违背单一职责 -
user.Repository接口只含Create、FindByEmail，而analytics.Reporter即使也用 PostgreSQL，也该定义自己的analytics.Storer - 这样换数据库时，只需重写对应接口的实现，上层完全无感；但如果共用一个
repo.UserRepo接口，改一处就牵连八方
参数差异：接口方法参数应按使用者视角设计，比如 FindByEmail(ctx context.Context, email string) (*User, error)，而不是暴露底层 SQL 参数如 query string, args ...any。
测试时怎么替换依赖？别 mock，直接换实现
Go 的依赖注入天然适合测试：把真实依赖换成内存版、空实现或伪造结构体即可，不需要第三方 mock 工具。
-
user.NewService(&mockRepo{}, log.New(ioutil.Discard, "", 0))——mockRepo就是个带字段的 struct，实现必要方法 - 不要试图 mock
*sql.DB或http.Client，而是封装一层接口，然后给它一个memDB实现 - 如果某个依赖初始化成本高（比如连接 Redis），测试时用
nil或轻量 stub，只要它不 panic 就行；真要测集成，另起测试文件用testcontainers
性能影响几乎为零，因为没反射、没代理、没中间层。唯一要注意的是：别在测试里复用全局 var db *sql.DB，每次测试用独立实例，避免状态污染。
事情说清了就结束。最复杂的从来不是怎么注入，而是想清楚谁该依赖谁、接口该长什么样、以及什么时候该让一个包彻底不知道另一个包的存在。
