2024年Stack Overflow調(diào)研顯示，YAML是開(kāi)發(fā)者最討厭的配置格式第三名，僅次于XML和INI。但諷刺的是，它同時(shí)是Kubernetes、GitHub Actions、Docker Compose的默認(rèn)語(yǔ)言——你每天罵它，卻離不開(kāi)它。

我見(jiàn)過(guò)凌晨三點(diǎn)被叫醒的SRE，原因只是某人把縮進(jìn)從2空格改成了4空格。YAML不會(huì)報(bào)錯(cuò)說(shuō)"縮進(jìn)錯(cuò)了"，它會(huì)默默解析成完全不同的數(shù)據(jù)結(jié)構(gòu)，然后你的Pod就起不來(lái)了。這種"沉默的背叛"比編譯錯(cuò)誤可怕十倍。

縮進(jìn)是語(yǔ)法，不是風(fēng)格

YAML用縮進(jìn)表達(dá)層級(jí)，跟Python一樣。但Python至少會(huì)拋IndentationError，YAML parser只會(huì)給你一棵歪掉的語(yǔ)法樹(shù)。

規(guī)則只有兩條：用空格，別用Tab；用2個(gè)空格，別用4個(gè)。Tab在YAML規(guī)范里是未定義行為，有些parser認(rèn)，有些不認(rèn)。2023年GitLab的一次全球服務(wù)中斷，根因就是某個(gè)CI模板里混進(jìn)了一個(gè)Tab字符。

VS Code用戶現(xiàn)在就去改設(shè)置：workspace.json里加"editor.insertSpaces": true和"editor.tabSize": 2。YAML插件能實(shí)時(shí)標(biāo)紅縮進(jìn)錯(cuò)誤，但前提是你得先裝上插件——很多人沒(méi)裝。

有個(gè)冷知識(shí)：YAML spec允許任意數(shù)量的空格縮進(jìn)，只要同一層級(jí)一致就行。但2空格是社區(qū)事實(shí)標(biāo)準(zhǔn)，偏離這個(gè)標(biāo)準(zhǔn)就是給自己埋雷。團(tuán)隊(duì)協(xié)作時(shí)，把.yamllint.yml放進(jìn)倉(cāng)庫(kù)根目錄，強(qiáng)制indentation: {spaces: 2}，比任何code review都管用。

引號(hào)不是裝飾，是防彈衣

YAML的自動(dòng)類型推斷是便利還是陷阱？看你怎么用。不加引號(hào)的值會(huì)被解析成字符串、布爾值、整數(shù)、浮點(diǎn)數(shù)或null，取決于內(nèi)容。

最陰險(xiǎn)的是布爾值。YAML 1.1（PyYAML等舊parser的默認(rèn)版本）把yes/no/on/off都當(dāng)布爾值。你的國(guó)家代碼列表里有NO（挪威）？變成false了。配置項(xiàng)寫(xiě)on？變成true了。

安全法則：任何可能被誤讀的值都加引號(hào)。版本號(hào)"1.10"不加引號(hào)會(huì)變成1.1（浮點(diǎn)數(shù)）。電話字符串"0123"會(huì)變成83（八進(jìn)制）。這些bug在預(yù)發(fā)布環(huán)境可能藏幾個(gè)月，直到某個(gè)用戶數(shù)據(jù)觸發(fā)邊界條件。

雙引號(hào)支持轉(zhuǎn)義序列（\n、\t、Unicode），單引號(hào)原樣輸出（不處理轉(zhuǎn)義）。簡(jiǎn)單字母數(shù)字串可以裸奔，但問(wèn)問(wèn)自己：這個(gè)值以后會(huì)不會(huì)變成"1.0"或者"yes"？

多行字符串：選錯(cuò)風(fēng)格，日志亂套

寫(xiě)shell腳本或SQL查詢時(shí)，多行字符串的換行處理能逼瘋?cè)?。YAML提供兩種塊標(biāo)量風(fēng)格，差別微妙但致命。

管道符|保留換行符，適合shell腳本。大于號(hào)>把換行轉(zhuǎn)成空格，適合長(zhǎng)段落文本。但等等——|后面還能跟-或+，控制末尾換行是否保留。

我見(jiàn)過(guò)一個(gè)生產(chǎn)事故：開(kāi)發(fā)者用|寫(xiě)Dockerfile指令，末尾多了個(gè)換行，導(dǎo)致RUN命令拼接失敗。鏡像構(gòu)建成功，但運(yùn)行時(shí)行為詭異，調(diào)試花了六小時(shí)。

建議：在團(tuán)隊(duì)wiki里貼一張cheat sheet，寫(xiě)明什么場(chǎng)景用什么風(fēng)格。別指望每個(gè)人去讀YAML spec，那玩意兒比大部分編程語(yǔ)言規(guī)范還難啃。

錨點(diǎn)與別名：DRY的甜蜜陷阱

&定義錨點(diǎn)，*引用別名，<<合并鍵——這套機(jī)制讓你能寫(xiě)一次配置，多環(huán)境復(fù)用。Helm values文件、Docker Compose多服務(wù)定義、CI矩陣，都是典型場(chǎng)景。

但錨點(diǎn)是在parser層面展開(kāi)的，你的應(yīng)用拿到的是展開(kāi)后的數(shù)據(jù)，看不到復(fù)用關(guān)系。這意味著：調(diào)試時(shí)你看到的YAML和實(shí)際生效的YAML是兩回事。

更隱蔽的問(wèn)題是覆蓋順序。<<: *defaults后面再寫(xiě)同名鍵，會(huì)覆蓋默認(rèn)值。但如果defaults里嵌套了對(duì)象，淺合并還是深合并？取決于你的parser和版本。PyYAML和ruamel.yaml行為就不一樣。

我的建議是：錨點(diǎn)別嵌套超過(guò)兩層，合并邏輯寫(xiě)進(jìn)文檔，復(fù)雜場(chǎng)景直接用模板引擎（Jinja2、Go template）代替原生錨點(diǎn)。YAML不是編程語(yǔ)言，別把它用成編程語(yǔ)言。

lint不是可選項(xiàng)，是門(mén)禁

yamllint、prettier、vscode-yaml——這些工具能在保存時(shí)就攔住80%的錯(cuò)誤。但2024年JetBrains的調(diào)研顯示，只有31%的DevOps團(tuán)隊(duì)把YAML linting寫(xiě)進(jìn)CI pipeline。

剩下的69%在干嘛？靠人眼review。人眼能發(fā)現(xiàn)2空格和4空格的區(qū)別嗎？能發(fā)現(xiàn)某個(gè)yes其實(shí)是字符串"yes"嗎？

GitHub Actions示例：在workflow里加一步y(tǒng)amllint，失敗就阻斷合并。成本幾乎為零，收益是少幾個(gè)凌晨三點(diǎn)的on-call。

最后說(shuō)個(gè)細(xì)節(jié)：YAML spec有1.1和1.2兩個(gè)版本，行為差異不小。你的parser默認(rèn)用哪個(gè)？跑yamllint --version查一下，然后在配置里顯式聲明yaml-version: "1.2"。別讓默認(rèn)設(shè)置替你做決定。

你最后一次因?yàn)閅AML格式問(wèn)題debug是什么時(shí)候？那次花了多久，最后發(fā)現(xiàn)是什么低級(jí)錯(cuò)誤？