autocomplete="off" 拦不住现代浏览器密码填充，因其被Chrome 80+、Edge 105+、Safari 15.4+视为弱提示并忽略；应改用autocomplete="current-password"或"new-password"等语义化值，并配合干扰字段、动态type切换等策略引导填充。
autocomplete="off" 为什么根本拦不住密码填充
现代浏览器（Chrome 80+、Edge 105+、Safari 15.4+）已将 autocomplete="off" 视为弱提示，尤其对 type="password" 字段——它们会直接忽略该属性，优先依据 name、type、DOM 位置和上下文语义触发填充。你看到密码框被填入旧密码，不是 bug，是浏览器在“履行安全职责”：它认为密码管理器比手输更可靠。
常见错误现象包括：
- 刷新登录页后，
type="password"输入框自动出现上次登录的密码 - 支付页的
input name="cvv"被填入其他网站保存的 CVV（尽管设了autocomplete="off"） - 控制台报 warning：
"autocomplete='off' is not supported"
实操建议：
- 永远不要单独使用
autocomplete="off"作为安全手段 - 对登录表单，改用
autocomplete="current-password"—— 明确告诉浏览器“这是当前账号的密码”，避免错填成其他账户 - 对注册/改密页，用
autocomplete="new-password"，浏览器会主动跳过已有密码记录
干扰浏览器识别逻辑的三种有效手段
浏览器自动填充时，会扫描 DOM 寻找第一个 type="password" 元素并优先填充它。你可以利用这个行为做“误导”，而不是硬对抗。
立即学习“前端免费学习笔记（深入）”；
推荐组合策略（按可靠性排序）：
- 插入隐藏干扰字段：
<input type="password" style="display:none;" autocomplete="new-password">放在真实密码框之前 - 动态切换 type：初始设
type="text"，onfocus时再改为type="password"（注意 Safari 对此有兼容性限制） - 去语义化 name/id：
name="pwd_8a2f"、id="pass_field_x9"，避免使用password、pwd、pass等关键词
注意：干扰字段必须是合法 HTML 元素（不能 display:none 同时又 disabled 或 readonly，否则部分国产浏览器会跳过）。
autocomplete 值选错反而引发新风险
autocomplete 不是开关，而是一套语义协议。选错值会导致浏览器“理解错你的意图”，比如把验证码当密码填、把银行卡号当地址填。
关键参数差异：
-
autocomplete="one-time-code"：专用于短信/邮箱验证码，禁用密码管理器，且多数浏览器不会保存该值 -
autocomplete="off"：仅建议不填充，但对敏感字段基本无效；对非敏感字段（如搜索框）可能误禁用户常用词 -
autocomplete="cc-csc"：明确标识 CVV 字段，某些浏览器会主动屏蔽填充（比off更精准）
性能与兼容性影响：
- 滥用
autocomplete="off"可能导致密码管理器无法正常工作，用户被迫手输弱密码，实际降低安全性 -
autocomplete="new-password"在 iOS Safari 中需配合type="password"才生效，单独使用无效
前端防填充只是第一层，后端才是真正的防线
所有前端手段都可被绕过：禁用 JS、手动修改 DOM、抓包重放。真正决定安全边界的，是服务端是否校验、是否绑定上下文、是否引入二次确认。
必须做到的后端强制措施：
- 所有密码类字段，服务端必须校验是否与当前用户账号匹配（不能只校验格式）
- 高风险操作（如改密、转账）必须校验 CSRF token，且 token 绑定 session + 时间戳
- 敏感字段（如银行卡号）需服务端校验 BIN 号、Luhn 算法，并拒绝明文回传
- 禁止在前端 JS 中暴露任何加密密钥、token 或原始密码逻辑
最易被忽略的一点：自动填充本身不是漏洞，失控的填充才是。重点不在“阻止”，而在“引导”——让浏览器把数据填到你设计好的、无害的位置，同时确保填进去的内容，服务端根本不认。
