现代浏览器不会真正关闭自动填充，只会按语义决定填什么、填到哪；autocomplete="off"基本失效，因chrome≥76、edge、safari主动忽略该属性，尤其对type="password"字段，转而采用current-password或new-password等标准值实现精准控制。
现代浏览器不会真正“关闭”自动填充，只会按语义决定填什么、填到哪——autocomplete="off"基本失效，但乱用autocomplete值反而会让密码填进邮箱框、把旧支付卡号塞进新地址栏。
为什么autocomplete="off"在密码字段里根本没用
Chrome ≥76、Edge、Safari 都会忽略它，尤其当字段是type="password"且周围有email或tel字段时。这不是 bug，是浏览器主动策略：防止开发者误关密码管理器的提示能力。
- 写
autocomplete="off"给密码框，Chrome 可能转而弹出“生成新密码”建议框 - 写
autocomplete="false"或autocomplete="nope"，部分 Chrome 版本会放弃识别，但 Safari 仍可能尝试匹配 - 真正有效的做法是用标准值：
autocomplete="current-password"（登录）或autocomplete="new-password"（注册/改密），二者被全平台支持且含义明确
autocomplete值写错等于没写
浏览器只认 WHATWG 规范里的标准 token，任何拼写偏差都会导致自动填充失效，且不报错、不警告，静默降级为历史字符串匹配（体验极差）。
-
autocomplete="Email"（大写 E）→ 被忽略 -
autocomplete="user_email"→ 当作无效值，等同于未设置 -
autocomplete="name"→ 不推荐；应拆为given-name+family-name，否则 Safari 拒绝建议 - 确认密码字段也必须设
autocomplete="new-password"，否则 Safari 可能复用上一次生成的密码填入两个框
动态表单和框架里最容易漏掉的三件事
React/Vue 渲染、JS 动态插入 input、SSR 后 hydration —— 这些场景下，autocomplete极易丢失或错位，浏览器扫描 DOM 时根本看不到语义。
- 用 JS 插入
<input>后，必须立刻设置autocomplete属性，不能靠后续setAttribute异步补——Safari 不识别延迟设置 - React 中用
value或v-model控制输入，但忘了显式写autocomplete="email"，浏览器就看不到语义 - SSR 页面中
autocomplete值和服务端一致，但 hydration 后前端状态更新导致 DOM 属性被抹除（比如清空value时连带删了autocomplete），Chrome 会重新扫描并意外激活填充
表单脱离<form></form>标签后，autocomplete语义基本失效
浏览器倾向只对语义化<form></form>内的字段启用智能填充。单独存在的input即使写了autocomplete="cc-number"，也大概率被跳过。
- 隐藏干扰字段必须是
type="password"，且不能带disabled或readonly（部分浏览器会跳过） - 用
style="display:none;"，而不是hidden属性或opacity:0——前者确保它参与解析，后两者仍可能被识别 - 真实密码框初始设为
type="text"，并在focus事件中切换为type="password"，防止页面加载瞬间被预填充
最常被忽略的点是：所有前端手段——包括动态创建、干扰字段、语义化取值——都只是干扰识别，不是阻断；后端仍须强制重输密码、校验二次因素、拒绝明文敏感字段提交，否则安全防线形同虚设。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
