在与同行交流跨链开发时，LayerZero 常见错误几乎是最高频的话题。这些错误本身并不复杂，但因为跨链涉及两条链与多个组件，常常让新手摸不着头脑。本文按错误现象分类，结合 Binance 智能链上的实战案例给出排查思路与修复建议，希望能帮你少走几小时弯路。
TrustedRemote未配置或配置错误
这是新手最常见的问题。表现为 send 调用成功、源链 emit PacketSent，但目标链一直没有 PacketReceived。原因往往是目标链合约的 trustedRemote 未指向源链合约，或两端的 chainId 写反了。解决方案是用脚本拉取两端 trustedRemote 当前值，与预期 abi.encodePacked(remote, local) 比对。务必记住 LayerZero 内部 chainId 与 EVM chainId 不同，必安 链是 102 不是 56。
estimateFees返回零或异常
如果 estimateFees 返回 (0, 0)，说明传入的 dstChainId 或 destination 不被 Endpoint 识别。可能是 chainId 拼写错误，也可能是 destination 没有按 abi.encodePacked 格式编码。建议在前端或脚本中先调用 Endpoint 的 isSupportedDstChain 方法确认链路可用，再传给 send。B安交易所 上不少 DApp 直接把这一步暴露给用户，避免因配置错误而扣手续费。
adapterParams格式错误
adapterParams 必须遵循特定字节格式。v1 格式是 0x0001 + uint256(gasLimit)，长度恰好 34 字节。如果手动拼接出错，send 会直接 revert。可以使用官方提供的 LzApp.sol 中 _getAdapterParams 函数确保格式正确。错误的 adapterParams 是 BN官网 跨链对接团队反复强调要在前端做校验的部分。
storedPayload卡住
目标链上 lzReceive 失败时会生成 storedPayload，并阻塞同一通道的后续消息。解决方法是先找出失败原因（通常通过 forge 本地复现），修复后调用 retryPayload；或者在确认无法恢复的情况下调用 forceResumeReceive 强制丢弃。注意 forceResumeReceive 会丢失这条消息携带的状态变更，必须谨慎使用。币岸 多个项目的 SOP 都把 forceResume 列为最后手段。
NonblockingLzApp的失败重入
NonblockingLzApp 通过 try/catch 把失败消息存到本地 failedMessages，避免阻塞通道。但有时开发者会发现 _nonblockingLzReceive 内部也 revert 了，且 failedMessages 中没有记录。原因往往是 try/catch 之外的代码同样 revert（例如内存分配过大）。建议把 _nonblockingLzReceive 体内所有逻辑都裹在一个内部函数中，确保任何 revert 都能被外层捕获。
跨链消息顺序
LayerZero 在同一通道（srcChainId + srcAddress + dstAddress）上保证消息顺序。如果你的应用对顺序敏感，注意所有发送方都要使用同一个源合约地址；否则消息会进入多个通道，可能乱序到达。这一点在某些桥接项目中曾导致用户资产入账错乱。
小结
LayerZero 常见错误绝大多数都集中在配置与编码层。把 trustedRemote、chainId、adapterParams、storedPayload 这四件事熟练掌握，开发与运维过程就会顺利得多。建议把本文这份清单贴在团队 Wiki，遇到问题时优先对照检查。