<main>只能出现一次且必须包裹核心内容，因浏览器和辅助技术将其视为页面唯一主干，重复或错放会破坏语义流，导致屏幕阅读器跳过导航直接进入主内容，SEO降权；正确做法是确保<main>为<body>直接子元素，内部用<section>划分小节，而非多层嵌套或滥用。
为什么只能出现一次，且必须包裹核心内容
浏览器和辅助技术（比如屏幕阅读器）把 <main></main> 当作页面“唯一主干”，重复或错放会破坏语义流。比如在页脚里嵌一个 <main></main>，会导致读屏软件跳过前面所有内容直接进“主内容”，用户根本听不到导航和标题。
常见错误现象：
- 用
<main></main>包裹整个，把<header></header>、<nav></nav>也塞进去 - 多个卡片模块各自套一层
<main></main>，以为“每个模块都是主内容” - SPA 路由切换时未销毁旧
<main></main>，导致 DOM 中残留多个
正确做法：
- 确保
<main></main>是的直接子元素，且只有一处 - 它里面的内容必须是当前路由/视图下真正不可替代的主体（如文章正文、商品列表、表单主区域）
- 如果页面有多个独立内容单元（如首页的“推荐文章”+“热门视频”），用
<section></section>或<article></article>划分，而不是<main></main>
如何用避免嵌套过深又保持语义清晰
<section></section> 不是视觉容器，而是“有主题、可独立理解的内容块”。嵌套超过两层，就等于在说“这段内容需要三层上下文才能懂”，这既难维护，也影响 SEO 和可访问性。
立即学习“前端免费学习笔记（深入）”；
使用场景判断：
- 一级
<section></section>：博客首页的“最新文章”区、“相关推荐”区 - 二级
<section></section>：某篇文章内的“技术细节”小节、“兼容性说明”小节 - 三级及以上：应抽成独立组件（如自定义元素
<faq-section></faq-section>），或改用<aside></aside>/<nav></nav>明确角色
性能影响：
- 每多一层嵌套，CSS 选择器匹配时间线性增长；
section section section h3比.faq-title慢得多 - JS 查询
document.querySelectorAll('section section section')在长列表页可能触发重排
data-属性怎么预留配置钩子而不污染语义
data- 属性是唯一被 HTML5 明确允许用于自定义数据的机制，但它不是“随便加个 data-id 就完事”。乱用会让结构变得像配置文件，失去 HTML 的表达力。
关键约束：
- 只存运行时需要、且无法通过 DOM 结构推导的信息，比如
data-load-strategy="lazy"、data-api-version="v2" - 避免用
data-class或data-style替代 CSS 类名——那是在退化 HTML 的职责 - 所有
data-名必须小写、用短横线分隔（data-user-role✅，dataUserRole❌）
容易踩的坑：
- 把 JSON 字符串塞进
data-config，结果 JS 解析失败还不好 debug - 用
data-hidden="true"控制显隐，却忘了同步更新 ARIA 状态（应配aria-hidden="true"） - 服务端渲染时硬编码
data-timestamp，但客户端 hydration 后没更新，导致时间不一致
DocumentFragment 批量插入 vs 直接 innerHTML，什么时候选哪个
往高密度容器（比如含 200 条评论的 <div id="comments"></div>）里追加节点时，性能差异明显。直接拼字符串再赋值 innerHTML 看似简单，但会强制浏览器重建整个子树，触发多次样式计算和布局。
实操建议：
- 新增少量节点（≤10 个）：用
element.append(...nodes)最直观 - 批量插入中等数量（10–100）：先创建
DocumentFragment，append 所有节点，再一次性 append 到目标容器 - 超大量（>100）或需滚动加载：结合
IntersectionObserver分片，每批用DocumentFragment插入
注意：
-
DocumentFragment不在 DOM 树中，所以对它的操作不会触发重排；但一旦 append 到真实元素，就会一次性生效 - 如果插入内容含 script 标签，
DocumentFragment不会执行；而innerHTML会——这是安全边界，别为了省事放弃
最常被忽略的一点：可扩展性不体现在标签多寡，而在于“当需求变时，你改几处、影响多少”。比如把一个 <section></section> 抽成 Web Component，要同步改的不只是 HTML，还有它的 data- 配置约定、JS 初始化逻辑、以及它对外暴露的事件命名——这些才是扩展成本的真正来源。
