一、版本管理基础：为什么需要版本管理？
说实话，我刚入行那会儿，对版本管理这事儿真没当回事。
那时候觉得，不就是改个版本号嘛，1.0、2.0随便写写得了。直到有一次，我在生产环境上栽了个大跟头——一个依赖库从 1.2.3 升到了 1.3.0，结果整个系统崩了。排查了一整天，最后发现是 API 接口变了，但版本号只升了个小版本，我压根没注意到。
嗯，从那以后，我再也不敢轻视版本管理了。
1.1 为什么需要版本管理？
你想想看，一个软件项目，少则几个依赖，多则上百个。每个依赖都在迭代，都在变化。如果没有版本管理，会是什么场景？
- 依赖地狱：A 需要 B 的 1.x，C 需要 B 的 2.x，你装哪个？
- 回滚无门：升级后出问题了，但你不记得之前装的是哪个版本。
- 协作混乱：团队里有人用 1.0，有人用 2.0，跑出来的结果都不一样。
- 安全漏洞：不知道当前版本有没有已知漏洞，也不敢随便升级。
我在项目中遇到过最典型的一个案例：一个前端项目，依赖了 200 多个包。因为没有锁版本，每次 CI 构建出来的产物都不一样。测试通过了，上线却挂了。后来一查，是某个间接依赖偷偷升了级。
核心观点：版本管理的本质，是让软件的每一次变化都可追溯、可控制、可复现。
1.2 常见版本号规范：语义化版本（SemVer）
说到版本号规范，目前业界最通用的就是 语义化版本（Semantic Versioning，简称 SemVer）。我个人习惯叫它「有意义的版本号」。
它的格式很简单：
主版本号.次版本号.修订号（MAJOR.MINOR.PATCH）举个例子：2.5.1
每个数字的含义是：
| 位置 | 名称 | 什么时候增加 | 举例 |
|---|---|---|---|
| 第一位 | 主版本号（MAJOR） | 做了不兼容的 API 修改 | 1.0.0 → 2.0.0 |
| 第二位 | 次版本号（MINOR） | 新增了功能，但向后兼容 | 1.0.0 → 1.1.0 |
| 第三位 | 修订号（PATCH） | 做了 bug 修复，向后兼容 | 1.0.0 → 1.0.1 |
小提示：我建议团队在项目初期就定好 SemVer 规范。别等到出问题了再补，那时候改版本号已经来不及了。
除了这三个基础数字，SemVer 还支持预发布版本和构建元数据：
1.0.0-alpha.1
2.3.0-beta+20240301
1.0.0-rc.1+build.1234这里要注意：
- 预发布版本（如
-alpha、-beta、-rc）的优先级低于正式版本 - 构建元数据（如
+20240301）不影响版本优先级，只是附加信息
1.3 安装路径与版本的关系
好，现在我们来聊聊安装路径和版本号之间到底有什么关系。
说白了，安装路径是版本号在文件系统上的物理体现。
我见过很多新手，把所有版本的软件都装到同一个目录下。结果想回退版本的时候，发现根本不知道哪个文件是哪个版本的。
常见的做法有这么几种：
方式一：版本号嵌入路径
/usr/local/node-v16.20.0/
/usr/local/node-v18.17.0/
/usr/local/node-v20.11.0/这种方式最直观。想用哪个版本，直接改 PATH 环境变量就行。我在管理多个 Node.js 版本时，就用的这种方案。
方式二：符号链接切换
/usr/local/node/current -> /usr/local/node-v18.17.0/这种方式更优雅。你只需要维护一个 current 软链接，指向当前使用的版本。切换版本时，改一下链接指向即可。
方式三：版本管理器
像 nvm、n、sdkman 这类工具，本质上也是在路径上做文章。它们把不同版本的软件安装到各自目录，然后通过修改 PATH 来实现版本切换。
注意：我曾经遇到过一个问题——用 nvm 切换了 Node 版本，但全局安装的包还在旧版本的目录下。这是因为全局包的安装路径和 Node 版本是绑定的。切换版本后，记得重新安装全局包，或者使用工具自动迁移。
1.4 版本与路径的协同管理原则
根据我多年的部署经验，总结了几条原则：
- 版本号必须出现在路径中：不要用
/usr/local/myapp/，要用/usr/local/myapp-1.2.3/ - 保留历史版本：别急着删旧版本，至少保留最近 2-3 个版本，方便快速回滚
- 使用符号链接指向当前版本：这样你的配置文件和脚本只需要引用固定的路径，比如
/usr/local/myapp/current - 版本切换要有日志：谁在什么时间切换到了哪个版本，都要记录下来。我在生产环境上吃过亏，有人半夜切了版本没通知，第二天全组排查了半天
1.5 一个简单的版本路径结构示例
下面是我个人比较推荐的一种目录结构：
/opt/app/
├── releases/
│ ├── 1.0.0/
│ ├── 1.1.0/
│ └── 2.0.0/
├── current -> /opt/app/releases/2.0.0/
└── version_history.log这种结构的好处是：
- 所有版本都在
releases目录下，一目了然 current软链接指向当前使用的版本version_history.log记录每次版本变更的时间、原因和操作人
一句话总结：版本管理不是写个数字就完事了。它关系到你的软件能不能稳定运行、能不能快速回滚、能不能多人协作。而安装路径，就是版本管理在文件系统上的「身份证」。
下一章，我会带你看看常见的版本管理工具，以及它们各自是怎么处理安装路径的。到时候我会拿 nvm、sdkman、pyenv 这几个工具来对比，看看它们的设计思路有什么不同。