results 属性已被所有主流浏览器弃用，对搜索建议无任何影响；控制建议需依赖 autocomplete 和 name，跨浏览器稳定方案应使用 datalist 或 JS 自实现下拉，并确保无障碍支持。
input type="search" 的 results 属性早已被弃用，不要在现代项目中使用
Chrome 从 92 版本起、Firefox 从未支持、Safari 早在 2018 年就移除了对 results 的实现——这个属性现在纯属历史残留。它曾试图控制搜索建议下拉列表最多显示几条（如 results="5"），但实际行为不可靠：既不强制截断，也不影响浏览器是否显示建议，更不参与无障碍读取。
当前所有主流浏览器都忽略该属性。写 <input type="search" results="3"> 和写 <input type="search"> 效果完全一样。
真正控制搜索建议显示的，只有 autocomplete 和 name
浏览器是否弹出历史建议下拉，只取决于两个条件：
-
type="search"+autocomplete值不是"off"（即autocomplete="on"、autocomplete="search"，或干脆不写） -
name属性存在且非空（如name="q"；没name的 search 输入框，Firefox/Chrome 都不会记录或回显历史）
注意：autocomplete="search" 在 Safari 中会优先展示搜索历史，在 Chrome 中效果与 "on" 几乎无差别；而 autocomplete="off" 会彻底禁用所有建议（包括地址栏联想）。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
想跨浏览器稳定控制建议？只能自己实现
依赖原生建议注定失败：Firefox 自 2025 年起默认关闭 type="search" 的建议列表，Chrome/Safari 行为也不一致。如果业务要求“必须有下拉建议”，就得放弃 results 这类幻觉属性，转向可控方案：
- 用
<datalist>：仅支持静态选项，不触发浏览器历史，且无法键盘导航（↑↓Enter 不生效） - 用 JS 实现下拉：监听
input事件 + 防抖 + AbortController 清理未完成请求 + 手动管理焦点和键盘操作（Enter 提交、Esc 关闭、↑↓ 切换选项） - 别忘了给自定义下拉加
role="listbox"、选项加role="option"，否则屏幕阅读器无法识别
移动端“搜索”键触发提交，跟 results 完全无关
手机键盘上点击“搜索”“前往”或回车键能触发表单提交，靠的是 type="search" 的语义 + <form method="get"> 的默认行为，不是 results。只要 input 在 form 内、没阻止默认行为，回车就会提交。
容易踩的坑：
- JS 中监听
keydown时忘记e.preventDefault()，导致页面跳转或重复提交 - 用
event.key === "Enter"判断，但部分安卓键盘发的是"enter"小写（稳妥做法是e.key.toLowerCase() === "enter"） - 清空按钮点击后没手动触发
input事件，导致绑定的过滤逻辑不更新
真正需要操心的是语义、可访问性和行为一致性，不是那个早就没人管的 results。
