服务端与客户端过滤：决策检查表

真正的问题：泄露、卡顿与结果不一致

在 UI 中的过滤不只是一个搜索框。通常它包含几类相关动作，这些动作都会改变用户所见内容：文本搜索（姓名、邮箱、订单 ID）、面板（状态、所有者、日期范围、标签）和排序（最新、最高价值、最后活动）。

关键问题不是哪种技术“更好”，而是完整数据集存放在哪里，谁能访问它。如果浏览器接收了用户不该看到的记录，UI 即使视觉上隐藏了它们也会泄露敏感数据。

多数关于服务端 vs 客户端过滤的争论，实际上是对用户立刻能注意到的两类失败的反应：

• 泄露： 数据出现在网络有效载荷、缓存响应，或者通过意外的过滤暴露了隐藏行。
• 卡顿： 屏幕感觉很慢，因为你传输了太多数据，然后让设备在每次按键时做大量工作。

还有第三个问题会制造无尽的 bug 报告：结果不一致。如果某些过滤在客户端运行而其他在服务端运行，用户会看到不匹配的计数、页面和总数。尤其在分页列表上，这会很快破坏信任。

一个实用的默认规则很简单：如果用户不被允许访问完整数据集，请在服务端过滤。如果允许并且数据集足够小可以快速加载，客户端过滤可以接受。

简明定义

过滤就是“显示符合条件的项目”。关键是匹配在何处发生：在用户的浏览器（客户端）还是你的后端（服务端）。

客户端过滤 在浏览器运行。应用下载一组记录（通常是 JSON），然后在本地应用过滤。数据加载后它能感觉很快，但只有在数据集足够小并且对外暴露安全时才适用。

服务端过滤 在你的后端运行。浏览器发送过滤输入（比如 status=open、owner=me、createdAfter=Jan 1），服务器只返回匹配的结果。通常这是一个接受过滤参数的 API 端点，构建数据库查询并返回分页列表和总数。

一个简单的心智模型：

• 客户端： 下载大量数据，在这里过滤。
• 服务端： 请求你确切需要的内容。

混合方案很常见。一个好的模式是把“重量级”过滤在服务端强制（权限、所有权、日期范围、搜索），再在本地用小的仅影响 UI 的切换（隐藏归档项、快速标签、列可见性）而不发起额外请求。

排序、分页和搜索通常也属于同一决策范畴。它们影响有效载荷大小、用户感受以及你暴露了哪些数据。

决策因素 1：数据量与有效载荷成本

先问最实际的问题：如果在客户端过滤，你需要发送多少数据到浏览器？如果真实答案是“超过几屏内容”，你会在下载时间、内存使用和交互速度上付出代价。

你不需要精确估算。只要得到数量级：用户可能看到多少行，每行的平均大小是多少？500 条短字段的列表和 50,000 条包含长备注、富文本或嵌套对象的记录是完全不同的情况。

宽表记录是有效载荷的隐形杀手。按行数看表格可能很小，但如果每行包含很多字段、长字符串或关联数据（联系人 + 公司 + 最近活动 + 完整地址 + 标签），负载就会暴涨。即使 UI 只显示三列，团队也常常“把所有数据都发过去以防万一”，结果有效载荷爆炸。

还要考虑增长。今天还能接受的数据集，几个月后可能就难以承受。如果数据增长很快，把客户端过滤视为短期捷径，而不是默认选择。

经验法则：

• 如果你无法舒适地通过典型移动网络发送完整数据集，应该在服务端过滤。
• 如果用户通常只会查看一小部分，拉取该切片并在服务端过滤更合适。
• 如果数据集小、稳定且确实可以安全暴露，客户端过滤能带来很好的体验。

最后一点不仅关乎性能：问自己“我们能把所有数据都发给浏览器吗？”这也是个安全问题。如果答案不是肯定的，请不要发送。

决策因素 2：延迟与用户感受

过滤选择往往在“感觉”上失败，而不是在正确性上。用户不会用毫秒来衡量，他们注意的是停顿、闪烁和在输入时结果跳动。

时间可以在不同环节消耗：

