现代浏览器无视autocomplete="off"，因将其视为安全策略而非bug；有效方案是动态切换type、混淆name/ID并配autocomplete="new-password"（注册/改密）或"current-password"（登录），禁用value预填充，避免DOM重建触发重填。
密码输入框仍被浏览器自动填充？autocomplete="off" 不管用
现代浏览器（chrome、edge、firefox）基本无视 autocomplete="off"，尤其对 <input type="password">。这不是 bug，是主动策略——浏览器认为“用户明确想存密”，强行禁用反而损害安全体验（比如诱导用户写明文密码到记事本）。所以单纯加 autocomplete="off" 无效，甚至可能触发更激进的自动填充逻辑。
- 真正起效的是让浏览器「认不出这是密码字段」：用
type="text"+ 输入时动态切换为type="password"，或混淆 name/ID（如name="pwd_field_123"） - 必须配合
autocomplete="new-password"（不是"off"）用于注册/改密场景；登录页则建议保留真实语义，靠其他手段弱化自动填充干扰 - 某些 Chrome 版本会对
autocomplete="new-password"的同域相邻文本框（如用户名）也尝试填充，需检查 DOM 顺序和 focus 行为
服务端生成的密码字段被 autofill 覆盖？后端模板里埋坑了
常见于 Django/Jinja/Thymeleaf 等模板直接输出 value="{{ user.password }}"，即使加了 autocomplete="off"，浏览器仍会把已保存的密码塞进这个有值的 <input>。关键不是属性，而是「字段已有初始值」+「类型为 password」这个组合触发了强制填充。
- 绝对不要在密码输入框的
value属性里渲染任何内容（包括空字符串value=""），删掉它 - 如果必须预填充（如编辑用户信息），改用 JavaScript 动态赋值：
inputEl.value = ""后再inputEl.focus()，避开 DOM 初始化阶段 - Spring Boot Thymeleaf 示例：
<input type="password" th:attr="autocomplete='new-password'" />，不加th:value
Vue/React 中密码框反复被覆盖？框架重渲染触发 autofill
单页应用里，组件 re-render 可能导致 input 元素被销毁重建，浏览器把这次“新出现的密码框”当作独立字段，重新执行自动填充。尤其在表单校验失败、错误提示更新后，input 失去焦点又恢复，极易触发。
- 给密码 input 加稳定
key（如:key="'password-input-1'"），避免无谓重建 - 在
mounted或useEffect里手动清空 value：inputRef.current.value = ""，且仅执行一次（加 flag 控制） - React 中慎用
defaultValue，它只在首次渲染生效，但若父组件传入的 props.password 是空字符串，仍可能被浏览器识别为“可填充字段”
为什么加了 autocomplete="new-password" 还弹出旧密码？
autocomplete="new-password" 本意是告诉浏览器：“这是一个需要用户新建密码的字段”，理论上应抑制填充。但它只在「当前页面没有同名密码字段」且「浏览器判定该字段处于创建/修改流程」时才可靠。一旦页面存在其他 type="password" 字段（比如登录框残留、隐藏的重置密码区），或 URL 被识别为登录页（如路径含 /login），策略就失效。
- 检查页面是否意外存在多个 password input（包括
display:none的） - 避免在登录页使用
new-password，它更适合注册页或密码修改页；登录页用autocomplete="current-password"反而更可控 - Chrome 117+ 对
new-password的处理更严格：要求字段必须位于<form>内，且 form 的action非空或含 submit 按钮
最麻烦的其实是「浏览器凭肉眼判断字段用途」——哪怕你把 name 改成 not_password_at_all，只要它出现在邮箱输入框下方、带锁图标、CSS 类叫 pw-field，照样填。这时候就得接受：完全阻止不现实，重点是别让它填错地方。
