HTML语义化标签是现代前端工程的基础设施，直接影响SEO、无障碍访问、框架协作等；如<main>确保爬虫准确识别核心内容，<nav>被识别为导航容器，<time>支持结构化数据，<header><aside>等原生标签提供屏幕阅读器可靠导航依据。
HTML语义化标签不是“写得更规范一点”的可选项，而是现代前端工程运转的基础设施——没有它，SEO、无障碍、框架协作、自动化检测、跨端渲染都会在你看不见的地方持续掉链子。
搜索引擎为什么只信 <main> 不信 class="content"
爬虫不解析 CSS 类名，也不读注释，只依赖原生标签语义做内容权重判断。<main> 被明确要求“每个页面仅出现一次”，且必须包裹核心内容；而 <article> 内容会被单独索引为可分发单元（比如 RSS 抓取或 Google News 收录）。如果你用 <div class="main-content"> 替代，爬虫就只能靠位置、字体大小、链接密度这些弱信号去猜——结果就是关键内容不被收录，或者被误判为广告区块。
-
<h1>必须出现在<main>内才构成有效标题层级，否则 Lighthouse 会报“标题结构不合法” -
<nav>是唯一被爬虫识别为“导航链接集合”的容器，<div role="navigation">属于冗余写法，ESLint 插件eslint-plugin-jsx-a11y会直接拦截 - 使用
<time datetime="2026-08-25">而非纯文本“2026年8月25日”，能让 Google 搜索结果直接显示结构化时间戳
屏幕阅读器跳不过 <header>，但会彻底忽略 <div id="top-bar">
视障用户按 Ctrl+Shift+H（NVDA）或 VO+U（VoiceOver）调出区域列表时，依赖的是原生标签名，不是 class 或 ID。一个没用 <header> 的顶部区域，哪怕加了 role="banner"，也大概率不会出现在快捷导航菜单里——因为 banner 是 ARIA 角色，而 <header> 是原生语义，前者需要手动维护，后者浏览器自动绑定。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
<main>是唯一能触发“跳至主内容”快捷键的原生标签，<div role="main">在部分旧版 iOS VoiceOver 中完全无效 -
<aside>内容默认被屏幕阅读器标记为“辅助信息”，用户可选择跳过；而<div class="sidebar">会被逐字朗读，打断主流程 - 嵌套错误会直接破坏导航：比如把
<nav>放在<footer>里，某些阅读器会认为这是“页脚内的导航”，而非全站主导航
Vue/React 组件模板里写 <section> 比写 <div class="card"> 更省事
语义标签天然带逻辑边界，不需要靠 class 名强行约定模块职责。在 Vue 的 <template> 或 React 的 JSX 中，一个 <section> 就是视觉+语义+可测试性的三重锚点——它既是样式作用域的自然分隔，也是 Cypress 测试中 cy.get('section').should('have.length', 3) 的稳定选择器，更是微前端沙箱里 <main> 焦点管理的依据。
立即学习“前端免费学习笔记（深入）”；
- 用
<article>包裹新闻卡片，组件文档生成器可自动标注“独立内容单元”，无需额外 JSDoc 注释 - SSR 渲染时，
<main>内容会被搜索引擎优先抓取，比等 JS 加载完再 hydrate 的<div id="app">更早获得 SEO 权重 - 团队 Code Review 时，“是否误用
<section>包裹单个按钮”比“class 命名是否符合 BEM”更容易达成一致——语义错误是客观事实，命名偏好是主观判断
最容易被忽略的一点：语义化不是一次性编码动作，而是持续校验过程。Lighthouse 的 a11y 审计、CI 中的 axe-core 扫描、甚至浏览器 DevTools 的“Accessibility”面板，都只认原生标签结构。你写对了 <nav>，不代表它就真起作用——如果里面塞了 27 个 <div onclick> 而不是 <a>，整个导航依然对屏幕阅读器不可用。语义化标签是起点，不是终点。
