autocomplete="new-password"并非关闭自动填充，而是提示浏览器该字段为新设密码、勿用旧密码填充；其常失效因浏览器仅在特定上下文中信任该属性，如Chrome 120+要求必须处于新账户注册流程且同域名无已保存密码记录，否则降级为off或忽略。
autocomplete="new-password" 不是“关掉自动填充”，而是告诉浏览器：“这是新设密码，别用我存过的旧密码填”。但它常失效，根本原因不是你写错了，而是浏览器只在特定上下文里才信它。
为什么autocomplete="new-password"经常被忽略
Chrome 120+ 和 Edge 要求该属性必须出现在「新账户注册流程」中，且页面不能已有同域名的已保存密码记录；否则直接降级为 autocomplete="off" 甚至完全无视。常见失效场景：
-
type不是"password"——autocomplete="new-password"在type="text"下基本无效 -
name或id含password、pwd、pass等关键词，浏览器会优先按语义匹配，绕过你的属性 - 表单里同时存在多个
type="password"字段（如旧密码 + 新密码 + 确认），但没配对标注语义（比如缺autocomplete="current-password"），浏览器因语义混乱而回退到默认行为 - 字段初始有
value，或 JS 在 DOM 加载前就设了值，Chrome 会认为“这已是用户输入”，触发填充逻辑
真正起效的组合写法（非单靠属性）
单写 autocomplete="new-password" 是弱信号，必须叠加 DOM 时机控制和语义隔离：
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 初始隐藏真实密码框：
style="display:none"或tabindex="-1"，等DOMContentLoaded后再显式设置type="password"并恢复显示 - 动态生成
name和id，比如name="pwd_7f3a9"，避开所有密码相关词 - 在真实密码框前插入一个干扰字段：
<input type="password" autocomplete="new-password" style="display:none">—— 浏览器会优先填充这个“假目标”，跳过你的真实字段 - 兜底加
autocomplete="off"（虽然规范弃用，但 Safari 和部分旧版仍响应，且与new-password不冲突）
Chrome 120+ 的关键限制与验证方式
新版 Chrome 对 autocomplete="new-password" 的信任门槛明显提高：
立即学习“前端免费学习笔记（深入）”；
- 仅在「注册页」或「首次创建账号」流程中被尊重；修改密码页几乎无效，此时应改用
autocomplete="current-password"配合 JS 清空逻辑 - 测试前必须清空该域名下所有已保存密码：Chrome 设置 → 密码 → 删除对应站点条目，否则填充行为不会重置
- 如果页面含登录表单（比如顶部导航栏带登录入口），新增的注册表单需确保 DOM 顺序靠后，且不与登录表单共用同一
<form></form>或 form 属性关联 - 避免用 CSS 伪装（如
-webkit-text-security: disc）替代type="password"—— Firefox 不支持该样式，且 Chrome 120+ 会拒绝识别为密码字段
最易被忽略的一点：浏览器不是“填错了”，而是“理解得太对”。它基于 name、type、label、DOM 位置综合推断字段用途，autocomplete 只是辅助信号。想让它听你的，就得先让它“认不出”这是密码字段。
