不能嵌套在里因语义冲突：将主内容区（）嵌入页眉（）违背“主内容是页眉一部分”的逻辑，导致屏幕阅读器报错、seo降权及lighthouse标红；正确写法是与、、并列于下。
为什么不能嵌套在里
因为语义冲突：浏览器和辅助技术会把 <main></main> 解析为“全页唯一主内容区”，而 <header></header> 是“页面或区块的顶部区域”，属于外围容器。一旦嵌套，就等于说“主内容是页眉的一部分”，逻辑上自相矛盾。
实际影响包括：
- 屏幕阅读器可能跳过
<main></main>或报错结构异常 - 搜索引擎降低该页面核心内容可信度，影响排名权重分配
- 部分 Lighthouse 审计项直接标红，提示“
<main></main>not at top level”
正确写法是让 <main></main> 与 <header></header>、<nav></nav>、<footer></footer> 并列，同级出现在 下。
和什么时候该选哪个
关键看内容能否独立存在并被单独分发：
- 用
<article></article>：博客正文、新闻稿、论坛帖、产品详情页——它们有明确作者、发布时间，能被 RSS 订阅、被搜索引擎单独索引 - 用
<section></section>：同一主题下的多个子块，比如“前端工具推荐”下并列三个工具介绍；或“用户评论区”里一组非独立的留言 - 误用典型：把侧边广告栏写成
<article></article>（它既无作者也不可分发），或把整篇技术文档硬拆成五个<section></section>却没加任何<h2></h2>标题（违反语义完整性）
<section></section> 必须配标题（<h2></h2>–<h6></h6>），否则机器无法识别其主题边界；<article></article> 可自带 <header></header> 和 <footer></footer>，比如含 <time datetime="2026-06-12"></time> 的发布时间。
导航链接塞进
不是所有带链接的区域都该用 <nav></nav>。滥用会导致语义稀释，反而削弱导航权重。
- 是否由**主要跳转路径**组成？如主导航菜单、面包屑、页内锚点列表——是，用
<nav></nav> - 是否用于**功能操作**？如“编辑”“删除”“分享”按钮——否，用
<div role="toolbar"> 或普通 <code><div> <li>是否只是**内容关联推荐**？如“猜你喜欢”“相关文章”——否，用 <code><aside></aside>或<section></section> - 搜索引擎无法提取准确发布时间，影响新鲜度排序（尤其新闻、教程类页面）
- 屏幕阅读器读不出具体日期，只念“发布于今天”，对视障用户失去时间参照
- Schema.org 结构化数据（如
Article）要求datePublished字段，必须由<time></time>提供有效值才能通过 Google Rich Results Test
一个页面可以有多个 <nav></nav>（比如顶部主导航 + 页脚快捷入口），但每个都必须满足“导航集合”这一本质定义。Chrome DevTools 的 Accessibility 面板会把非导航链接放在 <nav></nav> 里标为“misused landmark”。
时间信息不用
<time></time> 不是装饰性标签，它是机器可解析的时间节点声明。只写“发布于今天”而不用 <time datetime="2026-08-25"></time>，等于主动放弃两项关键能力：
注意：datetime 属性必须是机器可解析格式（YYYY-MM-DD 或 YYYY-MM-DDThh:mm:ss），不能是 “2026年八月” 或 “昨天”。
语义化不是贴标签比赛，而是持续校验“这个标签是否真能回答‘它是什么’这个问题”。最容易被忽略的是嵌套合法性与上下文一致性——比如在 <article></article> 内部又套了个 <main></main>，或者用 <section></section> 包裹纯视觉分隔线。这类错误不会让页面崩，但会让机器理解永远慢半拍。
