H5表单自动填充需遵循WHATWG标准：一、autocomplete值严格匹配规范关键词；二、type与autocomplete协同使用；三、DOM结构须在首屏直出且包裹于form内；四、密码字段按场景设current/new-password并避免干扰项。
团队在 H5 项目中要让表单自动填充既安全又可靠，核心不是“关不关”，而是“说清楚”——用浏览器能准确理解的语义，配合 DOM 结构、type 类型和渲染时机，形成一套可落地、可审查、可测试的标准规范。
一、autocomplete 值必须严格使用 WHATWG 标准关键词
所有输入字段的 autocomplete 属性值必须与 WHATWG Autofill spec 完全一致，大小写、连字符、拼写零容错：
- 邮箱：只能是 email（
user_email、Email、mail全部失效） - 手机号：只能是 tel（
mobile、phone不被识别） - 姓名：拆分为 given-name 和 family-name（
name是模糊值，Safari 拒绝填充） - 地址行：用 street-address；二级地址行必须用 address-line2（注意是
line2，不是line-2） - 密码：登录页用 current-password，注册/改密页用 new-password（二者不可混用，且确认密码框也必须设
new-password） - 验证码：专用值 one-time-code（禁用密码管理器保存，适配短信/邮箱动态码）
二、type + autocomplete 必须协同，不可割裂
浏览器按 type 和 autocomplete 联合判断字段语义。只写对其中一个，补全成功率断崖下降：
-
✅ 稳定触发邮箱键盘 + 历史建议 -
⚠️ Chrome 可能识别，iOS Safari 常跳过 -
❌ Chrome 主动禁用填充（邮政编码必须用type="text"或type="tel"） -
❌ 现代浏览器（Chrome ≥76、Edge ≥105、Safari ≥15.4）直接忽略，控制台报 warning
三、结构与渲染必须满足浏览器初始化前提
自动填充逻辑只在页面首次加载时扫描 DOM，后续 JS 补充或框架重渲染极易失效：
- 所有表单字段必须包裹在
内——脱离 form 的 input，语义基本丢失 - React/Vue 中禁止用
v-if或{show && }控制显示，应改用v-show或style={{ display: show ? 'block' : 'none' }}保持节点存在 - SSR 页面中，autocomplete 属性必须由服务端直出，不能靠 useEffect / mounted 后 setAttribute 补充
- 动态切换字段（如邮箱/手机号 tab 切换），每个 input 需有唯一且稳定的
name、id和autocomplete，不可复用 ref 或临时生成属性
四、密码类字段的安全设计不是“堵”，而是“导”
强行禁用自动填充既无效，还损害用户体验和安全性。正确做法是明确表达意图，并辅以干扰策略：
- 登录页：必须成对出现
+，顺序不可颠倒 - 注册/改密页：主密码框与确认密码框均设
autocomplete="new-password"，避免 Safari 复用上一次生成密码 - 不给密码字段设
value属性（含空字符串），否则 Chrome 跳过填充 - 必要时插入隐藏干扰字段：
放在真实密码框之前 - name/id 避免含
password、pwd、pass等关键词，可用哈希后缀如name="pwd_8a2f"
这套规范不依赖黑盒 hack，全部基于 WHATWG 标准和主流浏览器实际行为验证。团队可通过 ESLint 插件校验 autocomplete 值、CI 流程检查 SSR 输出、移动端真机测试补全触发率，把“能填对”变成可度量的前端质量项。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
