YAML：没有混乱的配置文件

每个Kubernetes清单。每个GitHub Actions工作流。每个Docker Compose文件。

YAML到处都是用于配置。它可读、灵活，并且有一些令人惊讶的怪癖。

为什么YAML？

JSON很严格：双引号，不允许注释，不允许尾随逗号。

YAML很宽容：最小语法，允许注释，人类可读。

# YAML配置
database:
  host: localhost
  port: 5432
  name: myapp

{
  "database": {
    "host": "localhost",
    "port": 5432,
    "name": "myapp"
  }
}

相同数据，YAML中噪音更少。

基础

键值对：

name: John
age: 30

嵌套结构（使用空格，不是制表符）：

person:
  name: John
  age: 30

列表：

colors:
  - red
  - green
  - blue

内联列表和对象：

colors: [red, green, blue]
person: {name: John, age: 30}

挪威问题

country: NO

NO是什么？布尔值false。YAML将NO、Yes、on、off等解释为布尔值。

挪威的国家代码变成false。你的配置以神秘方式崩溃。

修复： 引用可能被解释为布尔值的字符串。

country: "NO"

多行字符串问题

description: This is a long
  description that continues

这是两行还是一行，"that continues"缩进？取决于YAML解析器。

显式多行：

# 字面（保留换行）
description: |
  Line one
  Line two

# 折叠（连接行）
description: >
  This is one long
  line when parsed

缩进很重要

两个空格。不是制表符。不是一个空格。不是三个。

# 正确
parent:
  child: value

# 错误 - 制表符
parent:
	child: value

混合制表符和空格静默破坏YAML。配置你的编辑器使用空格。

数字解释

version: 1.10

那是字符串"1.10"还是数字1.1？大多数解析器将其解释为1.1。

浮点数学再次袭来。引用版本号。

version: "1.10"

锚点和别名

YAML可以引用重复内容：

defaults: &defaults
  timeout: 30
  retries: 3

production:
  <<: *defaults
  timeout: 60

强大以减少重复。过度使用时令人困惑。

验证YAML

YAML的灵活性意味着许多看起来有效的东西不是。

• 在编辑器中使用linter
• 尽可能针对模式验证
• 转换为JSON以查看解析器实际解释的内容

如果你的配置不工作，检查解析器看到的，而不是你写的。

YAML vs JSON vs TOML

YAML： 人类可读，许多特性，怪异的边缘情况。

JSON： 严格，简单，广泛支持，冗长。

TOML： 显式，更少惊喜，配置流行度增长。

对于机器到机器数据，JSON更安全。对于人类编辑的配置，如果你知道陷阱，YAML有效。

---

YAML优先考虑可读性而不是严格性。这种权衡创造边缘情况。引用看起来像布尔值或数字的字符串，使用显式多行语法，并在部署前验证。