autocomplete="new-password"有时不生效，因Chrome等浏览器优先识别name/type等语义而非该属性，须配合type="password"、避免敏感命名、拆分表单、动态设置或加隐藏干扰字段协同解决。
autocomplete="new-password" 为什么有时不生效
浏览器对 autocomplete 的处理越来越严格，尤其在密码类字段上——单纯写 autocomplete="new-password" 并不能保证禁用自动填充，特别是当表单里存在其他 type="password" 字段或历史提交记录时，浏览器仍可能强行注入值。根本原因在于：Chrome、Edge 等基于 Chromium 的浏览器会优先识别字段语义（如 name、id、type）而非仅依赖 autocomplete 属性。
- 必须配合
type="password"使用，type="text"即使设autocomplete="new-password"也常被忽略 -
name和id值不能包含password、pass、pwd等关键词，否则浏览器会“无视”你的autocomplete设置 - 若页面已有真实密码字段（比如登录表单），新增的
new-password字段需确保 DOM 顺序靠后，且不与旧字段形成逻辑组（例如不要放在同一个<form>内共用 submit）
绕过浏览器自动填充的实操组合拳
单靠 autocomplete="new-password" 不够稳健，需要叠加干扰策略。核心思路是让浏览器“认不出这是密码字段”，同时阻断其 autofill 触发时机。
- 把输入框
type设为"text"，用 CSS 伪装成密码框：input { -webkit-text-security: disc; }（注意 Safari 支持，Firefox 不支持） - 在
DOMContentLoaded后动态设置autocomplete="new-password"，避免初始渲染时被预判 - 添加随机
name和id（如name="pwd-field-123abc"），并移除所有可能暗示密码语义的 class 名（如class="password-input"） - 如果字段用于防重复提交（如二次确认密码），可改用
type="text"+inputmode="text"+autocomplete="off"（虽然规范已弃用off，但部分场景仍有效）
Chrome 120+ 对 autocomplete="new-password" 的新限制
新版 Chrome 要求：只有当字段明确属于「新账户注册流程」且前后无已保存的同域名密码记录时，autocomplete="new-password" 才会被尊重。否则它会降级为 autocomplete="off"，甚至直接忽略。
- 测试时务必清空该域名下的密码管理器数据（Chrome 设置 → 密码 → 删除对应站点条目）
- 若页面是修改密码页（非注册页），
new-password几乎无效，此时应改用autocomplete="current-password"配合 JS 清空逻辑 - DevTools 的 Application → Passwords 面板可查看当前页面实际被匹配到的密码项，便于验证是否真被绕过
真正禁用提示的底线方案：JS 动态控制
当 HTML 层面失效时，唯一可靠的方式是用 JavaScript 切断浏览器 autofill 的触发链。这不是“最佳实践”，但在支付、风控等关键场景下不得不做。
立即学习“前端免费学习笔记（深入）”；
- 监听
input和focus事件，在首次聚焦后立即执行el.value = ""（注意：不能在DOMContentLoaded就清空，否则影响用户粘贴） - 使用
setTimeout(() => el.select(), 0)配合document.execCommand("insertText", false, "")（已废弃但仍有兼容性）强制重置输入状态 - 更稳妥的做法是：用
contenteditable="true"替代input，再通过oninput同步到隐藏input，彻底脱离 autofill 检测范围
