prettier是工程级html统一规范首选，因其通过.prettierrc强制约束行为、保证跨编辑器输出一致，需配置htmlwhitespacesensitivity:"css"、tabwidth:2+usetabs:false，并结合.editorconfig兜底、ci校验及提交前自动化执行。
统一工程内 HTML 美化工具规范，核心不是选哪个工具，而是让所有人执行同一套规则——否则格式化后反而引发大量 Git 冲突、diff 噪声和协作摩擦。
为什么 Prettier 是工程级首选
VS Code、WebStorm、Sublime Text 都能装 Prettier，但关键在于它用 .prettierrc 文件强制约束行为，不依赖编辑器偏好。团队只要共享同一份配置，prettier --write *.html 在任何机器上输出结果一致。
- 它默认关闭“智能换行”，避免因行宽设置不同导致同一段代码在 A 机换三行、B 机换五行
-
htmlWhitespaceSensitivity: "css"这个参数必须显式设为"css"，否则对<span> </span>类空格敏感标签的处理会出错（比如破坏内联文本间距） - 别用
tabWidth混搭空格缩进：工程里统一设"tabWidth": 2+"useTabs": false，否则有人用 Tab、有人用空格，Git diff 里全是^I
如何让团队真正落地统一规范
光配好 .prettierrc 不够。开发者可能根本没启用“保存时格式化”，或本地插件版本不一致，导致格式化效果偏差。
- 在项目根目录放
.editorconfig，声明indent_style = space和indent_size = 2，作为编辑器底层兜底规则 - 把
prettier --check *.html加进 CI 流水线（如 GitHub Actions 的on: push阶段），失败直接阻断合并 - 提供一键初始化脚本：
npx prettier --write "**/*.html"+ 提交前自动运行，比口头提醒管用 - 禁止在
.prettierignore里随意排除 HTML 文件——例外必须写明原因并经前端负责人审批
Beautify 或 js-beautify 为什么不适合工程统一
它们的配置项命名和语义与 Prettier 不兼容，比如 indent_char vs useTabs，max_char vs printWidth。一旦混用，同一份 HTML 在不同人机器上格式化结果可能完全不同。
-
js-beautify默认对<pre class="brush:php;toolbar:false;"></pre>内容不做缩进，而 Prettier 默认会破坏其原始排版——除非你手动关掉preserveNewlines，但这个选项在 Prettier 里根本不存在 - Sublime 的
HTML-CSS-JS Prettify插件底层调用的是旧版 js-beautify，无法解析现代 Prettier 配置文件，团队里有人用 Sublime、有人用 VS Code 就必然分裂 - 在线工具（如 codebeautify.org）没有配置持久化能力，每次粘贴都要重选缩进/引号/换行策略，无法保证复现
最常被忽略的点是：HTML 格式化不是“美化完就结束”，而是要嵌入到提交前检查和 CI 中。没人检查的规范，三个月后就会退化成各写各的。工具可以换，但 .prettierrc 必须进 Git，且必须被验证执行。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
