结构体字段必须首字母大写且显式标注yaml:"key"标签，否则yaml.Unmarshal会静默设零值；须用os.ReadFile读取并检查错误，传结构体指针&cfg，YAML键名与标签严格一致（含大小写、下划线），嵌套字段同理。
结构体字段必须首字母大写 + 显式 yaml:"key" 标签
Go 的 yaml.Unmarshal 依赖反射，只能访问导出字段（即首字母大写的字段）。写 port int 即使加了 yaml:"port" 标签也会被完全忽略——值永远是 0，不报错也不警告。
正确写法是：Port int `yaml:"port"`。YAML 键名（如 redis_url）和标签字符串必须严格一致，包括下划线、连字符、大小写。比如 YAML 里是 skip-header-validation: true，标签就得写成 yaml:"skip-header-validation"，不能写成 yaml:"skip_header_validation"。
- 嵌套结构体里的字段也必须导出，不能只导出顶层结构体
- 字段名
RedisUrl默认会尝试匹配redisurl（全小写无下划线），不可靠，必须靠yaml:"redis_url"显式指定 - 如果字段类型是
*string或*bool，才能区分“未设置”和“显式设为 null”
os.ReadFile 读取 + &cfg 传指针，缺一不可
ioutil.ReadFile 在 Go 1.16+ 已彻底弃用，继续用会触发编译警告，且底层逻辑过时。必须改用 os.ReadFile。
更关键的是：哪怕文件读取成功，若把结构体变量本身（如 cfg）传给 yaml.Unmarshal，它根本无法修改原值——静默失败，字段全是零值。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- ✅ 正确：
data, err := os.ReadFile("config.yaml")；err != nil必须检查，否则后续 panic 是大概率事件 - ✅ 正确：
yaml.Unmarshal(data, &cfg)，不是yaml.Unmarshal(data, cfg) - 路径不确定时，先用
os.Stat("config.yaml")检查是否存在，避免运行时报no such file or directory - 读完可简单检查 BOM：
bytes.HasPrefix(data, []byte{0xEF, 0xBB, 0xBF})，防止 UTF-8 BOM 干扰解析
动态键名（如 V1、staging）不能硬套结构体
当 YAML 顶层是运行期才确定的键（比如不同环境、API 版本），定义固定结构体字段必然失败。直接用 map[string]interface{} 虽能读，但 v3 默认解析出的是 map[string]any，类型断言 v["V1"].(map[string]interface{}) 会 panic。
- 安全做法：定义一个结构体，实现
UnmarshalYAML接口，在方法中先提取已知字段（如skip-header-validation），再把剩余部分解析为map[string]MajorVersion - 临时调试可用
yaml.Node手动遍历树结构，但别上生产 - 避免写类似
v["V1"].(map[string]interface{})这种代码——v3 下大概率 panic，且类型不安全
默认值、环境适配等业务逻辑必须后置处理
yaml.Unmarshal 只负责把 YAML 字节准确转成 Go 值，不该掺杂任何业务逻辑。比如根据 env: "prod" 自动设 log_level: "warn"，不能写进 UnmarshalYAML 方法里。
- 默认值应在
yaml.Unmarshal成功之后、真正使用配置之前统一处理 - YAML 中的
null、空字符串、缺失字段，在结构体中都映射为 Go 零值（0、""、nil），没有自动区分能力 - 若需校验必填字段是否存在，得手动检查，比如
if cfg.Port == 0→ 报错或设默认值
解析 YAML 最容易被忽略的点，往往不在语法或库调用，而在于字段导出规则与反射机制的耦合——小写字段静默丢弃、标签不匹配就归零、指针传错就白忙活。这些都不是 bug，是 Go 语言设计的必然行为。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
