HTML代码排版直接影响协作效率、可访问性验证及CSS选择器准确性；pre/textarea需禁用Prettier缩进以保原始换行语义，class属性应按component-modifier-state-hook顺序书写，<main>缺失报错源于DOM结构错误而非缩进问题。
HTML代码排版不是“看着顺眼就行”，而是直接影响协作效率、可访问性验证通过率，以及后续 CSS 选择器是否容易写对。缩进错一位、标签没闭合、属性顺序混乱，这些看似小问题，在多人协作或长期维护时会快速放大成 debug 成本。
用 Prettier 自动格式化 HTML 时为什么 pre 和 textarea 里的换行会崩？
Prettier 默认把所有 HTML 节点按块级/内联规则统一缩进，但 pre 和 textarea 的内容是“原始文本”，其内部换行和空格具有语义，会被浏览器原样渲染。Prettier 若强行缩进其子内容，就会破坏显示效果。
- 解决方法：在
pre或textarea外层加注释标记，告诉 Prettier 跳过 —— 例如<!-- prettier-ignore --><pre>...</pre> - 更稳妥的做法：把长文本抽离为 JS 变量或外部文件，用
textContent动态注入，避免混在 HTML 源码里 - 别依赖 Prettier 处理含大量换行的模板字符串；它不是为这类场景设计的
class 属性值顺序混乱导致 CSS 覆盖失效怎么办？
当多个 class 同时作用于一个元素（如 class="btn btn-primary is-loading"），CSS 优先级只看选择器权重，不看 class 在属性里的书写顺序。但人眼阅读时，顺序混乱会让开发者误判样式来源，尤其在调试 BEM 命名（如 card__header--large）时容易漏掉修饰符。
- 推荐固定顺序：
component-name→component-name--modifier→is-state→js-hook（如button button--primary is-disabled js-button-submit） - 不要把
js-类和功能类混写，否则别人删 class 时可能误删行为绑定 - 用 ESLint 插件
eslint-plugin-html+ 自定义规则可静态检查 class 顺序，比肉眼靠谱
为什么 <main> 标签缩进后浏览器不报错，但 Lighthouse 仍提示“main 缺失”？
<main> 是语义化标签，不是排版装饰。它的存在与否由 DOM 结构决定，和缩进无关。Lighthouse 报这个错，是因为页面中根本没出现 <main>，或者出现了多次（规范要求只能有一个），又或者被包在 <article>、<aside> 等不允许嵌套的标签里。
立即学习“前端免费学习笔记（深入）”；
- 检查是否误写成
<main/>（自闭合写法无效）或拼错为<mian> - 确认没有在
<header>或<footer>内部又套了一个<main> - 如果页面确实无主内容（比如纯表单页、404页），可用
<main aria-hidden="true">显式声明，但需同步加role="application"等辅助说明
最常被忽略的其实是空格本身：HTML 中连续空白字符（空格、制表符、换行）会被浏览器合并为单个空格，所以靠缩进“模拟段落间距”毫无意义；真正控制视觉留白的，永远是 CSS 的 margin 和 padding。写 HTML 时只管结构清晰，别试图用回车和空格去“调样式”。
