autocomplete 属性必须严格使用 whatwg 规范定义的值才有效，如 street-address、address-level2、address-level1、postal-code；name 可省略但 autocomplete 必须准确，且表单需在 form 内、字段曾被聚焦并至少成功提交一次。
autocomplete 属性填什么才真有效
浏览器只认 WHATWG 规范里定义的 autocomplete 值，填错就等于没写。比如地址字段必须用 street-address，不能写成 address 或 addr；城市必须是 address-level2（不是 city），省是 address-level1，邮编是 postal-code。
常见踩坑点：
-
name属性可以省略，但autocomplete必须有且准确——只设name="email"不触发填充 -
autocomplete="off"已被 Chrome 117+、Safari 忽略，真要禁用密码字段得用autocomplete="new-password" - 移动端 Safari 对
address-level2支持弱，可额外加name="city"提升识别率 - 邮编字段若设
type="number"，Chrome 会直接禁用自动填充，得改用type="text"或type="tel"
表单结构不合规，自动填充根本不会触发
自动填充不是“写了属性就生效”，它依赖明确的上下文：必须在 <form></form> 标签内，用户需主动聚焦过该字段，且该表单至少成功提交过一次（浏览器才记录并复用数据）。
典型失效场景：
- 表单用 Vue/React 动态渲染，
<input>节点挂载后用户立刻点击——DOM 尚未稳定，浏览器来不及绑定填充逻辑 - 字段被包裹在
autocomplete="off"的父级<form></form>或<div> 中（部分浏览器会继承禁用） <li>地址字段用一个 <code><textarea></textarea>代替多个<input>，浏览器无法拆解语义，street-address等值无效 - 密码字段紧跟在邮箱字段后面，中间没视觉或 DOM 分隔，Chrome 可能误把邮箱凭据填进密码框
- 服务端输出前必须做 HTML 实体编码，
htmlspecialchars($email, ENT_QUOTES, 'UTF-8')，防 XSS - 若用 JS 动态填充，避免直接
el.value = data.email，应先清空再赋值，否则和浏览器自动填充冲突 - 数据库字段为空时，
value属性不要留空字符串，应完全省略——<input value="">和<input>渲染行为不同，前者可能覆盖用户已输入内容 - 中文地址字段即使代码全对，也可能空白——因为多数国内用户没在 Chrome 设置里存过完整中文地址，这不是代码问题，是数据源缺失
- 数字类：邮编用
inputmode="numeric"，金额用inputmode="decimal"，电话用inputmode="tel" - 邮箱/URL：除了
type="email"，还得加inputmode="email"或inputmode="url"，才能唤出@/.com快捷键 - 扫码填充场景：设
inputmode="none"彻底禁用软键盘，配合readonly更安全 - 兼容性注意：
inputmode在 Safari 16.4+ 才完全支持，旧版 iOS 直接忽略，别依赖它做核心验证
从数据库加载默认值，别只靠前端 JS
服务器端渲染（SSR）是最稳妥的方式：后端查库后，直接把值注入 value 属性，比如 PHP 输出 <input name="email" value="user@example.com">。客户端 JS 异步填充虽灵活，但有白屏、竞态、XSS 风险三重隐患。
实操要点：
inputmode 配合 autocomplete 才算完整体验
autocomplete 解决“填什么”，inputmode 解决“怎么填”。尤其在移动端，软键盘类型错配会导致用户手动切换、漏输符号甚至放弃填写。
关键组合：
