<main>必须唯一且为<body>直接子元素，嵌套在<article>或<section>中会破坏语义层级，导致屏幕阅读器跳过主内容、搜索引擎降权；其本质是文档级不可替代内容锚点，非局部容器。
main 必须唯一且直接子元素，否则屏幕阅读器和搜索引擎会误判主内容范围——这不是规范建议，而是可访问性与 SEO 的硬性约束。
为什么 main 不能嵌套在 article 或 section 里
浏览器和辅助技术将 main 视为整个文档的“不可替代内容锚点”。一旦它被包裹在 article 中，语义层级就坍缩了：原本应代表全页核心的区域，降级成了某篇文章的局部容器。
- 错误示例：
<article><main>...</main></article>→ 屏幕阅读器可能跳过该main，或将其权重等同于普通段落 - 正确用法：
main是<body>的直接子元素，且全页仅出现一次 - 例外场景：Web Component 内部可封装独立
main，但仅限 Shadow DOM 隔离环境，普通 HTML 文档不适用
article 和 section 的边界在哪
判断依据不是视觉分块，而是内容是否「独立可分发」：article 强调自包含、可脱离上下文存在；section 只是逻辑分组，无独立传播价值。
-
article适用：博客正文、新闻稿、用户评论、产品卡片（含标题+摘要+发布时间） -
section适用：文章内的「背景」「方法」「结论」小节；首页的「关于我们」「服务列表」「客户评价」区块 - 常见误用：
<section><h2>联系我们</h2><form>...</form></section>✅ 合理；但若把整页表单包装成article❌ 错误——表单本身不可被 RSS 抓取或单独转发
header 和 nav 的复用规则
header 不等于「页面顶部」，它依附于其父级语义容器；nav 专指主导航系统，非所有链接集合都配得上它。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 一个
article可以有自己的header（含标题、作者、时间），这和页面级header并存不冲突 -
nav应只包裹网站全局导航（如顶部菜单、侧边栏主菜单），页脚的「友情链接」或文章末尾的「相关阅读」用aside或普通div更合适 - 多个
nav允许存在，但需加aria-label区分用途，例如：<nav aria-label="主导航">、<nav aria-label="面包屑导航">
标题层级断裂为何比样式错乱更致命
h1–h6 不是字号开关，而是结构声明。跳级（如 h2 后直接 h4）或缺失 h1 会导致屏幕阅读器无法构建有效大纲，也干扰 Google 的内容聚类判断。
- 每个
article应有自己独立的标题层级（从h1或h2开始），但全页仍需且仅需一个根级h1（通常在main内） - 避免用 CSS 强行改变标题视觉大小来“绕过”层级，比如给
h3加font-size: 2em仍不能替代h2的语义角色 - 动态渲染页面时，服务端或客户端必须确保标题嵌套深度与语义层级一致，React/Vue 中尤其容易因条件渲染漏掉某级标题
真正难的不是记住标签名，而是在内容尚未完全成型时，就预判它的传播路径、访问方式和机器解析逻辑——语义化是写给未来看的代码，不是写给当前浏览器渲染的快照。
