语义化版本号
语义化版本号（Semantic Versioning，简称 SemVer） 是行业最通用的版本命名规范之一。其每位数字从左到右分别对应 主版本号（Major）、次版本号（Minor）、修订号（Patch），每一位的变更都有明确的含义，核心是通过版本号直观传递“软件变更的范围和影响程度”，方便开发者、用户和协作方理解兼容性风险。
1. 语义化版本号（SemVer）的核心定义：主版本号.次版本号.修订号
以 1.0.0 为例，三位数字的含义和变更规则如下表所示：
| 位置 | 名称（英文） | 含义（以 1.0.0 为例） |
变更场景（何时修改该位） | 兼容性影响 |
|---|---|---|---|---|
| 第1位 | 主版本号（Major） | 代表 核心架构/功能的重大迭代，1 表示第一个稳定的“大版本” |
1. 不兼容的 API 变更（如删除旧接口、修改参数格式）； 2. 核心功能重构（如从单体架构改为微服务）； 3. 彻底颠覆旧版本的设计逻辑（如 v1 是工具类，v2 改为平台类） |
不兼容：新版本无法向下兼容旧版本，旧代码可能报错 |
| 第2位 | 次版本号（Minor） | 代表 向后兼容的功能新增，0 表示该主版本下“暂无新增功能” |
1. 新增功能（如 v1.0.0 新增“数据导出”功能后变为 v1.1.0）； 2. 优化现有功能（如提升加载速度、增加配置项）； 3. 扩展 API（但不修改原有 API，保证旧代码可用） |
完全兼容：新版本可直接替换旧版本，旧代码无需修改 |
| 第3位 | 修订号（Patch） | 代表 向后兼容的问题修复，0 表示该版本“无已知 Bug 修复” |
1. 修复 Bug（如闪退、计算错误、逻辑漏洞）； 2. 修复安全漏洞（如 XSS、SQL 注入风险）； 3. 性能优化（不改变功能逻辑，仅提升运行效率） |
完全兼容：仅修复问题，不影响任何功能使用 |
2. 扩展：超出三位的版本号（可选后缀）
实际开发中，版本号可能在 Major.Minor.Patch 基础上增加 后缀，用于标记“非稳定版本”或“特殊版本”，常见格式如下：
- 预发布版本：用
-连接，标记“未正式发布的测试版”，如1.0.0-alpha（内部测试版）、1.0.0-beta（公开测试版）、1.0.0-rc.1（候选发布版，接近正式版）。
例：2.1.0-beta.3表示“2.1.0 版本的第 3 个公开测试版”。 - 构建信息：用
+连接，标记构建编号、时间或环境，如1.0.0+20240520（2024年5月20日构建）、1.0.0+build123（第123次构建）。
例：3.0.0-rc.2+build456表示“3.0.0 候选发布版第2版，第456次构建”。
3. 非语义化版本的特殊情况
部分软件（尤其是早期工具、客户端应用）可能不严格遵循 SemVer，此时版本号的含义需参考官方说明，常见特殊规则：
- 主版本号单独使用：如
Windows 10、macOS 14，这里的“10”“14”仅代表大版本迭代，无固定次版本/修订号逻辑。 - 四位版本号：如
Android 14.0.0.1，前三位遵循 SemVer，第四位可能是“紧急修复号”（针对特定设备的小补丁）。 - 日期格式版本：如
Chrome 125.0.6422.141（无日期，但部分工具如Git的版本号可能包含日期，如git-2.45.1.20240501），需结合官方文档理解。
总结
1.0.0 是 SemVer 规范的“初始稳定版”：
1（主版本号）：第一个稳定的核心版本，API 已定型；0（次版本号）：暂无新增功能，保持初始功能集；0（修订号）：无已知 Bug 修复，初始发布状态。
后续版本变更可通过数字变化快速判断影响：如 1.1.0 是“新增功能但兼容”，1.0.1 是“修复 Bug 且兼容”，2.0.0 是“不兼容的重大更新”。