Solana交易为什么很快过期：151个blockhash窗口怎么算
Solana交易迟迟没被打包就会失效，决定这个过期时间的不是钱包里的倒计时，而是交易引用的blockhash有多“老”。按Solana开发者文档的口径，集群目前要求交易使用的blockhash年龄不得超过151个区块。一旦超过这个上限，交易就不再具备被打包资格，只能重新获取blockhash并再次签名。
这里要先分清“区块计数”和“时间”的关系。151是一个以区块计数的窗口，不是写死的秒数。文档给出的换算是：当每个slot按400毫秒的目标时间处理时，151个区块可以快至约一分钟。也就是说，同样是151个区块的窗口，网络出块节奏不同，实际经过的墙钟时间会不同，不能把它当成固定的“60秒过期”。
这个窗口的起点，是客户端向RPC节点请求blockhash的那一刻，而不是用户点下“发送”的那一刻。一笔交易从获取blockhash、等待用户签名，到广播出去、再排队等待被leader接受，全都消耗这151个区块的额度。文档特别提醒，考虑到客户端要取最新blockhash、等签名、再指望广播的交易抵达愿意接受的leader，一分钟并不宽裕。因此过期往往不是“链上处理慢”这么简单，而是整条链路上的等待叠加起来吃掉了窗口。
窗口大小本身是一个权衡。文档明确写到：如果过期时间调长，验证者需要更多内存来跟踪更多交易ID以防重复处理；如果调短，用户可能还没来得及提交交易就已过期。目前选择151个区块，是在内存开销和可用性之间取的折中。文档还提到，未来有可能在不降低过期时间的前提下压缩这部分内存占用。
对应用和用户来说，能做的不是延长窗口，而是让交易尽量“新鲜”。文档建议在获取blockhash时使用getLatestBlockhash，并注意commitment级别：该接口默认返回最近已finalized区块的blockhash，也可以通过commitment参数改为其他级别。假设一笔交易在签名环节停留过久，或广播后迟迟没有进入区块，那么它过期后不会再有被打包的可能，用户重试时应当重新获取blockhash并重新签名，而不是把旧交易反复广播。理解这一点，就能把 pending 状态看成有明确终点的状态，而不是无限等待。