h1必须且只能出现一次，作为页面唯一主标题；h2–h6须严格按内容逻辑嵌套，禁止跳级或仅作样式使用；seo与无障碍依赖正确标题结构，需通过工具在ci中自动化校验。
h1 必须且只能出现一次，通常对应页面主标题
网页中 h1 是语义上最高层级的标题，搜索引擎和屏幕阅读器都把它当作页面核心主题。如果一个页面出现多个 h1，会弱化主标题权重，也会影响无障碍访问体验。
常见错误是模板里每个区块都用 h1（比如轮播图标题、商品卡片标题），或者 CMS 自动生成重复 h1。
- 首页的
h1通常是网站名或核心宣传语（如“高性能 React 组件库”） - 文章页的
h1应该是文章标题（如“useEffect 依赖数组为空数组时的陷阱”） - 避免在组件库、弹窗、卡片等复用单元里硬编码
h1；改用h2或通过aria-labelledby关联语义
h2–h6 要体现真实内容逻辑，不是为了“看起来像标题”
很多人把 h2–h6 当作样式标签：字号大就用 h2，小一点就用 h3。这是错的。标题层级必须反映内容的嵌套与从属关系，比如“安装 → 配置 → 启动”是线性流程，适合平级 h2；而“配置”下再分“环境变量”“配置文件”“CLI 参数”，才该用 h3。
实际开发中容易忽略的是「跳级」问题：直接从 h2 跳到 h4，中间缺了 h3，会导致结构断裂，部分读屏软件无法正确播报层级。
- 用浏览器开发者工具的「Accessibility」面板检查标题树是否连贯
- Markdown 渲染器（如 remark）默认把
##编译为h2，需确认源文档没跳级（如##后直接####） - Vue/React 中避免用
props.level动态生成<h></h>，除非你严格控制传入值为连续整数（1–6）且有 fallback
SEO 和可访问性对标题层级有硬性依赖
Google 明确表示会参考标题结构理解页面内容主次；WCAG 2.1 要求标题形成“有意义的层次结构”（准则 1.3.1）。不合理的层级不会直接导致排名下降，但会让页面在语义解析阶段失分——尤其是当 h1 缺失、或 h2 数量远超正文段落时，算法可能判定内容质量低或结构混乱。
另一个常被忽视的点：服务端渲染（SSR）页面若首屏无 h1（比如加载中状态占位），爬虫可能抓取到空结构；客户端渲染（CSR）页面若 JS 失败，标题也可能不渲染。
- Next.js 中确保
app/layout.tsx或pages/_app.tsx不覆盖或移除h1 - 使用
react-helmet-async或next/head动态设置h1时，要保证 SSR 与 CSR 一致 - 测试时禁用 JS，查看纯 HTML 是否仍保有合理标题流
用 CSS 控制样式，别靠标题标签“假装”层级
标题标签的语义和视觉表现是两回事。想让某个内容视觉上突出但语义上不是二级标题？那就用 div + CSS，而不是塞个 h2 再用 font-size: 0.8em 压小。反过来说，一段普通段落如果确实是章节起始，哪怕它只有一行字，也该用 h3。
团队协作中最难统一的，是设计稿里“看起来像标题”的元素（如卡片标题、Tab 标签、筛选项）。它们往往没有语义层级，强行用 h3 会污染结构。
- 卡片标题优先用
div class="card-title"，配合role="heading" aria-level="3"（仅当真需辅助技术识别时） - Tab 切换栏用
nav+button，不要用h2包裹每个 tab 文字 - 所有自定义标题组件（如
<sectiontitle level="{3}"></sectiontitle>）必须校验level在 1–6 范围内，并对非法值降级为span
h1 缺失、跳级、重复等基础问题——这类检查几行代码就能跑完，但能拦住 80% 的结构性缺陷。
