浏览器输入法行为由autocomplete属性控制，非系统开关或JS拦截；autocomplete="off"对单个input已基本失效，应改用无意义值如"nope"；密码框需分离语义，用text+遮罩与password双字段配合。
浏览器对表单控件的输入法自动开启行为，本质是由 autocomplete 属性控制的，不是靠系统输入法开关或 JS 拦截实现的。设错值或遗漏关键字段，会导致中文输入法在不该弹的时候弹、该弹的时候不弹——尤其在密码、搜索、多语言混合场景下特别明显。
autocomplete="off" 为什么经常失效
因为浏览器（尤其是 Chrome 80+、Edge 100+）已将 autocomplete="off" 视为“建议而非指令”。当字段有明确语义（如 type="email"、name="phone"），即使写了 autocomplete="off"，浏览器仍可能强行启用自动填充和输入法预测。
- 真正有效的写法是：给字段一个**无意义的 autocomplete 值**，比如
autocomplete="nope"或autocomplete="new-password"（仅对密码类有效） -
autocomplete="off"只对整个<form>标签生效较可靠，但对单个<input>已基本不可信 - 若字段是动态插入的 DOM，必须在插入后立即设置
autocomplete属性，延迟设置会被浏览器忽略
中文输入法强制开启的正确姿势
想让某个文本框默认激活中文输入法（比如搜索框、评论框），不能只依赖用户手动切换。关键是让浏览器识别它为“自由文本输入”且**不关联敏感语义**：
- 用
type="text"，避免type="search"或type="url"等带语义的类型 -
name属性不要用name="email"、name="tel"这类标准字段名；可改用name="query_text"、name="user_comment" - 显式设置
autocomplete="text"或autocomplete="on"—— 注意：这不是规范值，但部分浏览器会据此放松输入法限制 - 避免同时设置
autofocus和readonly，否则输入法根本不会唤起
密码框与输入法冲突的典型表现
用户在 <input type="password"> 中切出中文输入法后，再切回，光标常卡住、字符乱码，甚至触发浏览器自动填充覆盖用户输入。这是因为浏览器把密码字段视为高风险域，主动压制输入法行为。
立即学习“前端免费学习笔记（深入）”；
- 解决方案不是禁用输入法，而是**分离语义**：用两个字段，一个
type="text"+autocomplete="current-password"用于显示明文（带遮罩层），另一个type="password"+autocomplete="new-password"用于真实提交 - 绝对不要给密码字段设
autocomplete="off"—— 现代浏览器会把它当作“需要新密码”的信号，反而更激进地干预输入法 - 移动端 Safari 对
type="password"的输入法拦截最严，测试时务必真机验证
disabled 和 readonly 对输入法的影响差异
disabled 状态下，输入框完全失去焦点能力，输入法自然无法唤起；而 readonly 虽禁止编辑，但允许聚焦，因此输入法仍可能被意外触发（尤其在 iOS 上）。
- 如果目标是“暂时不让输但保留交互”，用
readonly+tabindex="-1"可阻止键盘和输入法聚焦 - 如果只是隐藏字段值但需提交，请用
<input type="hidden">，别用disabled或readonly文本框模拟 - JS 动态启用时，
element.readonly = false比删属性更稳定；element.disabled = false后，需手动element.focus()才能唤起输入法
输入法行为最终由浏览器引擎决定，HTML 层面只能引导，不能强制。最稳妥的做法是：语义命名诚实、autocomplete 值精准、type 类型匹配真实用途——绕开浏览器的智能猜测，比对抗它省力得多。
