结论先说
Solana 的 RPC 查询结果带着一个承诺级别（commitment）：官方文档定义了从松到紧的三档——processed、confirmed、finalized。processed 是该节点自己的最新视角，仍可能被推翻；confirmed 要求区块被不少于三分之二的活跃质押直接投票确认；finalized 是网络公认的、达到最大锁定高度的区块。不指定级别时，查询类方法默认返回 finalized。同一笔签名“查得到”还是“返回 null”，取决于你在哪一档提问，把三档混为一谈是最常见的误判来源。
三档的官方定义
processed 返回节点在当前最佳分叉上已处理的最高 slot，视角最新，但区块仍可能被分叉切换推翻，甚至被集群整体跳过——官方文档特别写明这一档只是该节点自己的视图，不代表网络共识。confirmed 的门槛是至少三分之二的活跃质押对该区块本身直接投票，注意官方口径强调只计直接投票、不累计对其后代的票，这一档对应所谓乐观确认保证。finalized 表示该 slot 在验证者的投票结构中达到最大锁定并被三分之二以上质押认可，是网络当前使用的最强确认状态。三档不是三个“确认数”，而是三种对同一份账本的不同信任强度。
场景怎么选
官方文档的建议是按用途分层：展示进度用较低档位，需要状态不会被回滚的判断用较高档位；连续发送互相依赖的交易时推荐 confirmed，在速度与回滚风险之间取平衡；追求最高确定性则用 finalized。方法层面的坑有两个：部分查询方法不接受 processed 参数，传错会得到报错而不是结果；以及 getTransaction 类方法返回 null 时，字面含义只是“在所请求的承诺级别上没找到”——交易完全可能已经出现在更低的档位里，正确的动作是降低档位复查，而不是直接宣布丢单。
默认值与时间线
容易被忽略的是默认：不传 commitment 时节点默认按 finalized 查询。这意味着一句朴素的“查最新余额”可能给出相当保守的视图，刚发出的交易会表现为“没变化”；反过来，不少界面为了让体验顺滑采用 confirmed 甚至 processed，用户看到的其实是仍可能改动的视图。两个方向别搞反：查询结果显得慢，不等于出错；显得快，也不等于已经不可回滚。
还有一层差别藏在调用方式里。一次性查询与订阅监听都接受 commitment 参数，订阅的语义是按你指定的档位推送新状态：档位选得越低，通知来得越早，但也越可能被后续推送推翻；工程上常见的做法是低档位推送先更新界面，等同一签名在更高档位再次推送后才落库确认。把协议自己标注为“仍可能被推翻”的首帧数据直接当作定论写入业务系统，是这类问题的典型来源。
交叉验证与误判
实操顺序：先确认你的页面或 RPC 服务商在哪个档位报数；同一签名在不同节点一处有一处没有，先怀疑档位不同或节点处在不同分叉视角，再谈异常；读取依赖前一笔交易的状态时，把读写两侧各自的 commitment 分开核对；核对余额或代币账户大小时，注明结果来自哪一档，再和交易所或其他平台给出的入账结论对比，避免拿不同强度的视图互相指控出错。关于 slot 与等待时长的关系见 Solana slot和确认时间区别？，那篇解释时间单位，这一档解释的是可信度档位，两者正交。
边界与风险
承诺级别刻画的是网络对区块可回滚程度的认定，不是应用层不出事的保险：交易即使 finalized，业务逻辑缺陷、误授权、地址错误也不会自动挽回。服务商也可能在自己的接口上再包一层策略（比如强制最低档位），文档默认值不等于你实际拿到的行为。方法行为与参数细节随版本演进，请以 Solana 官方文档和你所用 RPC 服务的实际返回为准。本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。