批量兑换到底省不省 gas：合并调用与摊销账

「把三步操作合成一笔做省 gas」——这句话在 DeFi 社区流传极广，但很少有人真的算过账。合并调用确实省，省得也确实不均匀：有的合并结构省一大截，有的只省个零头，有的合并省了 gas、却把你推进一种新的失败模式。这篇文章把合并调用的三种结构分别摆上账本，算清它们各自省在哪、代价长什么样。

先确立计费模型。每笔交易有一组固定开销（签名验证、调用数据上链、基础调度），和一笔按实际计算量计的变化开销。合并的核心红利来自固定开销的摊销：三笔交易付三次固定开销，合成一笔付一次——省的是这三减一等于二的份固定成本，外加交易之间的「空转计算」被省掉。所以合并收益的上限，基本由「固定开销在单笔成本里的占比」决定：链上越是平静、单笔计算越轻的操作，固定开销占比越高，合并越划算；反过来，本身就是重计算的操作，合并的相对收益被变化成本稀释。

第二层账：三类合并结构省钱效率不同。第一类叫「多调用」结构：一笔交易里顺序调用多个独立函数——先授权、再兑换、再存入，三条指令顺序执行，失败则全部回滚。这类结构在组合 DeFi 操作里最常用，省得最直接，因为每一笔单独发都是「轻计算加固定开销」的典型，摊销效率拉满。第二类叫「路由合并」：把多跳兑换的路由决策合并成一次调用，省掉中间资产在钱包端的多次往返。它省的不只是 gas，还省时间——三跳如果分三笔下，每跳之间的价格漂移都是裸露风险，合并成原子执行把这个风险直接清零。第三类叫「批接口」结构：新一代账户标准与批量执行接口把多笔调用做成账户原语，一次签名一次结算，摊销效率最高，但依赖账户类型支持，且引入「一笔签名管多件事」的授权集中风险——省 gas 的收益要用更宽的一把签名钥匙去换，这笔交易值不值，和 gas 无关，和你的安全模型有关。

然后是三笔容易被忽略的隐性成本。第一，原子性的代价：合并交易是「要么全成要么全废」的整体，一步失败全额回滚、gas 照付——单独操作时第一步成功你还有半程进展，合并失败等于从零重跑，在拥堵期这个差别可能比省下的固定开销更贵。第二，gas 上限的叠加误差：多步合并的 gas 用量估算波动比单步大（每步都有不确定性），合并后必须把总上限设得宽松，而宽上限虽不多扣，却会在「中途 gas 耗尽」这种最差情形里放大损失，重跑次数越多亏越多。第三，调试成本：合并失败的回滚信息往往只能定位到「整体失败」，排查要拆回单步重跑，对不熟悉链上调试的用户，一次失败的隐性时间成本很容易吞掉几笔固定开销的节省。

把两本账放在一起，分界线就出来了。值得合并的：步骤多而每步轻（授权加兑换加存入的标准三件套）、价格敏感要求原子落地（跨池多跳、搬仓自救）、以及你有现成工具能预演整条序列的场景。不值得合并的：单步本身已经很重的大额复杂操作（摊销空间本来就小）、对回滚概率敏感的场景（比如你离清算线很近，一次全回滚等于多暴露一个区块），以及任何「这一步成不成都想单独知道」的探索性操作。

最后给一个极简的操作顺序建议：组合操作优先合并，但合并前先逐单步模拟确认参数，合并后再跑一次整体模拟；急迫场景（清算自救）用合并换原子性；不急的批量整理（比如清理授权、批量撤回陈旧头寸）合并加低优先费慢慢排。各钱包对合并调用的支持方式和预演能力不同，支持批量接口的账户类型也在扩展中，动手前以你使用的工具文档为准。gas 机制随网络升级调整，本文只做机制说明，不构成投资建议。