浏览器根据<h1>到<h6>的嵌套位置和顺序自动推导文档大纲，<section>等sectioning root可重置内部标题层级，跳级写heading（如<h2>后直接<h4>）会导致语义断裂；需用Chrome DevTools Accessibility面板验证。
浏览器怎么生成文档大纲
浏览器不靠人工编号或目录生成大纲，而是严格按 <h1> 到 <h6> 的嵌套位置和顺序自动推导层级。这个大纲直接决定屏幕阅读器的“M 键跳转”路径、Safari 的页面缩略图导航，甚至 Google 对内容权重的判断。
关键规则有两条：<section>、<article>、<nav>、<aside> 是 sectioning root，它们内部的 <h1> 会被重置为该区块顶层标题；而跳级写 heading（比如 <h2> 后直接 <h4>）不会报错，但会让大纲断裂——浏览器仍按数字顺序硬推层级，语义却完全脱节。
- 常见错误：主内容区用
<h2>开头，但页头塞了三个<h1>，导致大纲根节点漂移 - 验证方式：用 Chrome DevTools 的 “Accessibility > Document Outline” 或 Firefox 的 “Inspector > Accessibility > Outline” 实时查看，别信肉眼数标签
- 性能影响：大纲断裂本身不拖慢加载，但会让屏幕阅读器反复回溯 DOM 寻找逻辑起点，语音响应延迟明显
为什么必须用 sectioning root 包裹逻辑区块
仅靠 heading 标签无法表达“同级并列内容块”。比如产品页里“参数详情”和“用户评价”两个 <h2>，若都放在 <main> 下，大纲里只是两个兄弟节点；但各自用 <section> 包裹后，每个区块获得独立上下文，其内部 <h3> 自动重算为子级，且能被辅助技术识别为可跳转单元。
- 滥用
<section>的典型场景：<section><p>欢迎关注我们</p></section>—— 没标题、不可分发、无结构意义 - 判断标准：这块内容是否自带
<h2>–<h6>？能否被 RSS 抓取？是否属于已有语义范畴（如页脚用<footer>）？ - SEO 影响：Google 参考大纲评估内容权重，节点泛滥或层级断裂会弱化主内容识别，尤其对长网页的段落权重分配影响显著
如何修复长网页常见的大纲断裂问题
长网页最容易在滚动区域、Tab 切换面板、动态加载区块出现大纲断裂。核心是避免“视觉优先”的 heading 写法，坚持“结构先行”。
立即学习“前端免费学习笔记（深入）”；
- 禁止从
<h2>开始：全页第一个 heading 必须是<h1>，且唯一；后续所有 heading 必须严格递进或由 sectioning root 重置 - Tab 面板处理：每个
<section>用<h2>做标题，内部用<h3>；不要把所有 Tab 内容堆在同一个<div>里再统一用<h3> - 动态内容注入：用
DocumentFragment插入新区块时，确保包裹<section>并带合法 heading，别直接 appendChild 一堆<p>和<h4> - 工具链检查：在 CI 中加入 axe-core 或 pa11y，配置 rule
heading-order和region，自动拦截大纲异常
容易被忽略的细节：无标题 section 和 main 的陷阱
<section> 没 heading 仍会出现在大纲中，显示为“无标题”，对屏幕阅读器用户是纯噪音；<main> 若包裹非核心内容（如广告、侧边栏），会导致辅助技术跳过真正正文。
- 常见坑：
<main>里塞了顶部 banner + 左侧菜单 + 内容区；Next.js 布局组件写一个<main>，子页面又渲染一个 - 正确做法：全 DOM 中仅一个
<main>，且只包含用户真正要操作/阅读的部分（如商品列表、表单主体、文章正文） - 最隐蔽的问题：小节用了
<h3>，但主内容还没出现<h2>—— 这会让大纲根节点悬空，长网页滚动到中段时，屏幕阅读器彻底失去上下文锚点
