input[type="search"]必须包裹在form中，否则回车不提交、Tab跳过、屏幕阅读器无法识别；需设method="GET"、action及name属性，监听search事件而非input，并用Range方案安全高亮关键词。
input[type="search"] 必须包在 form 里才能正常提交、获得焦点流、通过屏幕阅读器识别——脱离 form 的搜索框，回车不响应、Tab 键跳过、无障碍直接失败。
为什么回车没反应？检查 form 和 name 属性
常见错误不是写错了 type，而是漏掉两个硬性条件：
-
form标签缺失，或写了但没设method="GET"（推荐）和action（哪怕只是占位如action="#"） -
input没加name属性，比如name="q"；没有 name，提交时参数不会进 URL 查询串，FormData也取不到值 - 用 JS 监听时绑了
input或keyup，但用户点清空按钮或按回车实际触发的是search事件——它只在“确认搜索”时发生，比input更语义化
清空按钮样式怎么统一控制？别碰伪元素尺寸
各浏览器用不同伪元素渲染原生清空按钮：::-webkit-search-cancel-button（Chrome/Safari）、::-ms-clear（旧 Edge），Firefox 根本不渲染。它们不是普通 DOM 元素，不能用 color 或 font-size 调整外观。
- 想隐藏：必须分别写
input::-webkit-search-cancel-button { -webkit-appearance: none; appearance: none; }和input::-ms-clear { display: none; } - 想自定义图标：放弃原生按钮，用绝对定位的
button覆盖右侧，并监听input事件控制显隐：clearBtn.style.display = input.value ? 'block' : 'none' - Safari 15.4+ 对
appearance: none更严格，缺-webkit-appearance: none就无效
移动端软键盘“搜索”键出不来？type="search"只是必要非充分条件
能否触发软键盘上的“搜索”文字（iOS 显示“搜索”，Android 显示“前往”等），由浏览器 + OS 共同决定，HTML 层面无法强制。
立即学习“前端免费学习笔记（深入）”；
-
type="search"是基础前提，但 iOS Safari 还需配合inputmode="search"和正确lang属性才更稳定 - Android Chrome 桌面版默认禁用语音按钮，
chrome://flags/#enable-speech-input已废弃，别试 - 别依赖软键盘上显示的文字——系统语言、输入法都可能改变它；交互逻辑必须以回车键为准
实时过滤列表该监听哪个事件？别只靠 search
input[type="search"] 本身不扫描 DOM、不匹配文本、不高亮结果。所有这些都要手写 JS 实现，而事件选择直接影响体验和性能。
- 监听
input事件做防抖（如 300ms），比监听search更及时；后者只在回车/清空时触发，不适合实时反馈 - 过滤时用
textContent判断匹配，不用innerText（受 CSS 隐藏影响，可能返回空字符串） - 高亮关键词别用
innerHTML.replace()—— 会破坏事件绑定、丢失引用，甚至引入 XSS；应走Range+document.createElement方案
最易被忽略的一点：form 即使只作语义容器、不发请求，也必须存在。否则 Tab 导航断裂、屏幕阅读器读不出“这是个搜索框”，WCAG 2.1 A 级合规直接不通过。
