autocomplete="off"在密码字段中无效是浏览器主动策略而非bug，Chrome≥76等浏览器会忽略该属性以保障密码管理器功能，应改用autocomplete="current-password"或"new-password"并确保语义正确、位于form内且上下文合理。
autocomplete="off" 为什么在密码字段里根本不起作用
Chrome ≥76、Edge、Safari 都会忽略 autocomplete="off"，尤其当字段是 type="password" 且周围有 email 或 tel 字段时。这不是 bug，是浏览器主动策略：防止开发者误关密码管理器的提示能力。
常见错误现象包括：
- 刷新登录页后，
type="password"输入框自动出现上次登录的密码 - 控制台报 warning：
"autocomplete='off' is not supported" - 支付页的
input name="cvv"被填入其他网站保存的 CVV（尽管设了autocomplete="off"）
实操建议：
- 永远不要单独使用
autocomplete="off"作为安全手段 - 对登录表单，改用
autocomplete="current-password"—— 明确告诉浏览器“这是当前账号的密码” - 对注册/改密页，用
autocomplete="new-password"，浏览器会主动跳过已有密码记录 -
autocomplete值写错等于没写：拼写偏差（如autocomplete="Email"、autocomplete="user_email"）会被静默忽略，不报错也不警告
动态插入 input 后 autocomplete 属性丢失的典型场景
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> 标签后 autocomplete 语义失效
浏览器倾向只对语义化 <form></form> 内的字段启用智能填充。一旦 <input> 被移出 <form>（例如地图搜索组件、弹窗地址选择器、无表单封装的独立输入框），autocomplete 基本失效，即使值正确也大概率不触发填充。
实操建议：
- 确保关键字段（如
street-address、postal-code）位于合法<form>内部 - 若必须脱离
<form>（如第三方 SDK 封装），需额外插入一个隐藏的、语义正确的干扰字段：<input type="password" style="display:none;" autocomplete="new-password">放在真实密码框之前 - 避免同时加
disabled或readonly到隐藏干扰字段，部分国产浏览器会跳过它
autocomplete 值选错引发的跨字段错填风险
autocomplete 不是开关，而是一套语义协议。选错值会导致浏览器“理解错你的意图”，比如把验证码当密码填、把银行卡号当地址填、把旧支付卡号塞进新地址栏。
实操建议：
- 确认密码字段也必须设
autocomplete="new-password"，否则 Safari 可能复用上一次生成的密码填入两个框 -
name="name"不推荐；应拆为given-name+family-name，否则 Safari 拒绝建议 -
autocomplete="Email"（大写 E）→ 被忽略；autocomplete="email"（全小写）才有效 - 支付类字段优先用标准值：
cc-number、cc-exp、cc-csc，而非自造词如cardno或cvv_code
最常被忽略的一点是：表单字段的上下文位置比单个属性更重要。浏览器靠相邻字段推断语义，所以即使你写了正确的 autocomplete，如果前后字段类型混乱（比如 type="text" 后紧跟 type="password" 却没有 email 字段铺垫），填充结果依然不可控。
