批量操作界面怎么避免误选：跨页选择、影响范围与结果反馈

先定义选择集合

选择可以绑定一组确定的记录，也可以绑定一条筛选条件。前者容易核对具体对象，后者在数据不断变化时可能扩大范围。设计说明应写清提交时使用哪个时刻的集合、是否包含后来新增记录，并让业务方确认，不把这些决定留给一个勾选框。

假设列表一页显示二十条而筛选结果有数百条，首次全选可以明确显示“已选本页”，再单独提供选择全部匹配结果的动作。数字只是说明性例子；实际数量必须从系统返回，不能由前端加载条数猜测。

让选择模式始终可见

Carbon数据表格指导将批量操作作为选择条目后出现的操作模式。这提供了清晰的模式提示参考，但组件本身不会替项目决定跨页范围或后端权限。选择数量、取消选择和当前可用动作应放在能持续找到的位置。

筛选、排序和翻页要分别约定。排序通常不应改变选中的记录身份；翻页是否保留选择需要显示依据；筛选改变后可清空或重新确认，不能默默让旧的隐藏选择继续提交。界面应支持查看选中集合，而不只显示一个计数。

确认内容围绕影响，不堆通用警告

• 动作：将修改哪个字段或进入哪个状态。
• 范围：确定记录数、筛选条件或明确的对象清单。
• 例外：无权限、状态不符合或已被别人处理的记录。
• 后果：能否撤销、是否通知相关人、是否产生后续任务。

“确定操作吗”不能帮助核对范围。高影响动作需要可识别的摘要；低风险可恢复操作则不一定要反复弹窗。是否支持撤销必须来自真实业务实现，不能只画一个入口。

部分成功要留下逐项结果

如果一部分成功、一部分失败，结果应分别说明，并保留失败对象的原因和后续可选动作。重试失败项与重新执行整批不是一回事，不能让用户只能重新全选。网络超时还可能只是结果未返回，应先支持查询任务状态，避免诱导重复处理。

批量提交时仍需逐条校验权限和当前状态。提交前显示的可操作性只是当时快照；有人同时修改记录后，后台应决定接受、拒绝或报告冲突。UI验收与批量写入正确性验收要同时安排但分别记录。

用这些路径检查误操作风险

1. 本页全选后翻页，核对范围和计数。
2. 选择后改变筛选，确认旧选择被清理或明确保留。
3. 让一条记录在提交前失去权限或改变状态，检查部分结果。
4. 在处理未完成时刷新页面，确认能够恢复查询结果。
5. 仅重试失败项，核对成功项没有重复执行。

若系统只能处理当前已加载记录，应明确限制为本页操作，而不是显示含糊的“全部”。可以先交付范围清楚的能力，再按实际需求增加跨页任务；不应由视觉优化悄悄扩大批量操作权限。

批量操作原型应带着跨页选择、部分成功和刷新后的样例一起评审，并把反馈规则写入原型交付清单。改造已有列表时，再核对原操作流程的保留范围；委托UI设计需要说明实际有哪些批量动作，不能只交一套复选框外观。