Go中依赖管理应使用函数类型定义而非结构体字段反射注入，因前者由编译器校验、避免运行时panic、利于测试且无额外依赖；New*工厂函数需以接口为参数、指针为返回值、显式传递依赖并返回(T, error)。
Go 里没有“自动注入”的魔法，但用函数类型定义 + 显式组合，能写出比反射 DI 更可控、更易测试的轻量级依赖管理——它不靠标签、不扫描结构体、不递归解析，只靠类型签名和函数拼接。
为什么用 func 类型定义而不是结构体字段注入
结构体字段注入（比如 Repo UserRepository `inject:""`）依赖反射，在启动时遍历字段、查标签、找实现，容易出错且调试困难。而函数类型定义把依赖关系直接写进签名里，编译器能立刻检查：参数缺了、类型不对、顺序错了，全在 go build 阶段暴露。
- 避免运行时 panic：比如字段为 nil 却没被注入，只有调用时才崩
- IDE 和工具链支持更好：
NewService的参数列表就是它的依赖契约 - 单元测试天然友好：直接传 mock 实现，不用启动容器、注册 bean、绕过标签扫描
- 无额外依赖：不引入
reflect、不依赖第三方 DI 库的生命周期管理逻辑
NewService 这类工厂函数怎么写才符合依赖契约
关键不是函数名，而是参数类型和返回类型必须清晰表达“我需要什么”和“我提供什么”。不要返回 interface{} 或混用基础类型。
- 每个参数应是接口，而非具体实现：
func NewService(repo UserRepository, cache CacheClient) *Service，不是*UserRepoImpl - 避免多个同类型参数：两个
*sql.DB就会冲突，改用带语义的类型别名，比如type PrimaryDB *sql.DB和type ReplicaDB *sql.DB - 返回值推荐指针：Go 中结构体通常通过指针传递，避免拷贝；且便于后续扩展方法集
- 不隐藏依赖：不要把
log.Logger塞进 context 或全局变量，显式作为参数传入
如何组织多个 New* 函数形成可组合的初始化链
Wire 的核心思想其实就在这儿：把初始化逻辑拆成小函数，再用类型匹配把它们串起来。你不需要 Wire 工具，手写也能做到，只是少了代码生成。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 确保每层函数的输出类型，正好是下一层的输入类型：比如
NewDB() *sql.DB→NewRepository(*sql.DB) *Repository→NewService(*Repository) *Service - 用闭包或配置函数包装可变参数：例如
NewDBWithOptions(dsn string, opts ...DBOption)，保持主链干净 - 避免中间态暴露：不要导出
*Repository给业务层直接用，只让它作为NewService的内部依赖 - 错误处理要透出：每个
New*函数都该返回(T, error)，而不是 panic 或忽略失败
常见陷阱：类型别名、指针 vs 值、接口实现漏方法
看似简单的函数签名，实际最容易栽在类型细节上。Go 的类型系统严格，差一个 * 或少一个方法，编译就断。
-
type DB *sql.DB和*sql.DB是不同类型，不能互相赋值；必须统一用别名或原生类型 - 接口定义要完整：如果
UserRepository声明了GetUser(id int) string，但实现里写成GetUser(id int64) string，编译不报错但运行时 panic - 值接收者方法无法满足指针接收者接口：
func (u UserRepo) GetUser(...)不能赋给需要*UserRepo实现的接口 - 空 struct{} 不等于 nil 接口：用
var r UserRepository初始化后，r == nil为 true；但若用r = &UserRepo{}，即使字段全零，r != nil
最易被忽略的其实是组合粒度——不是每个 struct 都值得配一个 New* 函数，也不是所有依赖都要拆到最细。重点在于：当某段初始化逻辑开始出现条件分支、环境判断、或需要复用时，才把它抽成独立函数。否则，三行初始化代码硬写在 main 里，反而更清楚。
