语义化标签是网页可访问性与SEO的基础：<article>用于可独立分发的内容，<section>用于主题分组；<main>必须唯一；<nav>仅限主要导航；<aside>表示关联非必需内容。

<header>、<nav>、<main>、<article>、<section>、<aside>、<footer> 这些标签不是“锦上添花”的装饰，而是现代网页结构的基础设施——不用它们，页面照样能渲染；但用了，才能让浏览器、搜索引擎、屏幕阅读器真正“看懂”你写的到底是什么。

什么时候该用 <article> 而不是 <section>

核心判断标准就一条：这块内容能不能被单独拎出来发布、订阅或打印？

• 能——比如一篇博客正文、一条用户评论、一个新闻卡片，就用 <article>。它自带隐式语义：独立、可复用、可分发。
• 不能——比如“关于我们”“服务流程”“产品特性”这类只是对主内容做主题分组的区块，用 <section> 更准确。它强调的是“内部有共同主题”，不强调自包含性。
• 常见错误：<section> 里塞了一整篇带标题、作者、时间的博客，却没用 <article>——这会让 RSS 阅读器和爬虫误判内容粒度，降低聚合效率。
• 注意：<article> 可以嵌套（如文章里的评论），<section> 内部建议有 <h2>–<h6> 标题，否则容易沦为“语义化 <div>”。

<main> 的唯一性为什么必须严格遵守

<main> 表示文档中与中心主题直接相关的核心内容，它的唯一性不是规范“建议”，而是浏览器和辅助技术的解析前提。

• 多个 <main> 会导致屏幕阅读器在朗读时反复切换“主内容上下文”，用户会困惑哪部分才是当前焦点。
• SEO 工具（如 Lighthouse）会将多 <main> 视为结构缺陷，影响可访问性评分。
• 实际场景中容易踩坑：SPA 应用切换路由时，未清理旧 <main>；或在组件库中每个卡片都包裹 <main>（错把“局部主体”当“全局主体”）。
• 替代方案：局部重要内容用 <article> 或 <section>，全局唯一主体只留给最外层真正承载业务主逻辑的容器。

<nav> 不是所有链接集合的通用容器

<nav> 的语义是“主要导航”，不是“有链接的地方”。滥用它反而稀释语义价值。

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

立即学习“前端免费学习笔记（深入）”；

• 该用：<nav> 包裹顶部主导航栏、侧边栏目树、页脚站点地图、分页控件（如“上一页/下一页”）。
• 不该用：文章末尾的“相关阅读”链接、评论区的“回复”按钮、表单内的“取消”链接——这些属于操作或附属行为，不是导航意图。
• 性能提示：部分辅助技术会为 <nav> 提供快捷跳转（如按 N 键直达），若到处乱放，等于给用户制造干扰跳转点。
• 兼容性提醒：IE11 及更早版本不识别 <nav>，但不影响渲染；关键是别依赖它做样式布局（应始终用 CSS 类控制视觉）。

为什么 <aside> 比 float: right 更值得优先考虑

<aside> 描述的是逻辑关系，不是视觉位置。把它当成“侧边栏”来用，是典型误解。

• 适用场景包括：文章中的引用框（<blockquote> 外层）、术语解释浮层、广告模块、作者简介卡——只要内容与主内容“关联但非必需”，就符合 <aside> 语义。
• 移除 <aside> 后，主内容必须依然完整可理解；反之，如果删掉它导致主内容断裂（如缺失关键参数说明），那它其实该放在 <section> 或正文内。
• 响应式中：<aside> 在小屏可自然流式排布，无需 hack 式 media query 重置浮动，语义清晰 + 布局灵活是双重收益。
• 易忽略点：HTML5 允许 <aside> 出现在 <article> 内部（如某段技术说明旁的兼容性备注），这种嵌套是合法且推荐的。

真正难的不是记住每个标签怎么写，而是在写第一行 HTML 之前，先问一句：“这段内容，在脱离当前页面后，还能不能自己讲清楚故事？”——这个判断，决定了语义是否成立，也决定了你的页面是“能跑就行”，还是“能被真正理解”。