批量破坏性操作需列出受影响对象
别名: 批量删除确认 · 受影响对象清单 · 批量不可逆 · bulk delete preview
概念解释
数量和口径告诉人规模，并不告诉人名字。批量删除、归档、撤回权限这类不可逆或高代价动作，还要把即将被改写的对象清单（object listing for bulk destruction）摊开：至少列出可扫描的标识，而不是只写「确定删除 40 项？」。规模对、口径对，清单里仍可能夹着刚被误勾的那一条。这条约束不处理怎么显示已选数字，只处理破坏发生前对象是否可被点名认领。
机制
破坏性批量把许多对象压成一次确认。确认对话框擅长拦「手滑点了按钮」，不擅长拦「集合里混进了不该在的成员」——后者要靠识别，识别要靠名字。人在数字「40」上几乎无法做核查，只能全盘接受或全盘放弃。把标识列表拿出来，核查从抽象规模回到具体对象：用户可以在名单里看见那份不该删的合同、那个不该撤权的同事。清单必须是对象的识别字段，不能是内部 id 或「项目 1、项目 2」。名单过长时不能改回只显示数字，而应可滚动并支持在确认前取消个别成员，否则清单又退化成不可核的规模。
怎么研究
在已知混入一条「不该删」记录的选择集上，比较三种确认：只有数字、数字加口径、带识别字段的可滚动清单。因变量是那条不该删的记录被发现并剔除的比率、确认耗时、以及误删率。自变量：集合大小、识别字段是否截断、是否允许在确认里取消单个对象。集合变大时，只有数字的条件发现率应接近零；清单条件的发现率应随名单可扫性下降，而不是立刻归零。
边界
动作可逆且后果轻（给四十封邮件标已读）不需要对象清单，数字足够。清单若来不及在确认前加载完整标识，会出现空白或内部 id，比没有清单更危险，因为空名单被当成「没什么可核」。跨权限的对象用户本就看不见名字时，清单无法点名，应改为拒绝把不可见对象纳入批量，而不是列一行「受限项目」。真正的全库删除（清空回收站）对象以万计，清单失去可扫性，需要二次输入确认词，那是另一条高后果通道，不能假装仍在「列出对象」。
怎么落地
- 删除、永久移除、批量改权限等动作的确认里，列出识别字段；默认可见若干条，其余可滚。
- 允许在确认中取消个别对象并重算将要执行的集合，不要强迫全盘接受。
- 识别字段被截断到无法认领时，视为清单一项失败，加宽或给悬停全文。
- 验证：故意混入一条不该处理的记录，看确认阶段能否被找出来。找不出来就不要上这个批量入口。