一张订单异常清单摆在面前，业务人员原本只能逐笔打开、逐笔检查、逐笔处理。现在业务要求一次选中两百张订单，按同一套规则计算处理结果，再把每张订单的成功或失败原因分别显示出来。这一刻，很容易想到《天之痕》里的武神魂玉。武神魂玉赋予的是「群攻」指令。原来的普通攻击面向单个敌人，使用法宝后可以作用于全体敌人。它有一个很关键的成长过程，初期攻击力会折减，资料记载的折减幅度从百分之六十逐渐降到零；武器附加属性也会随攻击生效。把这几个细节一起带入软件设计，问题就比「有没有批量处理语句」有意思得多。ABAP 中没有名为武神魂玉的标准组件，也没有给一段单笔业务代码加个开关，就自动变成安全、高效、符合业务规则的批量程序。最接近它的，是把单笔业务能力提炼成可复用的规则，再为规则设计批量入口。读取时尽量按集合取数，计算时共享规则，写入时遵守业务对象的事务边界，每个对象的结果仍要单独交代。这个组合，才有武神魂玉那种「一招覆盖多个目标」的味道。游戏中的攻击力折减也很值得保留在类比里。现实系统里的群攻并非免费。批量规模扩大后，数据库读取、内存占用、锁等待、接口限流、事务持续时间，都可能成为代价。经验增长在程序世界里也不会自动发生，只有经过跟踪、重构和负载测试，才能逐渐减少这些代价。单笔变批量，究竟改变了什么我们先把一张销售订单想成一个目标。单笔处理方法收到订单编号，读取状态和明细，判断是否满足条件，计算结果并提交变更。业务人员在页面上选中一百张订单时，最容易写出的实现，是循环一百次调用这个方法。从功能上看，这已经打中了「全体」。从性能和一致性看，却可能只是把单体攻击重复了一百次。假定每次调用都要独立读取订单头、订单行、客户资料和配置，那么一百张订单可能带来数百次数据库往返。若方法内部还各自执