go中配置应显式传入构造函数而非依赖反射或yaml自动注入；配置需早期解析为具体类型并作为参数传给new函数；避免未初始化config字段、隐藏依赖及“配置幻觉”。
Go 里没有“配置框架”这回事，所谓“配置注入”，本质是把配置值作为依赖，用构造函数或结构体字段传进去——不是靠 YAML 文件自动塞进 struct 字段，更不该指望运行时反射猜你要什么。
config 字段直接传给 New 函数最安全
别把 ioc_golang.yaml 当成魔法开关。配置项（比如数据库地址、超时时间）应该先被解析成具体类型（string、time.Duration），再作为参数显式传给 NewService() 或 NewDB()。
- 避免在结构体里留未初始化的
Config *Config字段，否则测试时一调就 panic - 配置解析失败必须在
main()早期暴露，而不是等到某个 handler 第一次访问才报nil pointer dereference - 如果配置项多，可封装成一个
Config结构体，但它的字段必须全为导出、有明确语义（如DBTimeout time.Duration），而非map[string]interface{}
用 wire 生成注入代码时，config 必须出现在 provider 链里
wire 不会自动读配置文件，它只负责把已知类型连起来。如果你要注入 *sql.DB，那 ProvideDB 函数就必须接收 Config 类型参数，并在里面做解析和连接逻辑。
-
wire.Build(ProvideDB, ProvideLogger)中，ProvideDB的签名得是func(Config) (*sql.DB, error)，不能是func() (*sql.DB, error) - 漏掉
Config这个中间依赖，wire_gen.go编译就会报 undefined，错误指向*sql.DB构造失败，但真正原因是Config没传进去 - 测试时想绕过真实配置？用
wire.Value(myTestConfig)替换掉ProvideConfig即可，不用改业务逻辑
Gin handler 里别从 context.Keys 取 config
c.Keys["timeout"] 是 interface{}，取出来还得断言，IDE 补不了，编译不检查，测试难 mock —— 这根本不是 DI，是隐藏依赖。
- 正确做法：把 config 相关字段（如
HTTPTimeout、RetryCount）提前注入到 controller 结构体中，例如type VoteHandler struct { Timeout time.Duration } - handler 方法签名保持干净：
func (h *VoteHandler) Handle(c *gin.Context)，所有依赖都在h里，测试时直接 new 一个带 mock 值的实例就行 - 如果 config 项太多，说明这个 handler 职责过重，该拆了
配置不是独立存在的一等公民，它只是初始化依赖时需要的输入。最容易被忽略的点是：没人检查配置字段是否真的被用到了。写完 Config.Timeout，却在 NewDB 里硬编码了 5 * time.Second，这种“配置幻觉”比没配置还危险。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