• 网络： 请求/响应时间与有效载荷大小
• 服务器： 数据库查询、关联、排序、权限检查
• 浏览器： 解析 JSON、渲染行、过滤大型数组

为该屏定义“够快”的标准。列表视图可能需要在输入时立即响应并流畅滚动，而报表页面只要首条结果迅速出现即可接受短等待。

不要只在办公室 Wi‑Fi 下评判。在慢速连接上，客户端过滤在首次加载后可能感觉很好，但首次加载本身可能很慢。服务端过滤保持有效载荷小，但如果你在每次按键都发请求，也会感觉卡顿。

围绕人的输入设计。对输入做防抖。对于大结果集，使用渐进加载（progressive loading），让页面快速显示一些内容并在用户滚动时保持流畅。

决策因素 3：权限与数据暴露

权限应比速度更决定你的过滤方式。如果浏览器收到用户不应看到的数据，即使 UI 隐藏了这些数据，你也已经出现问题。

先列出该屏幕上哪些内容是敏感的。一些字段显而易见（邮箱、电话、地址）。另一些容易被忽视：内部备注、成本或毛利、特殊定价规则、风险评分、审核标记。

最大陷阱是“我们在客户端过滤，但只显示允许的行”。这仍然意味着完整数据集被下载了。任何人都可以检查网络响应、打开开发者工具或保存有效载荷。仅仅在 UI 隐藏列并不是访问控制。

服务端过滤作为安全默认

当授权因用户而异时，服务端过滤是更安全的默认：尤其是不同用户能看到不同的行或不同的字段时。

快速检查：

• 不同角色是否能看到不同的行（仅团队可见、仅区域可见、仅分配给我的）？
• 不同角色是否能看到不同字段（备注、定价、个人信息）？
• 是否存在行级规则（账户所有者、交易阶段、“私有”标记）？
• 导出、排序或总数会不会泄露受限信息？
• 泄露的有效载荷会不会造成合规问题？

如果有任意一个答案是肯定的，就把过滤和字段选择放到服务端。只发送用户被允许看到的内容，并对搜索、排序、分页和导出应用相同规则。

举例：在 CRM 联系人列表中，业务代表只能看到自己的账户，经理可以查看全部。如果浏览器下载了所有联系人并在本地过滤，业务代表仍能从响应中恢复隐藏账户。服务端过滤通过从未发送那些行来防止这种情况。

决策因素 4：缓存与新鲜度

缓存可以让界面感觉瞬时，也可能呈现错误的事实。关键在于决定哪些内容可以重用、多长时间，以及哪些事件必须清除缓存。

先选择缓存单元。缓存整个列表很简单但通常浪费带宽且容易过期。缓存分页对无限滚动有效。缓存查询结果（过滤 + 排序 + 搜索）准确，但如果用户尝试很多组合，缓存会膨胀。

在某些领域，新鲜度更重要。如果数据变化很快（库存、余额、配送状态），即便 30 秒缓存也会让用户困惑。如果数据变化慢（归档记录、参考数据），更长的缓存通常没问题。

在编写代码前规划失效策略。除了时间过期，还要决定哪些操作应强制刷新：创建/编辑/删除、权限变更、批量导入或合并、状态变更、回滚操作，以及后台任务更新了用户用来过滤的字段。

还要决定缓存放在哪里。浏览器内存能使前进/后退变快，但如果不按用户和组织键控，可能会在账户间泄露数据。后端缓存对权限和一致性更安全，但必须包含完整的过滤签名和调用者身份，避免不同权限的结果混合。

步骤指南：如何为新屏幕做选择

目标应不可妥协：界面在不泄露数据的前提下要感觉快速。

实用决策流程

1. 从最强约束开始。 如果访问因角色、团队、区域或订阅而异，权限优先。如果数据集很大或增长快，大小优先。
2. 数据大或敏感时默认服务端。 如果你不会放心地把完整数据集打印到浏览器控制台，就不要发送它。
3. 仅对小且安全的重复使用列表使用客户端过滤。 比如状态下拉、少量标签列表、单页已审批结果。
4. 先定义 API 形状，再做 UI。 写明过滤、排序、分页和默认值，避免服务器与 UI 出现分歧。
5. 加入护栏（guardrails）。 强制最大页大小、设置超时，并定义在过滤缓慢时 UI 应如何表现（显示加载指示、保留旧结果、提供重试）。

