灰度升级进行到第12个小时，Neptune的跨Dex调用失败率从不足1%一路冲到接近20%。我对着监控面板愣了挺久，因为本地模拟实验全部通过，测试网跑了几小时也风平浪静。用户反馈区已经出现大量“网络异常，交易回滚”，技术群里开始有人说是不是路由服务挂了。我后来把问题完全定位清楚，才发现这根本不是单点故障，而是跨Dex调用这个问题天然容易踩的一连串坑。
这篇文章以Neptune这个内部模拟项目为例，把跨Dex调用从定位到解决的完整过程拆开来讲，覆盖适配层设计、动态路由与拆单、逐跳滑点保护和回归测试。如果你也在做DeFi聚合器、借贷协议底层集成，或者正在被跨协议调用问题卡住，这篇应该能帮你省掉大量排查时间。毕竟，跨Dex调用看起来只是一次“把A换成B再把B换成C”的组合操作，但真正落到合约层，每一个中间环节都可能成为莫名其妙回滚的源头。
1. 一次跨Dex调用在链上到底经历了多少关
1.1 从用户点击到资金到账的七个节点
用户在前端点击“兑换”按钮之后，Neptune要干的事情远不止“调一个Router”。它的后端路由服务会先抓取DexA、DexB等市场的实时状态，组装出若干候选路径，再把这些路径和价格快照打包成路由提议返回给客户端。用户提交交易上链后，主合约开始执行一连串操作。我把整个流程拆成了七个节点：
- 前端构建请求：目标代币、输入数量、允许的最终滑点。
- 后端做路由提议：记录候选路径、预期输出、过期时间。
- 主合约入口校验：调用函数签名、msg.sender身份、路由提议是否在有效期内。
- 授权检查：用户有没有授权Neptune花他的资产，Neptune有没有授权各个Dex的Router去花Neptune中转仓位的资产。
- 执行第一段交换：比如把AAA换成中间代币BBB。
- 执行第二段交换：把BBB再换成目标代币CCC。
- 最终资产结算：校验到账数量是否满足最低输出限制，把CCC退回用户账户。
这七个节点看似常规，但灰度事故里真正出问题的集中在第4到第6步，而不是第1到第3步。这给了我们一个重要信号：问题不在产品入口和路由提议，而是在Neptune合约与各个真实Dex交互的细节里。第4到第6步恰好是跨Dex调用和单Dex调用差异最大的一部分，授权对象变多了，中间资产变多了，兑换行为也变多了，任何一个细节失守都会造成整条链路失败。
1.2 为什么跨Dex调用比单Dex多了一整个故障面
单Dex调用时，一次swap的完整逻辑被封在Dex自己的Router合约里，Neptune只要关心两件事：用户得先授权Neptune，Neptune得把币转给Router。哪怕池子深度临时变化，Dex Router内部也会自己处理路径，整体失败时直接回滚原始状态，用户损失很小。
跨Dex调用就完全不一样了。Neptune必须把“兑换”从一行调用扩展成“兑换-转移-再兑换”的组合，等于在原本的黑盒外面再包一层编排层。风险不是线性叠加，而是乘积关系。假设单段调用失败率是1%，三段链路不考虑其他因素时理论失败率已经做到1 - 0.99^3，大约是2.97%。如果把中间代币转账、授权额度检查、逐跳滑点校验、路由过期时间这些因素全部加进去，失败率冲到两位数非常正常，灰度事故里接近20%的失败率就是活生生的例子。
还有一个更隐蔽的问题：单Dex调用失败时是整体回滚，但在跨Dex调用里，一旦中间步骤做了一些不可逆操作，比如已经把AAA转给DexA的Router并且第一跳成交了，之后再触发第二段兑换，整个交易就不再是简单的“全部回滚”了。Neptune必须保证要么全部成功，要么全部失败，并且每一个中间环节都要有清晰的合规路径。这也是后面重点讲的原子性保护。
2. 灰度事故复盘：失败率为什么会从1%逼近20%
2.1 先盘一下三类高频失败
我把事故期的失败交易按错误特征做了分类，大致有三类。
第一类是授权类回滚。用户第一次使用某个Dex时，Neptune需要替用户给Dex的Router做授权。很多Dex要求先设置一笔额度，但不同代币的实现并不统一。有的需要先清零再授权，有的可以直接授权一个大额上限。Neptune之前在某些场景直接沿用上一笔未消费完的额度，等用户把额度用完之后，下一次跨Dex调用的第一步就会回滚，错误信息是很典型的allowance exceeded。这种失败不会出现在测试网里，因为测试环境里的代币授权额度通常被调试脚本设置得足够大。
第二类是流动性结构变化导致的滑点超限。跨Dex路由在链下构建时，用的是那一刻的池子深度，可用户上链执行需要时间，尤其链上拥堵时，从构建路由到交易被包含进区块可能要跨几十秒。在这段窗口里，某个池子可能被一笔大单抽走大半流动性，导致路径后半段的输出远远低于链下估算值。Neptune当时设了一个整体的minimumOut，却没有给中间每一跳设下限，结果第一跳成交后，第二跳的滑点超限导致整个交易回滚。更麻烦的是，中间路由仍然残留授权状态，下一笔交易会在一个“半复位”的状态里继续跑，错误信息被掩盖得更加彻底。
第三类是中间代币兼容性失败。某个中间代币的transfer会额外扣掉一部分手续费，实际到DexB的输入数量比预期少；又或者某个中间代币带黑名单机制，当Neptune合约被对方判定为风险地址时，transfer直接revert。这类错误通常不在路由估算模型里，也不在标准ERC20测试覆盖里，属于上线后才会暴露的隐性故障。灰度期间有一个交易占比不高的稳定币中间路径，就是因为这种兼容性问题间歇性失败，排查起来最耗时间。
2.2 三个表象背后其实是同一个设计缺陷
把三类失败放在一起看，会发现它们不是孤立的Bug，而是一个共同根因的三种投影：Neptune把对Dex的调用写得太“具体”了。
原本的实现里，Neptune直接调用某个Dex Router的具体函数，字段不是抽象接口，路由也是用静态map提前写死的。这个设计在Dex接口不改变、池子深度充足、代币全部为标准ERC20时确实不会出问题。可一旦其中任何一个前提被打破，调用就会立刻变得非常脆弱。而且逻辑散布在主合约里，很难单独做测试，也很难在某个Dex接口升级时快速切换。
真正要解决的，不是修这一笔或者那一笔交易，而是把“具体Dex的细节”和“跨Dex编排逻辑”彻底隔离。这个隔离层就是适配器。当有了适配器之后，DexA接口升级只是一个适配器的改动，DexB参数变化只是另一个适配器的改动，Neptune主流程完全不用关心。
3. 适配层改造：让每个Dex在Neptune眼里都是一个样
3.1 最小接口定义
要做适配层，第一步不是疯狂抽象，而是想清楚Neptune到底需要Dex给它什么。跨Dex编排不需要知道Dex内部路径怎么规划，不需要关心它的Router合约用了什么构造函数参数，只需要四件事：能算输入、能算输出、能执行兑换、能告知授权目标。于是我把接口收敛成下面这样：
interface IDexAdapter { function getAmountOut( address tokenIn, address tokenOut, uint256 amountIn ) external view returns (uint256 amountOut); function getAmountIn( address tokenIn, address tokenOut, uint256 amountOut ) external view returns (uint256 amountIn); function swapExactInput( SwapRequest calldata req, address recipient ) external returns (uint256 amountOut); function swapExactOutput( SwapRequest calldata req, address recipient ) external returns (uint256 amountIn); function getRouter() external view returns (address router); } struct SwapRequest { address tokenIn; address tokenOut; uint256 amountIn; uint256 amountOutMin; uint256 deadline; bytes extraData; // 各Dex特有的附加参数，比如路径、手续费档位 }这段接口看起来简单，但承担了所有Dex差异化适配。每个Dex写一个适配器，把自身swap函数签名转成这个统一结构。有人可能觉得，直接让Neptune调用Router不就行了，省一层gas。实际上适配器带来的gas开销是极低的，只是一次内部调用和参数搬运，换来的却是：Dex接口升级时只需要改适配器，新增一个Dex时只需要新增适配器，所有跨Dex边界问题都能集中在一个文件里排查。
这里要提醒一句：接口定义千万不要一开始就把所有Dex的特殊能力都塞进去。比如某个Dex支持自定义链上策略，另一个Dex支持多跳内部聚合，如果你试图让统一接口去表达这些差异，适配器就会越写越厚，最后变成一堆if else。我把这些差异全部塞进extraData字段，让需要特殊能力的适配器自己在内部解码。Neptune主流程只认固定字段，不关心extraData里到底是什么。
3.2 不同Dex的适配器是怎么转译的
以两个典型Dex为例。DexA的Router函数是典型的路径数组风格：
function swapExactTokensForTokens( uint256 amountIn, uint256 amountOutMin, address[] calldata path, address to, uint256 deadline ) external returns (uint256[] memory amounts);DexB的Router函数则带fee和额外标记：
function swap( address tokenIn, address tokenOut, uint256 amountIn, uint256 amountOutMin, uint256 fee, address recipient ) external returns (uint256 amountOut);适配器要做的，就是把统一接口翻译成这两种形态。我在实现DexAAdapter时，会把extraData解码成path，把req.deadline转给DexA；实现DexBAdapter时，则把extraData解码成fee。代码大概是这样：
contract DexAAdapter is IDexAdapter { address public immutable router; constructor(address _router) { router = _router; } function swapExactInput( SwapRequest calldata req, address recipient ) external override returns (uint256 amountOut) { address[] memory path = abi.decode(req.extraData, (address[])); uint256[] memory amounts = IDexARouter(router).swapExactTokensForTokens( req.amountIn, req.amountOutMin, path, recipient, req.deadline ); return amounts[amounts.length - 1]; } }这段代码看起来平淡，但它是整个跨Dex稳定执行的基础。所有Dex的具体行为都被限制在适配器内部。跨Dex编排层绝不应该出现“如果是DexA就调用这个函数，如果是DexB就调用另一个函数”的分支判断。一旦出现这种判断，适配层就形同虚设了。我见过很多项目所谓的“多Dex支持”，其实就是主合约里一夜加了好几个if else，最后每个Dex都变成特例。
3.3 在适配器里顺便解决授权问题
授权是跨Dex最容易出问题的隐形环节。很多开发者只检查用户对Neptune的授权，却完全忽略Neptune合约对各个Dex Router的授权，这是两类完全不同的问题。
- 用户要授权给Neptune合约，允许它转走用户账户里的AAA。
- Neptune合约要授权给各个DexAdapter或Dex Router，允许它转走Neptune中转仓位里的AAA。
我在适配器里统一处理了Neptune对Router的授权：每次swap前调用一次ensureAllowance，如果目标合约的allowance小于本次需要的额度，就先把额度清零，再设置本笔额度。这个“先清零再设置”的习惯，来自某些代币的特殊实现——它们不允许直接覆盖授权，只要求旧额度必须先归零。
function ensureAllowance(address token, address spender, uint256 amount) internal { uint256 currentAllowance = IERC20(token).allowance(address(this), spender); if (currentAllowance == 0) { IERC20(token).approve(spender, amount); } else if (currentAllowance < amount) { IERC20(token).approve(spender, 0); IERC20(token).approve(spender, amount); } }授权处理还要注意性能问题。如果每笔交易都做一次allowance查询和可能的重置，gas会多消耗一些，但它换来的确定性和安全性远超这点成本。尤其在跨Dex长链路里，授权失败往往发生在第一步之前，如果不彻底处理，用户会在前端看到Pending forever而不是明确的回滚错误，故障排查成本反而成倍增加。
4. 动态路由与拆单：跨Dex不只是路径跳转
4.1 静态快照为什么跑不远
适配层解决的是“怎么调”，接下来要解决“调哪里”。Neptune最初的跨Dex路由是半静态的：后端每隔几分钟抓一次各Dex的报价和池子深度，生成一张路由表，用户在有效期内重复使用同一张表。这种方案在震荡行情里天然失效，因为流动性是连续变化的，半静态快照注定滞后。
灰度事故里，故障交易集中发生在某个流动性池被套利者抽走后的三分钟内，所有还在使用旧快照的交易几乎全部滑点超限。这让我意识到真正的动态路由应该是：后端实时构建路径，同时标明这条路径的构建高度或过期时间，交易上链后，合约再过一遍关键校验。
Neptune采用的方案是：链下生成路由提议对象，链上只信任由维护方签名的路由，并要求路由里的deadline不早于当前区块时间。整个流程可以用下面这段伪代码描述：
后端服务 1. 从DexA/DexB拉取最新状态 2. 枚举候选路径，计算每一跳的输出 3. 生成 RouteProposal { path, expectedOut, eachOutMin, expiredAt, signedBy } 签名后返回给用户客户端 用户带上签名调用 Neptune.executeSwap(routeProposal, userRequest) 合约校验签名、校验 expiredAt >= block.timestamp 然后按 routeProposal 执行适配器调用这套流程的优点是，用户根本不需要信任后端维护方报出的价格，因为合约会在执行前校验路由过期时间，又会在每一跳校验最小输出。即使后端报了一个坑人的价格，用户最多是浪费一笔gas，不会被迫接受一个远差于市场价的执行结果。
4.2 拆单设计里的两个指标
同一个代币对，在DexA上的流动性可能集中在某个中间池，在DexB上的深度可能不够下大单，如果强行只路由到DexA，价格冲击会非常大。拆单的思路是把一个大额交易拆成多个子交易，分别在不同Dex上执行，最后再合并回目标代币。
Neptune在拆单时主要参考两个指标：当前路径的价格冲击系数和路径间的Gas成本差。我用的简化判断是：如果单条路径完成全部交易导致的滑点损失，大于拆成两条路径后的滑点损失加上额外两笔swap的gas成本，那就拆。
实际实现时是累计补足逻辑：
- 先用最优路径A尽可能吃下大部分仓位，让A的深度被利用到极致。
- 如果剩余数量还不够，再用路径B、路径C依次补充。
- 每拆一笔都要独立校验该笔的minimumOut。
这里要特别提醒：拆单不能做成死板的平均分配。流动性深度是非线性的，最优分配往往是“深度大的路径多吃，深度小的路径少吃”，而不是两条路径各吃一半。我的做法是用后端把候选路径按预期输出排序，用贪心算法逐条吃仓位，直到剩余仓位低于某个阈值。这个阈值通常设为最小交易数量，太小容易触发Dex的极低流动性空洞，太大则浪费了深度。
4.3 中间代币的危险系数比想象中大
跨Dex调用多出一跳，就多一个中间代币承载转移。中间代币不能只看深度，还要看代币本身是否“规矩”。我在Neptune内部给中间代币加了一个危险系数检查，包含三关：
- 是否标准ERC20：有些代币的transfer不返回bool，或者返回false但不revert，这类代币的到账校验很容易买地雷。
- 是否转账时扣费：用模拟转账核对实际到账，如果实际到账小于发送额且差额超过设定误差，直接标记为扣费币。
- 是否带转移黑名单：把Neptune合约地址放到对方接口里做一次查询试算，如果对方返回“不能转账”，直接淘汰。
这三关不需要在每笔交易里都做，但应该在适配器注册和中间池权重更新时定期扫描。灰度事故里那个“转移了却不到账”的中间代币，就是因为当初没做第二关检查才混进来的。那次教训之后，我把“危险代币过滤”提前到了路由构建阶段，而不是等交易上链后再去承受失败。
5. 原子性执行与滑点保护：最难的是可控回滚
5.1 为什么每个中间跳都要设minimumOut
可能有人会觉得，跨Dex最后的目标代币到账数量够了，中间跳不用管。这是一个非常危险的想法。举例：路径AAA→BBB→CCC，第二跳把BBB换成CCC时，如果BBB有转账扣费，或者DexB的实际输出被截断，最终的CCC到账可能勉强达到最终minimumOut，但中间实际消耗的AAA已经超过用户预期，用户等于无辜多付了钱。
更严重的情况是：如果中间跳已经把AAA换成了BBB，而BBB在下一跳的流动性突然消失，整个交易回滚。用户虽然没损失本金，但一开始的授权额度状态已经改变，下一次交易可能进入一个非常难排查的怪异分支。
所以Neptune在每个适配器swap前后都记录输入与输出，并对每一跳设置独立的minimumOut。这个minOut不是完全由后端说了算，而是来自路由提议的eachOutMin字段下传，合约在执行时逐跳检查。
for (uint256 i = 0; i < route.steps.length; i++) { RouteStep memory step = route.steps[i]; uint256 out = adapter.swapExactInput(SwapRequest({ tokenIn: step.tokenIn, tokenOut: step.tokenOut, amountIn: step.amountIn, amountOutMin: step.amountOutMin, deadline: route.deadline, extraData: step.extraData }), address(this)); require(out >= step.amountOutMin, "Neptune: step slippage too high"); }这段循环里最核心的是require(out >= step.amountOutMin)。它保证了整条路线的滑点不会是“某一跳吃掉全部，最后一跳勉强达标”。有人会觉得这样会让交易失败频率变高，但事实恰恰相反：早期不加逐跳保护时，失败是碎片化的，错误信息五花八门，修改成本极高；加了逐跳保护后，失败集中在滑点超限这一种原因，反而更容易优化路由算法。
5.2 用try/catch做路径降级，但要守住原子性底线
适配层接入之后，一个很自然的想法是：如果路径A失败，我能不能在同一个函数里catch住异常，自动切换路径B？可以，但要非常小心。跨Dex调用最怕的是“部分成功”状态。
举个例子：第一跳在DexA上已经成交，第二跳在DexB上失败，如果catch住异常后直接把第二跳替换成DexC，那么第一跳的成交就永远留在了链上，最终资金形态可能不是用户想要的。最坏情况下，用户的资金停在某个中间代币上，需要额外一笔自修复交易才能变回目标代币。
安全做法是把“路径降级”限制在准备阶段完成，而不是执行阶段。执行前的准备包括：把所有候选路径的中间跳都在本地数据上模拟一遍，只把模拟成功的路径打包进交易。执行阶段仍然保持“要么全部成功，要么全部回滚”的原子性，不吞任何失败。
如果真的需要在执行时尝试多路径，就需要引入外部补偿机制，比如用闪贷把中间失败状态冲销回初始状态。闪贷的思路是：先借出足够多的初始代币，把所有路径都跑一遍，最后用目标代币一次性归还闪贷本金。这种方案本身可行，但会成倍增加执行复杂度和gas。我的建议是，一般业务先用“模拟验证+原子执行”，只有路径竞争特别激烈的场景才考虑闪贷，否则维护成本会高到让人崩溃。
5.3 路由参数幂等与三明治攻击防御
跨Dex调用还会面临一个非常常见的攻击：三明治攻击。攻击者监控到用户的路由提议后，会在DexA的池子里先买入中间代币，把价格抬高，用户执行swap时滑点被放大，攻击者再卖出获利。
Neptune用来对抗的手段并不是复杂算法，而是把滑点从“允许阈值”细化为“后端实时报价的最小保证”。路由提议里的eachOutMin不是前端用户随便填的一个百分比折扣，而是后端基于当前链上状态计算出的可接受执行价格。它比用户配置的最终滑点更紧，但同时又留出了正常市场波动的余地。
攻击者如果想成功完成三明治，需要让用户的实际输出跌破eachOutMin。一旦跌破，用户交易会失败，攻击者提前买入的资产也会被套住，还得支付大量gas。这会把相当一部分低质量套利过滤掉。再配合提交时把交易发送到私有交易池暂存，等出块时再上链，三明治的监控窗口会被进一步压缩。
这套组合不是100%防MEV，但足以让专业套利者在面对Neptune的跨Dex交易时“不值得抢”。防御的目标不是让攻击彻底消失，而是让攻击收益小于攻击成本。
6. 复现与回归：跨Dex测试不能只测一条Happy Path
6.1 用本地分叉复现灰度事故
在动手改代码之前，我做的第一件事是把事故区块分叉出来，拿事故时间点的真实状态反复回放。复现步骤是：
- 用某个区块高度作为分叉点。
- 把当时失败交易的calldata原样重放一次。
- 对比失败前后的授权额度、代币余额、池子状态。
- 手动改掉一个参数，比如清空某个allowance，再看交易是否能成功。
一个简易的命令行流程长这样：
# 在本地分叉环境里重放失败交易 $ chain fork create --block <事故区块高度> $ chain fork replay --from <用户地址> \ --to <Neptune合约地址> \ --calldata <失败交易calldata> $ chain fork call --contract <Neptune合约地址> \ --func allowance(address,address) --args <用户地址> <DexRouter地址>这种复现方式有一个巨大的价值：它能把问题从“偶发失败”变成“在某一个区块高度、某几个状态参数下必然失败”。一旦变成确定性复现，修复就只是时间问题。灰度事故里那个中间代币到账不足的Bug，就是通过分叉复现，逐次读出实际转账数量后才彻底定位的。
如果你没有现成的分叉工具，也可以用模拟环境配合交易回放的方式做。重点不是工具选型，而是把事故现场尽量原样还原。很多跨Dex问题只有在准确的状态组合下才会触发，任何时候都不要再凭想象去猜原因。
6.2 回归矩阵里必须包含的八类场景
做完适配层改造后，我把测试矩阵扩展到八类场景。其中任何一类都不能只依赖主网交易模拟，必须写进自动化回归用例：
| 场景 | 典型条件 | 预期行为 |
|---|---|---|
| 非标准ERC20代币 | transfer不返回bool，或返回false但不revert | 在路由构建阶段过滤，不上链执行 |
| 转账扣费代币 | 转账后到账比发送额少0.5%以上 | 在适配器注册时标记，禁止作为中间币 |
| 带黑名单代币 | 目标地址被禁止转账 | 在主合约交互前预检，淘汰该路径 |
| 授权归零 | 用户首次使用、额度刚好用完、额度被第三方耗尽 | 自动重置授权，给出明确错误或自动补授权 |
| 深度突变 | 路由构建后，某池被大单抽干流动性 | 逐跳minimumOut失效，交易整体回滚 |
| Dex接口变化 | 某个Dex升级Router参数 | 只改对应适配器，不影响主流程 |
| 中间池暂停 | Dex异常暂停交易 | 路由构建阶段读取暂停状态，避免入路径 |
| 路由过期重放 | 用户拿过期签名交易再次提交 | 合约校验expiredAt，拒绝执行 |
回归矩阵里每一行都要有具体的预期结果。比如“带黑名单代币”这一行，预期是Neptune在路由构建阶段就淘汰这个中间代币，而不是到链上执行阶段才失败。这个预期可以保证问题被前置拦截，而不是让用户在钱包里反复看到回滚。
6.3 可观测性改造让下一次事故更快定位
代码修好后，我发现真正让灰度事故拖了很久的原因，是Neptune的日志只记录了“交易失败”和“路由Id”，没有记录失败发生在哪一跳、失败原因是什么类型。于是我把跨Dex执行事件做成了结构化输出：
event StepExecuted( bytes32 routeId, uint256 stepIndex, address adapter, address tokenIn, address tokenOut, uint256 amountIn, uint256 amountOut ); event SwapFailed( bytes32 routeId, uint256 stepIndex, bytes reason );每个失败事件都带上stepIndex和reason。前端拿到后可以直接把错误映射成“第2跳DexB滑点超限”这类人类可读信息，后端则能用routeId把一次失败交易关联到当时的路由提议，判断到底是链下估算问题还是链上执行问题。
这次改造之后，后续类似的跨Dex故障基本都能在半小时内定位。以前那种“从扫日志到最后找到原因要花半天”的体验彻底消失了。可观测性不是锦上添花，而是跨Dex问题修复的最后一道防线，它决定了你是带着黑盒子上线，还是带着仪表盘上线。
7. 这次问题解决后，我留下的一些经验
这套方案在Neptune里落地之后，跨Dex调用失败率从灰度事故时期的接近20%重新回到了0.5%以内。过程中最大的体会是：跨Dex调用这类问题，表面上是合约代码或者路由参数的问题，实质上是“责任边界”问题。DexA有DexA的规则，DexB有DexB的规则，中间代币有中间代币的脾气，如果Neptune把这些细节全部搅进主流程，任何一方变化都会引发连锁故障。适配层和路由提议，就是把“变化”挡在最外层的两道闸门。
另外有一个小建议：给跨Dex适配器做升级时，尽量让适配器不持有资金。所有资产在swap前后都直接归Neptune主合约管理，适配器只负责把统一请求转换成具体语义，不触碰余额。这样每次新增或升级一个Dex适配器，都不会影响用户资产安全，也不需要重新审计整个资金管理逻辑。这一点在后续项目复盘时被反复验证是值得的。
如果你也在做类似的多协议调用，或者正被某个“明明每步都对却总失败”的跨Dex问题折磨，我建议先把思路切到“边界”视角，逐段画出资金流向，而不是盯着某一行代码。当你把每一步的输入输出、授权、滑点、代币兼容性都写成可复现的断言时，真相会自己浮出来。
