搜索框必须置于内，因html规范明确定义为唯一承载页眉内容（含站点标题、导航、搜索）的语义容器；放错位置会导致屏幕阅读器无法识别其导航功能、google结构化数据解析失败，且lighthouse会报无障碍错误。
搜索框本身不决定文档结构，但它的位置、语义标签和上下文嵌套方式，直接暴露页面结构是否合理——尤其当它被塞进 <header></header> 之外的任意位置时，SEO 和可访问性风险就已产生。
为什么搜索框必须放在 <header></header> 里
不是“建议”，而是语义强制要求：<header></header> 是唯一被 HTML 规范定义为“包含页眉内容（如站点标题、导航、搜索）”的容器。放错地方会触发两个实际问题：
- 屏幕阅读器无法将搜索框识别为“全局导航工具”，用户需额外跳转才能定位
- Google 的结构化数据解析器在提取
<website></website>schema 时，只信任<header></header>内的<form></form>或<input type="search">作为“网站搜索入口” - 若用
<div class="search-box"> 替代语义标签，Lighthouse 的 “Accessibility” 审计项会明确报错 <code>Form element has no associated label<input type="search">比<input type="text">多什么表面看只是 UI 差异，实则影响行为逻辑：
- 原生支持清除按钮（×），无需 JS 实现；
type="text"必须手动加contenteditable+ 清除图标逻辑 - 移动端键盘自动唤起“搜索”回车键（而非“完成”或“下一步”），用户操作路径缩短 1 步
- 部分浏览器（如 Safari）对
type="search"应用特殊样式重置（如圆角、内边距），type="text"需额外重置 - 若未配
name属性，提交时参数名默认为q（搜索引擎友好），而type="text"默认无 name，提交为空字段
搜索表单要不要包裹
<form></form>要，且必须带
role="search"和method="get"：- 不包
<form></form>→ 无法按回车提交，只能靠 JS 绑定事件，破坏基础可用性 - 缺
role="search"→ 屏幕阅读器无法告知用户“这是一个搜索区域”，仅读作“输入框” - 用
method="post"→ 搜索结果页无法被书签收藏、无法后退刷新，违反搜索场景本质 - 遗漏
action→ 提交时 URL 变成当前页路径 +?q=xxx，虽能工作，但不利于 SEO 路由控制（比如你想导向/search?q=xxx）
<main></main>里塞搜索框是常见错误几乎所有 CMS 主题模板都犯这个错：把搜索框渲染在
<main></main>开头，理由是“用户一进来就要搜”。后果很实在：-
<main></main>必须只包裹“页面核心内容”，搜索框属于“全局导航辅助”，不属于正文 - Google 抓取时会把搜索框文本（如 placeholder “搜教程、API、错误码…”）误判为主内容关键词，稀释真实正文权重
- 当页面是搜索结果页时，
<main></main>内又出现一个搜索框，形成“搜索页里再搜”，结构循环混乱 - 正确做法：搜索框只在
<header></header>，搜索结果页的<main></main>里只放结果列表和分页
真正容易被忽略的是 placeholder 文本的语义处理——它不是标签替代品，必须配
<label></label>或aria-label，否则 WCAG 2.1 AA 级别直接不达标。这点连很多成熟框架的默认组件都没做全。 - 原生支持清除按钮（×），无需 JS 实现；
