比特币核心的版本维护期：多久出一版、旧版本何时停发补丁

版本号不是按心情起的

Bitcoin Core 的版本号遵循”主版本.次版本”两段式结构，候选版本再追加 rc1、rc2 这样的后缀。项目按大约每六个月发布一个大版本的目标推进，次版本则是发布周期里的维护版本，只修 bug、做安全修复和性能改进，不引入大的新功能。这套编号看起来像语义化版本，但官方文档明确说明它并不遵循 SemVer 规范：次版本号的上升不代表向后兼容承诺的升级，只是维护批次的计数。理解这一点对运维决策很关键——不能拿次版本号当”可以放心原地升级”的信号，每次更新仍应读一遍发布说明。

比特币核心的版本维护期：多久出一版、旧版本何时停发补丁图 2 — 比特币核心的版本维护期：多久出一版、旧版本何时停发补丁 · 图 2

维护窗口只有三个大版本

官方维护政策的核心是一句话：始终维护最近的三个大版本。当新的大版本发布时，最老的那个就退出维护窗口、进入生命周期终点。以官方页面公布的政策表为例，v30.x 发布于 2025 年 10 月，v31.x 发布于 2026 年 4 月；一旦某个版本被判为 EOL，它原则上不再接收安全修复，包括那些已经公开的漏洞。回移门槛也随版本年龄上升：越老的分支，官方越不愿意把改动同步过去，只有足够严重的修复才值得为此发布一版。这就是为什么”我的节点还能跑”不等于”我的节点还在被保护”：软件功能一切正常，修复流水线却已经对你关闭了。

共识规则变更走维护版而不是大版

一个容易被忽略的细节：涉及共识规则的改动总是先随维护版本（如 22.2、23.1 这种）发布，而不是塞进大版本。原因很务实——维护版的改动集小，企业和节点运营者更容易逐行审查、测试和部署。这也是历史上不少软分叉部署代码都藏在 x.y 小版本里的原因。如果你在评估一次升级是否包含共识变化，看版本号的奇偶或者大小没有意义，唯一可靠的办法是读那次发布的发布说明原文。

软件版本之外还有一堆”版本”

生命周期文档专门提醒：交易本身有版本字段，P2P 网络协议有自己协商用的协议版本号，内置钱包也有内部格式版本。这些编号是刻意与软件版本解耦的——因为项目方要么控制不了它们（区块和交易），要么必须与别的项目保持兼容（网络协议）。所以”我的节点是最新版”并不自动意味着”我的钱包格式是最新的”，legacy 钱包退役那类事情就是钱包内部版本层面的问题。排查兼容性时要把这几层版本分开看。

普通人怎么把政策用起来

对个人节点运营者，可执行的纪律其实很简单：保持在你能够升级到的最新大版本的最新维护版；大版本发布后给生态留出几周的磨合期再跟进是合理稳妥的，但 EOL 版本不应作为长期运行状态存在；升级前花几分钟读发布说明里的”Notable changes”一节，重点看默认值改动、数据目录迁移和 RPC 变动。运行中的节点不要为了追新而追新，但也不要为了”稳定”而停留在一个官方已经不再发补丁的分支上——那种稳定是假象，安全公告发布的那天，你没有任何渠道获得修复。

版本之外的时间感

很多运营事故源自把”发版频繁”误解为”必须紧跟”。维护政策其实给了一个缓冲节奏：大版本大约半年一次，中间穿插若干维护版；对普通用户，合理的节奏是每年跟进两次大版本窗口，或者至少保证任何时候手里的大版本不在 EOL 名单上。反过来说，如果你所在的发行版软件源长期停留在某个两三年前的版本，问题不在比特币网络，而在你的包管理策略——包管理器里”最新”的定义与上游维护窗口是两回事，必要时直接从官方发布渠道核对当前受支持版本清单，再看发行版仓库是否跟得上。把升级当成日历上的固定动作而不是出事后的应急动作，是这条生命周期政策落到个人层面的唯一正确姿势。