autocomplete 属性需用 WHATWG 规范关键词（如 email、tel）精准匹配语义，填错或用 on/off 无效；placeholder 仅作格式示例，title 补充无障碍说明，均不可替代 label；list + datalist 支持无 JS 本地联想。
用 autocomplete 控制浏览器自动填充行为
浏览器对表单字段的自动填充不是“开或关”的二选一，而是靠 autocomplete 属性值精准匹配语义。填错值会导致填充失效，甚至被忽略。
常见错误是写成 autocomplete="on" 或留空——这在现代浏览器中基本无效。必须使用标准关键词，比如：
-
autocomplete="email"对应邮箱输入框，触发邮箱建议 -
autocomplete="tel"触发手机号历史记录（注意不是"telephone"） -
autocomplete="shipping street-address"用于收货地址行，支持多级结构 -
autocomplete="off"仅在极少数场景下强制禁用（如密码确认框），但不能保证所有浏览器遵守
关键点：前后端字段名（name）可以任意，但 autocomplete 值必须是 WHATWG 规范定义的关键词，否则填充逻辑不触发。
placeholder 和 title 的分工要分清
placeholder 是视觉提示，只在输入为空时显示，失去焦点即消失；title 是 hover 提示，不干扰操作流，但对无障碍支持更友好。
立即学习“前端免费学习笔记（深入）”；
容易踩的坑：
- 把验证失败提示塞进
placeholder（例如placeholder="请输入5-10位用户名"）——用户输入后提示就没了，起不到持续提醒作用 - 在
type="email"或type="url"上滥用title，导致原生验证错误信息被覆盖，反而降低可访问性 -
placeholder不是 label 替代品，屏幕阅读器通常忽略它；必须配label元素才能满足 WCAG
推荐做法：用 placeholder 给格式示例（如 "example@domain.com"），用 title 补充非侵入式说明（如 "区分大小写"），验证逻辑交给 pattern + :invalid CSS 或 JS。
list + datalist 实现轻量级搜索建议
list 属性本身不发送请求、不依赖 JS，是纯 HTML 的“本地联想”方案，适合选项少（
必须注意的硬性规则：
-
<input list="xxx">中的xxx必须严格等于<datalist id="xxx"></datalist>的id值，大小写敏感 - 每个
<option></option>必须带value属性，label只是显示文本，不参与提交 -
datalist不限制唯一性，但重复value会导致选择时行为不可预测 - 不支持嵌套或动态更新，想加新选项只能重写 DOM 或替换整个
datalist
示例：<input type="url" list="proto_list" name="endpoint"><datalist id="proto_list"><option value="https://"><option value="http://"></datalist> —— 用户输 “h” 就能唤出两个协议建议。
autofocus 和 tabindex 配合提升首屏操作流
autofocus 让页面加载后光标直接落在目标输入框，但一个页面只能有一个生效（后续的会被忽略），且移动端部分浏览器会抑制该行为以防键盘意外弹出。
更可控的做法是结合 tabindex 显式定义操作顺序：
-
tabindex="1"表示第一个可 tab 到的元素（注意不是0，0表示按 DOM 顺序自然进入流） - 跳过某个控件？设
tabindex="-1"，它仍可通过 JS 聚焦，但不参与 tab 键导航 - 避免给非交互元素（如
div）设正数tabindex，会打乱语义流，影响屏幕阅读器
真正复杂的是多步骤表单：比如注册页分三步，每步展开时应重新计算 tabindex 并调用 element.focus()，否则用户 tab 出当前区域后可能卡在隐藏字段上。
最常被忽略的一点：所有这些属性只是辅助手段，不能替代服务端验证，也不能绕过移动端软键盘适配问题（比如 type="number" 在 iOS 上仍可能唤出字母键盘）。填报体验是否顺滑，最终取决于属性语义是否准确、DOM 结构是否合理、以及是否在关键节点做了降级处理。
