Kubernetes把2空格寫成4空格，整個集群崩了3小時

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

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

縮進是語法，不是風(fēng)格

YAML用縮進表達層級，跟Python一樣。但Python至少會拋IndentationError，YAML parser只會給你一棵歪掉的語法樹。

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

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

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

引號不是裝飾，是防彈衣

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

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

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

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

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

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

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

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

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

錨點與別名：DRY的甜蜜陷阱

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

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

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

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

lint不是可選項，是門禁

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

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

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

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

你最后一次因為YAML格式問題debug是什么時候？那次花了多久，最后發(fā)現(xiàn)是什么低級錯誤？