html格式化是防止协作崩坏的底线，非锦上添花；不格式化会导致定位困难、修改成本升高、git diff失效、merge失败或静默覆盖，必须统一tabwidth、htmlwhitespacesensitivity、endofline三项硬规则。
HTML格式化不是“锦上添花”，而是防止协作崩坏的底线
不格式化的HTML代码，三个月后连你自己都难定位一个div是不是该删——它不是“看起来乱一点”，而是直接抬高修改成本、放大合并冲突、让git diff变成猜谜游戏。团队里只要一人不格式化，所有人就得在git status里手动过滤空格变更；多人并行改同一块模板时，缩进混用（空格+Tab）、属性顺序错乱、标签挤成一行，会直接导致merge失败或静默覆盖。
哪些场景下不格式化会立刻出问题
以下情况一旦跳过格式化，当天就能触发真实故障：
- 多人协作修改
index.html中的<header></header>区域：A用4空格缩进，B用2空格+Tab混排，C把data-module和class写反顺序——Git无法智能合并，冲突块全是空白符 - 用
emmet快速生成结构后直接提交：ul>li*3产出的<ul> <li>...</li> <li>...</li> </ul>没换行没缩进，后续加id或data-属性时极易漏闭合或错层级 - 从线上页面“查看源码”复制片段进项目：原始HTML常是压缩态（无换行、无缩进），直接粘贴会导致本地
.prettierrc规则失效，且eslint-plugin-html校验报错 - CI流水线中启用
prettier --check但本地未配置保存自动格式化：PR被拒原因显示expected 2 spaces but found 4，却没人知道哪行出的问题
必须统一的三项硬规则，否则格式化等于白做
只装Prettier不够，关键在收敛行为边界：
-
"tabWidth": 2：强制2空格，禁用Tab——不同编辑器对Tab宽度解析不一致，vim和VS Code混编时极易错位 -
"htmlWhitespaceSensitivity": "css"：避免因空格敏感性误删<span>文字</span> <span>文字</span>中间空格被吃掉） -
"endOfLine": "lf"：统一行尾为\n，Windows开发机若设为crlf，在Linux部署机上可能触发Nginx 404（某些旧版静态服务对行尾敏感）
格式化不是终点，是每次修改的起点
真正卡住项目进度的，从来不是“要不要格式化”，而是“谁来保证每次git commit前都执行了”。本地prettier --write手敲太随意，必须靠husky配pre-commit钩子自动跑；但更关键的是，要接受一个事实：格式化修复不了语义混乱——<div class="card-wrapper-inner-container">再整齐，也比不上一个<code><article class="product-card"></article>。结构清晰比缩进漂亮重要十倍。
