autocomplete="new-password" 经常失效是因为它只是语义信号而非开关，需满足Chrome 120+要求（同表单含current-password）、type必须为password、无预设value等上下文条件，单一属性无效，须结合隐藏字段、动态name、type延迟切换等混淆策略。
autocomplete="new-password" 为什么经常失效
它不是开关，而是语义信号——浏览器只在“上下文合理”时才响应。Chrome 120+ 要求表单中同时存在 autocomplete="current-password" 字段，否则直接跳过识别；type 必须是 password，type="text" 下加该属性基本被无视；字段若预设了 value（包括 JS 初始化），浏览器会认为“已有内容”，反而触发填充逻辑。
真实有效的干扰组合写法
单一属性靠不住，得让浏览器“认不出这是密码字段”。推荐按优先级使用以下手段：
- 在真实密码框前插入隐藏干扰字段：
<input type="password" style="display:none;" autocomplete="new-password" name="fake_pwd">（不能加disabled或readonly，否则部分国产浏览器跳过） - 真实字段初始设为
type="text"，等DOMContentLoaded后再用 JS 改为type="password" -
name避开password、pwd、pass等关键词，改用动态值如name="pwd_<script>document.write(Date.now())</script>" - 仍可共存
autocomplete="off"作为 Safari 和旧 WebView 的兜底，不冲突
容易被忽略的 DOM 时机与结构问题
自动填充主要发生在 HTML 解析和 DOM 构建阶段。以下情况会让所有策略失效：
- 表单脱离
<form>标签——autocomplete语义基本失效，浏览器倾向只对语义化<form></form>内字段启用智能填充 - React/Vue 中 SSR hydration 后，
autocomplete属性容易丢失或错位：JS 插入<input>后必须立即设置autocomplete，不能靠后续setAttribute补 - 移动端或框架里，
focus事件中切换type可能被 Safari 拦截，需加setTimeout延迟或 fallback 到 CSS 伪装（-webkit-text-security: disc）
别把按钮当靶子
autocomplete 对 <button> 或 <input type="button"> 完全无效——规范明确只作用于可编辑控件。用户点“登录”后弹出填充菜单，根子在它前面的 <input>，不是按钮本身。常见错误是给按钮加 autocomplete="off"，却放任密码框用 name="password" + type="password" 暴露语义。
立即学习“前端免费学习笔记（深入）”；
真正起效的从来不是“阻止”，而是“引导”或“混淆”：让浏览器把填充行为导向一个无害位置，或让它压根无法建立字段语义映射。最常被漏掉的一点是——哪怕你用了全部前端手段，只要服务端没校验、没做防重放、没走 PCI 合规流程，前端干扰就只是纸糊的防线。
