autocomplete值必须严格遵循WHATWG规范小写标准词，如email、tel、street-address等；收货地址需加shipping前缀；type与autocomplete须协同生效；动态插入input时需用setAttribute显式设置且避免JS重置value。
autocomplete 值写错，浏览器直接跳过填充
浏览器不校验你写的值“合不合理”，只查它是否在 WHATWG 规范的 token 列表里。写 user-email、Email、mobile 或 province，等于没写——Chrome、Safari、Edge 全部忽略。
必须用小写、无空格、无下划线的标准词：
-
email（不是user-email或mail） -
tel（不是telephone或mobile） -
street-address（不是address或shipping-address） -
address-level1（不是province或state） -
given-name和family-name（name在 Safari 中支持率低，慎用）
收货地址字段必须加 shipping 前缀
账单地址和收货地址在浏览器看来是两套独立记录。不加前缀，比如写 autocomplete="tel"，浏览器可能把“账单联系人电话”填进“收货人电话”框里，甚至完全不触发。
正确写法要显式声明用途：
立即学习“前端免费学习笔记（深入）”；
autocomplete="shipping tel"autocomplete="shipping street-address"autocomplete="shipping address-line2"autocomplete="shipping postal-code"autocomplete="shipping country"
省市区字段可分别用 address-level1～address-level3，但若某级缺失（如没有“区”），直接省略该 input，别留空或 placeholder 占位——跳过比填错更安全。
type 和 autocomplete 必须协同生效
二者是绑定关系，只写对一个，效果打对折。例如 type="text" + autocomplete="email" 能填，但不会唤起邮箱键盘；而 type="email" + autocomplete="email" 才稳定触发建议+键盘优化。
常见冲突场景：
-
type="number"+autocomplete="postal-code"→ Chrome 禁用填充（改用type="text"） -
type="date"+autocomplete="bday"→ 有效；type="text"+bday→ 无效 -
type="password"不配current-password或new-password→ 浏览器可能乱填、覆盖、或拒绝保存
动态插入 input 时 autocomplete 容易丢失
Chrome 只在页面初始 HTML 解析阶段扫描 autocomplete 属性。React useEffect 创建、Vue v-model 渲染、JS document.createElement 插入，都属于“后加载”，浏览器大概率跳过识别。
补救方法只有两个：
- 用
setAttribute('autocomplete', 'email')显式设置（不能靠input.autocomplete = 'email'） - 确保该
input在 DOM 加载完成时已存在，且未被 JS 设过value（哪怕设为空字符串）
最隐蔽的坑是：SSR 页面 hydration 后，框架重置了 value 或覆盖了属性——这时 autocomplete 就失效了，得检查初始渲染是否保留了原生属性。
