一个页面必须有且仅有一个h1作为主语义锚点，h2–h6须严格逐级嵌套，禁止跳级；动态生成标题需对level做parseInt、限幅至1–6；h5/h6极少适用业务场景，应优先用dl或语义化p替代。
h1 必须唯一且承担页面主语义锚点
一个页面 DOM 中出现多个 <h1>，不是“风格问题”，而是语义结构直接失效。搜索引擎和屏幕阅读器会丢失对页面主题的判断依据，Lighthouse 立即报 heading-levels 错误，爬虫可能跳过后续层级解析。
常见翻车点：
- Layout 组件里硬编码
<h1>MySite</h1>，Page 组件又输出一个<h1>订单确认</h1> - SSR 首屏 HTML 为空或加载中状态，
<h1>由 JS 动态插入，爬虫抓到的是无主干结构 -
<title>写的是 “React 性能优化指南”，但<h1>是 “欢迎来到前端性能实验室”，AI 模型会标记该页“意图模糊”
h2–h6 必须严格逐级嵌套，跳级即断裂
不是“建议嵌套”，而是大纲生成算法（W3C Outline Algorithm）的硬性规则：<h2> 后可接 <h2> 或 <h3>，但绝不能直接接 <h4>；<h3> 前必须有 <h2> 或更高层级作为父级。
实际影响比报错更隐蔽：
立即学习“前端免费学习笔记（深入）”；
- Chrome DevTools Accessibility 面板里 heading-level 显示跳变（如 1→2→4），标红但不中断渲染
- Markdown 渲染器（如 remark）把
##编译为<h2>、####编译为<h4>，若源文档漏写###，就直接产出断裂结构 - iOS Safari 等旧环境可能跳过缺失层级的内容区块，用户根本读不到
动态生成标题时 level 参数必须做数值截断与 fallback
Vue/React 里用 props.level 渲染 <h${level}> 很常见，但 runtime 输入不可信——CMS 字段可能是字符串 "0"、"7"，或字段缺失导致 undefined，结果输出 <hNaN> 或直接 JS 报错。
安全写法只有一条路径：
- 强制转整数：
const level = parseInt(props.level) || 2 - 限幅到合法范围：
Math.min(6, Math.max(1, level)) - 最终标签名：
`h${level}`，而非条件判断或三元切换（v-if/{condition ? <h1> : <h2>}</h2> </h1>）——DOM 结构浮动会让 Lighthouse 无法静态分析
h5 和 h6 几乎不该出现在业务页面中
95% 的业务页面（含后台系统、营销页、表单页、详情页）不需要 <h5> 或 <h6>。它们语义是“法律条款末级子项”或“API 参数表细分字段”，不是“小字备注”或“视觉弱化标题”。
真要用，得满足两个前提：
- 内容本身存在四级以上逻辑嵌套（比如：文档 → 章节 → 小节 → 子项 → 细则 → 示例）
- 移动端显式声明
line-height: 1.2，否则 iOS Safari 对<h6>的行高渲染异常
更常见的替代方案是用 <dl> + <dt>/<dd> 表达细粒度定义，或用带语义 class 的 <p> 控制样式——语义不靠标签大小撑，靠结构真实存在。
