把一份三千行的名单一次性导进系统，中间夹着几十行手机号缺位、身份证格式不对、部门名对不上的记录，这时候说“回滚”，指的到底是哪一种？一种是整批要么全进要么全不进，只要有一行不合格，前面两千多行也一并撤销；另一种是合格的先落库，不合格的单独挑出来退回给操作者去改。两种都叫回滚，代价和体验完全不同，动手之前得先把要哪一种说清楚。
全有或全无：一次事务的干净与代价
整批回滚靠的是数据库事务——把三千行写入包在一个事务里，任何一行触发校验错误就整体撤销，库里回到导入前的样子。它的好处是状态干净，不会留下半批数据让人分不清哪些进了、哪些没进。代价是粒度太粗：一份大名单只要有一行填错，整批就白导，操作者改完那一行还得从头再来一次。名单越大、来源越杂，出现个别坏行的概率越高，全有或全无就越容易变成反复导、反复失败。何况几千行包在单个长事务里，本身也会长时间占着锁，和其他写入相互挤。
部分成功：为什么它更贴合大规模名单
大规模名单更常用的是部分成功：在真正写库之前先做一轮完整校验，把每一行标成“可入库”或“有问题”，可入库的一批写进去，有问题的连同行号和具体原因一起退回。操作者拿到的不是一句笼统的“导入失败”，而是一张明确的问题清单——第几行错在哪、该怎么改。这样两千多行合格的当场生效，剩下几十行改完再补导，不必推倒重来。橙星云在处理批量名单导入时走的就是先校验、再分流入库的路子，合格记录直接建档，失败记录带着原因导出成一份可回填的清单，让操作者只处理真正出问题的那部分。
失败行退回去，成功行怎么保证不重复
部分成功留下一个必须回答的问题：改完失败行再导一次，第一次已经进去的两千多行会不会又进一遍？答案取决于有没有一把稳定的去重钥匙。用工号、学号或手机号这类在名单里唯一的字段做标识，第二次导入时先比对已存在的记录，已经在库的跳过或更新，只把新补的那几十行写进去，重复导入就不会产生两份档案。反过来，如果每次导入都无脑新增，第二次补导就会把之前成功的行复制一遍，比最初的错行更难收拾。所以部分成功和幂等导入是一对：允许分多次补齐，前提是同一个人无论导几次都只落一条。
说到底，大规模名单导入很少有“一次干净导完”的运气，真正要设计的是它出错之后怎么收——是整批退回图个状态干净，还是放行合格行、退回问题行图个不返工。选后者的代价，是必须把去重和补导一并想清楚，否则省下的返工会变成清不完的重复档案。