依赖注入本质是外部传入依赖而非自行创建，Go 中 NewUserService(logger, repo) 即符合；Wire 等工具仅自动化构造函数拼接，并非 DI 前提。
依赖注入不是“用框架才叫DI”
Go 里写 NewUserService(logger, repo) 就是依赖注入——只要依赖由外部传入，不自己 new，就满足 DI 的本质。Wire、fx、dig 这些工具只是帮你自动拼接这些构造函数，不是 DI 的前提。
很多人一上来就配 Wire，结果连 NewDB(...) 和 NewCache(...) 的参数顺序都还没理清，生成的 inject.go 编译不过。先手动写一遍依赖链，比直接上工具更能暴露设计问题。
- 检查每个构造函数是否只依赖接口（如
Logger），而非具体类型（如*zap.Logger） - 把配置项（
timeout、workers）和核心依赖（db、cache）分开传，避免构造函数膨胀 - 如果某个服务要同时用
*sql.DB和redis.Client，别硬塞进一个NewService()；拆成两层：先造连接，再组合业务逻辑
Wire build 会 panic？多半是反射没过这三关
wire build 报错常见于运行时 panic，但其实它根本没运行——错误来自生成代码里的反射调用，比如 reflect.Value.Interface() 在 nil 指针上调用。
Wire 不做运行时解析，但它生成的 inject.go 里大量使用反射来取字段、调构造函数。一旦你注册了一个 *Service，而某处构造函数参数却是 Service（值类型），生成的代码就会在 v.Interface() 崩掉。
立即学习“go语言免费学习笔记（深入）”；
- 所有被注入的字段必须是导出的（首字母大写），否则
reflect.Value.Field(i)返回无效值 - 若字段类型是
*T，确保注册进容器的是非 nil 指针；可用if !v.IsValid() || v.IsNil()提前 guard - 别指望 Wire 自动解引用：注册
Service{}，但参数要*Service？不行。必须显式注册&Service{}或改构造函数签名
什么时候该用 Wire，什么时候该手写 NewXXX？
Wire 的价值在「编译期检查 + 零运行时开销」，代价是每次改依赖都要 wire build，且不支持运行时替换（比如测试时换 mock）。
小项目或模块边界清晰时，手写 main.go 里的初始化逻辑反而更可控。Wire 真正省力的地方，是当你的服务树超过 5 层、每层都有多个可选实现（Postgres vs SQLite）、还要跨 package 注入时。
- 测试多、需频繁替换依赖 → 优先手写工厂函数，用 interface 参数控制实现
- 上线服务、依赖稳定、强调启动速度 → 用 Wire，它生成的代码和手写几乎一样快
- 有泛型依赖（如
Repository[User]）→ Wire 目前不原生支持泛型类型推导，得靠bind显式声明，容易写错
配置注入不是偷懒，是降低耦合的关键动作
当你发现 80% 的构造函数开头都是 logger, metrics, timeout, retryPolicy，说明该抽配置了。这不是为了减少参数个数，而是把“系统级策略”和“业务逻辑”分离开。
比如 type AppConfig struct { Logger Logger; Timeout time.Duration; MaxRetries int }，然后让所有服务接收 cfg AppConfig 而不是一堆零散参数。这样改超时不用翻 20 个文件，改日志级别也不用 grep 全局。
- 配置结构体字段必须是导出的，否则 Wire 反射不到
- 别把业务依赖（如
DB）塞进配置结构体里——配置只管“怎么做”，不管“用什么做” - 如果要用 YAML/TOML 加载配置，确保
Unmarshal后的值已完全初始化，特别是嵌套指针字段（*sql.DB不能是 nil）
