Prettier 的 htmlWhitespaceSensitivity 必须设为 "css" 而非 "strict"，否则会因空白敏感导致 DOM 结构变化、布局错位；.editorconfig 与 prettier 缩进需严格对齐；Git Hooks 应强制格式化而非仅校验；CI 中 prettier --check 必须比对 origin/main。
prettier 配置必须覆盖所有团队成员的编辑器行为，否则格式差异会直接在 Git diff 里爆炸式出现——这不是风格偏好问题，而是每次合并都可能触发冲突的工程风险。
为什么 prettier 的 htmlWhitespaceSensitivity 不能设为 "strict"
设为 "strict" 会让 Prettier 把 HTML 中所有空白字符（包括换行、缩进、空格）都视为语义的一部分，结果是：原本写在一行的 <div class="header">
<h1>标题</h1>
<nav>...</nav>
</div> 被强制拆成多行，而某些模板引擎（如 Nunjucks、Handlebars）或 SSR 框架（如 Next.js 的 getStaticProps 渲染）对空白敏感，会导致 DOM 结构意外变化或布局错位。
真实踩坑场景：
- Vue SFC 中
<template>内联写法被格式化后多出换行，触发display: inline-block元素间默认间隙 - PHP include 的 HTML 片段因空格被重排，导致
trim()后首尾内容丢失
建议统一设为 "css"：它把空白当作 CSS 渲染上下文处理，既保留可读性，又不破坏语义。配置项必须显式写入 .prettierrc，不能依赖默认值。
立即学习“前端免费学习笔记（深入）”；
editorconfig 和 prettier 的缩进规则必须完全对齐
VS Code 用户常忽略一点：editorconfig 控制的是编辑器“输入时”的行为（比如按 Tab 键插几个空格），而 prettier 控制的是“保存时”的输出结果。两者若不一致，会出现诡异现象：你手动敲了 4 个空格，保存后被 prettier 改成 2 个，下次打开文件又因 editorconfig 自动转成 4 个——Git 提交记录里全是无意义的空格变更。
必须同步以下三项：
-
.editorconfig中[*.html]块的indent_size = 2 -
.prettierrc中"tabWidth": 2且"useTabs": false - VS Code 设置中禁用
editor.detectIndentation，防止编辑器自动覆盖.editorconfig
新成员入职第一件事不是看 Wiki，而是拉下代码、打开项目、确认右下角状态栏显示 Spaces: 2 —— 这才是生效信号。
Git Hooks 必须拦截未格式化的 HTML，而不是仅“提醒”
用 Husky + lint-staged 时，常见错误是把命令写成 prettier --check 然后靠 CI 报错来卡住合入。这等于把质量防线建在远端，本地提交已污染历史。
正确做法是预提交钩子直接改写文件：
- 在
package.json中定义脚本："format:html": "prettier --write \"src/**/*.html\" \"templates/**/*.html\"" - Husky 的
pre-commit钩子调用lint-staged，而lint-staged配置匹配*.{html}并执行该脚本 - 关键：不加
--quiet，让开发者看到哪些文件被重写了；失败时进程退出码非 0，强制中断提交
这样做的效果是：没人能“忘记格式化”，也没人能“先提交再修复”。格式即契约，不是可选项。
CI 流程里 prettier --check 要比对的是 origin/main，不是当前分支
很多团队在 GitHub Actions 或 GitLab CI 里简单跑 prettier --check .，结果发现 PR 合并前检查总通过，但合入后主干却报错——因为 --check 默认检查工作区全部文件，而 PR 构建环境只 checkout 当前分支变更，漏掉了其他文件可能已被他人修改但尚未格式化。
真正可靠的检查方式是：
- 在 CI 中明确指定比对基准：
prettier --check \"$(git diff --name-only origin/main -- '*.html')\" - 或者更稳妥地，用
git diff origin/main...HEAD --name-only -- '*.html'获取本次 PR 引入的所有 HTML 变更路径 - 如果返回空（即无 HTML 文件变更），跳过检查；否则只校验这些路径
否则，CI 就只是个装饰品。真正的防线不在提交那一刻，而在 PR Diff 页面上一眼就能看出格式是否合规。
复杂点在于：HTML 格式化不是独立动作，它和模板语法、构建流程、甚至部署后的 DOM 解析深度耦合。一个 prettier 配置项改错，可能要花半天排查为什么某个按钮点击区域变小了——那往往不是 CSS 问题，而是格式化后多出来的换行被解析成了文本节点。
