header代表语义上的“介绍性或导航辅助区域”，非视觉顶部；可嵌套于页面、文章或区块级作用域，须含恰当标题且与CSS布局解耦。
<header></header> 不代表页面顶部位置，它代表的是“内容的起始介绍性区域”——语义上是“页眉”，不是“页顶”。位置靠上只是常见视觉习惯，不是规范要求。
为什么<header></header>不能简单理解为“顶部”
HTML5 规范明确指出：<header></header> 是“a group of introductory or navigational aids”，即一组介绍性或导航辅助内容。它的语义锚点是“作用”，不是“坐标”。浏览器、屏幕阅读器、SEO 工具都只认这个语义，不读 CSS 的 top: 0 或 position: fixed。
- 一个
<article></article>里嵌套的<header></header>（含<h2></h2>+ 作者信息）可能出现在页面中间，但它仍是合法且语义正确的页眉 - 把
<header></header>放在<main></main>下方、<footer></footer>上方，只要它包裹的是该区块的标题和元信息，就完全合规 - 用
display: flex; flex-direction: column-reverse把<header></header>渲染到底部？没问题——语义没变，只是视觉翻转了
<header></header> 嵌套使用的典型场景
一个页面可以有多个 <header></header>，但每个必须对应一个语义作用域。关键看它“属于谁”：
- 页面级：
直接子元素的<header></header>，包含网站 logo、全局导航、搜索框 - 文章级：嵌套在
<article></article>内的<header></header>，只放这篇文的<h1></h1>或<h2></h2>、作者、时间、分类标签 - 区块级：放在
<section></section>或<aside></aside>开头，比如“相关推荐”区块的标题栏<header><h3>你可能还喜欢</h3></header> - 错误用法：把整个
<main></main>和<footer></footer>都包进一个<header></header>——这破坏了语义边界，Lighthouse 会报 “header contains non-introductory content”
容易被忽略的可访问性影响
屏幕阅读器（如 NVDA、VoiceOver）遇到 <header></header> 时，会自动将其识别为“可跳转区域”，并朗读其中第一个标题（<h1></h1>–<h6></h6>）。如果里面没标题，或标题层级混乱，就会导致：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 键盘用户按
H键跳页眉时失效（报 “no header found”） - 视障用户听到 “header, banner” 后，却听不到实际标题内容，无法判断当前在哪部分
- 某些读屏软件对嵌套
<header></header>的支持较弱，若内层没显式标题，可能直接跳过
所以，每个 <header></header> 至少应含一个 <h1></h1>–<h6></h6>，且层级需反映内容结构（例如 <article></article> 里的 <header></header> 用 <h2></h2>，别用 <h1></h1>）。
CSS 布局与语义解耦的关键提醒
用 Flexbox 或 Grid 布局时，<header></header> 的视觉位置完全由父容器决定，但它的语义角色不会因此改变。最容易出问题的是响应式折叠导航：
- 汉堡菜单展开后，把原
<nav></nav>移动到<header></header>外部（比如 body 底部）？会导致导航脱离语义上下文，屏幕阅读器无法关联它和页眉 - 用
position: absolute把<header></header>拉到右侧做侧边栏？语义错乱——它不再是“introductory aid”，而成了布局 hack - 正确做法：保持
<nav></nav>在<header></header>内（哪怕视觉上它被 JS 移动），或用aria-labelledby显式绑定语义关系
语义结构一旦写进 HTML，就不该靠 CSS 或 JS 去“覆盖解释”。位置可以变，作用不能模糊。
