批量操作要先回答“选中了哪些对象”，再说明“会改变什么”，最后让用户能找到失败项。全选当前页不等于全选全部结果；删除、归档、转移等动作的风险也不同。设计时把选择范围、确认门槛、执行进度和部分失败作为一条完整任务。
用墨刀原型做一张可点击的数据表格，案例设为“客户资料归档”：选择当前页两条记录、扩展到全部筛选结果、确认后模拟一条权限失败。团队能直接看到每个状态如何返回，而不是只看静态按钮。
先把选择范围说清楚
勾选一行时显示“已选1条”；勾选表头时应说明是当前页还是全部筛选结果，并提供扩展入口。翻页或改筛选条件后，已选项是保留还是清空必须可见。若数据更新导致部分记录不再符合条件，提交前再次提示范围，避免误操作。
当前页、跨页和全部结果是三种选择模型
先为产品选定一套模型，再设计复选框。当前页选择最容易理解，但不适合处理几百条结果；跨页保留选择更灵活，却需要用户随时看见已选总数；全部结果选择效率高，必须明确筛选条件以及排除项，不能只靠表头勾选状态表达。
| 用户操作 | 推荐呈现 | 必须约定的行为 |
|---|---|---|
| 勾选当前页表头 | 已选择本页20条；另提供“选择全部128条结果” | 先只选本页，不默认扩大范围 |
| 扩展到全部结果，再取消一条 | 已选择127条，已排除1条；可查看已选记录 | 提交范围必须剔除已取消的对象，不能重新全选 |
| 修改筛选条件 | 提示选择将重置，或明确保留原范围 | 不能静默把旧选择替换为新结果 |
| 翻页后继续选择 | 在固定操作条持续显示累计数量 | 若采用仅当前页模式，离页前说明选择会清除 |
“全部128条”还涉及时间边界。用户确认期间新增的记录是否纳入，本例建议按确认时列出的对象处理，新增记录留到下一批。若系统按执行时条件重新查询，就必须在确认文案中说清楚，否则用户看到128条、结果却处理132条，会失去对范围的判断。
选中态也要覆盖部分选中：表头应能区分未选、部分选中、全部选中。不能操作的行可以保留禁用选择框并解释原因，或让用户选中后在确认阶段明确剔除；两种方式择一保持一致，避免“已选12条”到执行时突然只剩8条而没有说明。
按风险决定确认方式
| 动作 | 确认信息 | 执行中 | 完成后 |
|---|---|---|---|
| 批量打标签 | 将给12条客户增加“重点” | 允许离开并提示进度 | 显示成功数量 |
| 批量归档 | 归档后默认列表不再显示 | 禁止重复提交 | 提供查看归档入口 |
| 批量删除 | 说明是否可恢复及影响 | 明确不可逆提示 | 列出失败项和原因 |
确认框不应只重复按钮名称。它应包含对象数量、范围、关键字段和可逆性。危险动作可以要求输入短语或二次确认，但不要为低风险动作统一增加阻力。
确认框写后果，不写“确定操作吗”
对客户资料归档，可以写：“归档所选12条客户资料？归档后这些资料不再出现在默认客户列表，可在归档列表中查看并恢复。与资料关联的历史跟进记录保留。”主按钮用“归档12条”，次按钮用“取消”。其中是否可恢复、关联记录是否保留，应先由业务规则确定，再落到界面文案。
低风险、可撤销的打标签动作可以在执行后提供撤销，不必每次都弹出确认框；涉及对外发送、扣费、永久删除等动作，则先展示收件对象、费用或数据影响。输入确认短语只能增加操作阻力，不能代替范围和后果说明。
执行中别让“取消”和“撤销”混在一起
取消是停止尚未执行的部分，撤销是逆转已经完成的变化。若归档批次进行到7条时取消，可能得到“已归档7条、已取消5条”，不能提示“操作已取消”却让用户以为12条都未改变。若后端无法中途取消，就不要展示这个按钮，可以让用户离开结果页后在任务记录里继续查看进度。
执行时间不可预测时，用“正在处理12条”表达状态；后端能返回可靠数量时再显示“已处理7/12条”。不要用动画百分比暗示不存在的真实进度。提交按钮进入处理中状态，同时给批次一个可追踪的编号，刷新页面或网络断开后仍能查询结果。
撤销需要回答撤销哪些记录、多久内有效，以及这期间被别人修改的记录如何处理。对已被修改的对象，可以拒绝覆盖并列出冲突项；不能让一个“撤销”按钮无提示地覆盖其他成员的新操作。设计稿应画出撤销成功和部分撤销失败两种结果。
部分失败要留下可继续处理的清单
假设12条记录中10条归档成功，2条分别因权限不足和资料已被修改而失败。结果页显示成功与失败数量，失败列表包含记录名称、原因和下一动作；不要用“操作失败”覆盖已经成功的10条。重试按钮只提交失败项，避免重复修改已完成记录。
本例结果摘要可以直接写成：“12条客户资料中，10条已归档，2条未处理。”其中客户A显示“没有归档权限，请联系管理员”，客户B显示“资料已被其他成员修改，请刷新后重试”。失败原因决定下一动作：权限问题不能靠重复点击解决，数据变更则应先重新确认，网络类失败才适合直接重试。
还有一种容易漏掉的结果是“状态待确认”。请求超时不等于执行失败，服务端可能已经完成归档。此时先查询原批次状态，再决定是否允许重试；界面可以显示“正在核对处理结果”，不要立即给全部记录重发一次。批次内成功、失败、取消和待确认数量加起来，应与提交数量一致。
失败清单应保留对象标识、名称、原因和处理入口；数量较多时允许筛选原因或导出清单。用户离开页面再回来，也应能定位这次批次，而不是只剩一条几秒后消失的提示。重试后将原失败项更新为新结果，保留前后关系，避免看起来像又多执行了一批。
用四条任务验收原型
验收依次走：当前页全选→扩展到全部结果→中途取消→部分失败后只重试失败项。每次记录选择数量、确认文案、返回位置和数据变化。研发交接需要明确批次标识、幂等规则、超时、权限错误和撤销期限。最终成果是一张选择范围表、一张状态转换表和一份失败项展示规则。
可将研发交接规则写成一句完整约定：“批次B-001按确认时的12个记录标识归档；重复提交同一批次不重复执行；超时先查状态；重试只包含明确失败且允许重试的记录。”再为当前页全选、跨页保留、改筛选、记录被删除、权限变化、断网恢复各保留一条原型路径。这样评审看到的就不只是一个弹窗，而是一项能被继续处理的任务。
