填充错误
一次失败的 Solana 填充通常会以一个没有附带消息的数字错误呈现出来。下表列出了当前部署（Anchor 0.31.1）下常见错误码的含义。请把每一行都当作一个可能的原因，而不是确定的诊断结论。在解读某个错误码之前，先确认究竟是哪个程序、哪条指令失败了：来自内部 CPI（System Program、SPL Token 或intents_protocol）的错误也是通过同一个通道报告的。
结算与退款错误
这些错误来自input_settler_escrow，或者来自托管程序通过 CPI 消费认证时的 intents_protocol。
先释放输入结算的错误
一次先释放输入的结算会作为单笔交易整体失败。以下六个错误来自input_settler_escrow。
output_settler_simple 有自己的 NotTopLevel（6507，0x196b），用于当紧凑填充被某个程序调用的情况。
证明、未填充与租金错误
现在每个程序都有自己的错误码区间：
CommonErrors 为 6000–6022（共享），intents_protocol 为 61xx，输入结算器为 62xx–63xx，输出结算器为 64xx–65xx，预言机为 66xx–68xx。共享的 CommonErrors 错误码仍可能来自其中任何一个程序，而 SPL Token、System Program 和 Anchor 本身也使用各自的编号。请先从日志中读出失败的程序 id，再去解读错误码，并在 errors.json 中查找——见事件与错误。解读原始错误
Anchor 的错误编号是十进制的，而原始日志使用十六进制（3007 = 0xbbf）。请对照完整交易来核对”Instruction N”。钱包和构建工具可能会在前面插入 ComputeBudget 指令，从而使索引发生偏移。
预检和 RPC 行为
当一笔交易在预检阶段就失败时，链上不会产生任何交易，getTransaction/getLogs 也就无从查起。请从错误对象本身读取模拟日志（web3.js 中的 error.logs），或者重新模拟这笔已签名的交易。此外还有两个 RPC 方面的现实情况：
TransactionExpiredBlockheightExceededError只是客户端侧的超时，绝不是最终结论——该交易仍可能已经上链。在重建并重试之前，请先检查签名状态，否则可能会支付两次。- 在极少数情况下，一笔
confirmed的交易仍可能被回滚；在最终性至关重要的场景中，请使用finalized。
后续步骤
Solana 填充
填充指令及其验证规则
Solana 程序
这些错误背后的程序参考