单条校验是给人看的：输入一条，立刻看到结论。批量校验是给流程用的：输入一份文件，输出一份能被下一步程序或人继续处理的报告。两者用的是同一批算法，但工程上的难点几乎全在算法之外。
批量校验和单条校验差在哪?
第一处差别在容错。单条校验一次只面对一个输入，可以直接拒绝；批量校验必须让整批跑完，不能因为中间有一条坏数据就整体失败，否则用户永远拿不到报告。
第二处差别在信息保留。单条校验给出结论就够了，批量校验必须回答「是哪一条」，否则报告没有可操作性。原始值、在文件里的位置、失败的原因，这三样缺一不可。
第三处差别在成本结构。批量任务的耗时主要不在算术，而在读文件、清洗字符串、组织输出与写出结果。算法本身极快，别把优化方向搞反了。
先清洗再校验的流水线
一条稳妥的流水线可以分成四段：读取与解析、清洗与归一化、分流与校验、汇总与输出。每一段都有明确的输入输出，中间任何一段都可以单独测试。
读取阶段要处理编码、分隔符与列错位。带引号的字段、内含逗号的文本、表头行缺失都会在这一步变成脏数据，越早发现越好。
清洗阶段负责去空白、去分隔符、统一大小写，并把明显为空的记录单独标记出来，不要直接丢进校验逻辑。空值不是格式错误，两者在报告里的处理方式不同。
分流阶段按形状把输入送到对应的规则上，再算校验位。汇总阶段把结论按类别聚合，并保留每条记录的明细。分段清晰带来的好处是，出错时你能很快判断问题出在解析还是判定。
校验结果要分成哪几类?
按四态结论分类是基本要求：校验通过、校验失败、仅格式、无规则。前三类可以直接对应到用户动作，第四类说明本地没有规则，需要其他途径确认。
在四态之外，批量场景还需要三类工程状态：输入为空、字符集或长度不合规、以及重复记录。它们不属于算法结论，但直接决定报告的可读性。
一个常见错误是把所有不合格项压成一类「失败」。用户拿到这样的报告只能逐条重看，等于没有报告。一份能被直接使用的报告，至少要有这几列：
- 记录在源文件里的位置，例如行号或主键。
- 原始值，保持与源文件一致，不做任何改写。
- 规范化后的值，供比对与去重使用。
- 结论，取通过、失败、仅格式、无规则之一。
- 失败原因与判定依据，便于判断该改源头还是改清洗规则。把原因分开，用户就能按类批量处理：空值去补，重复去重，格式错的回原系统核对。
分类的粒度也会影响输出体积。如果每一条记录都把完整的规范化结果写进报告，输出文件可能比输入还大；如果只写结论不写位置，报告又没法用。折中的做法是明细里只保留位置、结论与失败原因，需要复查某一条时按位置回原文件取原文。
重复项、空值与超大文件
重复项值得单独处理，因为它的含义依赖业务：同一份名单里出现两次可能是正常的多条记录，也可能是导入时的重复插入。工具只能标出重复，不能替你决定删除哪一个。
空值与占位值也要区别对待。真正为空的字段与写着「暂无」「无」的字段在数据里长得很不一样，却都属于无法校验的输入。清洗规则里最好显式列出可接受的占位值，避免它们被当成格式错误。
超大文件不能一次读进内存。按块读取、边读边校验、把结果写到临时输出，是更稳的做法；同时要限制单次任务的规模，让失败可以重跑而不必从头开始。
断点续跑的前提是任务能被切成彼此独立、可重复执行的块。每块处理完就把结果落盘并记录进度，重跑时跳过已完成的块。这样即使中途中断，也不必从头再跑一遍，长任务的可用性会明显改善。
报告怎么写才可行动
报告的第一原则是可定位：每条问题记录都要带上它在源文件里的位置与原始值。只给规范化后的值不够，用户需要拿原始值去比对源系统。
第二原则是可归类：按失败原因分组统计，让用户一眼看出主要问题集中在哪一类，而不是先看到一长串明细。
第三原则是可复核：结论旁边附上判定依据，例如套用了哪套规则、属于哪一层失败。批量数据的问题往往出在源头，依据能帮用户判断该改上游还是改自己的清洗规则。
最后，报告不要夹带真实号码。输出到共享位置或工单系统时，敏感字段应当先做遮蔽，只保留定位所需的最少信息。
报告的呈现顺序也值得讲究：先给总的分类统计，再给按原因分组的示例，最后才是完整明细。使用者绝大多数时候只看前两部分就能决定下一步动作，明细留作备查即可。
给开发者：分块、并发与幂等
分块读取与并发处理能显著缩短耗时，但有几个前提。一是任务必须幂等：同一份输入重跑两次，结果应当一致，不能因为并发顺序不同而产生差异。二是输出必须可合并：分块结果汇总时不要依赖块的到达顺序，靠记录位置或主键排序。
并发还要考虑下游。如果校验过程要调用外部查询，并发度需要受控，并且要有超时与回退策略；本地算法校验则可以更激进地并行，因为它不依赖网络。
进度反馈值得投入。大批量任务的用户最怕的是没有反馈，哪怕只报「已处理的记录数」也比静默强。
进度之外，开始前的预检也很有价值：先只读前若干行，确认列位置、编码与分隔符符合预期，再放开全量。多数事故并不是算法算错，而是把错误的那一列当成了号码列。日志里同样不要写完整号码，只写位置与结论，接口边界的处理方式见接口边界的校验；分层与结论定义可回到号码校验的原理。
最后提醒一句：批量结论同样是字符层面的，不能替代对数据的业务判断。一条通过校验的记录只说明它写得对，不说明它属于谁，也不说明它当前可用。
下一步
先用号码校验工具抽查几条样本，确认你对结论分类的预期与工具一致，再写批量流程，能省下不少返工。跑之前先备份源文件，并把首次运行限制在部分行上，确认报告格式符合预期再放开全量。
涉及真实数据的批次，请先做脱敏或隔离：用合成的占位值完成流程调试，真实数据只在受控环境下处理。本文不保证任何号码的真实性、归属或可用性，批量结论同样只关于字符层面。