XML 缩进风格不统一，为什么会让合并请求与厂商对账同时失控？
同一份厂商模板，运营改两行说明、研发改两行配置，Git diff 却满屏「整文件重写」——点进去发现只是 Tab 与空格、两格与四格、属性换行策略不同。大家搜「xml 缩进 统一」「pretty print 两空格」「与 editorconfig 对齐」是为了在会签技术附件、回传 XSD 实例、同步 Spring XML 样例时，先固定「每层几个空格、属性是否另起一行、文本节点是否保留空白」。缩进统一后再做语义 diff，评审才能把精力放在业务字段上，而不是吵「你为什么要动我空行」。与外包、与多地域团队协同时，把缩进规则写进仓库根配置与 CI 格式化任务，比每次在线手工点一下更可持续；本页适合临时对齐、培训演示与应急对屏，黄金版本仍以流水线输出为准。若厂商交付物强制 Tab 而内部规定空格，可在入库网关做一次性格式转换并写审计日志；在线页只证明可读等价，真正写入主仓仍以批处理脚本为准，避免人手反复点出多版本。对跨地域外包，把「缩进与换行策略」写进接口手册附录，比会后再开语音对齐更有效。
如何在团队与厂商之间统一 XML 缩进策略并减少假大 diff
- 在仓库添加 editorconfig 或 XML 专用格式化配置，明确禁止 Tab 与空格混用；粘贴原文前先粘到纯文本区显示空白，发现制表符时按规则整体替换再进工具。
- 选择团队约定的每层空格数与属性换行策略，执行统一缩进后抽样比对关键文本节点是否被意外规范化；对 xml:space="preserve" 区域要单独走查，避免破坏排版敏感内容。
- 将输出与 CI 或官方 pretty-print 命令结果做哈希或 diff 抽检，再提交 MR；对厂商回传文件若对方强制不同风格，应在接口手册设立「inbound 规范化与 outbound 原样」双通道，避免互相覆盖。
XML缩进常见问题
团队有人坚持属性同一行、有人坚持每个属性换行，统一缩进会不会让其中一方在 code review 里反复拒合并、我们该如何投票定规？
应由架构或平台组发布唯一《XML 书写规范》并给迁移窗口；属性换行影响可读性与 diff 噪音，需书面取舍。临时争议可统计历史 MR 冲突成本数据，用数据说服而不是凭个人审美否决。
统一缩进后数字与文本之间的普通空格被合并，导致财务金额展示少了一个千分位空格，这种风险是工具问题还是我们不该对含金额的文本节点做空白规范化？
金额应以 XSD 小数类型或独立元素表达，不应依赖普通空格排版；若必须保留视觉空格，应使用 xml:space 保留或非断行空格并写入规范。发现此类问题要回到数据模型层修，而不是关掉全文件格式化。
我想把缩进从四空格改成两空格以适配前端仓库，但 XSD 校验与签名都过了，是否仍可能触发下游 XSLT 行号敏感逻辑？
XSLT 若依赖绝对行号是脆弱设计，应推动改为 XPath 定位；若短期无法改，应在变更说明标注风险并做回归。缩进变更仍建议走小步合并与灰度观察，而不是一次性全仓重写。
厂商样例使用 CRLF 而我方仓库使用 LF，统一缩进后 diff 仍显示整文件变更，有没有行业通行的换行符治理做法？
应在 Git 配置与 pre-commit 统一 eol=lf 或按语言例外；对厂商 inbound 可在网关转换后再入库。把「换行符策略」写进集成手册，避免评审把 CRLF 差异误判为业务修改。
超大 Spring 上下文 XML 在浏览器统一缩进会卡死，是否说明此类文件只能走 IDE 或命令行，本页只适合小片段演示？
是。大文件应使用带增量解析的本地工具或拆分模块；网页适合截取 bean 定义片段做评审。若必须全量处理，请在非生产机分批执行并监控内存，同时遵守公司关于大文件外发的合规要求。