autocomplete属性不控制是否填充，只声明字段语义；密码框设off无效，须用current-password或new-password；值必须严格符合whatwg规范；需包裹在form内且动态插入时须同步设置。
浏览器自动填充不是“开关式功能”，而是基于语义识别的匹配行为——autocomplete 属性不控制“是否填充”，只告诉浏览器“这个框该填哪类数据”。设错值、脱离上下文、或忽略密码字段特殊规则，都会导致填充失效或触发反效果。
为什么 autocomplete="off" 在密码框里完全没用
Chrome ≥76、Edge、Safari 会主动忽略 autocomplete="off"（尤其是 type="password" 字段），这是策略性设计，防止开发者误关密码管理器。更糟的是：写 autocomplete="off" 可能让 Chrome 转而弹出“生成新密码”建议；写 autocomplete="false" 或 autocomplete="nope" 则属于非法值，部分浏览器直接跳过识别。
- 真正有效且跨平台的密码字段写法只有两个：
autocomplete="current-password"（登录页）和autocomplete="new-password"（注册/改密页） - “确认密码”字段也必须用
autocomplete="new-password"，否则 Safari 可能复用上一次生成的密码填进两个框 - 若表单中同时存在
email和password字段，浏览器会优先激活密码管理器逻辑，off更无意义
autocomplete 值必须严格匹配 WHATWG 规范
浏览器只认标准 token，大小写、连字符、前缀、空格任一偏差都会被当作无效值，等同于未设置。例如：
-
autocomplete="Email"→ 首字母大写 → 被忽略 -
autocomplete="user_email"→ 下划线 + 自定义前缀 → 无效 -
autocomplete="name"→ 含义模糊 → Safari 拒绝建议，应拆为given-name+family-name -
autocomplete="cc-exp"→ 正确（信用卡有效期），但写成cc-expiry或cc-expiration就失效
推荐优先使用明确语义值：email、tel、street-address、postal-code、country、cc-number 等。
动态插入 input 或框架渲染时最容易丢掉 autocomplete
React/Vue 渲染、JS 动态插入 <input>、SSR 后 hydration —— 这些场景下，autocomplete 极易丢失或错位。关键问题不是“怎么加”，而是“什么时候加”。
- 用 JS 插入
<input>后，必须在插入 DOM 的**同一轮同步操作中**设置autocomplete属性；异步调用setAttribute（如 setTimeout 或 Promise.then）在 Safari 中不被识别 - React 中即使用了
value或v-model控制输入，也必须显式写autocomplete="email"，否则浏览器看不到语义 - SSR 页面中服务端输出了
autocomplete="email"，但 hydration 后前端状态更新清空value时，若顺手删了整个属性（比如用el.removeAttribute('autocomplete')），Chrome 会重新扫描并意外激活填充
表单脱离 <form></form> 标签就基本等于放弃自动填充
autocomplete 依赖表单上下文才能生效。单独一个 <input autocomplete="email"> 即使写了正确值，在多数浏览器中也不会触发邮箱建议。
- 必须包裹在
<form></form>内，且<form></form>最好有action和method（哪怕只是占位） - 如果业务逻辑强制不用
<form></form>（比如纯 JS 提交），可用<form style="display:none"></form>包一层隐藏表单，把 input 移进去，不影响样式但恢复语义上下文 -
<datalist></datalist>是另一套机制（客户端本地建议），和autocomplete无关，不能替代它解决密码/邮箱等敏感字段的跨站点填充需求
最常被忽略的一点：autocomplete 不是“填完就完”，它依赖浏览器对字段用途的稳定判断——一旦语义模糊、结构松散或动态失配，填充行为就会退化成随机猜测，甚至引发安全提示干扰用户。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
