搜索下拉框设计要先分清“输入了什么”和“选中了谁”。输入文字用于筛选候选，列表高亮表示正在浏览，只有确认某个选项后才形成表单可提交的值。对于从已有客户中选一个客户的场景，即使输入框里有完整公司名，也不能自动当作已经选中该客户。
画订单、合同或工单表单时，可以先把候选列表与选中状态做成可点击原型，让评审者从搜索一直走到提交。本例围绕“为订单选择一个已有客户”，处理同名候选、搜索失败、改选和键盘确认；客户名称与编号均为虚构示例。
先决定用户是在选客户，还是填写一个名字
搜索下拉框常被用来完成两类任务：从固定集合中挑选一个值，或在建议的帮助下自由输入。Fluent 的 Combobox 说明区分了过滤候选与允许自由文本提交的配置。两种控件外形可以相近，但校验逻辑不能混用。
如果用户需要提交查询后比较多篇文档，而不是从候选项中选定一个值，可以按搜索结果页的摘要、筛选与无结果设计另行组织检索页面。
本例只接受用户有权访问的已有客户。订单提交的是客户编号，显示名称只负责帮助识别。新建客户是另一个业务动作，若产品需要支持，应另设入口并检查权限；不能把搜索不到的文字悄悄创建成客户记录。
字段标签使用“客户”，始终保留在输入框外；占位文字可以写“搜索客户名称或编号”。选中后仍显示标签，不让用户只能靠记忆判断这个值代表什么。若客户数量很少、用户能快速浏览完，用普通选择框可能已经足够，不必让所有字段都增加搜索。
同名选项要在确认之前就能区分
输入“青禾”后，列表返回两个客户。它们的主名称一样，所在地和编号不同，因此候选项需要提供一条稳定、可理解的辅助信息。只在鼠标悬浮后显示完整资料，会让触屏和键盘使用者难以判断。
| 主名称 | 候选项辅助信息 | 确认后的业务值 |
|---|---|---|
| 青禾科技 | 杭州 · 客户编号 C018 | C018 |
| 青禾科技 | 成都 · 客户编号 C042 | C042 |
选中杭州这一项后，折叠状态可以显示“青禾科技（杭州 · C018）”，或在主名称下面保留简短编号。不能选完只剩“青禾科技”，到提交前又失去区分依据。辅助信息应来自真实业务允许展示的字段，既不要塞满联系人和地址，也不要为了方便选择泄露用户无权查看的信息。
候选项尽量使用一致的结构：第一行名称，第二行同一种辅助信息，停用状态用文字明确说明。若停用客户不允许新建订单，可以保留在历史订单的已选展示里，但新选择时应禁用或排除，并解释原因；是否展示历史客户应按权限与业务规则决定。
把查询、活动候选和已确认值分别写进规则
评审稿里可以保留三个状态名称：查询文字 query、当前活动候选 activeOption、已确认客户 selectedCustomerId。它们是解释行为的记法，不要求原型工具提供同名变量。再保留一份最近确认的选择，供用户取消改选时恢复。
本例采用明确确认的方式：点击候选或按 Enter 接受当前候选后，才写入已确认客户。上下键移动只是在候选间浏览，不表示已把订单客户改掉。对屏幕阅读器的选项选中语义，应由研发按实际组件模式实现；这里区分的是业务值何时提交。
| 动作 | 输入与候选 | 表单中的客户值 |
|---|---|---|
| 输入“青禾” | 查询为青禾，展示两个候选 | 尚未确认，不能提交 |
| 移到成都候选 | 成都项高亮，仍可继续浏览 | 尚未确认 |
| 确认杭州候选 | 列表收起，展示杭州客户标签 | C018 |
| 开始修改已选名称 | 进入新查询，保留旧选择供取消恢复 | 进入待选择状态，不能沿用旧编号提交 |
| 取消本次改选 | 恢复上次确认的杭州客户 | C018 |
| 点击清除 | 文本与旧选择一并清空 | 空，必填字段需重新选择 |
最容易遗漏的是第四行：输入框已经写成另一家公司，表单却仍带着 C018。可采用上表中的“开始编辑就撤销当前提交资格”策略；也可以让已选客户显示为不可编辑标签，通过“更换”进入独立搜索。无论采用哪一种，都不能让画面上的名称与实际提交对象分离。
加载、没有匹配和请求失败要给不同出口
空输入时，可以展示有限的最近使用客户，并明确标注“最近使用”；如果没有适合的默认候选，就提示开始输入。搜索很多数据时可设定最少输入字符数，但要在提示里说明原因，并确保客户编号等短查询仍能完成任务。
正在加载时，列表区域显示加载状态，保持输入可编辑。新查询已经发出，旧列表要么暂时隐藏，要么明确显示“正在更新”并防止误选与当前查询不符的项。不能让旧结果看起来像新查询的确定答案。
| 返回状态 | 可见信息示例 | 继续方式 |
|---|---|---|
| 查询成功且有匹配 | 青禾科技，杭州；青禾科技，成都 | 选择一个明确的客户 |
| 查询成功但无匹配 | 未找到“青禾咨询”的可选客户 | 检查名称或尝试客户编号 |
| 请求失败 | 客户列表暂时无法加载 | 保留查询文字，提供重试 |
| 结果过多 | 结果较多，请补充名称或编号 | 缩小查询；若有分页，说明仍可加载更多 |
“无匹配”只描述当前查询与可见范围，不等于这个客户在整套系统中不存在。请求失败更不能显示“没有客户”，否则用户可能误建一条重复记录。若后台只返回前一部分结果，也不要展示看似完整的总数；完整总量与当前已加载数量需要区分。
远程搜索还要处理先发后到的响应。例如用户先输入“青”，随后输入“青禾”，第二次结果先返回；第一次的响应晚到时不能覆盖“青禾”的列表。原型可用两个注释状态表现这个顺序，交付时要求研发仅接收与当前查询及当前访问范围一致的有效响应。等待片刻再发请求可以减少频繁调用，但不能替代响应归属检查。
离开输入框时，不要替用户确认第一项
本例规定：只有明确选择才算选中。用户输入了文字后点击其他字段，列表关闭，文字可以保留，但旁边提示“请从候选中选择客户”，提交时仍按未选中处理。即使搜索只返回一项，也不因失焦自动建立关联。这样能减少相似名称下的误选。
若用户只是重新打开已选客户列表、没有修改文字，点击外部关闭不会改变原选择。若已经开始改选，按 Esc 取消本次编辑并恢复最近确认的客户；原先没有选择时恢复为空。点击清除则是明确撤销选择，清除后再按 Esc 不恢复旧客户。这些细节要和组件采用的模式一起写明，不要求所有搜索下拉框遵循相同策略。
在可编辑、列表型的组合框中，可以按WAI-ARIA 的 Combobox 模式约定基本键盘行为：上下方向键浏览候选，Enter 接受活动候选，Esc 关闭弹层，Tab 按页面顺序离开。是否自动接受候选属于需明确选择的模式，本例不在 Tab 离开时自动确认。
候选弹层打开且没有有效活动项时，Enter 不能误触整个订单提交。输入中文时，确认拼音候选所用的 Enter 也不应同时选择客户；应等输入法组字结束，再处理业务确认。空格、左右方向键和删除键应保留文本编辑用途，不随意截获。
键盘焦点、当前活动项和表单错误都需要可感知的提示。字段有独立名称，弹层展开状态与活动候选能被辅助技术识别；选中或失败的信息也不能仅靠颜色。整体表单中的焦点顺序可与键盘导航与焦点管理约定保持一致。
用一次改选和一次失败走查组件
先在原型中输入“青禾”，用上下键浏览两项，再确认杭州客户，检查折叠后是否仍能区分客户编号。重新编辑为“青禾咨询”，进入无匹配状态；点击其他字段时应显示待选择提示，不能悄悄提交 C018。按取消改选的规则返回后，再检查旧选择能否正确恢复。
第二条路径让查询失败：保留“青禾”文字，点击重试后恢复候选，选择成都客户。再触发先后两次查询反向返回，观察旧响应是否会把新的候选覆盖。已有客户被停用或访问权限变化时，提交仍需重新验证；返回失效原因并让用户重选，不能因为先前选过就保证一直有效。
交付给研发的材料应包括候选内容结构、三种值的含义、确认与取消规则，以及加载、无匹配和失败页面。可点击原型能帮助团队审查这些行为，真实键盘、输入法和辅助技术支持仍需在实现中验证。需要把组件放回完整界面时，可参考UI/UX 设计专题，检查它与其他字段、错误提示及提交状态的关系。
