3. 版本号的生命周期：Alpha、Beta、RC、Stable 各阶段的特点与命名规则

聊到版本号，很多人第一反应就是「1.0.0」这种数字组合。但说实话，真正让我头疼的从来不是数字怎么排，而是——这个版本到底能不能用？

我记得刚入行那会儿，看到软件包后面跟着「Alpha」「Beta」这些标签，完全没当回事。结果有一次在生产环境部署了一个 Beta 版本，半夜被报警电话叫醒……嗯，从那以后，我再也不敢小看这些后缀了。

今天我们就来拆解一下，版本号生命周期里这几个关键阶段——Alpha、Beta、RC、Stable。它们到底代表什么？命名上有什么讲究？

3.1 为什么需要生命周期阶段？

说白了，一个软件从写完到真正交付，中间隔着一条河。你不能刚写完代码就扔给用户，对吧？

我个人的习惯是，把版本生命周期分成四个阶段：

• Alpha —— 内部开发，功能可能不全，Bug 遍地跑
• Beta —— 功能冻结，开始找外部用户帮忙踩坑
• RC —— 候选发布，基本稳定，就差最后一哆嗦
• Stable —— 正式发布，可以放心用了

你想想看，如果没有这套阶段划分，你拿到的版本可能是昨天刚写完的代码，连编译都没通过。那谁还敢用？

3.2 Alpha 阶段：内部尝鲜，别往外传

Alpha 这个词，最早来自希腊字母 α。在软件领域，它代表「最早期的可用版本」。

特点：

• 功能可能不完整，有些模块还是空的
• Bug 数量多，而且可能很严重（比如直接崩溃）
• 仅供内部开发团队或少数信任的测试人员使用
• API 不稳定，随时可能改

命名规则：

常见的写法有：

v1.0.0-alpha.1
v2.3.0-alpha.20250301
v0.9.0-alpha

3.3 Beta 阶段：功能定了，开始找 Bug

Beta 是希腊字母 β。到了这个阶段，功能基本冻结了——也就是说，不会再加新功能了。团队的主要精力放在修 Bug 上。

特点：

• 功能完整，但可能有隐藏的 Bug
• 会邀请外部用户参与测试（也就是「公测」）
• API 基本稳定，但可能还有小调整
• 性能、安全性等非功能性需求可能还没优化到位

命名规则：

v1.0.0-beta.1
v2.3.0-beta.20250315
v1.0.0-beta2

3.4 RC 阶段：就差临门一脚

RC 全称是 Release Candidate，翻译过来就是「候选发布版本」。到了这一步，团队认为软件已经足够稳定了，如果没有发现严重问题，就直接拿它当正式版发布。

特点：

• 代码与正式版几乎一致
• 只修关键 Bug，不修小问题
• 通常只发布 1~3 个 RC 版本
• 如果 RC1 没问题，RC1 就是最终的 Stable

命名规则：

v1.0.0-rc.1
v2.3.0-rc.20250401
v1.0.0-rc2

3.5 Stable 阶段：正式交付

Stable 就是正式版。到了这一步，软件可以放心地部署到生产环境了。

特点：

• 经过充分测试，关键 Bug 已修复
• API 稳定，向后兼容
• 提供长期支持（LTS）的版本会在这个阶段标记
• 用户可以直接下载使用

命名规则：

v1.0.0
v2.3.0
v1.0.0-stable

其实很多项目在 Stable 版本上不会特意加「-stable」后缀，因为默认就是稳定版。但有些项目为了明确区分，还是会写上。

3.6 一张图看懂生命周期

下面这张图，是我自己画的一个版本生命周期流转图。你可以看到，每个阶段都有明确的进入和退出条件。

从图上你可以看到，每个阶段都有可能回退。比如 Beta 阶段发现了一个严重的设计缺陷，那就得回到 Alpha 阶段重新开发。这不是失败，而是正常的迭代过程。

3.7 常见命名风格对比

不同的项目，命名风格差别还挺大的。我整理了一个表格，方便你对比：

3.8 避坑指南

最后，分享几个我踩过的坑：

• 我曾经把 RC 版本当 Stable 发布 —— 结果发现 RC 版本里有一个内存泄漏，上线两天 OOM 了。后来我养成了一个习惯：RC 转 Stable 之前，必须经过至少 48 小时的线上压测。
• 我曾经在 Alpha 阶段就开放了下载 —— 用户下载后各种崩溃，差评如潮。Alpha 版本真的只适合内部，别手痒。
• 命名不一致 —— 同一个项目里，有的版本叫 beta1，有的叫 beta.1，还有的叫 beta-1。解析脚本写起来非常痛苦。统一风格，从第一天做起。

好了，关于版本号的生命周期，今天就聊到这里。下一章我们会深入讲讲语义化版本规范（SemVer）的具体规则，到时候你会看到，版本号里的每一个数字都不是随便写的。