导读不必强制用，但因其语义上属于与主内容相关却可独立的辅助信息，故在绝大多数场景下最适配；它应置于内而非或中，避免干扰seo与无障碍解析。
文章导读不是装饰性模块，而是语义上可独立识别、机器可解析的“内容摘要入口”。用对标签，才能让搜索引擎抓取到它，也让屏幕阅读器用户一键跳转。
导读必须包裹在 <aside></aside> 里吗？
不是必须，但绝大多数场景下最合适。<aside></aside> 表示与主内容相关但可独立存在的辅助信息——这正是导读的本质：它服务于 <article></article>，但本身不参与正文逻辑流。如果导读混在 <header></header> 里（比如紧贴标题下方），容易被爬虫误判为元数据而非导航线索；若塞进 <nav></nav>，又会干扰主导航权重分配。
-
<aside></aside>内部建议用<h2></h2>或<h3></h3>标明“本文导读”或“目录”，确保出现在文档大纲中 - 避免把整篇摘要文字直接丢进
<aside></aside>——它不是内容容器，而是结构容器；摘要段落仍需用<p></p> - 若页面含多篇文章（如博客列表页），每篇的导读应各自包裹在独立的
<aside></aside>中，而非共用一个
用 <nav></nav> 做目录链接是否更 SEO 友好？
是，但仅限于真实跳转锚点。如果导读是纯视觉锚点（例如点击后 JS 滚动到对应 <section></section>），<nav></nav> 反而有害——因为 <nav></nav> 要求内部链接具备明确导航意图，空 href="#" 或 JS 绑定链接会被算法视为低质信号。
- 真正带
href="#introduction"的锚点链接，放<nav></nav>合理；否则优先用<aside></aside>+<ol></ol>或<ul></ul> -
<nav></nav>内必须有至少两个有效链接，单个“回到顶部”不算合格导航 - 时间戳、作者名等元信息别塞进
<nav></nav>，它们属于<header></header>或<footer></footer>
<details></details> + <summary></summary> 适合做折叠式导读吗？
适合，但仅限移动端或信息密度高的场景。这两个标签天生携带“可交互摘要”语义，比 JS 模拟的折叠更利于无障碍访问——屏幕阅读器会明确播报“摘要已折叠/展开”。
-
<summary></summary>文本必须简洁（建议 ≤12 字），如“展开导读”“查看章节” -
<details></details>内部仍需保持语义层级：标题用<h3></h3>，条目用<ul></ul>，避免嵌套<div> <li>不要在 <code><details></details>外再包一层<aside></aside>——它自身已是语义化容器，双重包裹反而稀释含义 - 典型错误：
<main><h1>如何写语义化HTML</h1> <p>本文将分三部分讲解…</p></main>—— 这段<p></p>是导读，应移出 - 正确结构：
<article><header><h1>…</h1></header><aside><p>本文将分三部分…</p></aside><main><p>第一部分正文…</p></main></article> - 注意：
<main></main>在整页中只能出现一次，但每个<article></article>内可以有自己的<main></main>（不过极少需要）
为什么 <main></main> 里不能直接放导读？
因为 <main></main> 必须只包含对当前页面唯一核心内容的直接表达。导读是“关于内容的描述”，不是“内容本身”。把它放进 <main></main>，等于告诉搜索引擎：“这段文字就是本文主旨”，可能覆盖掉真正的正文关键词权重。
最易被忽略的一点：导读里的所有链接锚点，必须对应正文中真实存在的 id，且该 id 应落在语义化区块内（如 <section id="compatibility"></section>），而不是随意挂在 <div> 上——否则大纲生成失败，屏幕阅读器无法跳转，SEO 也收不到结构信号。</div>
