时间锁到期，只说明这笔交易在协议规则层面不再被拒绝，不等于矿工会优先打包它。交易能不能进区块，还取决于另外两件事：这笔交易是否真的带了有效的锁，以及它出的手续费在内存池里排在第几位。时间锁解决的是"什么时候可以花"，手续费解决的是"矿工愿不愿意现在花空间装你"。
先确认：你的时间锁是不是真的生效了
有一种情况会让时间锁形同虚设：交易设置了 nLockTime，但所有输入的 nSequence 都等于 0xffffffff。在这种组合下，nLockTime 会被节点直接忽略，交易从广播那一刻起就是可打包状态。也就是说，你以为设了一个"到某高度/某时间之前不能进块"的锁，实际上这个锁从来没有锁上过。如果你用的是钱包自动生成的交易，通常不会出现这种矛盾配置；但如果是通过脚本、RPC 或某些高级工具手动构造的，值得先核对一下 nSequence 的取值。
另一种情况是脚本层面的时间锁（如 OP_CHECKLOCKTIMEVERIFY/CLTV）。这类锁的条件写在锁定脚本里，不满足时交易在验证阶段就会被判无效，根本进不了内存池，而不是"在内存池里排队等着"。如果你看到的交易已经广播出去、有 TxID、在区块浏览器上显示为未确认，那它大概率已经通过了脚本验证，问题不在脚本层面。nLockTime 的交易级锁和 CLTV 的脚本级锁是两套机制，不要混在一起判断。
时间锁到期后，真正的门槛是手续费
一笔已经广播、时间锁也已到期的交易，在内存池里的处境和普通交易没有区别：矿工按 sat/vB 从高到低挑选，区块空间装满就停。你的交易能进块，取决于前面有多少笔出价更高的交易在排队。
时间锁到期有一个容易被忽略的副作用：在锁未到期时，这笔交易在内存池里可能处于"非最终"（non-final）状态，部分节点不会把它当作正常的待打包交易来对待。一旦锁到期，它才正式进入手续费竞争队列。也就是说，你等待的那段时间里，内存池的费率水平可能已经变了。到期那一刻的推荐费率，未必是你广播时看到的那个数字。
如果你在广播时设置的手续费偏低，到期后它依然排在队尾。Ledger 的帮助文档给了一个实用的判断窗口：交易发出后等 2 到 3 小时是正常的；超过 3 小时仍未确认，手续费偏低的嫌疑就比较大。时间锁到期的交易同样适用这个逻辑——到期后如果迟迟不进块，先查费率，而不是怀疑锁没解开。
怎么查、怎么处理
第一步，用 TxID 在区块浏览器确认三件事：交易是否仍处于未确认状态、当前费率是多少 sat/vB、以及这笔交易是否标记为可替换（RBF）。如果费率明显低于当前内存池的推荐值，原因就找到了。
第二步，看钱包是否支持加速。 如果交易启用了 RBF，大多数自托管钱包会提供"提高手续费"（Increase Fee / Bump Fee / Accelerate）的入口。你重新提交的是同一笔支付，只是出价更高，旧版本会被替换掉。注意 RBF 的规则通常要求新版本在费率和绝对手续费上都高于旧版本，单纯把交易体积改小不一定够。
第三步，如果钱包不支持 RBF，或者交易没有标记可替换，处理起来会更被动。一种可能的结局是：交易在内存池里停留足够久之后被节点逐出，UTXO 回到可用状态，你可以重新构造一笔交易。但这个过程可能需要数天甚至更长，取决于内存池的拥堵程度和节点策略。在 UTXO 尚未释放之前，不要用同一笔输入重新发交易，否则可能造成冲突。
常见问题
Q：时间锁到期了，交易在浏览器上显示"未确认"，是不是锁没生效？
A：不一定。未确认只说明它还没被打包，不说明锁的状态。如果这笔交易在锁到期前就已经广播并出现在内存池中，到期后它自然进入正常的费率竞争。锁生效与否，看的是它有没有在到期前被拒绝；既然它一直在内存池里等着，说明锁的条件大概率已经满足，卡住的原因是手续费。
Q：我把 nLockTime 设在了未来，但交易立刻就被打包了，为什么？
A：检查 nSequence。如果所有输入都用了 0xffffffff，nLockTime 会被忽略，交易不会受到任何延迟。这种情况通常出现在手动构造交易或某些工具默认把 nSequence 设为最终值的时候。时间锁要生效，至少需要一个输入的 nSequence 小于 0xffffffff。
Q：交易卡了很久，我可以直接重新发一笔同样的转账吗？
A：取决于原交易的状态和你的钱包是否支持 RBF。如果原交易仍在内存池中且未启用 RBF，用同样的输入重新发交易会形成冲突，两个版本可能都无法确认。如果原交易已经被节点逐出、UTXO 回到钱包余额中，重新发才是安全的。在区块浏览器确认原交易的状态之前，不要盲目重发。
