<main>必须唯一且不得嵌套，因其是浏览器和辅助技术定位核心内容的语义锚点，重复或嵌套会破坏语义流、导致SEO降权与焦点错乱；实际使用中须直接置于<body>下，仅包裹不可剥离的主体内容，内部可用<article>区分独立单元。
为什么只能出现一次且不能嵌套
浏览器和辅助技术（如读屏软件）依赖 <main> 的唯一性来定位核心内容。重复或嵌套会破坏语义流，导致 SEO 降权、焦点跳转错乱，甚至被部分爬虫忽略整块区域。
常见错误现象：<main><section><main>... 或在 <header> 里塞 <main>；实际使用中，<main> 必须直接位于 <body> 下，且仅包裹真正不可剥离的主体内容（比如文章正文、表单主区域）。
- 若页面有多个“主要内容”区块（如首页含三篇推荐文章），用一个
<main>包裹全部，内部用<article>区分独立单元 -
<main>不得出现在<aside>、<nav>、<footer>内部 - 动态渲染时，服务端或 JS 拼接 HTML 前要校验
<main>数量，避免 SSR/SSG 输出重复
用还是？关键看能不能独立复用
<section> 是主题分组容器，<article> 是可独立分发的内容单元——这个区别直接影响 RSS 抓取、分享链接生成和搜索引擎片段提取。
错误示例：把“用户评论列表”整个包进 <section>，但每条评论本身具备完整语义（作者、时间、内容），应单独用 <article>；又或者把“产品参数表格”硬套 <article>，它既无署名也无发布时间，只是附属信息，<section> 更合适。
立即学习“前端免费学习笔记（深入）”；
-
<article>必须自带标识性元数据：至少含<header>+<h1>或<time datetime> -
<section>可以没有标题，但若加了<h2>，该标题必须准确反映本节主题 - 嵌套关系上，
<article>内可用<section>拆解子章节（如“背景”“方法”“结论”），但反向不成立
嵌套超过三层就该警惕 DOM 性能问题
浏览器解析 HTML 是深度优先遍历，每多一层嵌套，不仅增加内存开销，还让 CSS 选择器匹配成本指数上升。实测显示，<div><div><div><p> 这类结构在低端设备上滚动重排延迟明显高于 <section><article><p>。
容易踩的坑：用 Flex/Grid 布局时仍保留冗余包裹层，比如三栏布局写成 <div class="container"><div class="row"><div class="col">…</div></div></div>，其实 <main> 直接设 display: grid 就够了。
- 用 Chrome DevTools 的 Elements 面板按
Ctrl+Shift+C悬停检查，重点标出连续 3 个以上<div>嵌套的节点 - 单个
<section>或<article>下子元素超过 50 个时，滚动卡顿概率陡增，应拆分为多个逻辑块 - 动态插入大量项时，必须用
DocumentFragment批量 append，而非循环appendChild
preload 关键资源但别滥用，否则反而拖慢首屏
<link rel="preload"> 强制提前拉取资源，但它不控制执行时机，也不压缩带宽——如果对非首屏 JS 或整站通用 CSS 都 preload，会挤占关键 HTML 和字体的下载通道。
典型误用：<link rel="preload" href="https://www.php.cn/link/3fdc35e4182c8401034d9710c5e5f8c1" as="script"> 放在 <head>，结果首屏文字等了 800ms 才渲染出来。
- 只对真正阻塞首屏的资源 preload：比如
<h1>用的自定义字体、首屏 Hero 图片、内联关键 CSS 之外的主样式表 - preload 的
as值必须精确：字体用as="font"，图片用as="image"，否则浏览器可能忽略或错误解析 - 永远不要对
<script>使用 preload 后再用defer，二者语义冲突；需要提前加载+延迟执行，改用<link rel="prefetch">（低优先级）
语义标签不是装饰，是浏览器和机器理解页面的“协议”。写错一个 <main> 或多套两层 <div>，表面看不出问题，但首屏时间、SEO 排名、读屏体验全在悄悄掉分。
