一个页面绝大多数情况下只能有1个<h1>，它是语义上唯一的页面核心主题声明，用于搜索引擎理解主旨和屏幕阅读器定位主内容；重复或缺失会导致Lighthouse报错、SEO权重分散及无障碍访问障碍。
一个页面到底该有几个 <h1>？
绝大多数情况下，就该只有 1 个 <h1>。它代表整个页面的唯一核心主题，比如文章标题、产品主名称或首页的站点名。屏幕阅读器默认会把第一个 <h1> 当作“页面起点”，跳过它就等于跳过了入口。
HTML5 允许在 <section> 或 <article> 内部再用 <h1>，但实际中极少需要——除非你在做独立可复用的卡片组件（如博客列表项），且该组件会被嵌入不同上下文。否则，强行多用 <h1> 会让读屏用户反复听到“标题、标题、标题”，失去主次判断。
- 错误做法：
<h1>用在侧边栏小标题、轮播图标题、页脚版权行 - 正确替代：
<h2>或<h3>，配合语义容器（如<aside>、<footer>）明确上下文 - 验证方式：用 NVDA 或 VoiceOver 按
H键遍历标题，看是否只报出一个主标题
<h2> 到 <h6> 跳级会怎样？
跳级不是“样式不生效”，而是直接破坏可访问性导航流。当屏幕阅读器用户按 H 键从 <h2> 跳到 <h4>，中间缺失的层级会让其误判内容结构——比如以为 <h4> 是某个未出现的 <h3> 的子项，从而漏读或重复读。
常见跳级场景：
立即学习“前端免费学习笔记（深入）”；
- 用
<h2>做章节标题，紧接着用<h4>做小段说明（应为<h3>） - 为控制字体大小，把本该是
<h3>的内容写成<h5>，再靠 CSS 放大 - 从
<h1>直接写<h3>，跳过<h2>（尤其在 CMS 自动生成内容时高发）
修复原则：先理清内容大纲，再按逻辑深度分配标签，样式交给 CSS。
为什么 <nav> 里必须套 <ul>？
因为屏幕阅读器依赖原生列表语义来播报导航项数量和结构。“共 5 项”这个提示，只在 <ul> + <li> 组合下才稳定触发。如果只用 <nav> 包一堆 <a>，读屏会连读成一串无停顿的文本，比如“首页关于我们产品支持联系我们”，用户根本分不清哪是哪。
关键细节：
-
<ul>不是“为了好看”，是辅助技术识别列表的唯一可靠信号 - 别用
<div role="list">替代 —— 兼容性差，部分旧版读屏不识别 - 当前页标识不能只靠
class="active"，必须加aria-current="page"
标题结构对 SEO 和 JS 渲染的影响
搜索引擎爬虫和现代 SSR/CSR 框架（如 Next.js、Nuxt）都依赖标题层级推断内容权重。一个没有 <h1> 或满屏 <h2> 的页面，可能被判定为“结构混乱”，降低索引优先级；而动态渲染时若 JS 插入标题却没同步更新层级（比如插入了 <h3> 却漏掉父级 <h2>），会导致首屏可访问性失效。
实操提醒：
- 服务端渲染时，确保初始 HTML 就含完整、合法的标题链
- 客户端 JS 动态更新标题区域后，手动检查
document.querySelectorAll('h1, h2, h3, h4, h5, h6')是否连续递进 - 避免用
display: none隐藏标题再用 JS show —— 屏幕阅读器仍会读，但用户看不到上下文
标题结构不是“写完再补”的装饰项，它从第一行 HTML 就开始影响可访问性、SEO 和 JS 行为的一致性。最容易被忽略的，恰恰是那些看似“反正能显示出来”的跳级和冗余 <h1>。
