在 regtest 沙箱里排练协议场景时，比特币核心给测试脚本留了一台”时间机器”：启动参数 -mocktime 与运行期命令 setmocktime。它们看起来是一对——都把节点眼里的”现在”换掉——但实现位置、生效范围和限制条件完全不同。v31.0 源码里两条路径的差别值得逐项对照，因为误用 mocktime 造成的假通过测试，比测试本身没写更危险。
启动参数：一次赋值，全程有效
init.cpp 的注册行写着 “Replace actual time with <UNIX epoch time> (default: 0)”，归类在仅调试的测试选项里。实现只有一步：初始化阶段若检测到该整数参数，就调用 SetMockTime 把全局假时间设进时钟抽象。此后节点内部凡是取自这个时钟的时间判断——区块时间戳窗口、节点是否在初始同步期的判定、交易过期相关逻辑——读到的都是这个固定值，不会随墙钟走动。“固定”是关键：mocktime 不会自动前进，脚本必须靠反复调用 setmocktime 一格一格推时间。
值得注意的细节是：源码在启动路径上把这条赋值放在”回归测试用”的注释之下，但没有按网络类型设置准入判断，而运行期的 RPC 命令则明确写着仅限 regtest，在非模拟链上会抛出 “setmocktime is for regression testing (-regtest mode) only”。也就是说，防护主要落在 RPC 上。这条差别是社区教程里极少讲清的事实，也解释了为什么任何在生产网络玩 mocktime 的教程都不值得信任——它技术上或许可行，但后果包括区块被当作超前时间拒绝、节点被对端断连、自身判定长期卡在同步态。
RPC 路径：一格一格推时间
setmocktime <timestamp> 的文档写得很短：设置本地时间为给定时间戳，传 0 恢复系统时间。实现里还有两个保护：验证进行中不允许改时间，避免一半用旧时间一半用新时间；改动之后时间不会自己流动，直到下一次调用。典型用法是配合 generatetodescriptor/-regtest 造块：把时间拨到目标高度之前的任意位置，验证相对时间锁的边界块、区块时间戳的超前判定，观察节点在自己时钟下的取舍。
测试与现实的三道落差
第一，真实网络的不确定性不在场。mocktime 让你以为”两小时零一秒后区块被拒”这条规则被验证过了，实际上你验证的是规则在理想时钟下的表现，节点间时钟偏移、消息乱序、重组交错都没有参与。第二，时间字段的可信来源在测试里被你垄断：主网上区块时间是矿工写的、由全网按中位数校验，regtest 里你自己造块，等于把被测对象和裁判都攥在手里。第三，setmocktime 传 0 只是恢复系统时钟，不是清除测试已经写入的链上状态；测试之间应当用干净的 datadir 隔离，而不是靠拨回时间假装什么都没发生。
写脚本的三条纪律
启动时用 -mocktime 钉一个起点，运行中只用 setmocktime 推进，别混用系统时间与假时间做断言；每个场景独立 datadir，测完即弃；把”时间推进量”写进用例标题，让评审的人一眼看出哪条边界是被人为制造出来的。能做到这三条，mocktime 从玄学变成可审计的测试夹具。
最后一个常被问到的问题：mocktime 会不会影响钱包交易的时间标记？在测试网络内，节点记录的块时间与交易时间都取自同一假时钟，因此钱包视图会跟着你的剧本走——这恰好是测试目的，但也意味着测试里”某笔收款显示为某天”不代表主网会有同样表现。
一句话总结分工
启动参数的定位是”给整场测试一个统一的假起点”，RPC 命令的定位是”在剧本的关键节点拨表”。前者设一次，后者拨多次；前者影响进程生命周期的所有时刻，后者受验证状态保护。理解了分工，再看到测试框架里成对出现的启动参数与 setmocktime 调用，就不会误以为其中一个是冗余。顺带提醒：mocktime 与真实时间源不发生任何关系，你的系统时钟、NTP、对端的时钟全部照常运行，被测的只有这台节点自己的判断——这也是为什么跨节点的时间锁演练必须用真实时钟、不能靠假时间糊弄。
风险提示：本文为测试参数与调试命令机制说明，对应 Bitcoin Core v31.0 源码；调试参数不得用于生产网络，任何据此得出的结论仅代表测试环境；不构成投资建议或任何收益承诺。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。