关于HTML文档大纲生成的深度解析_掌握h1至h6标签的层级运用-html教程-PHP中文网

chrome devtools中验证heading-level是否合法，需打开accessibility面板→右键标题节点→“reveal in accessibility tree”，检查heading-level是否连续无跳变；常见错误包括多h1、h1后直连h4、首屏无h1仅js插入。

关于html文档大纲生成的深度解析_掌握h1至h6标签的层级运用

HTML文档大纲不会自动“长出来”，它只按W3C Outline Algorithm严格推导；跳级、多h1、首屏无h1都会导致大纲断裂或为空，不是样式问题，是结构解析失败。

Chrome DevTools里怎么验证heading-level是否合法

别只看页面渲染效果——打开 Chrome DevTools → 切换到 Accessibility 面板 → 右键任意标题节点 → 选择 Reveal in Accessibility Tree，观察其 heading-level 属性值是否连续、有无突变（比如从 2 直接跳到 4）。

常见错误现象包括：

同一页面出现两个 heading-level: 1 节点（多h1）
h1 后紧跟 heading-level: 4（跳级）
首屏 DOM 中没有 h1，但 JS 后续插入了（SSR未输出，爬虫抓不到）

命令行快速筛查：curl -s URL | grep -o '<h>，输出应为 <code>h1、h2、h2、h3……不能出现 h1 后直接 h4。

React/Vue中动态渲染的三个硬性约束

用 props.level 渲染 <h></h> 很常见，但 runtime 值不可信，必须加三重防护：

数值范围强制截断：const level = Math.min(6, Math.max(1, parseInt(props.level) || 2))
禁止传入字符串 "0"、"7" 或 undefined，否则可能产出 <hnan></hnan> 或直接报错
组件库中的卡片、弹窗、侧边栏等复用单元，禁止硬编码 h1；若需语义标题，统一 fallback 到 h3 并配 aria-labelledby

特别注意：Vue 的 v-html 或 React 的 dangerouslySetInnerHTML 若拼接标题标签，level 字符串拼错一个数字（如写成 "h7"），就生成非法标签，浏览器虽不报错，但大纲提取器会忽略或中断解析。

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

为什么
包裹能修复“多个h2并列却无法形成独立区块”的问题

section 是 sectioning root，它会重置内部 heading 的隐含层级边界。没它时，两个 h2 只是大纲里的兄弟节点；加了 section，每个 h2 就变成各自区块的顶层标题，且能被屏幕阅读器识别为可跳转单元。

典型场景：

产品页里“规格参数”和“用户评价”都用 h2，不包 section → 大纲里只是平级两节点
加上 <section><h2>规格参数</h2>...</section> 和另一组 → 它们各自成为独立子树根节点
此时每个 section 内部可重新从 h1 开始计层（语义上等价于 h2），但不会干扰全局层级

没 section 时，h3 必须严格跟在 h2 后才表示从属；有 section 后，h3 可以作为该区块内最高标题使用——这是解决“逻辑同级但需语义隔离”的唯一标准方式。

h5和h6几乎不该出现在大多数项目中

95% 的业务页面不需要 h5 或 h6。它们语义是“最末级标题”，不是“小号文字”。真要用，优先考虑 dl、带语义的 class 或 aria-label，而非强行塞进标题流。

真实适用场景极少，仅限：

法律条款文档（条款→子款→项→目→点）
API 参数表（接口名→请求参数→字段名→类型→说明→示例）
极细分的技术白皮书（章节→小节→子小节→技术点→配置项）

更关键的是：浏览器默认 h6 行高异常（尤其旧版 iOS Safari），且所有标题默认 margin 不一致，建议项目起步就重置：h1, h2, h3, h4, h5, h6 { margin: 0; font-weight: normal; line-height: 1.2; }。视觉上 h6 比 h1 还大也没关系，只要 DOM 结构没乱，机器就能读对。