chrome从64版起无视autocomplete="off"对密码等敏感字段的设置，因其主动“纠正”开发者行为；替代方案是用autocomplete="new-password"或混淆语义值。
autocomplete="off" 为什么在 Chrome 里不生效？
Chrome 从版本 64 起就无视 autocomplete="off" 对密码类输入框（type="password"）和部分敏感字段（如 email、tel）的设置，这是浏览器主动“纠正”开发者行为，目的是防止用户因禁用自动填充而反复输错密码或漏填关键信息。
常见现象：你写了 autocomplete="off"，但点击输入框时仍弹出历史邮箱/密码建议；或者表单提交后，Chrome 自动记住并下拉填充——这并非 bug，而是策略性忽略。
- Chrome 优先信任
autocomplete的语义值（如"username"、"new-password"），而非"off" - 对
type="text"类输入，autocomplete="off"多数情况下仍有效；但一旦涉及登录、注册流程，浏览器会降级处理 - Firefox 和 Safari 行为更接近标准，但新版 Safari 也逐步收紧对
"off"的支持
真正能阻止自动填充的替代方案
绕过浏览器策略的关键是“误导”自动填充逻辑：让浏览器无法识别字段用途，或明确声明该字段不参与密码管理流程。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 对密码输入框，改用
autocomplete="new-password"（不是"off"）——这是 Chrome 官方推荐方式，表示“此处用于设置新密码”，浏览器不会填充已保存密码 - 对用户名/邮箱等字段，可加随机字符串混淆语义，例如：
autocomplete="username-123abc"或autocomplete="nope"（只要不是标准 token，Chrome 就放弃匹配） - 动态修改
name和id属性（如用 JS 在 DOM 加载后重设），也能打断自动填充的字段关联链 - 极端情况可禁用整个表单的自动填充：
<form autocomplete="off"></form>，但注意：现代浏览器同样可能忽略它，且仅对非密码字段有有限效果
input type="password" + autocomplete="new-password" 的坑
这个组合看似稳妥，但实际容易踩两个隐形雷：
- 如果页面中存在另一个
type="password"且autocomplete值为"current-password"或空值，Chrome 可能把"new-password"字段当作“确认密码”并错误填充——务必确保同一表单内所有密码字段的autocomplete值语义清晰、互斥 - 某些旧版 Android WebView 或 Electron 应用仍把
"new-password"当作普通文本处理，导致密码明文显示（需配合type="password"才生效） - 不要写成
autocomplete="new-password "（末尾空格）或autocomplete="New-Password"—— 浏览器严格区分大小写和空格，只认小写无空格的"new-password"
需要服务端配合的终极手段
前端手段总有边界。当业务强要求禁止任何客户端记忆（比如金融类一次性验证码输入框），唯一可靠方式是服务端干预：
- 生成带时间戳或随机 suffix 的
name属性，如name="otp_20240521_abc123"，每次加载都不同，浏览器无法建立字段映射 - 配合 HTTP 响应头
autocomplete: off（注意：这不是标准头，仅部分浏览器实验性支持；更通用的是Cache-Control: no-store防止表单数据被缓存） - 对敏感字段，可在 focus 事件中用 JS 清空
value并调用inputElement.setAttribute('autocomplete', 'off')，但这只是障眼法，不能阻止下拉菜单出现
真正难搞的从来不是属性怎么写，而是浏览器和密码管理器之间那层没写进规范的默契——你得先猜它想填什么，再想办法让它觉得“这栏不对劲”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
