viper 默认行为隐式、调试困难，易因自动合并导致覆盖逻辑不可控；自定义解析器可精准掌控加载顺序、错误定位与类型约束。
为什么不用 viper 而要自己写配置解析器
因为 viper 太重、行为隐式、调试困难——比如它自动合并环境变量、命令行参数，导致你改了 config.yaml 却发现值没生效，最后查到是某个未声明的 ENV=prod 覆盖了字段。自定义解析器的核心诉求不是“造轮子”，而是掌控加载顺序、错误定位和类型约束。
用 encoding/json 和 encoding/yaml 读文件时的路径与错误处理
Go 标准库不自动处理文件路径查找或 fallback，必须显式指定。常见错误是 open config.json: no such file or directory，但实际是因为当前工作目录不是你认为的那个目录。
- 始终用
filepath.Abs或os.ReadFile前加os.Stat判断文件是否存在，别依赖 panic 捕获 - YAML 解析需导入
gopkg.in/yaml.v3（不是gopkg.in/yaml.v2），v2 对 map[string]interface{} 支持差，且不保留字段顺序 - JSON 解析后若字段名首字母小写，
json.Unmarshal会静默忽略——结构体字段必须导出（大写开头）且带json:"key"tag
结构体定义与类型安全之间的取舍
硬编码结构体最稳，但改配置就得改代码；用 map[string]interface{} 灵活，却失去编译期检查和 IDE 自动补全。折中方案是：为高频配置项定义 struct，其余用 map[string]any 做扩展字段。
示例：
type Config struct {
Server struct {
Port int `json:"port" yaml:"port"`
Host string `json:"host" yaml:"host"`
} `json:"server" yaml:"server"`
Features map[string]any `json:"features" yaml:"features"` // 允许动态键
}
- 嵌套结构体必须用匿名 struct 或独立 type，否则
yaml.Unmarshal无法正确映射 -
map[string]any中的数字默认是float64，取值时需手动转int或bool，否则运行时报interface{} is float64, not int - 如果配置含数组，确保 JSON/YAML 中对应字段是列表格式，否则
Unmarshal会把单个值当字符串塞进 slice
环境变量与配置文件的优先级合并逻辑
环境变量应该覆盖配置文件，但不是简单地 os.Getenv("PORT") 替换整个字段——而是按 key path 逐层覆盖，比如 SERVER_PORT=8081 只改 Server.Port，不影响 Server.Host。
- 用
strings.Split(os.Getenv(key), "_")拆解环境变量名，映射到结构体字段路径（如SERVER_PORT→Server.Port） - 避免用反射遍历所有字段做覆盖：性能差、易出错；推荐在 Unmarshal 后，对已知关键字段做显式赋值
- 不要在解析器里调用
log.Fatal，返回error让调用方决定是否 panic——测试时你没法捕获日志中断
真正难的不是读文件，而是让不同来源的配置能 predictably override，且报错时精准指出是哪个文件第几行哪个 key 缺失或类型错。这点标准库不提供，得自己加 yaml.Line 或用第三方库如 go-yaml 的 Node API 才行。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
