autocomplete="off"对密码字段无效是浏览器主动安全策略，现代浏览器忽略该属性并优先启用密码管理器；真正有效的是语义化autocomplete值（如current-password）、DOM干扰（隐藏fake_pwd字段）及动态创建输入框。
单独写 autocomplete="off" 对密码、银行卡等字段完全无效，现代浏览器（Chrome 80+、Edge 105+、Safari 15.4+）会直接忽略它，甚至在控制台报 warning。真正可控的方式是语义化取值 + DOM 干扰 + 动态行为组合，但所有前端手段都只是干扰识别，不是阻断——后端二次验证仍是不可替代的防线。
为什么 autocomplete="off" 在密码字段上必然失效
这不是浏览器 bug，而是主动策略：厂商认定密码管理器比手输更安全，尤其在防钓鱼和弱密码复用场景下。当你给 type="password" 的输入框设 autocomplete="off"，Chrome 可能转而弹出“生成新密码”建议框；Safari 则可能静默跳过该属性，继续按 name 和上下文填充。
- 常见错误现象包括：刷新登录页后密码框自动出现旧密码、支付页的
name="cvv"被填入其他网站保存的 CVV -
autocomplete="false"、autocomplete="nope"等非标准值，部分 Chrome 版本会放弃识别，但 Safari 仍尝试匹配，不可靠 - 真正有效的标准值只有
current-password（登录）、new-password（注册/改密）、one-time-code（验证码）等 WHATWG 规范定义的 token
autocomplete 值写错等于没写，且不报错
浏览器只认大小写、连字符、语义完全匹配的标准值。写错一个字母或放错上下文，它就静默降级为历史字符串匹配——体验差，还可能引发误填风险。
-
autocomplete="Email"（大写 E）→ 被完全忽略 -
autocomplete="user_email"→ 当作无效值，等同于未设置 -
autocomplete="name"→ 不推荐；应拆为given-name+family-name，否则 Safari 拒绝建议 - 确认密码字段也必须设
autocomplete="new-password"，否则 Safari 可能复用上一次生成的密码填入两个框
用隐藏干扰字段骗过浏览器 DOM 扫描逻辑
浏览器自动填充时，会从上到下扫描 DOM，找到第一个 type="password" 元素就优先填进去。你可以利用这个行为“误导”，而不是硬对抗。
立即学习“前端免费学习笔记（深入）”；
- 插入一个
style="display:none;"的干扰字段，type="password"，autocomplete="new-password"，放在真实密码框之前 - 干扰字段不能加
disabled或readonly（部分国产浏览器跳过），也不能用hidden属性或opacity:0 - 真实密码框初始设为
type="text"，在focus事件中再切换为type="password"，防止页面加载瞬间被预填充 - 干扰字段的
name别用password，比如叫fake_pwd，服务端直接忽略该字段
动态创建输入框绕过初始解析阶段
自动填充主要发生在 HTML 解析和 DOM 构建阶段。如果敏感字段是 JS 加载完才插入的，浏览器大概率不会把它纳入候选列表。
- 不要在 HTML 源码里写死
<input type="password">，改用document.createElement('input')动态生成 - 插入前必须立刻设置好
autocomplete、name、id，类型可先设为text，交互时再改 - 若页面启用了 CSP，需提前配置
script-src，否则动态脚本可能被拦截 - 移动端 WebView（如 iOS WKWebView）支持较稳定，但某些旧版安卓 WebView 可能 fallback 到初始解析逻辑
最常被忽略的一点是：表单脱离 <form> 标签后，autocomplete 语义基本失效；浏览器倾向只对语义化 <form></form> 内的字段启用智能填充。还有就是 React/Vue 渲染、SSR hydration 后，autocomplete 属性容易被清空或错位——这些场景下，浏览器扫描 DOM 时根本看不到语义。
