autocomplete="new-password"是密码框最可靠的写法，它明确告知浏览器该字段用于新密码而非旧账号密码，且仅对type="password"有效，需在每个input上单独设置。
autocomplete="new-password" 是密码框最可靠的写法
对 type="password" 的输入框，autocomplete="off" 基本无效——Chrome 从 2014 年起就明确忽略它，转而用启发式规则判断是否填充。真正被 Chrome、Edge、Firefox 官方文档认可且稳定生效的值是 autocomplete="new-password"。它不表示“关闭”，而是告诉浏览器：“这是个新密码字段，别拿旧账号密码来填”。
必须注意两点：
-
autocomplete="new-password"只对type="password"有效；对普通文本框（如用户名）设这个值，浏览器可能直接无视 - 不能只写在
<form>上，必须每个需要控制的<input>单独设置，否则会被子元素的显式声明覆盖 - 如果同时用了
v-model（Vue）或value受控，需确保初始渲染时属性已存在，否则 JS 后续补上autocomplete属性来不及阻止填充
非密码字段得“骗过”浏览器语义识别
用户名、手机号、邮箱这类字段，即使写了 autocomplete="off"，只要 name="email" 或 type="email"，Chrome 仍大概率自动填充。核心思路不是关，而是让浏览器认不出这是什么字段。
实操组合如下：
立即学习“前端免费学习笔记（深入）”；
- 把
autocomplete设为无意义字符串，例如autocomplete="nope"或autocomplete="false"（注意：是字符串，不是布尔值） -
name和id避免使用语义化关键词，改用name="user_contact_2026"而非name="email" - 若业务允许，把
type="email"改成type="text"；type="tel"改成type="text"，可大幅降低触发概率 - 不要依赖 CSS
display: none隐藏辅助字段——浏览器仍会识别并填充；要用width: 0; height: 0; opacity: 0; position: absolute;彻底脱离渲染流
readonly + JS 解锁是最暴力但有效的兜底方案
当以上方法在特定环境（如老旧 MiniUI 组件、WebView 内嵌页）仍失效时，readonly 是目前兼容性最强的兜底手段。原理是：浏览器自动填充只作用于可编辑字段，readonly 状态下它连尝试都不做。
关键细节：
- HTML 初始加载时就必须带
readonly，不能等 JS 执行完再加——填充逻辑发生在 DOM ready 前 - 解锁时机要卡在用户聚焦前，例如绑定
@focus或onfocus事件，立即移除readonly并调用inputElement.focus()保持光标位置 - 该方案无法阻止聚焦时弹出的自动填充下拉菜单，仅阻止字段被预填值；如需彻底隐藏下拉菜单，还得配合样式屏蔽（如
input::-webkit-credentials-auto-fill-button）
动态切换 type="text" → type="password" 的陷阱
用 type="text" 初始化、聚焦后再切为 type="password"，确实能绕过部分浏览器的登录表单识别逻辑，但实际落地问题很多。
典型风险点：
- 页面加载后、用户聚焦前，密码明文暴露在 DOM 中，有被 XSS 或录屏工具捕获的风险
- 如果服务端要求 URL 参数预填密码，会出现“先明文显示 → 再变圆点”的闪烁，体验割裂
- 某些 WebView（如微信内置浏览器）会在
type切换瞬间重绘输入法键盘，导致光标错位或输入中断 - Vue/React 中若用
v-model或受控组件，type切换可能触发额外的 re-render，引发值丢失或校验错乱
真正难处理的不是“怎么禁用”，而是浏览器填充决策发生在 focus 之前、DOM 渲染之后、JS 可干预之前——所有方案都是在时间差里抢跑，没有银弹。最稳的做法，是把 autocomplete、name、type 三者作为一套组合策略同步配置，而不是只改其中一个。