常见错误导致泄露或卡顿

多数团队踩到相同的坑：演示时看起来很棒的 UI，在真实数据、真实权限和真实网络下就暴露出了问题。

导致数据泄露的错误

最严重的失败是把过滤当成展示层处理。如果浏览器接收了不该有的记录，你已经失败。

两个常见原因：

• 将完整数据集发送到浏览器并在本地过滤以“提高速度”。任何人都可以检查响应或在内存中查询它。
• 缓存过滤响应时没有把缓存键关联到用户身份、组织、角色或策略版本。权限变更可能无声地暴露旧数据。

示例：实习生只应看到其辖区的线索。如果 API 返回了所有区域而下拉在 React 中本地过滤，实习生仍能提取完整列表。

导致界面变慢的错误

卡顿常常来自错误的假设：

• 认为客户端过滤总是更快。对于 50,000 条记录，下载和解析可能比一次聚焦查询更慢。
• 忘记分页和加载状态。在渲染巨大列表时界面被阻塞，即便查询正确也感觉崩坏。

一个微妙但痛苦的问题是规则不匹配。如果服务器和客户端对“前缀匹配”或大小写处理不同，用户会看到计数不一致或刷新后项目消失。

上线前快速检查表

带着两种心态做最终检查：好奇的用户和网络不佳的那一天。

• 有效载荷合理性： 确认响应绝不包含用户不应看到的行或字段，即便 UI 隐藏它们。注意总数、分组计数或 ID 是否允许推断受限信息。
• 安全日志： 过滤常包含邮箱、姓名或 ID。不要在众多可访问日志的地方记录敏感过滤值、完整 SQL 或完整请求体。
• 跨设备一致性： 在桌面和移动端应用相同过滤。差异常来自客户端排序、地区规则（大小写、重音）或默认值。
• 明确状态： 加载、空结果和错误状态要清晰。测试快速改变（输入、回退、切换），防止界面闪烁或显示陈旧结果。
• 最坏情况护栏： 最大页大小、最大日期范围和超时。防止昂贵查询（通配符、过多 OR 条件、未建立索引的字段）。

一个简单测试：创建一个受限记录并确认它在有效载荷、计数或缓存中永远不会出现，即便你广泛地过滤或清除过滤条件。

示例场景：CRM 联系人列表

想象一个有 200,000 条联系人的 CRM。业务代表只能看到自己的账户，经理能看到其团队，管理员能看到全部。界面有搜索、过滤（状态、所有者、最近活动）和排序。

客户端过滤在这里会很快失败。有效载荷很大、首次加载变慢，且数据泄露风险高。即便 UI 隐藏了某些行，浏览器也接收了数据。你还会给设备施加压力：大型数组、繁重排序、重复过滤、高内存使用，旧手机可能崩溃。

更安全的做法是带分页的服务端过滤。客户端发送过滤选项和搜索文本，服务器只返回用户被允许看到的、已经过滤和排序后的行。

实用模式：

• 先应用权限，然后再过滤和排序。
• 每次返回一页（例如 50 行）并附带总数。
• 小心缓存（按用户或角色）以避免不同权限的结果混合。

一个小例外是微小且静态的数据：一个包含 8 个值的“联系人状态”下拉可以一次性加载并在本地过滤，风险和成本都很小。

下一步：记录决策，减少返工

团队通常不是因为某次选择“错”一次而受苦，而是因为在每个屏做不同选择，然后在压力下修复泄露和慢页。

为每个屏写一份简短的决策说明：包含数据集大小、发送成本、什么程度算“够快”、哪些字段敏感、以及结果应如何缓存（或不缓存）。保持服务器和 UI 的一致，避免出现两个过滤“真相”。

如果你在 Koder.ai (koder.ai) 上快速构建屏幕，值得事先决定哪些过滤必须在后端执行（权限与行级访问），哪些小的仅限 UI 的切换可以留在 React 层。那一个决定往往能防止之后最昂贵的重写。