<section>标签本身不定义标题等级，仅作语义分组；文档大纲严格依赖h1–h6的嵌套层级，跳级或缺失标题将导致大纲断裂、SEO弱化及无障碍访问失效。
section 标签本身不定义标题等级
<section> 是语义容器，不是标题元素。它不自带层级权重，也不会在文档大纲中自动产生条目——除非内部包含 <h1> 到 <h6>。浏览器和屏幕阅读器解析大纲时，只认标题标签的嵌套关系，<section> 仅起分组作用。
常见错误现象：<section><p>产品介绍</p></section> 这样的结构不会出现在大纲里，搜索引擎也完全忽略这段“伪标题”。
- 必须配合标题标签使用，例如
<section><h2>产品介绍</h2><p>…</p></section> -
<section>内部可另起<h1>（HTML5 允许），但实际中多数 SEO 工具仍按传统单<h1>规则处理，容易误判主标题 - 多个
<section>并列时，应统一用<h2>开头，而非混用<h1>、<h3>等
文档大纲由 h1–h6 的嵌套深度决定，不是 section 数量
浏览器（如 Chrome 的开发者工具 → “Accessibility” 面板）和 Lighthouse 生成的大纲，完全基于标题标签的顺序与层级跳变。例如：
<h1>年度报告</h1>
<section>
<h2>财务摘要</h2>
<section>
<h3>营收构成</h3>
</section>
</section>
<section>
<h2>研发进展</h2>
</section>
这段会生成清晰的三级大纲；但如果写成 <h1>…</h1><h3>…</h3>，大纲就会断裂——<h3> 被当作“无父级的孤立项”，部分阅读器直接跳过。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 跳级（
<h2>后接<h4>）会导致大纲缺失中间层级，axe 插件会报heading-order错误 -
<section>可以嵌套，但大纲不随嵌套加深而自动降级；降级只由下一个标题标签的级别决定 - 不要依赖
<section>数量来推算标题该用几级——先定逻辑层级，再选<h2>或<h3>
h1 在 section 内部是否允许？要看上下文
HTML5 规范允许每个 <section> 拥有自己的 <h1>，语义上表示“该区块的独立主题”。但现实约束很紧：
- CMS 输出或 SSR 模板中硬塞多个
<h1>，Google 通常只取第一个作为页面主标题，其余被弱化甚至忽略 - 屏幕阅读器 NVDA 和 JAWS 在“标题导航模式”下，可能把所有
<h1>当作同级并列项，破坏原有主次感 - 如果真需要多主题（如仪表盘首页含“订单”“用户”“统计”三个独立模块），更稳妥的做法是：全部用
<h2>，外层用<main>+ 多个<section>明确分隔
检查大纲是否健康，别只看视觉效果
CSS 可以把 <h3> 样式调得比 <h2> 还大，但大纲解析器只读标签名，不读样式。一个看似整齐的页面，大纲可能全是平铺的 <h2>，毫无层次。
- 用 Chrome DevTools → Elements 面板右键节点 → “Copy outerHTML”，粘贴到 W3C Markup Validator 查
outline报告 - Lighthouse 的 Accessibility 审计项里，“Heading levels should only increase by one” 是高频失败项，直接对应跳级问题
- 真实陷阱：某些设计系统组件库把标题封装成
<Heading level={3}>，但渲染后生成的是<div class="h3">—— 这类“假标题”对大纲零贡献
语义结构一旦写错，后期靠 CSS 或 JS 补救不了。标题层级不是排版开关，是文档骨架的钢筋。
