比特币节点运维里有两类”到点自动停”的需求：一种是同步跑到某个区块高度就收工，另一种是磁盘上的历史区块导入完就停下。比特币核心把这两个需求做成了两个独立开关，-stopatheight 与 -stopafterblockimport，但它们都藏在帮助信息的调试档位里，普通帮助看不到，导致很多人根本不知道有这回事。
为什么普通 help 里查不到
在 v31.0 的参数注册表里，这两个开关都归在测试与调试类别，并带”仅调试”标记。帮助打印逻辑会检查一个名为 -help-debug 的开关：没打开时，所有带这个标记的参数会被整段跳过，不出现在输出里。它们不是隐藏秘密，而是官方明确认为普通用户不该日常改动的旋钮，所以默认不占帮助篇幅。想确认自己这个版本到底支持不支持，最直接的办法是运行带 -help-debug 的帮助输出再搜索参数名，而不是在普通帮助里翻半天然后断定”没有这个功能”。
stopatheight 的高度语义与那半句新增提示
-stopatheight 的默认值是 0，含义是”不设停线，一直跑”。设成正整数后，节点在主链达到该高度后停止运行。实现上这个值由内核通知模块读入并保存，运行中每接到一个新块就对照一次。
v31.0 的帮助文本在这行末尾补了一句值得注意的话：目标高度之后的区块可能在关闭过程中被处理。这句话澄清了一个常见误解——“到高度就停”不是把节点冻在某一高度的快照上，而是一条进程退出指令。节点在收拾数据库、落盘、断开对端的过程中，仍可能已经收到了更高的区块并处理了其中一部分。所以如果你的验证流程要求”账本必须精确停在第 N 块”，光靠这个参数不够，还得在停止之后核对节点报告的最高高度，而不是假设进程退出时刻与高度精确对齐。
stopafterblockimport 管的是另一件事
-stopafterblockimport 默认关闭，打开后的停点在”从磁盘导入区块”这个阶段结束的时刻。它对应的场景是区块文件重放式的启动：节点先把已经存在磁盘上的区块重新读一遍，再进入正常的追块与网络同步。把它打开，就等于在这两个阶段之间插了一道断点。
典型用法是配合启动自检参数做分阶段验证演练：先确认历史区块能通过校验，再决定要不要继续联网跑。对普通全节点用户，日常不需要碰它；对搭建自动化测试或校验流水线的运维，它省掉了”凭经验猜导入要多久”的等待。
用起来要注意的三件事
第一，停完就是进程真的退出，不是暂停。脚本要把这当成任务正常结束，而不是故障重启——否则会陷入”起来、跑到目标高度、停、再被拉起来”的循环。想续跑，把参数从配置里删掉或调高目标高度再启动。
第二，这两个开关只决定停在哪里，不改变校验规则本身。停机高度不等于检查点，也不给之后的数据提供额外保证。
第三，配置里同时留着一堆调试参数时要定期清理。带”仅调试”标记的参数不会因为写在配置文件里就失效，它们照样生效，只是不会出现在日常帮助里，最容易成为”谁都不知道是谁改的”的历史遗留。排查诡异行为时，把 -help-debug 帮助与自己的配置文件对照一遍，往往比读日志更快定位问题。
风险提示：本文为客户端参数机制说明，不构成任何投资或运维建议；调试类参数可能在不同版本中变更或移除，修改前请在测试网或副本数据目录验证，并保留完整数据目录备份。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。