语义化是dom结构的强制前提，因搜索引擎和屏幕阅读器只解析标签本义而非class名；如明确定义导航、要求全页唯一、须可独立分发，错误使用将导致seo降权、无障碍失效及ci阻断。
现代前端规范不是“推荐”语义化标签，而是把语义化当作 DOM 结构的强制前提——没有它，工程化、无障碍、SEO 和跨端协作都会在底层失稳。
为什么搜索引擎和屏幕阅读器不认 class 名，只认 <header></header> 这类标签
爬虫和辅助技术解析 HTML 时，完全忽略 CSS 类名、ID 和样式，只依赖标签本身的语义定义。比如：<nav></nav> 被 W3C 明确定义为“一组导航链接”，<main></main> 要求页面中唯一且包裹核心内容，<article></article> 表示可独立分发、有明确作者和时间的信息单元。
这些约束是浏览器原生行为的基础：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- Chrome 的“跳转到主内容”快捷键（
Ctrl+Alt+I）直接定位<main></main>，不是靠 JS 模拟 - Lighthouse 的 a11y 审计项会报错
<main> must be unique</main>，无法用div role="main"规避 - Google Search Console 把
<article></article>内的<time datetime="2026-08-25"></time>当作发布时间信号，而<span class="date">2026-08-25</span>不会被识别
<section></section> 和 <article></article> 的边界在哪，乱用会导致什么问题
二者不是视觉分组工具，而是语义职责划分：
-
<section></section>必须有标题（<h2></h2>或更高级），表示逻辑上自成一章的内容，比如“商品参数表”“用户评价区” -
<article></article>是完整、独立、可复用的内容实体，自带发布上下文，例如一篇博客、一条评论、一个商品卡片 - 错误用法：
<section></section>包裹单个按钮、<article></article>套<div class="card"> —— 这会让 Lighthouse 报 <code>Section does not have heading或触发 ARIA 校验失败 - 后果：SSR 页面首屏 SEO 权重被稀释；微前端子应用焦点管理失效；自动化文档生成器把侧边栏误标为“主内容”
- Vue SFC 中写
<div class="nav">，即使绑了 <code>@click，屏幕阅读器仍读作“div”，不会提示“导航栏”或支持快捷跳转 - React JSX 中用
<div role="navigation"> 属于冗余补救，违反 eslint-plugin-jsx-a11y 规则 <code>jsx-a11y/role-has-required-aria-props - 构建工具链（如 vite-plugin-checker）会基于语义结构做静态分析，
<main></main>缺失或重复直接阻断 CI 流程 - 团队 Code Review 时，
<header></header>误嵌套在<article></article>内比 class 名拼错更容易发现和统一修复
Vue/React 组件模板里写 <div class="header"> 为什么比 <code><header></header> 更危险
框架编译后输出的是真实 DOM，语义错误不会被框架拦截或修正：
真正容易被忽略的点在于：语义化不是“加一层标签”，而是对内容职责的判断。一个商品卡片该用 <article></article> 还是 <section></section>，取决于它是否具备独立传播性（比如能被 RSS 抓取、能单独分享链接）——这个判断一旦出错，后续所有工程化手段都在给错误结构打补丁。
