autocomplete属性不是开关，写错值（如email、user-email、name）等于无效；必须严格使用whatwg标准小写token，且input需在初始dom中、包裹于内、type与autocomplete协同匹配。
autocomplete 属性不是开关，写错值（比如 Email、user-email、name）等于没写，浏览器直接跳过自动填充——兼容设置的核心不是“加不加”，而是“每个字段是否在初始 DOM 中就带标准语义 + 正确 type + 合理结构”。
必须用 WHATWG 标准值，大小写/连字符/拼写全错即失效
浏览器只认规范定义的 token，不接受自然语言或经验推导。常见错误和对应写法如下：
-
email✅ 有效；Email、user-email、mail❌ 被忽略 -
given-name和family-name✅ Safari 填充稳定；first-name、lastname、name❌ 在 Safari 中基本不触发 -
street-address✅；address、shipping-address❌ -
postal-code✅；zip、postcode、pincode❌ -
current-password和new-password✅；password、pwd、false❌
type 和 autocomplete 必须协同，不能只靠其中一个
仅设 autocomplete="email" 但 type="text"，触发率远低于 type="email" + autocomplete="email"。Safari 尤其依赖 type 的语义强度：
-
type="email"+autocomplete="email"→ 邮箱键盘 + 建议最稳 -
type="tel"+autocomplete="tel"→ 手机号填充准确率明显更高 -
type="date"+autocomplete="bday"→ 才能唤起生日历史建议 -
type="number"+autocomplete="postal-code"→ Chrome 会禁用自动填充，改用type="text"或type="tel" -
type="search"、type="url"、type="hidden"→ 不支持任何autocomplete值
动态渲染和框架里最容易漏掉的三件事
React/Vue 渲染、JS 动态插入 input、SSR 后 hydration —— 这些场景下 autocomplete 极易失效，因为浏览器只在初始 DOM 加载时扫描字段：
- 用
{show && <input>}或v-if动态渲染 → 字段挂载时机晚于浏览器初始化阶段，填充失效 - JS 插入
<input>后再setAttribute('autocomplete', 'email')→ Safari 不识别延迟设置 - SSR 输出 HTML 时未直出
autocomplete属性 → 客户端补上完全无效 - 同一页面多个字段共用相同
autocomplete值（如两个都写tel）→ 浏览器随机选一个填，行为不可控
密码字段必须区分 current-password 和 new-password
Chrome ≥76、Edge、Safari 都会无视 autocomplete="off"，尤其在 type="password" 场景下。这不是 bug，是主动策略：
- 登录页密码框必须写
autocomplete="current-password"，且需与username或email字段共存（顺序相邻更稳） - 注册/改密页的密码框和“确认密码”框都得设
autocomplete="new-password"，否则 Safari 可能复用上一次生成的密码填进两个框 -
new-password不代表“生成密码”，只是语义标记：告诉浏览器“别填已有记录，允许在此保存新密码” - 不要给密码字段设
value={state}双向绑定初始值，否则填充后 React 会覆盖浏览器填入的内容
真正难的不是写对 autocomplete 值，而是理解浏览器把它当“提示”而非“指令”——它有权无视你，也有权在你没预料的时候突然弹窗。字段必须在初始 DOM 就完整、语义正确、包裹在 <form></form> 内，缺一不可。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
