autocomplete属性是语义标签而非开关，必须严格匹配whatwg规范；错误值如email、user-email等被浏览器忽略；姓名需拆为given-name/family-name；密码须区分current-password/new-password；type与autocomplete须协同使用；动态表单中需确保初始dom即含正确语义。
直接说结论：autocomplete 属性不是开关，而是语义标签；写错值（比如 user-email、Email、name）等于没写，浏览器直接跳过自动填充。
autocomplete 值必须严格匹配 WHATWG 规范
浏览器只认标准 token，大小写、连字符、拼写偏差全算错。常见字段对应关系如下：
-
email有效，UserEmail、user_email、Email全无效 - 姓名必须拆成
given-name和family-name，name是模糊值，Safari 拒绝填充 - 地址行用
street-address，不是address或shipping-address - 手机号用
tel，telephone或mobile不被识别 - 省/市分别用
address-level1和address-level2，province或city无效
密码字段必须区分 current-password 和 new-password
Chrome ≥76、Edge、Safari 都会无视 autocomplete="off"，尤其在 type="password" 场景下。这不是 bug，是主动策略。
- 登录页密码框必须写
autocomplete="current-password"，且需与username或email字段共存 - 注册/改密页的密码框和“确认密码”框都得设
autocomplete="new-password"，否则 Safari 可能复用上一次生成的密码填进两个框 -
new-password不代表“生成密码”，只是语义标记：告诉浏览器“别填已有记录，允许在此保存新密码” - 写
autocomplete="false"或autocomplete="nope"属于无效 hack，部分 Chrome 版本放弃识别，但 Safari 仍可能尝试匹配
type + autocomplete 必须协同，不能只靠其中一个
仅写 autocomplete="email" 但 type="text"，触发率远低于 type="email" + autocomplete="email"。Safari 尤其依赖 type 的语义强度。
-
type="email"+autocomplete="email"→ 邮箱建议最稳定 -
type="tel"+autocomplete="tel"→ 手机号填充准确率明显更高 -
postal-code字段若用type="number"，Chrome 会禁用自动填充，必须用type="text"或type="tel" -
type="password"字段如果没配对autocomplete，浏览器可能强行填入错误密码（比如把注册新密码塞进登录框）
动态表单和框架里最容易漏掉的三件事
React/Vue 渲染、JS 动态插入 input、SSR 后 hydration —— 这些场景下 autocomplete 极易失效，因为浏览器只在初始 DOM 加载时扫描字段。
- 用 JS 插入
<input>后，必须立刻设置autocomplete属性，不能靠后续setAttribute异步补；Safari 不识别延迟设置 - React 中用
value控制输入，但忘了显式写autocomplete="email"，浏览器就看不到语义 - SSR 页面中
autocomplete值和服务端一致，但 hydration 后前端状态更新导致 DOM 属性被抹除（比如清空value时连带删了autocomplete），Chrome 会重新扫描并意外激活填充 - Vue 中避免用
v-bind:autocomplete="computedValue"，模板里直接写死autocomplete="given-name"最可靠
真正关键的不是“要不要开自动填充”，而是字段是否在 DOM 初始加载时就带着正确、完整、成对的语义信息出现——哪怕只差一个连字符，或少一个 form 包裹，浏览器就当它不存在。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
