运营想通过 20 条，误点了全选当页 3000 条，确认弹窗只有一句「确定吗」，十秒后全部变成已通过。乍看像缓存或者权限的锅，追下去往往不是。
POST /api/audit/batch {ids: [...], action: 'approve', confirm_count: 3000}
# 服务端校验 confirm_count 与实际条数一致
追下去是这么回事：批量操作没有二次确认数量，也没有撤销窗口，接口一次性提交全部 ID。权限上普通审核员就能执行全量通过。
「批量审核误操作」相关的验证我通常做两遍，改完一次、隔天再看一次，确认不是临时生效。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
具体做法是，确认弹窗里显示实际条数，超过 100 条要求输入条数确认；操作后保留十分钟撤销入口，记录批次号；批量通过限制为管理员权限，普通审核员只能小批量。
验收就看一点，误选大量记录时被拦下，撤销入口能在十分钟内恢复状态。