autocomplete="new-password"有时无效，因其仅在type="password"且上下文合理（如配对current-password字段）时被浏览器信任；Chrome 120+更要求新旧密码成对出现才生效，否则可能忽略该属性。
为什么 autocomplete="new-password" 有时不起作用
浏览器对 autocomplete 的处理越来越严格，尤其在密码字段上。单纯写 autocomplete="new-password" 并不能保证禁用自动填充——它只在“该字段明确用于设置新密码”时才被浏览器当作可信信号；如果字段类型不是 password、或者前后没有合理上下文（比如没配对的旧密码字段），Chrome 和 Edge 可能直接忽略它。
- 必须配合
type="password"使用，type="text"下加autocomplete="new-password"基本无效 - 不要给该字段预设
value或通过 JS 初始化值，否则 Chrome 会认为这是“已有内容”，可能触发填充逻辑 - 避免在表单内同时存在多个
type="password"字段却未标注语义（如旧密码、新密码、确认密码），浏览器会因语义混乱而回退到默认行为
真正阻止自动填充的组合写法
单靠 autocomplete 属性不够，需要叠加 DOM 时机与属性隔离。核心思路是：让浏览器在渲染完成前“看不见”这个字段，或让它脱离自动填充的识别路径。
- 初始状态用
display: none或移出 tab 顺序（tabindex="-1"），JS 在DOMContentLoaded后再显式设为type="password"并恢复显示 - 字段名避开敏感词：
name="newpwd"比name="password"更安全；更彻底的做法是动态生成 name（如name="pwd_12345"） - 加上
autocomplete="off"作为兜底（虽然规范已不推荐，但 Safari 和部分旧版仍响应它），和autocomplete="new-password"不冲突，可共存
示例：
<input
type="text"
id="new-pass-field"
autocomplete="off"
name="pwd_<script>document.write(Date.now())</script>"
/>
<script>
document.addEventListener('DOMContentLoaded', () => {
const el = document.getElementById('new-pass-field');
el.type = 'password';
el.style.display = 'block';
});
</script>
Chrome 120+ 对 autocomplete="new-password" 的新限制
从 Chrome 120 开始，仅当表单中存在至少一个带 autocomplete="current-password" 的字段时，new-password 才会被认真对待。换句话说：浏览器现在要求“新旧密码成对出现”才启用该策略。
立即学习“前端免费学习笔记（深入）”；
- 如果你只有“设置新密码”页面（无旧密码输入），Chrome 会无视
autocomplete="new-password"，并可能强行填充上次保存的密码 - 临时解法：加一个隐藏的旧密码字段（
type="password"+autocomplete="current-password"+style="position:absolute;clip:rect(0 0 0 0);"） - 注意：该隐藏字段不能有
name，否则可能被后端误收；也不能有value，否则触发填充
比禁用更可靠的做法：接受自动填充但控制行为
完全阻止自动填充在现代浏览器中越来越不可靠，反而容易引发 UX 断层。更务实的方式是允许填充，但确保它不破坏逻辑。
- 监听
input或change事件，检查是否为浏览器自动填充（可通过event.inputType === 'insertFromPaste'或检测连续字符输入节奏粗略判断） - 提交前校验：若字段值等于用户最近一次保存的密码（需服务端配合），提示“请勿重复使用当前密码”
- 对关键操作（如修改密码）强制二次确认，比如要求输入当前密码，而不是只依赖前端禁填
自动填充本身不是漏洞，失控的字段语义和缺失的业务校验才是问题根源。
