表格跨页全选怎么设计？批量操作范围、部分失败与撤销规则

表格上的“全选”究竟选中了什么？当前页面的20条订单，还是筛选条件下的268条订单？这个问题如果要等点击“批量关闭”后才得到答案，交互设计已经留下了风险。跨页全选的核心不是多画一个复选框，而是让选择范围始终可以被理解、核对和恢复。

本文以订单后台为例：运营人员筛选“待处理”订单，逐页核对后批量分配负责人。我们只讨论选择集合及其后续行为；颜色、布局和组件基础可参考B端产品的基础设计规范。设计前先让产品与研发写下同一句规则：用户选中的是具体记录，还是某个筛选结果集合。

把“本页全选”与“全部结果”拆成两步

表头复选框可以先选择当前页，并显示“已选择本页20条”。如果业务需要一次处理全部结果，再提供“选择符合当前筛选条件的全部268条”入口。用户主动切换之后，动作栏明确变成“已选择全部268条结果”，同时提供清除选择。这样可以兼顾逐页核对与大批量操作，而不把两个含义塞进同一个默认动作。

这是一种适用于大结果集的产品规则，不是所有表格都必须采用的标准。仅有少量数据且不分页的列表，简单全选即可；业务要求逐条阅读确认的审批场景，可能根本不应提供跨页全选。需要选择哪种方式，应由实际任务决定，而不是因为组件库恰好支持多选。

Carbon数据表格规范提供了选择行、表头选择与批量动作栏的基础模式。在此之上，跨页范围、筛选变化和数据更新属于产品必须补充的业务约定，不能只在接口文档中出现。

选择状态至少有两个维度

第一个维度是复选框视觉状态：未选、部分选中、全部选中。第二个维度是集合范围：当前页、跨页具体记录、全部筛选结果。表头出现勾号，只能说明它所代表的那一组记录已选完，不能单靠这个图形告诉用户后台还有248条也被选中了。

部分选中要有程序可识别的状态，而不是只画一条横线。W3C复选框模式说明了混合状态和空格键切换等行为。设计稿同时标注可访问名称，例如“选择本页全部订单”，便于开发实现和读屏验收。

翻页、排序与修改筛选要分别规定

如果产品允许跨页选择，翻页后应保留已选的具体记录，并让总数持续可见；返回之前页面时，勾选状态仍准确。改变每页条数也不应把同一条订单变成另一条，选择应关联稳定的记录标识，而不是表格第几行。分页区域需要清楚呈现当前范围与总量，可参照Carbon分页规范。

排序只是改变顺序，通常可以保留选择。修改搜索词、筛选条件或业务空间则改变集合含义，必须另作处理。一种稳妥方案是清除选择并明确提示；另一种方案是保留原记录，但持续显示“包含当前筛选之外的记录”。后一种更灵活，也更容易误操作，必须允许用户查看已选列表。不要表面上只显示新筛选结果，批量执行时却悄悄带上旧记录。

以“待处理→已完成”的筛选切换为例，原来的20条不应该不加解释地继续参与“批量退款”。搜索框与过滤器的设计实践解决的是如何找到结果，而跨页选择需要进一步规定找到结果之后如何保持操作对象的一致性。

数据会变化，确认窗口不能只写“确定吗”

用户选中268条订单后，后台可能新增订单，其他人员也可能改变订单状态。产品需要选择“选择时的固定记录集合”或“执行时重新匹配筛选条件”。前者更容易让数量稳定，后者适合持续处理某类记录，但必须清楚提示执行时范围可能变化，并在真正提交前重新确认。

对关闭、删除等影响较大的动作，确认内容应包含动作、数量、筛选范围和后果。例如“关闭所选268条待处理订单；其中已进入发货的订单将跳过”。如果服务端检查发现可执行数量已变，更新摘要，让用户确认新的事实。不要先显示268条，完成后只返回“成功”，把被跳过的记录隐藏起来。

这个规则也决定“全选后新增一条”是否算被选中。如果采用固定集合，新记录默认不在其中；如果采用实时筛选集合，新记录可能进入执行范围。两者没有适用于所有产品的唯一答案，但界面、后端和验收用例必须使用同一个答案。

部分失败时，只让用户处理剩下的问题

一次批量分配268条订单，238条成功、30条因负责人权限或订单状态变化失败。结果面板要同时给出成功数、失败数和失败项入口，并在每条失败记录旁说明可采取的动作。成功项不应继续留在“待重试”集合里，否则重复点击可能再次发送通知或触发业务流程。

“重试失败项”不是无条件把30条再次提交。临时网络错误可以重试；业务状态不再符合的订单需要跳过或重新选择操作；权限问题需要恢复权限。若请求超时导致结果未知，应先查询任务结果，避免把“没有收到回复”当作“全部没有执行”。大批量任务最好有可再次进入的结果页，用户离开表格后仍能查看完成情况。

界面可以保留失败记录为当前选择，并展示“已保留30条失败项”，也可以清空选择并引导至失败清单。选择哪种方式取决于工作流，但不能一边清空全部勾选，一边要求用户自行从268条里找出失败的30条。

撤销是一项业务能力，不是通用补救按钮

批量加标签等可逆动作，可以在完成后提供撤销；已经对外发送的邮件、不可逆的删除或产生外部影响的动作，不应承诺一键恢复。即使支持撤销，也要约定时限、权限与冲突处理：如果另一名同事随后修改了同一订单，撤销是否会覆盖他的改动。

撤销部分失败时，同样需要结果明细。用户点击“撤销238条”之后，只恢复230条，另外8条状态已变化，应当说明实际结果和后续路径。只有确认前后的业务数据确实能恢复，按钮才应使用“撤销”；否则可以提供“查看结果”或相应的新业务操作。

不是每条已选记录都能执行同一个动作

选中集合里可能同时包含待处理、已完成和已锁定订单。要先确定批量动作的资格规则：只要有一条不符合就阻止执行，还是允许处理符合条件的子集。前者适合必须保持整体一致的任务；后者适合可以独立处理的记录。设计稿不能只画一个始终可用的“批量处理”按钮，把这项选择全部留给开发。

采用子集执行时，可以显示“268条中250条可分配，18条不可分配”，并允许查看原因。采用整体阻止时，说明哪类记录需要取消选择，不要只把按钮变灰。涉及多个动作时，也不必把所有动作都藏起来：保留能执行的动作，对暂不可用的动作提供与当前选择相关的解释。

还有一个容易遗漏的边界是“清除选择”的范围。动作栏里的清除通常应清空整个已选集合；表头取消勾选可以只取消本页，但要同步显示其他页面仍选中了多少条。二者最好使用不同的可访问名称与明确文案，避免用户以为全部取消，实际仍留下隐藏选择。

在手机或窄窗口中，批量操作栏应优先保留数量、主要动作和退出入口，次要动作放入菜单。范围文案可以换行，但不能为了省空间只剩下一个数字。若用粘性栏，检查它是否遮住最后一行、分页按钮或键盘焦点。

把八项规则写进交付清单

键盘和动态结果反馈还可以结合WCAG设计检查清单逐项验证。批量动作栏出现后不要让焦点无故跳走，退出批量模式后也应保留合理的操作位置。

评审时可以使用Pixso制作表格组件和状态画板：用同一批订单画出本页选中、跨页选中、全结果选中、部分失败及撤销冲突，再把范围文案和按钮连接起来。与高保真原型交付结合，要求参与者只看画面回答“下一步会影响哪些订单”，答不清楚的地方就需要继续修改。