Solana失败交易照扣费，后端开发踩坑实录

做了三年后端开发，我以为自己对"失败请求"早就免疫了。HTTP 500？重试就行。数据库回滚？零成本。直到这三周在Solana上写合约，才发现Web3的计费逻辑完全不同——交易失败了，钱照样扣。

这不是理论，是我用真金白银试出来的。

为了验证这件事，我专门做了两组实验。第一组用最简单的方式：创建一个空钱包（0 SOL），尝试转账。solana transfer --from /tmp/broke-wallet.json $RECIPIENT 1，CLI直接拦截，提示余额不足。这次没收钱，因为验证发生在本地。

第二组才真正暴露问题。我换了一个有余额的钱包，但故意发起超额转账，并且加了危险参数skipPreflight = true——这个设置会跳过RPC预检，直接把交易送上链。结果？交易状态显示"Error processing Instruction 0"，但手续费0.000005 SOL照扣不误。钱包余额从8.39795变成8.397945，失败记录永远留在链上。

这个设计背后的逻辑和Web2完全相反。传统后端的习惯是"先验证，后执行"：检查余额、检查权限、检查参数，全部通过才落库。Solana的架构则是"先执行，后回滚"——交易一旦进入区块，无论成功与否，计算资源已经消耗，矿工费必须支付。

对开发者来说，这意味着容错成本被前置了。本地CLI拦截和RPC模拟是免费的防线，但一旦突破这两层，每笔失败交易都是实打实的开销。高频场景下，这个设计会放大代码缺陷的代价。

规避方案并不复杂，但需要改变思维习惯。第一，永远不要主动关闭skipPreflight，让RPC层的模拟检查成为默认流程。第二，客户端必须自己算清楚：余额不仅要覆盖转账金额，还要预留手续费。第三，把Solana的计费模型纳入错误处理设计——这里没有"试错"空间，每次上链请求都是最终状态。

我在GitHub上整理了完整代码和复现步骤，这是Solana百日开发的第19天记录。对于从Web2迁移过来的后端工程师，这个坑可能比你想象的更常见。