autocomplete="off"在现代浏览器中基本无效，因chrome、edge、firefox均基于语义启发式识别字段并忽略该属性；唯一可靠方案是密码类字段使用autocomplete="new-password"（需配合type="password"），旧密码用"current-password"，并辅以dom结构干扰、动态插入等组合策略。
autocomplete="off" 在现代浏览器中基本无效，尤其对 type="password"、name="email" 等字段，Chrome、Edge、Firefox 均会主动忽略它——这不是你代码写错了，而是浏览器有意为之。
为什么 autocomplete="off" 会被浏览器无视
浏览器的自动填充机制早已脱离“是否允许”的开关逻辑，转为基于语义的启发式判断。它会扫描 name、type、label、相邻字段顺序、表单上下文甚至 DOM 位置来识别字段用途。一旦判定是密码、银行卡号或身份证号，autocomplete="off" 就像没写一样。
- Chrome 控制台会直接报 warning：
"autocomplete='off' is not supported" - 表单提交后刷新，密码框仍被填入旧值，说明填充发生在渲染后、JS 执行前
- 即使
type="text"，只要name="cc-number"或 placeholder 含 “卡号”，也可能触发填充
autocomplete="new-password" 是密码类字段唯一靠谱的写法
W3C 规范明确定义了 new-password 的语义：该字段用于设置新密码，浏览器应禁用已有密码的自动填充。这是目前对注册页、修改密码页最稳定有效的方案。
- 必须配合
type="password"使用，单独设autocomplete="new-password"但type="text"无效 - 旧密码字段应设
autocomplete="current-password"，而非"off"——这反而能避免错填成其他账号密码 - 三个密码字段（旧/新/确认）要分别设置：
current-password、new-password、new-password - Safari 对
new-password支持较弱，若发现仍填充，可加name="pwd_new_2026"这类无意义 name 辅助干扰
绕过浏览器识别的实操组合策略
单一属性无法奏效，需从 DOM 结构、命名、加载时机三方面协同干扰。
- 在表单开头插入一个
display:none的隐藏输入框：<input type="password" autocomplete="new-password" style="display:none">——它会“骗过”浏览器字段排序逻辑，让真实密码框不被当作首个密码字段 - 移除或打乱
name和id：用name="field_z9k"替代name="password"；避免id="email"这类关键词 - 动态生成敏感 input：用 JS 在
DOMContentLoaded后插入，避开浏览器初始解析阶段的语义识别 - 对 contenteditable 编辑器（如 Monaco 封装的输入区），确保其内部
textarea没有name、id，且父容器不带role="textbox"+aria-label="password"组合
容易被忽略的兼容性与副作用
过度屏蔽可能带来反效果，尤其是测试常被跳过的边缘场景。
- 某些版本 Safari 会对
type="text"+autocomplete="new-password"误判为密码字段并拒绝聚焦——此时需改用autocomplete="nope"配合无name - 移除
name属性虽能降低匹配率，但会导致表单 submit 时该字段不被提交，务必用 JS 补充收集逻辑 - 用
setTimeout(() => { input.value = ''; }, 1)清空值，在部分 Chrome 版本中会触发重绘闪烁，且无法阻止 shadow DOM 中已注入的下拉建议层 - 无障碍访问可能受影响：若完全去掉
label或用aria-label模糊化，屏幕阅读器将无法准确传达字段用途
真正起作用的从来不是某个 magic attribute，而是让浏览器“认不出这是啥”。测试时别只看源码，要点开 Chrome DevTools → 右键输入框 → “检查”，看 shadow root 里有没有浏览器悄悄塞进去的 suggestion list。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
