给团队发工资、给用户空投、给合作方结算，批量工具把几十上百笔转账打包成交付。发完之后最危险的一刻，是看着钱包里一条“交易成功”提示就收工——那一个哈希背后可能是几十条独立结果，任何一条不落地，名单都不会自己报警。
一个哈希为什么不等于全部成功
在以太坊类网络上，批量合约通常把一份名单装进一笔交易执行。回执里的 status 字段为 1，只代表这笔交易整体执行完没有回滚，不保证名单里每一条都把钱送到：合约实现若对子调用做了容错，个别失败会被跳过继续跑；若没做容错，任何一条失败会连累整批回滚——好在回滚意味着一条都没发，方向反而清楚。要数清“到底发出去几条”，看的是交易回执日志里的代币转入事件或合约自己的发放事件，以及区块浏览器上的内部交易列表：每条事件对应一个收款地址和金额，逐条与名单比对才算核对完成。
比特币侧的“批量”多半是另一种形态：一笔交易带几十个输出。一个哈希，名单每人对应其中一个输出，核对方式是打开原始交易逐项看地址与金额，注意比特币地址在原始数据里以脚本形式存放，肉眼比对容易看漏，交给脚本比对更稳；也有的工具用连续编号发一组独立交易，那就要逐哈希确认，别看漏最后一笔。
对账的最小动作清单
第一步，等确认数达到所在链的稳妥水平再对账，pending 阶段的内部调用结果可能还没定型。第二步，把工具产出的名单（地址加金额）导成表格，从区块浏览器导出该交易的转入事件或输出列表，两边做行级比对：条数相等、金额合计相等、地址逐字符一致。以太坊地址核对大小写混合校验和即可发现复制错位；比特币地址建议逐字符或扫码双通道复核。第三步，专查三类边角：名单里的地址是不是合约地址或跨链误发的目标（格式像但不是收款人）、金额单位是否被小数位错误放大或缩小、有没有收款方因自身原因拒绝接收（代币转账中收款合约拒收导致该条失败，是真实存在的情形）。
核对技巧上，先用合计数做快检：事件金额总和应等于名单总额（代币转账不涉及找零，理论上分毫不差；比特币则应等于输入减费用后的输出总和）。合计数一旦对不上，说明有遗漏或多余，再逐行排查。批量发放前对拟签交易的核对方法，见 用批量转账工具前，先核对它让你签的那笔交易；回执状态的更多细节，见 交易回执 status 为 1 就成功了吗。
批量之前的小名单试跑
正式批量前先拿名单里的一到两个真实地址做小规模试跑，是成本最低的保险：地址能到账、金额小数位正确、事件能被你的对账脚本识别，三个信号齐全再发全量。试跑地址选自己的受控地址会漏掉“收款方拒绝接收”这类问题，最好从真实收款人里挑一个知情且配合的对象。名单文件本身也要有版本管理：每轮发放固定一份带编号的 CSV 并留存哈希，补发轮次另建编号，避免多轮名单互相覆盖后无法回答“这个人到底该收到几笔”。
发现漏发怎么办
先定性：是名单行没被合约执行（事件里根本没有这条），还是执行了但收款方不认账（事件里有、对方钱包看不到）。前者按原名单补发这一条即可，注意新交易的编号取当前值；后者先去对应链的浏览器查收款地址页，确认代币确实入账——多半是代币合约地址不同或小数位显示差异，钱没丢。补发产生的额外手续费属于运营成本，建议写进发放前预算。
批量转账涉及真实资产转移，核对不彻底可能造成难以追回的错发。本文提供的流程用于降低差错，不构成投资建议，也不替代发放方自身的财务复核。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。