autocomplete="off"常失效，因chrome≥76等浏览器会忽略它，优先依据type/name语义自动填充；密码字段应改用autocomplete="new-password"，文本字段需配合随机name、隐藏假字段等策略干扰识别。
autocomplete 属性不是用来“增强体验”的开关，而是浏览器是否从本地历史中拉取旧值并展示下拉建议的控制开关。它不触发远程请求，也不做校验或补全逻辑——只管“要不要显示你填过的那些记录”。
为什么 autocomplete="off" 有时不生效
浏览器（尤其是 Chrome 和 Edge）会忽略 autocomplete="off"，特别是对 type="password" 或 type="email" 这类敏感字段。这不是 bug，是主动策略：防止开发者误关安全提示。
- Chrome 从 v76 起，只要表单里有 password 字段，就会无视全局
autocomplete="off" - 某些浏览器把
autocomplete="nope"或autocomplete="false"当作无效值，仍按on处理 - 如果
<form></form>设了autocomplete="on"，而某个<input>设autocomplete="off"，后者通常能生效；但反过来（form off + input on）不一定
autocomplete 的合法值只有 on 和 off 吗
不是。HTML5 允许更细粒度的语义化取值，比如 autocomplete="email"、autocomplete="given-name"、autocomplete="cc-number"。这些值本身不会禁用自动填充，反而会**强化匹配精度**——告诉浏览器“这个框填的是邮箱”，它就只从邮箱历史里捞。
- 有效值必须是规范定义的 token，如
name、organization、postal-code，完整列表见 WHATWG HTML spec - 写错值（如
autocomplete="user-email"）会被当作off处理 - 设成语义值后，即使没关自动填充，也能避免“把上次填的身份证号塞进银行卡号框”这类错配
想彻底禁用自动填充，还能做什么
没有 100% 可靠的方法，但组合手段能大幅降低触发概率。关键是让浏览器“认不出这是常规表单字段”。
- 把
type="text"改成type="search"或type="tel"（视场景而定），部分浏览器对非标准 type 不启动 autocomplete - 动态生成
name和id，比如加时间戳或随机字符串：name="email_1714393482"，破坏历史匹配依据 - 聚焦时清空
value并设readonly，再在focus后立即移除：<input autocomplete="off" readonly onfocus="this.removeAttribute('readonly'); this.value='';"> - 对密码字段，可额外加
autocomplete="new-password"——这是被广泛支持的特殊值，明确表示“这不是登录，是注册新密码”
服务端渲染或框架里要注意什么
React/Vue/Svelte 等框架在 SSR 或 hydrate 阶段若未同步 autocomplete 属性，会导致首屏渲染时属性缺失，之后 JS 补上也晚了——浏览器已在初始解析时决定是否启用自动填充。
- Next.js 的
app/目录中，确保autocomplete出现在服务端生成的 HTML 中，而不是仅靠客户端 useEffect 设置 - ASP.NET Web Forms 的
TextBox.AutoCompleteType枚举（如AutoCompleteType.Disabled）最终也输出为autocomplete="off"，同样受前述浏览器策略限制 - 如果用
inputmode或spellcheck等辅助属性，它们不影响 autocomplete 行为，别指望靠它们绕过
真正难处理的从来不是怎么写 autocomplete，而是浏览器在不同版本、不同字段类型、不同上下文（登录页 vs 注册页 vs 修改密码页）下对同一属性的差异化解释。多测几个主流浏览器的真实行为，比死磕 spec 更管用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
