autocomplete="off"对密码字段无效，现代浏览器直接忽略并依据语义值（如current-password、new-password）自动填充；前端干扰仅治标，后端校验与pci合规才是关键防线。
autocomplete="off"为什么拦不住密码自动填充
它根本不是开关，而是被现代浏览器（Chrome 80+、Edge 105+、Safari 15.4+）当作无效提示直接忽略的字符串。尤其对type="password"字段，浏览器会主动跳过该属性，转而依据name、DOM位置、上下文（比如旁边有email输入框）触发填充。
常见现象包括：刷新登录页后密码框自动出现旧密码；控制台报warning: "autocomplete='off' is not supported"；甚至填错——把注册页的new-password框当成登录框塞进历史密码。
-
autocomplete="off"只对非敏感文本字段（如搜索框）偶有作用，对密码、CVV、身份证号等字段基本失效 - 写在
<form></form>上完全没用，浏览器只认<input>、<textarea></textarea>、<select></select>上的声明 - JS 动态设置
input.autocomplete = "off"也无效，填充决策发生在 DOM 渲染阶段，早于 JS 执行
真正起效的 autocomplete 语义值怎么选
浏览器靠语义值决定“填什么、填到哪”，不是靠type="password"本身。写错或漏掉，等于主动邀请填错。
- 登录页密码框必须用
autocomplete="current-password"——告诉浏览器“这是当前账号的凭证”，避免复用其他站点记录 - 注册页、改密页、确认密码框统一用
autocomplete="new-password"——表示“这是新凭证，不填旧的，且允许保存” -
autocomplete="one-time-code"专用于短信/邮箱验证码，禁用密码管理器，且不会被保存 - 避免拼写错误：
autocomplete="Email"、autocomplete="user_email"、autocomplete="password"全都不被标准支持，静默降级为历史字符串匹配
干扰浏览器识别逻辑的实操手段
既然不能硬关，就引导它填错地方——利用浏览器 DOM 扫描顺序和字段识别弱点做干扰。
- 在真实密码框前插入一个
<input type="password" style="display:none;" autocomplete="new-password">，浏览器会优先填这个隐藏框 - 初始设
type="text"，用户聚焦时再用 JS 改为type="password"（注意 Safari 对此兼容性较差） - 给
name和id加随机后缀，比如name="pwd_9f3a"、id="pass_x7k2"，避开password/pwd/pass等启发式关键词 - 动态创建输入框：用
document.createElement('input')生成，而非写死在 HTML 中，绕过初始解析阶段的自动填充判断
前端干扰只是表层，后端才是最后防线
所有前端策略都防不住用户粘贴、右键“填充密码”、脚本注入或绕过 JS 的行为。浏览器仍可能把值塞进 input，你看到的“没填”只是没在加载时自动填。
- 服务端必须对所有敏感字段做二次校验：
CVV必须是 3–4 位纯数字、cardNumber需通过 Luhn 算法、idCard要验证位数与校验码 - 不要依赖
autocomplete值判断是否被自动填充；应监控异常模式，比如同一 IP 短时间内提交多条含相同 CVV 但不同卡号的请求 - 涉及支付场景，必须使用 PCI DSS 合规方案（如 Stripe Elements），让敏感数据根本不经过你的服务器
最容易被忽略的是：表单脱离<form></form>标签后，autocomplete语义基本失效；浏览器倾向只对语义化<form></form>内的字段启用智能填充。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
