autocomplete属性是向浏览器声明字段语义而非直接触发填表，仅w3c标准值如name、email、tel、current-password、new-password等被识别，大小写敏感且不可变体；错配type与autocomplete、脱离form结构、动态插入未同步属性、多字段无区分或safari对非标值严格忽略均导致失效。
HTML 的 autocomplete 属性不是“让浏览器自动填表”，而是向浏览器声明：“这个字段代表什么语义”，浏览器据此决定是否、以及用哪条历史记录来建议或填充。配错值，等于没写。
哪些 autocomplete 值浏览器真认
只认 W3C 定义的标准值，非标准字符串（如 user_email、myname）会被直接忽略：
-
name：全名（不拆 first/last；浏览器按用户保存的完整姓名匹配） -
email：必须搭配type="email"，写成type="text"会降级触发率 -
tel、street-address、postal-code、country -
current-password：仅用于登录页的密码框，告诉浏览器“这是要验证的老密码” -
new-password：注册或改密时的密码/确认密码框，提示浏览器生成新密码、不复用旧存档 -
off可用于单个字段，但全局禁用请慎用——它可能被现代浏览器无视（尤其 Chrome）
type 和 autocomplete 必须对得上号
两者错配是自动填充失效最常见原因：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
<input type="email" autocomplete="username">→ Safari 直接跳过建议 -
<input type="password" autocomplete="off">→ Chrome 仍可能在密码管理器弹窗里显示该字段 -
<input type="text" autocomplete="email">→ 能工作，但不如原生type="email"触发稳定 - 动态插入的
<input>（如 React/Vue 渲染后），需确保autocomplete属性在 DOM 插入后立即存在，否则 Safari 不识别
为什么写了正确值，浏览器还是不填
即使语法和值都对，以下情况也会导致自动填充静默失败：
- 表单脱离
<form></form>标签上下文（比如用<div> 包裹所有 input） <li>JS 在页面加载后清空或重设 <code>input.value，打断浏览器填充时机 - 多个同类型字段未区分优先级：两个邮箱应分别用
autocomplete="email"和autocomplete="home email"（部分浏览器支持） - 地址类字段混用：用
autocomplete="shipping address"这种自定义拼写，浏览器无法识别；应拆为autocomplete="street-address"+autocomplete="address-level1" - label 缺失或仅靠
placeholder提示：没有显式<label for="id"></label>关联，可访问性和基础识别都会打折 - Safari 对
address-level1/address-level2支持较好，但对province或city这类非标值完全无视 - iOS 上若表单无明确
action或method，部分版本 Safari 会拒绝触发填充 - 密码字段若同时设
autocomplete="new-password"且 JS 绑定v-model或value，必须显式写出autocomplete，框架不会帮你补
移动端和 Safari 的兼容性特别容易翻车
Chrome 相对宽容，会结合 name、id、前后 DOM 结构猜测；Safari 则严格依赖 autocomplete 值本身是否精准：
真正起效的关键，从来不是“加了属性”，而是“每个字段都在语义、type、DOM 结构、命名一致性上协同对齐”。漏掉任意一环，浏览器就当没看见。
