Go项目配置应分层管理：系统级参数（如超时、重试、日志）须抽为统一结构体（如ServiceConfig），避免构造函数参数膨胀；IOC-golang路径需严格匹配YAML层级，字段名大小写必须一致，且配置加载须前置到main()中并显式错误处理。
Go 项目里配置注入不是“配完就跑”，而是要分清哪些该进构造函数、哪些该进 config 结构体、哪些根本不该注入——否则很快就会在 NewUserService 里塞满 timeout、retryCount、logger、metrics、cacheClient，最后连自己都记不清哪个参数是干啥的。
什么时候该把配置抽成独立结构体？
当多个服务共用同一组系统级参数（比如日志级别、超时时间、重试策略）且这些参数来源一致（如 YAML 文件或环境变量）时，必须抽离。硬编码或零散传参会导致三处问题：
-
NewOrderService和NewPaymentService都要接收ctxTimeout time.Duration，但实际值都来自同一个config.yaml的service.timeout节点 - 测试时想改 timeout，得 mock 两个构造函数参数，而不是只换一个 config 实例
- 上线后发现要动态调大重试次数，结果要改 5 个 New 函数签名 + 5 处调用，还容易漏
正确做法是定义统一的 type ServiceConfig struct { Timeout time.Duration; RetryCount int; LogLevel string }，再让所有服务只依赖它。IOC-golang 的 config.ConfigInt 等类型本质也是这个思路的封装，但别被它的标签语法带偏——核心不是怎么写 config:",autowire.config.service.timeout"，而是你是否真需要这层间接性。
IOC-golang 的 config 标签路径怎么对得上 YAML？
路径匹配不是字符串模糊查找，而是严格按 YAML 层级展开。比如你的 ioc_golang.yaml 是：
立即学习“go语言免费学习笔记（深入）”；
autowire:
config:
service:
timeout: 5s
retry-count: 3那么对应字段标签必须写成 config:",autowire.config.service.timeout"，不能省略 autowire.，也不能写成 config:",service.timeout"。常见错误包括：
- YAML 里用了缩进空格不一致（比如混用 tab 和空格），导致解析后
autowire.config根本不存在 - 结构体字段声明为
Timeout *config.ConfigString，但 YAML 中timeout: 5s是字符串，而你本意是要解析成time.Duration——IOC-golang 的ConfigString不做类型转换，它只负责把 YAML 字符串原样塞进去 - 路径中含连字符（如
retry-count），YAML 解析器能认，但 Go struct tag 里写config:",autowire.config.service.retry-count"是合法的；不过更稳妥的是统一用下划线，避免某些 loader 对连字符处理不一致
构造函数参数里该放 config 还是具体字段？
看变化频率和组合粒度。如果 timeout 和 retryCount 总是一起变（比如灰度发布时整套策略切换），就合并在 ServiceConfig 里传；如果 timeout 要单独调优（如支付链路设 8s，查询链路设 2s），那就拆成独立参数，直接进构造函数签名。
IOC-golang 的 *config.ConfigInt 类型适合「静态配置项」：启动时读一次，运行中不变。但它不适合以下场景：
- 需要运行时热更新（如通过 HTTP 接口改重试次数）——
ConfigInt是只读指针，改了值也不会触发回调 - 参数之间有约束（如
retryCount > 0 && timeout > time.Second * time.Duration(retryCount)）——校验逻辑得放在 config 结构体的Validate()方法里，而不是靠注入框架 - 不同环境用不同值（dev/staging/prod），但又不想维护多份 YAML——这时应该用环境变量覆盖，而非依赖 IOC-golang 的文件加载顺序
为什么别在 New 函数里直接 new config 实例？
因为 config 初始化本身可能失败（文件不存在、格式错误、字段缺失），而构造函数按约定不应返回 error（NewXXX 应该是纯函数）。一旦你在 NewUserService 里写 cfg, _ := loadConfig()，错误就被吞掉了，程序可能带着默认值跑起来，出问题时很难定位。
正确姿势是把 config 加载提前到组装阶段：
- 手写初始化时，在
main()或app.NewApp()里先调loadServiceConfig()，出错就log.Fatal - 用 IOC-golang 时，确保
ioc_golang.yaml在启动前已存在且合法，框架会在 autowire 阶段 panic 报错，比运行时静默失败好查得多 - 若需 fallback 逻辑（如配置缺失时用默认值），必须显式写在 config 加载函数里，而不是指望注入框架自动补缺
最易被忽略的一点：config 结构体字段名大小写必须和 YAML key 完全一致（Go 默认导出字段首字母大写，YAML key 小写），中间没有自动映射。别以为写了 Timeout time.Duration，YAML 里写 timeout: 5s 就能自动绑定——IOC-golang 的 ConfigInt 不走 struct tag 反射，它只认你标签里写的路径字符串。
