go无内置di，手动构造依赖树+接口抽象+显式传参即本质di；第三方框架如wire、dig不必要，因中小型项目无需、反增复杂度，且仍需显式声明依赖；手动di应组织为集中可测的app.newapp()，构造函数参数全为接口，避免循环依赖与过度抽象。
Go 语言没有内置依赖注入（DI）机制，所谓“Go 的 DI”本质是手动构造依赖树 + 接口抽象 + 构造函数显式传参——不是靠框架自动扫描或反射注入。
为什么不用第三方 DI 框架（比如 wire、dig）？
多数中小型 Go 项目用不上；强行引入反而增加理解成本和构建复杂度。Wire 是 compile-time 代码生成，dig 是 runtime 反射，两者都绕不开「显式声明依赖关系」这个核心动作——而你手写 NewService 函数时已经在做了。
- Wire 生成的代码难调试，错误信息指向生成后的文件，不是源码
- dig 在容器未注册依赖时 panic 报错是
interface{} is not registered，但调用栈不告诉你哪个Get调用漏了注册 - 所有 DI 框架都无法解决循环依赖，Go 编译器本身会报
import cycle，比运行时报错更早、更明确
怎么手动做 DI 才不乱？
关键不是“怎么注入”，而是“怎么组织构造逻辑”。把依赖组装从 main() 里抽出来，单独成一个 app.NewApp() 函数，所有初始化逻辑集中、可测试、可替换。
- 每个组件只暴露
NewXxx(...)构造函数，参数全是接口，不依赖具体实现 - 数据库连接、配置、日志等基础依赖，统一由
app.Config结构体承载，避免零散传参 - 不要在构造函数里做耗时操作（如连 DB），除非你明确要它失败时整个启动失败
示例：
func NewUserService(repo UserRepo, logger *zap.Logger) *UserService {
return &UserService{repo: repo, logger: logger}
}
func NewApp(cfg Config) (*App, error) {
db := sql.Open(...)
userRepo := NewUserRepo(db)
logger := zap.NewExample()
userService := NewUserService(userRepo, logger)
return &App{userService: userService}, nil
}
接口定义和实现分离的常见坑
DI 的前提是依赖倒置，但 Go 里容易写成「先写实现，再补接口」，结果接口绑死实现细节，失去替换能力。
- 接口应该按调用方需要定义，不是按实现方能提供什么定义。比如
UserRepo不该有UpdateEmailTx()，而应是UpdateUser(ctx, u User) - 一个结构体别实现太多接口，否则违反单一职责，也导致测试 mock 成本高
- 别为了 DI 强行加接口：如果某个类型只被一处使用、且无替换需求（如本地缓存
map[string]string），直接传值更清晰
什么时候真该用 Wire？
只有当构造链特别长（>5 层）、且不同环境（test/staging/prod）依赖组合差异大、人工维护易出错时，才值得引入 Wire。
- 必须配合
//go:build wireinject标签隔离生成代码 - Wire 文件里不能出现业务逻辑，只写
BuildXXX()和Provider声明 - 每次改依赖后要重新
wire generate，CI 里得加检查，否则生成代码过期没人发现
一句话：Wire 解决的是「构造代码重复写、容易漏」的问题，不是「Go 缺少 DI」的问题。
真正容易被忽略的，是把 DI 当成目的而非手段——最后跑起来的程序，没人关心对象是谁 new 的，只关心它能不能正确响应请求、出错时能不能快速定位到哪一层没接好。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
