type="search"本质是input但触发搜索专属逻辑，如Safari清除按钮、Spotlight动画、软键盘“搜索”键；需注意跨浏览器兼容性、防抖实现、URL编码及提交机制。
HTML表单里type="search"和普通text到底差在哪
差别很小，但浏览器行为和默认样式有实际影响。它本质还是input，不是独立控件，但会触发搜索框专属逻辑。
常见错误现象：type="search"在 Safari 里自动带清除按钮（×），但 Chrome 需要appearance: none才能统一控制；部分安卓 WebView 不识别results属性。
-
type="search"会自动获得系统级搜索语义，比如 macOS 的 Spotlight 风格聚焦动画 - 支持
results属性（如results="5"），但仅 Safari 实现，Chrome 忽略 - 移动端软键盘可能显示“搜索”而非“完成”按钮——取决于浏览器和 OS，不能强依赖
- 若用
autocomplete="off"，部分浏览器仍会缓存，得加autocomplete="search"或随机name值才更可靠
怎么让form按回车就搜，又不意外提交
关键不在input类型，而在form的提交机制和事件拦截逻辑是否干净。
使用场景：搜索框常嵌在导航栏或页头，旁边还有其他按钮，用户敲回车时不该跳转或刷新页面。
- 确保
form有onsubmit="return false;"或用 JS 绑定event.preventDefault() - 别只监听
input的keyup，回车触发的是form的submit事件，优先处理它 - 如果不用
form包裹，纯靠input+keydown判断event.key === "Enter"，注意 IE 用keyCode === 13 - 避免同时绑定
submit和click在搜索按钮上，容易重复触发
搜索关键词带空格或特殊字符，后端收不到怎么办
不是前端没发，是 URL 编码或表单编码方式不匹配，或者后端解析逻辑卡在第一步。
立即学习“前端免费学习笔记（深入）”；
参数差异：GET请求走application/x-www-form-urlencoded，空格变+或%20；POST体里空格正常，但若用fetch手动拼 URL，漏了encodeURIComponent()就直接丢字符。
- 用
form method="get"时，浏览器自动编码，放心；但后端框架（如 Express）需用req.query而非req.body - 用
fetch发GET，必须对关键词做encodeURIComponent(searchValue)，否则空格、中文、&全乱 - 若关键词含
#，它会在 URL 中被截断——这不是 bug，是浏览器规范，得改用POST或把#替换成%23 - 服务端 Nginx 或 CDN 若开了
underscores_in_headers off，又用了下划线命名参数（如q_term），可能直接 400
为什么搜索框一输就发请求，但防抖后反而卡顿
防抖本身没错，但实现位置和时机不对，就会让输入体验变粘滞。
性能影响：每次输入都新建定时器，旧定时器未清除，内存泄漏+响应延迟；或把防抖放在fetch外层，导致网络请求排队阻塞 UI。
- 用
setTimeout时，务必在新输入前clearTimeout(prevTimer)，变量得闭包保存 - 别在
input事件里直接调fetch，先防抖，再发请求；但防抖时间别设成 500ms 以上，用户会觉得“迟钝” - 移动端输入法上屏可能触发多次
input（比如拼音转汉字），可加event.isComposing判断过滤 - 如果用
IntersectionObserver或requestIdleCallback做节流，反而过度设计——搜索框不需要那么复杂
真正难的是平衡实时性与资源消耗：用户连打“react hooks”，中间停顿 200ms 就该查，但连续敲字母时不能每键都发。这个阈值没有标准答案，得看接口延迟和用户预期。
