搜索框必须用<form>包裹并设name属性，否则丢失提交、回车触发、屏幕阅读器识别等能力；type="search"影响软键盘、清空按钮、拼写检查等原生行为。
搜索框必须用 <form> 包裹才符合语义和可访问性
单独放一个 <input type="search"> 看似能用，但实际会丢失提交行为、键盘回车触发、屏幕阅读器识别等关键能力。浏览器对 <form> 内的 type="search" 有专门优化，比如 Safari 会自动添加清除按钮，Windows 高对比度模式下也能正确映射操作。
常见错误是把搜索框写成：<div><input type="search"></div>——这会让辅助技术无法识别其目的，也无法响应 Enter 键提交。
- 始终用
<form>包裹，且设置role="search"（增强旧版屏幕阅读器兼容） -
<input>必须有name属性（如name="q"），否则提交时参数不会被发送 - 推荐加
autocomplete="off"或autocomplete="search"，避免浏览器填充无关历史项干扰搜索意图
type="search" 和 type="text" 的实际差异不止在样式
两者在 DOM 行为上基本一致，但 type="search" 触发更精准的移动端软键盘（显示“搜索”而非“前往”）、支持系统级搜索建议（如 macOS Spotlight 集成）、且部分浏览器会默认禁用拼写检查（spellcheck="false"）。
注意：不要为了“看起来像搜索框”而只靠 CSS 模拟——那只是视觉欺骗，丧失了所有语义与平台集成能力。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 移动端 iOS/Android 原生键盘右下角文字由
type决定，type="search"显示“搜索”，type="text"显示“前往”或“完成” - Chrome 对
type="search"会自动添加appearance: textfield，而某些自定义样式（如border-radius）需手动重置以避免双层圆角 - 若后端接口要求参数名为
keyword，就设name="keyword"，别硬套q——语义优先，但要服从 API 合约
清空按钮（×）不是 JS 加的，是浏览器原生行为
只要使用 <input type="search"> 且输入内容非空，Chrome、Edge、Safari 都会在右侧自动渲染清空按钮。它不依赖 JS，也不需要监听 input 事件手动控制显隐。
问题常出在 CSS 覆盖：比如写了 input::-webkit-search-cancel-button { display: none; } 却忘了给 Firefox 加 input::-moz-search-cancel-button，结果跨浏览器表现不一致。
- 清空按钮点击后，
input值清空并触发input事件，可直接监听做响应（如隐藏搜索建议面板） - 若需自定义清空逻辑（如同时清空 URL 参数），保留原生按钮，再用 JS 绑定
click事件即可，不必移除它 - Firefox 不支持
::-webkit-search-cancel-button，要用::-moz-search-cancel-button单独处理，或统一用 JS 实现（但会损失原生性能和可访问性）
提交行为必须明确指定 method 和 action，否则可能跳转到当前页
省略 action 时，表单默认提交到当前 URL；省略 method 时默认为 GET。这看似合理，但容易引发两个问题：一是搜索关键词暴露在 URL 中导致缓存/日志泄露，二是服务端未处理 GET 参数时返回 404。
更隐蔽的问题是：如果页面用了前端路由（如 React Router），<form> 默认刷新页面，直接破坏 SPA 体验。
- 纯前端搜索（如过滤列表）应加
onsubmit="event.preventDefault();"，再用 JS 拦截提交 - 服务端搜索必须设
action="/search"和method="GET"（利于分享、缓存、SEO） - 若用
POST，需确认后端是否接受 POST 提交的搜索请求——多数 RESTful 搜索接口只认 GET
name 就传不出参数，不包 <form> 就废掉回车提交，乱加 display: none 清空按钮就等于主动放弃一部分用户。 
