Solana 交易流水线的八道关卡：为什么失败的交易也要扣费

从签字到提交：一笔交易在验证者机器上走过的路径

在 Solana 上点击发送之后，一笔交易并不是直接写进账本，而是在出块验证者的机器上过一遍流水线。官方文档把这段路径拆成八个阶段：接收并反序列化、签名验证、格式清洗、计算预算与时效检查、付款账户校验、账户加载、指令执行、提交。前几关挡掉的是结构或授权有问题的交易，它们连执行的机会都没有；越往后走，交易离状态变更越近，被拒绝时已经付出的成本也越高。理解这条先后顺序，是理解为什么有的失败不花钱、有的失败照扣费的前提。

签名、格式与时效：还没执行就被挡下的三种情况

第一关的开销最小也最不留情面：交易字节先要能按格式解开，随后每个签名与对应账户公钥逐一核对，任何一处签名无效，数据包直接丢弃，不涉及任何费用。通过签名关之后是清洗阶段，检查签名数量与头部声明是否一致、指令里引用的程序索引和账户索引是否越界、排在零号位的付款账户是否同时具备可写和签名两个属性。这些检查是纯机械的，失败的交易走到这里还没有产生扣费。再往后是计算预算解析与时效检查：交易引用的近期区块哈希必须在有效期内，官方文档记载的有效期上限为一百五十个时隙，超龄或查不到的交易需要改用耐久随机数（durable nonce）重新构建，否则被拒绝。同一阶段还会查状态缓存，消息哈希刚被处理过的交易直接以已处理拒绝。

扣费发生在执行之前：失败交易的两种结局

关键的分界点在账户加载之前：官方文档明确，交易费用在进入指令执行前就从付款账户扣除，如果后续任何指令报错，整笔交易的中间状态变更被回滚，但手续费不退。文档还专门给出一种叫 FeesOnly 的结局——付款校验通过、但账户加载失败的交易，只收手续费、不执行任何指令。换句话说，执行失败和没资格执行在账单上是两回事：前者钱照扣、状态不变，后者在扣费前的关卡就被拦下，分文不损。

手续费本身由两部分组成。基础费按签名个数计收，官方文档记载每个签名当前为 5000 lamports，其中一半销毁、一半归出块验证者；优先费按单价乘以计算单元上限的公式折算，官方文档记载其全额归验证者。这些数字与分配比例可能随协议演进调整，动手前以官方文档当期记载为准。

时效与缓存如何决定重发姿势

没有传统公共内存池的 Solana，靠区块哈希时效加状态缓存来防止重复入账与永久积压：过期未上链的交易会自然作废，而不是留在某个池子里等待，也因此过一会儿自动生效在 Solana 上通常不成立。等待失败的交易应当重建交易内容、引用新的区块哈希后重新签名发送，而不是原地重发同一份字节。

对普通用户意味着什么

把八道关卡映射回日常操作，可以得出几条实用判断：报错发生在签名或格式阶段，费用损失为零，修好重发即可；报错发生在执行阶段，手续费已经消费，回滚的只是状态；交易查无音讯多半是区块哈希过期，需要重建重签。查账时把是否扣费与状态是否变更分成两列核对，比只看一个成功失败标记更接近事实。

本文只解释协议机制，不构成任何投资建议，也不对任何资产价值作判断。