一笔交易拆成几张收据：NEAR 的收据链、退款收据与六种等待档位

在 NEAR 上，真正被执行的单位不是交易。官方文档写得很直接：交易是用户表达意图的结构，进入网络后会被转换成一连串收据（Receipt）——节点之间交换的消息才是执行与调度的对象。这套”交易生收据、收据生收据”的结构，决定了好几种对交易状态的直觉读法在这里并不成立。

一笔交易怎么一块一块走下去

第一块区块做两件事：验证交易，把它转成一张包含全部动作的收据，同时从签名者的余额里扣掉 gas 与随行动作的附加金额——付费在收据创建时就发生了。如果签名者与接收者是同一个账户（比如给自己的账户加一把密钥），这张收据在同一个区块里就被处理完，交易即刻终局。签名者与接收者不同（比如给人转账），收据要到第二块区块才被执行。

收据执行过程中的一次函数调用还能再派生出一张或多张新收据——跨合约调用就是这么实现的——每张派生收据又要各自再占一块区块，如此递归。链条的结尾通常还有一张退款收据，在一个新区块里把没用完的 gas 退回：NEAR 的 gas 买入价通常高于销毁价，差价正是靠它返还。于是官方文档给出的典型图景是：简单交易一到一个三块区块达到终局，函数调用链越长拖得越久，分片拥堵还会进一步拉长每张收据的处理时间。

退款收据永远成功

每张收据执行时，系统都会顺手生成一张退款收据，归还未使用的附加金额与 gas 买卖价差。它永远执行成功、不承载任何应用逻辑。这个看似琐碎的细节，正是选择等待级别的依据之一：有些等待档位刻意不等退款收据，因为业务结果早已落定。

六种等待档位拆成两条轴

向 RPC 提交交易时可以指定 wait_until 参数。官方文档把六个档位拆在两条互不相同的轴上：执行轴（收据跑完没有）和终局轴（装交易与收据的区块被定死没有）。None 与 Included 只确认交易被受理；ExecutedOptimistic 表示非退款收据的结果都已可得，但区块还没终局；IncludedFinal 表示交易所在区块已终局，可部分收据仍可能悬着，结果只拿到一部分；Executed 是两者兼备——非退款收据执行完、区块也终局；Final 则是全轴闭环：所有收据（含退款）执行完毕、所有相关区块终局。官方文档特意提醒：ExecutedOptimistic 与 IncludedFinal 之间没有先后关系，它们是不同轴上的进度。想让业务结果既不缺席也不回滚，只有 Final 这一档做得到。

交易打勾不等于每张收据都绿

收据的状态有 Success、Failed 与 Unknown 三种；一张收据内部只要有一个动作失败，这张收据的全部动作整体回滚。而交易的状态由它的头一张收据决定。这就产生官方文档明确写出的情形：函数调用成功发出跨合约承诺时，头一张收据是成功的，交易被标记成功——哪怕随后被调用的函数所在收据彻底失败。只查交易哈希上那个绿色对勾，在 NEAR 上不足以断言”对方合约也执行成功了”，应当顺着交易详情把每张收据的执行结果都读一遍。这也是它和”所有动作要么全成要么全败”的账户模型直觉最大的分歧点：原子性管住的是单张收据的内部，跨收据的链条靠的是各自的命运。本文仅为机制解释，不构成投资建议。