autocomplete属性是语义提示而非开关，现代浏览器无视autocomplete="off"对密码字段的设置，应改用autocomplete="new-password"禁用填充，且需确保字段位于form内、初始DOM即含该属性、type与语义协同。
表单字段被自动填充的典型现象
用户没输密码，input[type="password"] 里已经显示星号；用户名框刚聚焦就弹出下拉历史账号；Chrome 地址栏右侧出现钥匙图标——这些都不是“贴心”，而是浏览器在未经你代码授权的情况下，把 autocomplete 值塞进了表单字段。问题在于：如果这个页面是公共终端（如酒店前台电脑、网吧），或者表单本该禁用自动填充（比如重置密码页、2FA 输入页），那这些预填内容就直接暴露了用户敏感信息。
autocomplete 属性到底控制了什么
它不是开关，而是一组语义化提示，告诉浏览器“这个字段想存/读哪类数据”。浏览器按自己的策略决定是否响应。常见值有：off、new-password、current-password、username、email 等。但要注意：
-
autocomplete="off"在现代浏览器中基本失效，Chrome 从 76 版起就无视它对密码字段的设置 -
autocomplete="new-password"是目前唯一被主流浏览器（Chrome/Firefox/Safari）一致尊重的禁用填充指令，仅适用于新建密码场景 - 字段顺序和
name属性名会影响识别：比如name="user"+autocomplete="username"容易触发填充，而name="loginId"就可能绕过 - 隐藏字段（
type="hidden"）若带autocomplete，也可能被浏览器记录并反向影响可见字段
真实漏洞场景与修复动作
排查不能只看 HTML 源码，得结合浏览器行为验证：
- 打开 DevTools → Application → Clear storage → 清空 “Autofill” 和 “Passwords” 数据，再刷新页面测试是否还自动填充
- 检查所有
input是否显式设置了autocomplete，尤其注意密码重置页的两个密码字段：第一个应为autocomplete="new-password"，第二个（确认密码）也必须设成同样值，否则浏览器可能把第一个的值填进第二个 - 避免用
type="text"伪装密码框，哪怕加了autocomplete="off"，Chrome 仍会根据上下文识别为密码字段并填充 - 动态生成的表单（如 JS 插入的登录弹窗）容易漏掉
autocomplete设置，需确保插入 DOM 时一并带上属性
为什么加随机 name 和 id 不可靠
有人用 name="pwd_123abc" 或 id="pass-field-456" 试图混淆浏览器识别逻辑。这招短期可能有效，但风险极高：
立即学习“前端免费学习笔记（深入）”；
- Chrome 已支持基于 DOM 结构、label 关联、前后字段类型组合的智能推断，不依赖
name - 某些版本 Safari 会回退到
id或placeholder文本匹配，写placeholder="输入新密码"反而强化了识别 - 一旦用户手动保存过该组合（比如在测试环境点过“保存密码”），后续即使改了
name，浏览器仍可能基于页面 URL 和字段位置恢复填充
真正可控的手段只有两条：明确使用 autocomplete="new-password"（新建场景）或彻底移除密码字段的可填充上下文（比如用 contenteditable + 自定义输入框，但代价是失去原生校验和无障碍支持）。
