Chrome 68–92 对 autocomplete="new-password" 支持不稳定：68–75仅注册/改密页有效，76–92遇name="password"等仍可能降级填充；93+起需动态name且立即设置，否则失效；iOS Safari长期不支持且长按粘贴绕过所有前端校验。
Chrome 68–92 对 autocomplete="new-password" 的识别情况
Chrome 68 开始正式支持 autocomplete="new-password"，但行为不稳定：早期版本（68–75）仅在注册/改密页有效，登录页若误用会触发“保存密码”提示；76–92 版本虽能识别该值，但遇到 name="password" 或 id="pwd" 仍可能降级为自动填充已存密码。关键点是——它不拒绝填充，只“建议不填”，浏览器有最终决定权。
为什么 Chrome 93+ 才算真正可用
Chrome 93 起引入两项硬性约束：
-
autocomplete="new-password"必须配合动态生成的name属性（如name="pwd_abc123"），否则仍可能被绕过 - DOM 插入后必须立即设置该属性，延迟哪怕 1ms（比如在
setTimeout或DOMContentLoaded后设），浏览器就按初始状态（如type="text"）完成自动填充判定 - 若同时存在多个
type="password"字段，仅第一个会被用于密码对匹配，其余字段即使设了new-password也大概率被忽略
iOS Safari 的特殊坑：长按粘贴无视前端校验
iOS 15.4 之前版本对 autocomplete="new-password" 完全不响应，直接当普通 input 处理；更麻烦的是，用户长按粘贴时，会跳过 pattern、maxlength 甚至 JS 的 input 事件监听，直接插入超长或非法内容。这意味着：
- 服务端必须做二次校验，不能依赖前端限制
- 若用
-webkit-text-security: disc模拟密码框，iOS 粘贴后仍显示明文（直到失去焦点才转为圆点），视觉上已泄露 - 不要指望
onpaste阻止——iOS Safari 中该事件触发时内容早已写入 value
Firefox 和旧版 Chrome 兼容 fallback 方案
Firefox 至今不认 new-password，而 Chrome ≤ 92 对双声明兜底逻辑支持不一致。最简实效组合是：
- 表单级加
autocomplete="off"，所有input再单独加autocomplete="new-password"（部分浏览器取后者，部分取前者） - 隐藏一个
type="password"的空输入框（position: absolute; left: -9999px;），放在真实密码框之前，干扰浏览器的“账号+密码”配对逻辑 - 初始设
type="text"+-webkit-text-security: disc，聚焦时再切为type="password"—— 这招对 Chrome 80+ 和 Firefox 78+ 都有效，但需注意安卓 WebView 键盘唤起异常问题
真正难处理的不是属性写法，而是浏览器把“密码字段”当作一种上下文信号——只要 DOM 结构、命名、位置稍有暗示，它就自行决定是否填充。防不住时，不如接受它，转而加固服务端校验和粘贴后的内容清洗逻辑。
