autocomplete="off" 无效是因浏览器忽略该值，真正有效的是 autocomplete="new-password" 配合 autocapitalize="none"、autocorrect="off"、spellcheck="false" 等属性组合，减少输入法语义线索。
input 标签里 autocomplete="off" 不管用？
这是最常见误解：以为加了 autocomplete="off" 就能屏蔽输入法的搜索建议。实际上，现代浏览器（尤其 Chrome、Safari iOS）会忽略这个值，尤其当 type="text" 或 type="search" 时，输入法仍会基于字段名、上下文推测意图并展示搜索候选。
真正起效的是更具体的语义化属性：
-
autocomplete="none"比"off"稍强一点，但 iOS Safari 仍可能无视 -
autocomplete="new-password"是目前最稳定的“伪装方案”——让浏览器误判为密码字段，从而禁用输入法的搜索联想（注意：不是真的设成密码，type保持"text"） - 配合
autocapitalize="none"和autocorrect="off"，进一步削弱输入法干预
为什么 type="search" 反而更容易触发搜索引擎建议？
因为 type="search" 明确告诉浏览器和输入法：“这是搜索框”，iOS 键盘顶部会直接显示搜索按钮 + 历史词，Android 输入法也倾向推送热词。这不是 bug，是规范行为。
如果只是普通文本输入（比如地址、用户名、备注），别用 type="search"。换成 type="text"，再叠加语义欺骗：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
<input type="text" autocomplete="new-password" autocapitalize="none" autocorrect="off" spellcheck="false">
其中 spellcheck="false" 能关掉拼写下划线和纠错候选，对中文影响小，但对双语混合场景有用。
iOS 键盘顶部的搜索条怎么干掉？
那个横条（含“搜索”按钮和历史词）由 form 的 action 和 method 触发，尤其是当 <form></form> 包裹了 input 且 method="get" 时，iOS 会认定这是搜索表单。
- 去掉外层
<form></form>，改用 JS 手动提交 - 如果必须用
<form></form>，把method改成"post"（iOS 对 post 表单不显示搜索条） - 或者给
<form></form>加role="application"，让辅助技术绕过表单语义，间接影响输入法判断
安卓输入法（如 Gboard）还有搜索候选？
安卓更依赖输入法自身策略，浏览器控制力更弱。除了前面的属性组合，关键在「不给输入法任何线索」：
- 避免
name和id出现search、q、query、keyword等关键词 - 不要用
placeholder="搜索..."—— Gboard 会读取 placeholder 判定用途 - 动态生成 input（比如用 JS 插入）有时能绕过初始识别，但不可靠，仅作备选
真正稳定的做法是接受「无法 100% 屏蔽」，把重点放在不让输入法干扰用户输入逻辑上：比如监听 input 事件时忽略合成事件（event.isComposing），防止中文输入中途触发校验。
输入法不是 DOM，它运行在系统层；我们能做的，是减少暴露给它的语义信号，而不是试图“关闭”一个不存在的开关。
