为什么选择 Ai2Done YAML 格式化工具？
GitHub Actions、GitLab CI、Argo CD、Helm values、Spring Boot 的 application.yml、Docker Compose、Kubernetes Deployment 与 Ingress——白领日常接触的配置几乎都用 YAML 写「给人看的树」。真正折磨人的不是键名，而是缩进：同级键差一个空格，解析器就把子树挂到上一层，线上才暴露端口监听错、健康探针没挂上、环境变量整块落空。大家常搜「yaml 在线格式化」「yml 缩进对齐」「ci 配置美化」是为了在评审会、变更单和 IM 里把结构摊平。Ai2Done 在浏览器侧统一空格层级、规范冒号后空格与列表短横线对齐，让你和研发做 diff 时只看业务改动，而不是被满屏跳动的空白分心。先格式化再比对，还能显著减少从表格、富文本、飞书文档往返粘贴时常见的锚点丢失、合并键断裂与多文档分隔符三类隐性损坏。含数据库口令、对象存储密钥、内网地址的片段务必先脱敏；剪贴板与会话同样是暴露面，处理完请清空输入区。很多人检索「gitlab-ci.yml 美化」「github actions yaml 校验」「spring boot application.yml 缩进」是在提合并请求前自检：工作流里的 if、env、uses 是否仍挂在 job 子树，而不是被 IM 里复制的空格挤到顶层。把本页当作合并前的排版缓冲区，能少一次把「表格里的制表符」误判成流水线脚本本身写错。
如何在浏览器里完成 YAML 在线格式化并与研发对齐 diff
- 打开「YAML 格式化」，将完整片段粘贴到输入区；若来自 IM 或 Wiki，先粘到纯文本编辑器检查是否被插入软换行、全角冒号或 Tab 与空格混用，再决定是否手工统一缩进宽度后提交解析。
- 执行格式化后自上而下扫一遍：映射与序列的层级是否连续、列表项短横线是否同一列、多文档是否仍被「---」正确分隔；若报错，优先对照报错行号检查少空格、多缩进或字符串未闭合，而不是反复整段重贴。
- 将输出复制到 Git 分支、工单或评审纪要前，与对端各保留一份「格式化后基线」再做二次编辑；涉及生产发布的文件仍需走 kubectl dry-run、流水线校验或配置中心审批，本页产出只降低阅读成本不替代变更闸门。
YAML 格式化常见问题
同事说格式化只是动空白，可我担心排序键或重写换行会悄悄改变线上语义，YAML 美化结果到底能不能直接当发版稿提交？
标准格式化应以「解析树不变」为目标，只调整缩进、换行与可选的键序；若工具提供键排序且你们仓库未约定稳定顺序，提交前必须与研发确认并在 MR 里标注，避免把纯排版 diff 混进业务变更。发版前仍建议用集群或流水线自带的 schema、策略校验跑一遍，把本页当作阅读与对齐工具而非唯一门禁。
从飞书或企业微信复制整段流水线 YAML 后，工具一直报缩进错误，但肉眼看每行都对齐，这种「隐形错位」最常见该怎么自查？
多为前导空格被换成不间断空格、制表符与空格混用、或列表项里夹了零宽字符；用十六进制视图或「显示空白」功能逐行比对前导列。修复后先在本地用同一缩进宽度全选重排，再进格式化器，比在群里发截图让同事肉眼数空格更快。
一个文件里有多段「---」分隔的文档，在线 YAML 格式化会不会把多文档粘成单文档或打乱顺序，从而影响 Helm 或 Kustomize 的叠加逻辑？
是否保留多文档取决于解析器与工具实现；若输出合并成一段，应按分隔符手工拆回多段再分别格式化，或在仓库里保持上游生成器的原始结构。对 Helm 这类「模板渲染后再校验」的链路，务必对渲染结果而不是未渲染模板做最终排版，以免把 Go template 指令误当成 YAML 键。
我想把含内网主机名与测试账号的 values 贴进页面排版，公司安全说浏览器本地处理也不行，这类敏感 YAML 有没有最低风险的用法？
最低风险仍是先替换为占位符与假端口再粘贴，并在独立浏览器配置文件中操作、结束后清空输入与历史；不要在投屏会议中打开含真实凭据的文件。若制度禁止任何网页接触业务配置，请改用内网离线工具链，本页仅适合脱敏样例与公开脚手架。
同一仓库里有人用两空格有人用四空格，格式化后会不会和 Prettier、editorconfig 冲突导致 CI 又打回？我们应该以仓库里落地的 editorconfig 与 CI 脚本为唯一真相，还是允许个人习惯与在线工具输出并存？
应在仓库根写明 indent 规则并让本地编辑器与 CI 使用同一格式化器；在线结果若与流水线不一致，以流水线为准回写团队模板。可把本页输出当作「临时对齐稿」，合并前再用项目脚本统一一遍，避免个人习惯与团队门禁互相打架。