必须用<form>包裹<input type="search">，否则回车、软键盘“搜索”键及无障碍访问失效；type="search"提供原生语义支持，包括iOS显示“搜索”按钮、自动清除图标、autocomplete历史下拉及屏幕阅读器正确识别。
必须用 <form> 包裹 <input type="search">，否则回车、软键盘「搜索」键、无障碍访问全部失效。
为什么一定要用 type="search" 而不是 type="text"
浏览器对 type="search" 有原生语义支持：iOS/Safari 软键盘显示「搜索」按钮（不是「前往」），Chrome/Safari 自动渲染清除按钮，autocomplete 默认启用历史词下拉，且屏幕阅读器能正确识别为“搜索输入”。换成 type="text" 后这些能力全丢，还得手动补 JS 和 ARIA，得不偿失。
- 移动端用户按「搜索」键不触发提交 → 八成是用了
type="text" - 清空按钮在 Safari 隐藏或错位 → 没设
type="search"或 CSS 干扰了 UA 样式 - 用户无法用语音输入 →
type="search"是浏览器启用语音图标的前提条件
<form> 的 method 和 name 怎么设才合规
method="get" 是硬性要求：它让关键词出现在 URL 查询参数里（如 ?q=react），便于分享、缓存、后退重载。同时 <input> 必须带 name 属性（推荐 name="q"），否则提交时参数根本不会被序列化，服务端收不到值。
- 别写
method="post"—— 搜索是幂等只读操作，POST 违反 REST 原则，也禁用浏览器缓存 - 别漏
name：即使你用 JS 拦截提交，也要保留它，方便降级（比如 JS 失效时直连后端） - 可加
action="/search"，明确提交目标路径，避免相对路径歧义
清除按钮怎么处理才不破坏可访问性
现代浏览器对 type="search" 自动插入清除按钮，但直接用 CSS 隐藏（如 display: none）会让屏幕阅读器误判控件状态，甚至导致焦点丢失。正确做法是用 appearance 重置，再用伪元素覆盖样式。
立即学习“前端免费学习笔记（深入）”；
- 隐藏原生按钮：用
input::-webkit-search-cancel-button { -webkit-appearance: none; }+input::-ms-clear { display: none; } - 自定义图标：额外加一个
<button type="button">绝对定位覆盖，绑定click清空input.value并调用input.focus() - 绝对别用
input::before—— 伪元素不响应事件，也不被辅助技术识别
事件监听该绑 submit 还是 input 或 keydown
真正代表“用户确认搜索”的唯一可靠信号是 form 的 submit 事件。它覆盖所有路径：回车、点击按钮、软键盘搜索键、语音输入完成。而 input 或 keydown 只反映输入动作，容易误触发（比如方向键、粘贴中途）。
- 必须在回调里调用
event.preventDefault()，否则页面会跳转或刷新 - 获取值用
new FormData(form).get('q')，比手动取input.value更健壮（自动 trim、兼容 enctype） - 实时建议（如搜索下拉）才用
input事件，且务必加防抖（300ms）
最容易被忽略的是 required 属性和 label 显式绑定：没 required 就失去原生校验；没 <label for="id"> 关联，屏幕阅读器可能完全跳过这个输入框——它就等于“不可见”。
