header用于页面或区块的引导性内容（如logo、导航、标题），main标识唯一核心内容区且不可嵌套于article/section，section则按主题逻辑分组内容并须含标题。
怎么用 header、main、section 区分内容角色
语义标签不是“换汤不换药”的 div 替代品，它们直接参与浏览器解析、辅助技术导航和搜索引擎建模。比如 main 标签告诉读屏软件“这是页面唯一核心内容区”，而包裹在 section 里的 h2 会被识别为该区块的标题，脱离上下文后仍保有结构意义。
常见错误现象：nav 里塞一堆 h3；aside 里放整段产品介绍；把轮播图容器硬套 article 却没有独立可分发性。
-
header应只包含本级内容的引导信息（如文章标题+作者+发布时间），不是全站顶部通栏 -
main必须且只能出现一次，且不能嵌套在article或section内部（除非是嵌套路由页） -
section需有明确主题，且建议以标题开头（h2或对应层级），空section会破坏结构可信度 -
article要满足“能单独被 RSS 抓取、邮件转发或分享到社交平台”的语义强度，博客正文、用户评论、新闻稿适用；导航菜单、页脚链接列表不适用
为什么 h1 到 h6 不能当字体样式用
h1–h6 是文档大纲的锚点，不是 CSS 类名。跳级（h1→h4）、重复（多个 h1）、滥用（按钮包 h3）都会让屏幕阅读器生成错误的导航树，也导致 SEO 工具判定内容逻辑断裂。
使用场景：CMS 模板中全局插入的 h1 和正文又加一个 h1，实际形成两个顶层节点，结构塌陷；用 CSS display: none 隐藏某个 h1，DOM 中仍存在，读屏器照读不误。
立即学习“前端免费学习笔记（深入）”；
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 现代实践倾向单个
h1，放在main内部，代表整个文档主旨 -
section或article内允许有自己的h1，但这是语义隔离——它的层级计数从该容器起始，不影响外层文档大纲 - 检查方式：Chrome DevTools → Elements → 右键任意标题 → “Inspect ARIA attributes”，看
aria-level是否连续、是否符合预期
section 和 article 的边界到底在哪
关键判断标准是“能否独立存在并被理解”。一篇博客全文是 article；它下面的“评论区”是另一个 article（每条评论本身也是 article）；而“相关推荐”“作者简介”这类附属内容，属于同一主题下的分组，用 section 更准确。
参数差异：article 自带隐式 aria-roledescription="article"，会被 RSS 阅读器、微信公众号抓取工具识别为独立内容单元；section 无此能力，仅表示逻辑分组。
- 不要因为视觉上用了卡片样式，就给每个卡片套
article—— 如果它们共享同一主题（如“我们的服务”下三个平行列项），section+h2+ 多个div更合理 -
aside里放广告或赞助商 logo，不属于article，也不属于section，它只是旁注，语义权重最低 - 兼容性注意：IE8 及更早需 HTML5 Shiv 才能渲染这些标签，但语义解析仍不可靠，老项目需评估是否值得强依赖
嵌套层级超过 5 层为什么危险
深层嵌套（如 div > section > article > section > div > p）会让 CSS 选择器耦合过重、JS 查询路径变长、可访问性树膨胀，也增加协作时的理解成本。
性能影响：无直接加载延迟，但 DOM 树过深会拖慢辅助技术遍历速度，实测在 NVDA 中，5 层以上嵌套的 section 块平均响应延迟增加 200–400ms。
- 优先扁平化：用类名区分功能（
class="product-card"）比靠多层section嵌套更可控 - 缩进统一用 2 或 4 空格，避免 Tab 与空格混用导致 IDE 折叠错乱
- 模块注释写在容器起始处，例如
<!-- 产品列表模块 start --><section class="product-list"></section>，别写在闭合标签后
真正难的不是记住标签名，而是每次写 section 前停半秒问自己：这个区块删掉，主内容还能自洽吗？如果答案是否定的，它大概率不该是 section，而是 main 的一部分。
