学校、城市、收件人、标签：候选项多到列不全，但用户已知部分关键词，边输边筛最省力。
界面与交互 · 操作与输入
自动完成AutoComplete
输入时给出可搜索建议、用键盘高亮待选项、Enter 或点击才确认的控件；异步检索要防抖并丢弃过期响应。
输入产生建议，键盘高亮 ≠ 已确认
自动完成的每一步都长在物件上：字段上方的已选/已提交/错误物件、建议列表里的高亮项、请求日志里被丢弃的过期响应。先把它们操作出来，再解释为什么。
场景：学校报名表选学校。输入产生建议、上下键移动高亮、Enter 或点击才确认。切换模式与防抖，看字段物件、错误物件和请求日志怎么变。
未选还没确认任何学校
请求日志（最近 4 条）输入后这里会记录每次出建议是否被采用
对照：遮住底部反馈也能看出结果——字段上方只有「未选」物件；建议列表里高亮项是待选，字段物件才是确认。请求日志会在输入后显示每次请求的去留。
对照：在输入框打字出建议，用上下键移动高亮，Enter 或点击建议才确认。原因：高亮只是待选，确认后才锁定为字段值。下一步：先输入「北京」，再切换模式与防抖，观察字段物件和请求日志。
做自动完成时要盯这些
实验台证明的是机制；真正写控件时，用这五条检查边界。
- 高亮和确认是两步上下键只移动高亮（待选），Enter 或点击才把高亮项锁定为字段值；不要把高亮当作已填值提交。
- 键盘要走完整条路径用 combobox 语义：上下移动、Enter 确认、Esc 收起、Home/End 进到词首词尾；只支持鼠标的自动完成读屏用户用不了。
- 建议要带区分信息每条建议除了名称还要带所在地、邮箱、编号等能区分的副字段；只回重复名称，用户仍要靠记忆判断。
- 异步请求要防抖并丢弃过期响应连续输入时用防抖合并请求；给每次请求编号，新请求到达后丢弃旧响应，避免慢网络把过期建议覆盖到新关键词上。
- 明确允许手输还是必须选建议学校、城市等代码字段必须从建议里选；标签、备注等允许自由填写。边界不清时，无匹配与提交自定义值会出错。
什么时候用自动完成，什么时候换别的
判断依据是「数据集多大、用户已知多少、是否必须命中」。
用户心里有答案，自动完成替他省去完整输入；确认后还能带上所在地、编号等区分字段。
三五个固定选项用选择器或单选框更直接；自动完成反而多一次输入和确认。
省市区、组织架构等结构化字段用级联或树形选择更可靠；自动完成容易让用户提交自定义错值。
怎么用：从输入到确认的最短路径
让输入、高亮、确认和错误都挂在同一个字段上，键盘和读屏都能完成。
- 用 combobox 语义：input 上写 role="combobox"、aria-expanded、aria-controls、aria-activedescendant，让读屏知道当前高亮项。
- 设定触发阈值：英文常用 2–3 个字符，中文 1 个字；阈值内不出建议，避免候选项过多。
- 连续输入做防抖（如 200–250 毫秒），并给每次请求编号；新请求到达后丢弃旧响应，杜绝过期覆盖。
- 每条建议带区分副字段（所在地、邮箱、编号）；上下键移动高亮、Enter 确认、Esc 收起；点击同样确认。
- 明确边界：必须选建议时，无匹配要说明并禁止提交自定义值；允许手输时，提交前给一次确认机会。
正反例：同一个学校字段，只改确认边界
目标都是采集一所学校。差别只在「高亮和输入算不算已经确认」。
输入「北京」出建议，上下键移动高亮，Enter 或点击才把高亮项锁定为字段值；无匹配时说明「换关键词」，并不允许把自定义文本当作学校提交。高亮、确认、提交三步在物件上能区分。
这样选用户刚打到「北京理工大」还没确认，就被当作已选提交；或键盘高亮不可达、只能鼠标点。结果提交了未完整或不存在的学校，错误也无法定位到字段，用户不知哪里出错。
别这么省快速自测
请求「北京」的建议还在慢响应中，用户已改成输入「北京大」。这时最该保证的是哪一项？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。