go无需自动依赖注入，di本质是显式传参；wire/dig仅解决构造链冗长问题，但易因接口设计不当、循环依赖或配置错误失效，手动di应聚焦于app.newapp()组装与接口正交设计。
Go 语言没有、也不需要“自动依赖注入”。所谓依赖注入，就是 NewUserService 显式接收 repo UserRepo 和 logger Logger，而不是在函数体内调用 newUserRepo() 或 zap.NewExample() —— 这一行传参动作，就是 DI 的全部。
为什么别急着上 wire 或 dig
第三方 DI 工具解决的是“构造链太长、重复太多”的体力问题，不是设计问题。多数项目卡在第一步：连 NewDB() 该返回 *sql.DB 还是 database/sql.Conn 都没想清，就去配 wire.Build()，结果生成一堆 wire_gen.go 报错，堆栈指向不存在的行号。
-
wire生成的代码不可调试，panic 时看到的是wire_gen.go:42，但真正错的是你漏写了func NewCache() Cache这个 provider -
dig运行时报interface{} is not registered，但不告诉你哪个 handler 的Get(&svc)漏了注册，得自己翻调用栈逐层查 - 所有框架都无法绕过「循环依赖」——Go 编译器早就在 import cycle 阶段报错，比 runtime panic 更早、更准
- 测试时 mock 依赖，根本不需要容器：只要
UserService构造函数参数是UserRepo interface{...}，直接传个 struct 实现就行
手动 DI 怎么组织才不乱
核心不是“怎么注入”，而是“在哪组装”。把所有初始化逻辑从 main() 抽出来，封装成一个可测试、可替换的 app.NewApp() 函数。
- 每个组件只暴露
NewXxx()函数，参数全是接口（如Logger），不接受具体类型（如*zap.Logger） - 基础依赖（配置、日志、指标）统一由
app.Config结构体承载，避免每个NewXXX()都传一堆相同参数 - 构造函数里不做耗时操作：不要在
NewDB()里调db.Ping()，失败应由上层决定是否启动失败 - 避免零散全局变量：
var db *sql.DB是反模式；func NewUserService(db *sql.DB, repo UserRepo)才是显性依赖
wire 使用必须踩准的三个硬约束
wire 不是魔法，它只是帮你写死一串 NewXXX() 调用。一旦违反以下任一条件，wire build 就会静默失败或报错难定位。
-
wire.go文件第一行必须是// +build wireinject（无空格、无逗号、无多余字符），否则wire build扫不到 injector - provider 函数必须导出（首字母大写）、无副作用、签名严格匹配：返回
*sql.DB就不能是type DB *sql.DB别名，也不能是database/sql.DB - 生成的
wire_gen.go必须提交进 Git —— 它不是缓存，CI 里漏跑wire build，新人拉代码直接编译失败，报undefined: InitializeApp
最常被忽略的一点：接口定义必须按调用方需要来写，而不是按实现方能提供什么。比如 UserRepo 接口里出现 UpdateEmailTx()，说明它已经和事务实现耦死了，后续换 Redis 或 mock 测试都会被迫补一堆空实现。DI 起效的前提，是接口真的能被替换，而不是名义上存在。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
