现代浏览器主动忽略autocomplete="off"对密码字段的设置，因其优先保障密码管理器体验；有效方案是语义化属性（如current-password）、dom干扰（隐藏fake_pwd字段）与动态创建输入框组合，并依赖服务端校验与pci合规方案。
autocomplete="off"为什么对密码字段完全无效
现代浏览器（Chrome 80+、Edge 105+、Safari 15.4+）主动忽略 autocomplete="off" 对 type="password" 字段的设置，不是你写错了，是浏览器故意跳过——它把密码管理器体验置于开发者指令之上。控制台甚至会报 warning，提示该属性已被弃用。
常见错误现象包括：登录页刷新后密码框自动填入旧密码；支付页的 name="cvv" 被塞进其他网站保存的 CVV 值；写 autocomplete="false" 或 autocomplete="nope" 等非标准值，部分浏览器直接降级为模糊匹配，反而更不可控。
真正起效的是语义化取值 + DOM 干扰 + 动态行为组合：
-
current-password用于登录页，明确告诉浏览器“这是当前账号的密码”，避免错填成其他保存账号 -
new-password用于注册或改密页，多数浏览器会禁用已有密码填充，并可能触发密码生成器 -
one-time-code用于短信/邮箱验证码，防止被当成普通文本填充
用隐藏干扰字段骗过浏览器自动填充扫描逻辑
浏览器自动填充时，会从上到下扫描 DOM，找到第一个 type="password" 元素就优先填进去。你可以利用这点“误导”，而不是硬对抗。
实操要点：
- 在真实密码框前插入一个
style="display:none;"的干扰字段，type="password"，autocomplete="new-password"，name="fake_pwd" - 干扰字段不能带
disabled或readonly（部分国产浏览器跳过），也不能用hidden属性或opacity:0（它们不参与解析） - 真实密码框初始设为
type="text"，在focus事件中再切换为type="password"，防止页面加载瞬间被预填充 - 服务端直接忽略
fake_pwd字段，不校验、不记录、不透传
动态创建敏感输入框绕过初始 DOM 解析阶段
自动填充主要发生在 HTML 解析和 DOM 构建阶段。如果敏感字段是 JS 加载完才插入的，浏览器大概率不会把它纳入候选列表。
关键操作：
- 不要在 HTML 源码里写死
<input type="password">，改用document.createElement('input')动态生成 - 插入前设置好
autocomplete、name、id，但类型可先设为text，交互时再改 - 若页面启用了 CSP，需提前配置
script-src，否则动态执行可能被拦截 - 移动端 WebView（如 iOS WKWebView）支持较稳定，但部分安卓 WebView 对
createElement后立即设置type的兼容性较差，建议加setTimeout(..., 0)微任务延迟
所有前端防填充手段都只是干扰识别，后端才是唯一防线
浏览器仍可能把值塞进 input，用户也可能粘贴、脚本注入、绕过 JS。前端任何技巧都不构成安全边界。
必须强制的服务端措施：
- 密码类字段：提交时必须强制重输（如二次确认密码）、或启用 OTP/生物认证等二次验证
- 银行卡号、CVV、身份证号：服务端做格式校验 + 长度限制（如 CVV 必须是 3–4 位数字） + 敏感词过滤（如检测是否含
card、cvv等明文字段名） - 支付类表单：务必使用 PCI DSS 合规方案（如 Stripe Elements、Checkout.js），确保敏感数据根本不经过你的服务器
- 不要依赖
autocomplete值判断字段是否被自动填充；要用服务端逻辑识别异常模式（如连续多条请求含相同 CVV+不同卡号）
最易被忽略的一点：干扰字段的 name 和 autocomplete 值一旦写错（比如大小写、连字符缺失、空格位置不对），浏览器就静默降级为历史字符串匹配——既没防住填充，又破坏了密码生成器的正常触发。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
