一次借一串代币：ERC-3234 批量闪电贷的数组对齐与回调约定

闪电贷的常规形态是一笔交易借一种资产、用完归还。做清算、套利的合约经常同时要动用好几种币，按单币接口就得串多笔调用，任何一环的时序都暴露在同一个区块的排布里。ERC-3234 提出批量形态：一次请求借一篮子。文件头记录创建于 2021 年 1 月 31 日，仓库记录状态为 Stagnant。

数组怎么对齐

放款函数是 batchFlashLoan(receiver, tokens, amounts, data)：接收者合约地址、按顺序排列的代币合约地址数组、对应金额的数组、以及原样透传给回调的数据。规范用 MUST 字样的硬规则规定了执行顺序——借贷方必须先把每个 tokens 项对应的 amounts 数量转给接收者合约，然后才回调接收者的 onBatchFlashLoan。回调签名里把同一串代币、金额数组连同数据一起送回，接收方在回调里完成操作并归还全部本金加费用。三个数组共享同一个下标空间，第 i 笔借的是第 i 个合约的第 i 个金额，错位一次，后面全部错位。

出借方接口还有两把查询尺子：maxFlashLoan 对传入的代币数组逐项返回当前可借上限，flashFee 返回逐项费用。规范期望借贷方在放款前对全部数组元素做一次校验，任何一个元素超限就整批拒绝，不存在“先借能借的那几笔”的部分成交。

与单币接口的差异

和一次借一种币的老路线相比，批量接口省的不只是调用次数。单币接口串多笔时，每笔的回调都独立完成借贷闭环，资产进出被切成好几段；批量版把所有资金流压进同一次放款、同一次回调、同一次归还，外部观察者在事件层面看到的是一个整体。这种整体性是双刃剑：好处是逻辑上一口气，代价是失败面合并——数组里任何一个地址拼错、任何一项金额超限、回调里任何一项没还够，整笔交易回滚，没有部分成功可言。调试时定位问题也要先确认数组长度一致、顺序与预期严格对应，这类错误在单币接口里根本不存在。

接口之外的账

回调里的还款纪律

借出容易还上难，规范的约束集中在回调之后：接收方在 onBatchFlashLoan 里对多种资产各干各的事——换汇、还旧债、铸新券——结束时必须让借贷方有办法确认每一笔都足额归还。标准给出的路径是借贷方在回调返回后检查各代币余额增量，任何一项没达到本金加费用的和就整笔回滚；与单币接口逐项独立结算不同，批量版的还款判定是一次性总检，回调实现者省了多次结算调用，换来的是任何一项小差错都让整笔操作消失。数据参数 data 逐笔透传的设计还有个容易被忽略的用意：借贷方可以按数组下标给每个回调分配不同的上下文，比如第 i 笔对应哪份订单、哪个清算额度，全部编码在同一个 data 数组里，接收方合约自己解析。对审计者，批量闪电贷的交易面比看起来更简洁——一次事件序列里完成多资产进出——但正因为信息密度高，复核时要按数组顺序逐笔核对金额、代币地址与费用三项，错位与漏还是这个接口独有的两类事故。

规范声明与ERC-4626 金库接口的兼容关系，把借贷方通常就是一个金库这一路径写实了：金库替持有人们承担资产池，批量放款相当于在同一笔交易里动用了多个金库的流动性。也正因此，费用归属、金库存款排队与批量放款的交互细节被留给实现，标准只锚定了“先转钱后回调”“逐项全有全无”两条骨架。仓库记录中它停在 Stagnant，属于没有大规模落地证据的提案，读它更像读一种设计推演：数组化的收益是调用紧凑，成本是把所有对齐责任压给调用方。评估任何批量借贷产品时，把它和链上实际暴露的接口对照——它是否真的申报了 batchFlashLoan 与 onBatchFlashLoan 这一对函数名，还是只借用了“批量”这个词——是区分标准兼容与话术兼容的第一步。本文为机制说明，不构成任何投资建议。