autocomplete 属性并未失效，但其行为高度依赖浏览器实现、表单结构及语义化命名；它不直接控制“显示哪些历史值”，而是向浏览器提供语义提示，能否生效取决于 name/id、 包裹、提交按钮等多重条件。

`autocomplete` 属性并未失效，但其行为高度依赖浏览器实现、表单结构及语义化命名；它不直接控制“显示哪些历史值”，而是向浏览器提供**语义提示**，能否生效取决于 `name`/`id`、`

` 包裹、提交按钮等多重条件。

HTML 的 autocomplete 属性常被误解为“强制触发邮箱/姓名等特定历史记录填充”，实际上它是一个提示性（hint-based）标准，而非指令性 API。根据 WHATWG HTML 规范 和主流浏览器实践，autocomplete 的作用是向用户代理（浏览器）声明该字段的语义意图，从而协助其在符合隐私与安全策略的前提下，从本地存储的已知数据中匹配并建议填充内容。

✅ 有效前提（缺一不可）

• 输入框必须位于 <form></form> 元素内部（非孤立 <input>）；
• 必须具有有效的 name 属性（id 可辅助，但 name 是核心依据）；
• 表单应包含可提交的控件（如 <button type="submit"></button> 或 <input type="submit">）；
• autocomplete 值需符合规范定义的合法 tokens，例如 "email"、"given-name"、"current-password" 等——autocomplete="on email" 是非法值，将被完全忽略。

? 为什么你的测试无效？
你列出的多个失败示例（如 <input type="email" autocomplete="email">）缺失关键 name 属性，或未嵌套于 <form></form> 中。浏览器在缺乏语义锚点（name）时，无法将 autocomplete 提示与用户已保存的凭证/地址数据关联。而成功案例（如 <input type="email" name="email">）之所以生效，并非因 autocomplete="email" 起作用，而是因为 name="email" 本身已被浏览器广泛识别为邮箱字段标识——autocomplete 在此仅为冗余强化。

? 最佳实践写法（推荐）

Email Submit

✅ 同时满足：<form></form> 包裹、name="email"（语义主键）、autocomplete="email"（标准提示）、存在提交按钮。

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

⚠️ 重要注意事项

• id 不足以驱动自动填充：仅靠 id="email" 无法触发邮箱建议，name 才是浏览器匹配历史数据的核心字段；
• 复合值慎用：如 autocomplete="section-spouse email" 属于高级分组场景，实际支持度极低，多数浏览器会降级处理或忽略；
• 隐私策略优先：现代浏览器（尤其启用了“防跟踪”或“严格 Cookie 策略”的环境）会主动抑制自动填充，即使标记正确；
• 密码字段有特殊规则：<input type="password"> 若前序兄弟节点 name="username"，浏览器将自动赋予 autocomplete="current-password"，无需显式声明。

? 总结
autocomplete 属性依然完全有效且被所有主流浏览器支持（caniuse 数据 显示 100% 支持），但它不是“开关”，而是“标签”。真正决定自动填充效果的是：语义化的 name + 正确的表单结构 + 浏览器自身的启发式策略。与其过度依赖 autocomplete 值，不如优先确保 name 属性准确反映字段用途（如 name="email"、name="billing-postal-code"），再辅以合规的 autocomplete 值作为增强提示——这才是稳定、可维护、符合标准的表单构建方式。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！