getLatestBlockhash如何判断过期？

getLatestBlockhash 返回 blockhash 和 lastValidBlockHeight。交易是否过期应比较当前 block height 与这个上限，而不是从本机时钟估算已经过了多少秒。

取得区块哈希窗口

    {"jsonrpc":"2.0","id":72,"method":"getLatestBlockhash","params":[{"commitment":"confirmed"}]}

    {"jsonrpc":"2.0","id":72,"result":{"context":{"slot":301000000},"value":{"blockhash":"9xQeWv...","lastValidBlockHeight":279123456}}}

构造、模拟和发送应使用一致的 commitment 语义。不要把 context.slot 与 lastValidBlockHeight 直接比较，它们不是同一个计数。

正确判断过期

以下示例使用 @solana/web3.js 的 Connection：

    const latest = await connection.getLatestBlockhash("confirmed");
    const current = await connection.getBlockHeight("confirmed");
    const expired = current > latest.lastValidBlockHeight;

尚未过期时继续用 blockhash 与高度上限确认；已过期时先查询旧签名状态，确认没有落块，再取新 blockhash、重新模拟并重新签名。

不可盲目重发

网络延迟可能让客户端先超时而交易随后落块。直接换哈希重签可能重复执行业务，尤其是非幂等合约调用。应用应保存业务幂等键、旧签名和提交时使用的高度窗口。

还可用 isBlockhashValid 对旧哈希做辅助检查，但交易确认仍要带原始 lastValidBlockHeight 调用确认接口。重签前查询旧 signature 的各 commitment 状态；只有确定未处理且业务允许重试，才创建新的 message，避免两份有效签名竞争执行。

多签或离线签名耗时较长时，不应反复刷新 recent blockhash 让各方签署不同消息。流程若无法在有效高度内完成，应评估 durable nonce，并明确 nonce authority、advance 指令与重放保护；这与简单延长客户端超时不是一回事。

Solana getLatestBlockhash：当前证据的停止位置

网络负载和RPC链头差异会改变实际可用窗口，离线或多签流程应考虑durable nonce而不是无限延长近期hash。

Solana getLatestBlockhash：来源支持到哪一层

getLatestBlockhash返回近期blockhash与lastValidBlockHeight，交易可用二者设置生命周期。
判断过期应比较当前block height与lastValidBlockHeight，而不是把slot或本地等待秒数直接代入。
blockhash来自特定commitment上下文；签名、模拟和广播使用不一致的RPC或commitment可能导致blockhash not found。（有限确认）