autocomplete属性不是开关而是语义标签，仅告知浏览器字段用途以匹配历史记录；设错值如“user-email”等同于未设置，密码框必须用“new-password”或“current-password”才有效。
autocomplete 属性不是开关，而是语义标签——它不“开启/关闭自动填充”，只告诉浏览器“这个框该匹配哪类历史记录”。设错值（比如 autocomplete="user-email"）等于没写，浏览器直接当 off 处理；设对了但没配对 type 或脱离 <form> 上下文，照样不触发。
为什么 autocomplete="off" 在密码框里根本不起作用
Chrome ≥76、Edge、Safari 都会无视它，尤其当字段是 type="password" 且表单中存在其他敏感字段（如 email）时。这不是 bug，是浏览器主动策略：防止开发者误关密码管理器的提示能力。
- 写
autocomplete="off"给密码框，Chrome 可能转而弹出“生成新密码”建议框 - 写
autocomplete="false"或autocomplete="nope"，部分版本 Chrome 会放弃识别，但 Safari 可能仍尝试匹配 - 真正有效的做法是：用
autocomplete="new-password"（注册/改密）或autocomplete="current-password"（登录），二者都合法、被全平台支持，且含义明确 - 如果字段只是“确认密码”，也必须设
autocomplete="new-password"，否则 Safari 可能复用上一次生成的密码填入两个框
autocomplete 值必须严格匹配 WHATWG 规范
浏览器只认标准 token，比如 email、given-name、street-address、cc-exp。任何拼写偏差（大小写、连字符、自定义前缀）都会导致失效。
-
autocomplete="Email"（大写 E）→ 被忽略 -
autocomplete="user_email"→ 当作无效值，等同于未设置 -
autocomplete="name"→ 不推荐，应拆为given-name+family-name，否则 Safari 拒绝建议 -
type="text"+autocomplete="email"可行，但不如type="email"+autocomplete="email"触发稳定
动态表单和框架里最容易漏掉的三件事
React/Vue 渲染、JS 动态插入 input、服务端首次渲染（SSR）后 hydration —— 这些场景下，autocomplete 极易丢失或错位。
立即学习“前端免费学习笔记（深入）”；
- 用 JS 插入
<input>后，必须立刻设置autocomplete属性，不能靠后续 setAttribute 异步补 —— Safari 不识别延迟设置 - React 中用
value或v-model控制输入，但忘了显式写autocomplete="email"，浏览器就看不到语义 - SSR 页面中
autocomplete值和服务端一致，但 hydration 后前端状态更新导致 DOM 属性被抹除（比如清空 value 时连带删了 autocomplete），Chrome 会重新扫描并意外激活填充 - 表单脱离
<form>标签（例如纯 UI 组件内独立 input），哪怕属性全对，浏览器也大概率不触发建议
最常被忽略的细节是：autocomplete 生效不靠“有没有写”，而靠“写得准不准 + 放得对不对 + 出现在什么时候”。一个 given-name 写成 firstname，或一个 new-password 被 SSR 和 CSR 渲染不一致，问题就会在 Safari 或 Edge 上静默出现，且难以复现。
