直接用json.Unmarshal读YAML文件会失败，因为YAML不是JSON超集，其支持注释、缩进、锚点等json.Unmarshal无法识别的语法，导致解析时出现invalid character错误；正确做法是使用yaml.Unmarshal配合导出字段和匹配标签。
为什么直接用 json.Unmarshal 读 YAML 文件会失败
因为 YAML 不是 JSON 的超集，虽然很多 YAML 文件看起来像 JSON，但 YAML 支持更多语法（如注释、缩进、锚点、!!int 类型标记），json.Unmarshal 完全不识别这些。直接把 .yaml 文件内容丢给 json.Unmarshal，大概率触发 invalid character 'y' looking for beginning of value 或类似错误——它连文件头的 yam 都解析不了。
正确做法是先用 YAML 解析器（如 gopkg.in/yaml.v3）把文件转成 Go 结构体或 map[string]interface{}，再按需处理。JSON 文件则可直接用标准库 encoding/json。
- YAML 文件必须用
yaml.Unmarshal，不能绕过 - 如果配置结构固定，定义 struct 比用
map[string]interface{}更安全、易维护 -
yaml.v3默认忽略未定义字段；若需检测多余字段，得手动启用yaml.DisallowUnknownFields()
如何统一处理 JSON 和 YAML 配置文件而不重复写解析逻辑
核心思路是抽象出“读取 + 反序列化”两步：先根据扩展名选择解析器，再统一调用反序列化函数。避免为每种格式写一套 os.Open → io.ReadAll → Unmarshal 流程。
示例关键片段：
立即学习“go语言免费学习笔记（深入）”；
func LoadConfig(filename string, v interface{}) error {
ext := filepath.Ext(filename)
data, err := os.ReadFile(filename)
if err != nil {
return err
}
switch ext {
case ".json":
return json.Unmarshal(data, v)
case ".yaml", ".yml":
return yaml.Unmarshal(data, v)
default:
return fmt.Errorf("unsupported config format: %s", ext)
}
}
- 注意
filepath.Ext返回包括点的后缀（如".yaml"），别写成"yaml" -
yaml.Unmarshal对 struct 字段标签默认同时识别json和yaml，所以一个 struct 可同时用于两种格式（前提是字段名和嵌套一致） - 如果配置文件路径含环境变量（如
${HOME}/config.yaml），需在LoadConfig前做os.ExpandEnv替换
struct 标签里 json: 和 yaml: 冲突怎么办
多数情况下不用冲突——gopkg.in/yaml.v3 会优先读 yaml: 标签，没找到才 fallback 到 json:。但如果你显式写了两个，且值不同（比如 json:"user_id" yaml:"uid"），yaml.Unmarshal 就会按 yaml: 的值绑定，json.Unmarshal 按 json: 绑定，行为分离是预期的。
- 想让两者完全一致，只写
json:标签即可，yaml.v3能识别它 - 若需差异化（例如 YAML 用短字段名、JSON 用长描述名），必须明确写出两个标签，并接受解析结果取决于所用格式
- 空字符串标签（
yaml:""）表示忽略该字段，但json:""在标准库中含义不同（表示使用字段名），慎用
加载时发现配置字段总是零值？检查这三件事
最常见原因是字段未导出（首字母小写），Go 的 encoding/json 和 gopkg.in/yaml.v3 都无法访问非导出字段，直接跳过赋值，留零值。
- 确认 struct 字段首字母大写（如
Name string，不是name string） - 检查 YAML/JSON 中的 key 名是否与 struct 标签完全匹配（大小写敏感，
yaml:"db_host"对应 YAML 中的db_host:） - 嵌套 struct 必须也是导出的；如果用了
map[string]interface{}，确保 map key 是字符串，且类型能被自动转换（如 YAML 的true可转bool，但123默认是float64）
字段导出与否是硬性门槛，其他问题都排在这之后。
