nLockTime、CLTV和CSV有何区别？

把nLockTime、CLTV和CSV都翻译成“时间锁”，很容易误以为它们只是三种写法。其实三者回答的问题不同：nLockTime约束整笔交易最早何时可被确认；CLTV让某段脚本要求这笔交易的绝对锁定值达到门槛；CSV则让某个输入在其被确认后再等待若干区块或相对时间。

先分清“交易级还是脚本级”“绝对还是相对”，再看具体数字，排查会快很多。

一张表先定位三者

机制	作用位置	时间参照	关键字段	典型用途
nLockTime	整笔交易	绝对高度或时间	locktime、input sequence	预签未来交易
CLTV	输出脚本	绝对高度或时间	脚本阈值、交易nLockTime	到期后退款、继承条件
CSV	输入脚本	相对确认时间	transaction version、nSequence	延迟退出、惩罚窗口

nLockTime中的数值小于5亿时按区块高度解释，达到或超过5亿时按Unix时间解释。它不是“到点自动执行”：条件满足后，交易只是从不可被区块接受变成可以被打包，仍需广播、支付合适费率并通过其他验证。

一笔交易即使写了nLockTime，如果所有输入的sequence都使用最终值，锁定条件不会按预期生效。BIP 65也要求执行CLTV的那个输入不能使用最终sequence。于是签名前只看页面上的“解锁日期”不够，还要检查每个输入的sequence。

交易使用哪些UTXO、找零回哪里，可结合比特币UTXO与账户模型理解。若你收到的是PSBT，更应在可信设备上核对完整交易字段，参见PSBT签名前核对清单。

CLTV不会修改交易的nLockTime，而是拿脚本栈中的门槛与交易nLockTime比较。二者必须属于同一类型：不能拿区块高度门槛去匹配时间戳型nLockTime。交易值若早于脚本要求，或输入sequence为最终值，脚本验证失败。

这让一个输出可以设计两条路径：例如某方在到期前凭指定条件花费，另一方在到期后走退款路径。关键是，真正被锁住的是这枚输出的花费条件，而不是钱包界面里的标签。

BIP 68把版本2交易输入的nSequence部分位解释成相对锁定值：可按区块数，也可按以512秒为单位的相对时间。BIP 112的CSV操作码在脚本里检查这组条件。因此它适合表达“这枚输出确认后至少再等N块”，而不是某个固定日历日期。

CSV还包含禁用标志、类型标志和掩码规则。若交易版本、sequence类型或数值不匹配，不能简单把一个十进制数字当作等待块数。钱包或合约说明只写“延迟一天”时，应要求它展示原始交易和脚本依据。

时间型锁定不是直接相信单个新区块的timestamp。BIP 113使用过去11个区块时间戳的中位数，即Median Time Past，作为共识时间参照。这样可以减弱单个矿工把区块时间拨快对锁定交易的影响。

因此，本地电脑已经到达某个时间，不代表交易立刻满足链上条件。MTP可能落后于墙上时间；高度型锁定也要等相应区块真正产生。加速费率只能改善满足条件后的打包竞争，不能绕过时间锁。交易可花费后若费率不足，再考虑RBF和CPFP的选择。

“交易已经签名，所以到期一定执行”是错的；没有广播者、费率不足或UTXO已被其他交易花费，都可能让它不执行。“提高矿工费可以提前解锁”也是错的，未满足共识条件的交易不能靠加价通过。“sequence只负责RBF”同样不完整，它还承载相对时间锁语义，必须结合交易版本和具体位判断。

本文用于比特币协议与签名安全教育，不构成托管或交易建议。时间锁脚本可能包含多条分支，钱包展示也可能省略原始字段。金额较大或涉及继承、托管、闪电网络时，应在隔离环境解析完整交易与脚本，并先做小额演练。