筛选条件就四五个，做成下拉后用户说找不到，是下拉本身的问题吗？

结论先说：筛选条件只有四五个，做成下拉后用户说找不到，通常不是下拉「不好用」，而是控件和用户的任务不匹配。按 2026 年交付中的经验区间：2-5 个选项、需要互相对比、移动端高频改动的，摊开平铺或分段选择更稳；6 个以上、低频、用户已经知道要找哪个的，下拉加搜索更省空间。超过 15 个选项时，下拉加搜索一般优于纯平铺，但要一并处理加载态和空结果。

下拉省的是版面，赔进去的是可发现性

下拉框把选项收起来，页面是整齐了，代价是用户在点开之前不知道里面有什么。点开之后还要在一列文字里逐条读，移动端原生选择器又会把页面切成滚轮或全屏列表，路径比平铺多出一到两步。字段一多就全做成下拉，是后台表单里比较常见的整齐陷阱：状态、类型这类高频项被反复点开又收起，用户会逐渐放弃使用筛选。

• 选项被隐藏，会抬高「先点开再看」的成本，低频项无所谓，高频项会被放大。
• 移动端原生下拉的样式由系统控制，跨端差异大，走查时容易被算成还原度问题。
• 选项文字长度接近时，下拉里的误点率会上升，「启用/停用」这类语义相近项尤其明显。
• 在下拉里做多选、搜索、分组都会增加交互状态，开发工作量往往比平铺更高。

换句话说，下拉不是「更高级的控件」，它只是把空间成本换成了发现成本。这笔交换划不划算，取决于下面几个条件。

先分清用户是「认选项」还是「找选项」

与其凭手感挑控件，不如按固定顺序判断。交付评审里比较省沟通的做法是「三看一定」：先看数量，再看要不要横向对比，最后看频率和端型，再定承载方式。

1. 看数量。2-5 个优先平铺或分段；6-15 个可用下拉加搜索；超过 15 个建议下拉搜索或分步选择。这是经验区间，不是硬标准。
2. 看要不要横向对比。要在套餐、权限、时段之间比差异，平铺能让差异同时可见；只是找一个已知项，下拉更省空间。
3. 看频率和端型。被反复修改的字段，移动端优先平铺；一次填完很少再动的字段，下拉可以接受。
4. 定下承载方式并写进交付说明。把控件、默认值、校验规则列清楚，开发按清单实现，减少上线前临时换控件。

第三步往往比数量更能决定体验。一个有 4 个选项、每天被点几十次的筛选器，平铺比下拉稳；一个有 8 个选项、一年只改一次的配置项，下拉也不会造成明显负担。

四类承载方式的对比：平铺、分段、下拉、搜索选择

常见做法不止两种，把四类放在同一组维度里看更容易取舍。下面是 2026 年交付中比较常见的经验区间，实际项目还要结合组件库和排期。

• 平铺单选/复选：适合 2-5 个选项，可发现性高、占空间大、误点风险低；常见于状态切换、类型选择、筛选条件。
• 分段选择：适合 2-4 个互斥且高频的选项，可发现性高、占空间中等；常见于列表筛选、视图切换。
• 下拉框：适合 6 个以上低频选项，可发现性中低、占空间小；常见于配置项、地区、分类。
• 搜索选择：适合 15 个以上或动态加载的选项，可发现性取决于搜索质量，占空间小；常见于人员、标签、商品。

判断标准不是控件先不先进，而是用户能不能在预期步数内选完。平铺的合格线是扫一眼能看全，下拉的合格线是点开后能快速定位，搜索选择的合格线是输入两个字内出现目标项。如果下拉里的选项超过一屏又没有搜索，基本可以判定需要换承载方式。

交付现场：一次后台筛选栏的返工

约束条件常常比设计原则更早出现。我们接过一个后台列表页，筛选栏有 6 个条件：状态 4 个值、标签 20 多个、负责人由接口动态返回，前端已按原生下拉排了 3 天工期，字段说明还是分批给的。第一版为了版面整齐，6 个条件全部收进下拉；走查时发现运营在移动端改状态往往要点开两次，标签要滚动查找，负责人下拉偶尔为空又没有提示。

后来的做法是：状态改成平铺分段，负责人改成搜索选择并补上默认值和清空入口，标签保留下拉但加搜索，同时在交付说明里写清每个条件的控件、默认值和空结果文案。代价是前后端多花了约半天到一天联调，设计侧多改了一轮稿；上线后「找不到某一项」的反馈变少了。按 2026 年的项目节奏，这类返工大多发生在走查阶段，常见区间是半个工作日到一天，越早定下控件选型，后期改稿成本越低。

适用与不适用边界

把边界写清楚，比反复争论更省时间。下面这组判断可以直接放进评审清单。

• 适合平铺/分段：选项 2-5 个、需要同时对比、移动端高频、用户对选项名称不熟、需要扫读建立印象。
• 适合下拉：选项 6 个以上、低频修改、空间受限、用户已经知道要找什么，且下拉支持搜索或分组。
• 不必平铺：只有两个互斥且语义相反的选项，开关或复选更直接；选项由接口动态返回且数量不定，平铺会把布局撑开。
• 不必下拉：选项少又高频，却为了整齐塞进下拉，会把一次点击变成两次；移动端还要额外处理原生与自定义控件的兼容。
• 需要警惕：选项文字很长、必须看说明才能选，平铺和下拉都不理想，可能要改成卡片或带说明的列表。

一句话边界：平铺适合「认选项」，下拉适合「找选项」；用户既不知道有哪些选项、又要频繁改的，先解决信息呈现，再讨论控件。

常见问题

下拉里加个搜索框，是不是就够了？

搜索能解决定位，但解决不了加载和空结果。15 个以上选项建议搜索加分组，并补空结果提示和最近使用，别让用户输完一片空白。

平铺会不会把表单撑得太长？

会。2-5 个平铺通常可接受；超过 6 个又必须同时可见，可以改成两列、折叠分组或分段选择，先控制纵向长度再考虑下拉。

手机和电脑能共用一套控件吗？

可以统一视觉，但交互要分端处理。桌面下拉可带搜索和键盘操作，移动端建议用分段或底部弹层，避免原生滚轮在不同系统上差异过大。

选项是接口动态返回的，还能平铺吗？

数量稳定且较少时可以，但要处理加载态和失败态；数量不固定或可能超过 10 个，优先搜索选择，并给默认值和清空方式。

怎么判断用户是「认选项」还是「找选项」？

看用户是否已经知道目标名称。知道名称、要快速定位的是「找选项」；不知道有哪些、需要比较后再定的是「认选项」。前者下拉，后者平铺。

行动指引：下次评审时，先按选项数量、对比需求、使用频率三步过一遍，再定平铺、分段、下拉还是搜索选择，并把控件选型写进交付说明。适用边界：选项少且高频、需要对比时优先平铺；选项多且低频、用户目标明确时用下拉加搜索。若选项语义复杂、必须看说明才能选，应先调整信息呈现，而不是只换控件。