Chrome旧版支持new-password吗？

autocomplete="new-password" 在 Chrome 中的支持远非“写了就生效”——从 Chrome 46 初步识别，到 68–92 版本的混乱行为（仅特定页面有效、遇常见 name/id 仍降级填充），再到 93+ 的严苛要求（必须动态 name + 零延迟设置），其实际效果高度依赖版本、DOM 时机与上下文；更棘手的是 iOS Safari 长期无视该属性，且用户长按粘贴可绕过所有前端校验，Firefox 则至今不支持。真正可靠的方案不是死磕属性写法，而是组合表单级 autocomplete="off"、隐藏干扰字段、type 动态切换等 fallback，并将安全防线坚决后移到服务端校验与粘贴内容清洗——因为浏览器永远比你更“懂”什么是密码字段。

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 结构、命名、位置稍有暗示，它就自行决定是否填充。防不住时，不如接受它，转而加固服务端校验和粘贴后的内容清洗逻辑。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~