当一个列表拥有 12 组筛选、每组几十个选项时，用户可能还没看到结果就先完成了一份配置表。筛选的价值不是展示系统字段有多完整，而是帮助用户用最少操作缩小到“有意义的候选集合”。
01 筛选的目标是减少数据集，而不是展示所有字段
Carbon 当前 Filtering 指南把筛选定义为根据预设属性添加或移除数据项，帮助用户在大数据集中寻找、判断和决策。
因此不是每个数据库字段都应该成为 Filter。优先选择用户真实用于判断的维度，例如状态、时间、负责人、类型和关键范围。
02 单选、多选和多分类对应不同任务
如果用户只能处于一个状态，单选自然；如果商品可以同时选择多个品牌，则需要多选；跨价格、品牌、特性多个类别则属于多分类筛选。
选错控件会直接改变逻辑。例如用 Radio 做本来应该可以组合的标签，用户只能反复切换而无法形成结果集。
03 默认筛选必须非常谨慎
“只显示进行中项目”可能对某角色有帮助，但如果用户不知道系统默认隐藏了已完成项目，他会误以为数据丢失。
所有非显而易见的默认条件都应该可见，并提供一键清除。用户必须能理解“当前看到的是全部，还是某个子集”。
04 已选条件应该在结果附近持续可见
复杂筛选抽屉关闭后，如果用户忘记自己选了什么，就会困惑为什么某条数据找不到。常见做法是显示 Filter Chips、计数或简短摘要。
条件很多时不必把十几个 Chip 全铺开，可以显示前几个 + 数量，并允许快速清除。
05 “清除全部”要明确恢复到什么状态
如果系统有不可取消的权限范围、日期基础范围或产品上下文，“清除全部”并不一定真的等于所有数据。
文案可以使用“重置筛选”并恢复到明确默认值。操作后结果应立即更新，避免用户还要再点一次“应用”却不确定是否生效。
06 自动应用还是点击 Apply，取决于反馈速度和选择成本
少量筛选且结果瞬间更新时，自动应用更直接；筛选复杂、每次请求昂贵或用户需要一次选择多个条件时，Apply 更稳妥。
移动端抽屉尤其适合集中选择后应用，并在按钮上显示预计结果数量，例如“查看 126 条结果”，帮助用户判断条件是否过窄。
07 空结果不应该只说“暂无数据”
当用户组合条件后得到 0 条结果，界面应该告诉他是筛选导致，并提供移除某条件、清除全部或扩大范围。
如果系统能够识别哪一个条件导致结果骤降，可以进一步提示，但不要擅自取消用户条件而不说明。
08 把筛选状态写入 URL，有利于分享和返回任务
在 Web 产品中，稳定筛选可以考虑同步 Query 参数。用户分享链接给同事时，对方能看到同一组结果；刷新或返回也不会丢失上下文。
这需要和开发、SEO 一起设计，公开网站尤其要防止生成大量低价值可索引组合 URL。
09 排序选项应该用业务语言而不是数据库字段
“Created_at DESC”对开发清楚，对用户没有意义。界面应该写“最新创建”“金额从高到低”“即将到期”。
如果两个字段共同决定排序，例如风险优先 + 更新时间，可以直接作为一个业务排序选项，而不必让用户理解底层规则。
10 范围筛选要避免用户手工猜边界
价格、日期、数量适合 Range，但可以提供常用快捷项，例如“过去 7 天 / 30 天 / 本季度”。用户需要精确值时再自定义。
对于开区间和闭区间要在逻辑上统一：选择 100–500 到底是否包含 500，产品不应在不同页面使用不同规则。
11 筛选性能也是体验的一部分
每改一个 Checkbox 就等待两秒，用户会停止探索。前端可以使用延迟请求、局部加载或集中 Apply，后端也要支持合理索引。
设计稿无法解决性能，但交互策略必须基于真实响应时间制定。
常见问题
筛选和排序有什么区别？
筛选决定哪些数据进入结果集，排序只改变现有结果的排列顺序。
筛选条件越多越好吗？
不是。优先保留真实决策维度，低频条件可放到高级筛选。
筛选需要“应用”按钮吗？
取决于条件复杂度、请求速度和平台。简单快速可实时更新，复杂多选可以集中应用。
移动端筛选适合 Bottom Sheet 吗？
常见且有效，但要保证已选状态、结果数量、应用与重置操作清楚。
筛选结果 URL 要不要被搜索引擎收录？
公开网站需谨慎。大量组合页可能产生重复或低价值页面，应与 SEO 技术策略一起处理。
相关服务与进一步咨询
链接复制成功
