Ansible Playbook 缩进一错，为什么日志里只剩一句 YAML 解析错误却找不到行号？
交付自动化时，play、hosts、vars、tasks、handlers、roles 多层嵌套，再夹 Jinja2 条件与循环，复制粘贴最容易把列表项短横线挤出同一列，ansible-playbook 直接报「mapping values are not allowed here」。甲方验收、内部运维接班、外包回传补丁，大家都希望打开文件就能分清「哪块管执行、哪块管变量、哪块管通知」。大家搜「ansible yaml 格式化」「playbook 缩进」「roles 目录 yml 整理」是为了在跑 ansible-lint 与 Molecule 前先用人眼扫清结构，减少「模板渲染后才爆」的无效迭代。vars_files 与 vault 加密串若与 tasks 同级错位，会导致变量悄悄变成空字典，运行时行为与评审材料不一致。含 ansible-vault 的密文不应贴公共网页；请先用占位符或解密后的脱敏副本排版，再在受控环境用 vault encrypt 回写。include_tasks、import_role、block、rescue、always 五类结构里，一旦 rescue 与 tasks 列表缩进错位，失败回滚逻辑会悄悄失效，值班手册却写「已配置自动回滚」——这不是 Ansible 本身玄学，而是 YAML 与人眼对齐的博弈。在 Ansible Tower 或 AWX 里点语法检查前，先用本页把 rescue 与 always 块摊平，能减少日志里只剩 Python traceback、却没人敢改行的黑盒感。把「先排版再 ansible-playbook --syntax-check」写进交付 checklist，夜班交接就少一句「谁改的最后缩进」这种无法取证的对骂，新人第一次合仓库也能在提 MR 前自检。
如何把 Playbook 与 role 片段整理到可跑 ansible-lint 的可读结构
- 粘贴前区分「静态 YAML」与「含 Jinja 的模板」：后者应先在被控端或本地用 ansible-playbook --syntax-check 能接受的最小 inventory 渲染，再对渲染结果排版；不要把未渲染模板误当纯 YAML 强转。
- 格式化后检查 tasks 列表、handlers 列表与 role: 调用的缩进是否仍在 play 子树内；when、loop、become 等关键字是否挂在 task 项下而非误升到 play 顶层。
- 将整理稿合入仓库前，在 CI 跑 ansible-lint 与一次 check 模式；涉及 privilege escalation 的任务在评审表里单独勾选，vault 文件仍只走加密通道与最小权限账号。