跨链协议的调试，与单链应用最大的区别在于消息要走两条链。任何一端出现问题都会让整条路径卡住。LayerZero 调试方法的核心思想就是：在每个关键节点找证据、对齐预期。本文按发送、传输、接收、回执四个阶段拆解调试流程，并结合 Binance 智能链上多次排查事故的经验给出建议。
第一步看LayerZeroScan
官方提供的 LayerZeroScan 是排查跨链消息最直接的工具。输入源链 tx hash 即可看到这条消息当前所处的阶段：Inflight、Delivered、Failed。如果状态是 Inflight 且时间超过预期，多半是 Relayer 故障；如果是 Failed，则需要进一步看 storedPayload 详情。建议把这个工具加入团队的故障排查手册，所有 必安 链与目标链之间的跨链消息都先在这里查一遍。
第二步看源链事件
源链上的 PacketSent 事件包含完整的目标 chainId、destinationAddress、payload。逐字段比对：destinationAddress 是否等于预期合约的 abi.encodePacked 形式、payload 长度是否合理、adapterParams 是否覆盖了目标链 lzReceive 的 gas 需求。任何一项不对都意味着发送端代码逻辑有 bug。B安交易所 浏览器的事件展开功能比一般区块浏览器更友好，方便逐字段查看。
第三步看目标链事件
目标链上的 PacketReceived 与 storedPayload 是两个关键事件。如果出现 storedPayload，说明 lzReceive 内部 revert 了。这时需要把 storedPayload 的 payload 与 srcChainId、srcAddress 取出，在本地用 Foundry 模拟执行一次，找到具体的失败原因。常见原因包括：amount 太大触发 SafeERC20 失败、目标合约状态未初始化、自定义校验 revert。
第四步用Foundry本地复现
本地复现的关键是构造与链上一致的环境。可以通过 forge test --fork-url 把目标链 fork 到本地，然后用 vm.prank(endpoint) 调用 lzReceive，传入 storedPayload 中的字节。这种做法能精确再现失败路径。BN官网 内部工具链中类似的 fork 调试已经成为标准操作。
adapterParams调试
如果 storedPayload 的失败原因是 out of gas，那就是 adapterParams 设得太低。可以通过 send 的 v1 格式 adapterParams 把 gasLimit 调高，例如从 200000 提到 500000。需要注意 adapterParams 是按消息附带的，调高后所有新发消息都会以新值为准，而之前卡住的 storedPayload 仍需要 retryPayload 单独触发。
监控辅助调试
生产环境中，单纯依赖人工查事件效率太低。建议把 PacketSent、PacketReceived、PayloadStored 这三类事件全部接入监控系统，并配置自动告警。一旦 storedPayload 出现就立刻通知值班同学，避免用户的资产长时间被卡。币岸 团队的实践显示，这一步能把平均故障恢复时间缩短到十分钟以内。
小结
LayerZero 调试方法的本质是「沿着消息路径一步步看证据」。Scan、事件、Foundry、监控四件套配合使用，绝大多数跨链异常都能在半小时内定位。把这些工具固化到团队的 SOP 中，跨链项目的运维难度会显著下降。