语义化html的核心是让标签承担协议角色而非仅视觉功能：h1是主主题声明，article是可独立分发的内容单元，main是唯一主内容锚点，错误使用会导致seo降权、无障碍导航失效和机器解析偏移。
因为“能用 Googlebot 等现代爬虫已深度支持语义化解析，但它们不会猜类名。当你写 常见错误现象： 辅助技术（AT）依赖原生语义做快捷导航： 容易踩的坑： 使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。 性能影响很小，但可访问性断点极大：一个没 关键判断依据就一条：能否脱离当前页面独立存在、被单独链接或订阅？ 适用场景对比： 误用后果：SEO 权重被错误切片，AT 导航出现冗余入口， 最常被忽略的其实是 为什么搜索引擎会跳过你的
却给一个
<div class="title">产品详情</div>，它只看到一个无角色的容器；而 <h2>产品详情</h2> 会被直接映射为“二级标题”并参与内容权重计算。
<span></span> 包裹整个文章标题，只为了加个颜色<div id="nav">，却不加 <code><nav></nav>
<article></article> 被漏掉了，只留了一堆 <div class="post">
<p>真正起作用的不是“用了新标签”，而是“让每个标签承担它该有的协议角色”。<code><h1></h1> 不只是最大号字体，它是整页唯一主主题声明；<article></article> 不只是视觉卡片，它自带可独立分发、可被聚合器识别的语义契约。
屏幕阅读器用户按“R”键想跳到
<main></main>，结果卡在<main></main> 对应“跳至主内容”，<nav></nav> 对应“列出所有导航区”，<aside></aside> 对应“读取相关补充信息”。这些不是靠 ARIA 补出来的，是浏览器内置的无障碍 API 映射。
<main></main> 嵌套在 <section></section> 或 <article></article> 内 —— 这会让 AT 认为“这个区块 = 全页主内容”，忽略真实导航和页脚<div role="button"> 替代 <code><button></button>，却忘了加 tabindex="0" 和 onkeydown 处理回车/空格
<aside></aside>，但它既不关联主内容，也不提供补充信息，纯属干扰项<main></main> 的页面，对键盘用户来说可能需要 Tab 47 次才能摸到正文。
<section></section> 和 <article></article> 的边界到底在哪
<article></article>：博客正文（有独立 URL）、新闻稿（可被 RSS 抓取）、用户评论（带作者、时间戳、可复用）<section></section>：“技术参数”小节（依赖上文产品标题）、“售后政策”模块（仅在此页上下文有意义）<article></article>：轮播图每张图（无独立 ID/URL）、商品 Grid 中每个卡片（除非点击后跳转详情页且有自洽标题）<article></article> 嵌套 <article></article> 会让聚合器困惑——它不知道哪个才是“原子内容单元”。<main></main> 的强制约束：它必须且只能出现一次，且不能是 <header></header>、<footer></footer>、<nav></nav>、<aside></aside>、<section></section> 的子元素。这不是规范洁癖，是机器解析时的结构锚点——一旦松动，所有依赖它的协议（爬虫索引、AT 导航、Lighthouse 评分）都会偏移。
