1、SDK 概述：什么是 SDK、SDK 的生命周期、SDK 版本号规范

1.1 什么是 SDK？

SDK 的全称是 Software Development Kit，中文叫“软件开发工具包”。说白了，它就是一套打包好的“积木盒”，里面装了库、API、文档、示例代码、编译工具等等。你开发应用的时候，直接用这套工具就能快速接入某个功能或平台，不用自己从零造轮子。

我刚开始接触 SDK 时，觉得它跟普通库差不多。后来发现区别挺大——SDK 通常更完整，它不光给你代码，还告诉你“怎么用、怎么配、怎么调”。比如 Android SDK，它包含了完整的模拟器、调试工具和系统镜像。你想想看，没有 SDK，你连个 Hello World 都跑不起来。

组成要素	说明
核心库 / 框架	封装好的功能接口，供你调用
API 文档	每个接口的用途、参数、返回值、错误码
示例代码	快速上手的 demo 工程
构建 / 调试工具	编译、打包、日志、性能分析工具
配置文件	密钥、环境标识、依赖声明

1.2 SDK 的生命周期

一个 SDK 不是写好就能一直用。它有自己的“生老病死”。我自己总结了四个阶段：开发 → 发布 → 维护 → 废弃。

1. 开发阶段：内部迭代，通常有 alpha、beta 版本。API 可能随时变，不适合外部大规模使用。
2. 发布阶段：推出第一个正式版（1.0.0）。这时候 API 稳定，文档和示例基本完善。
3. 维护阶段：收到 bug 反馈、发小版本修修补补，也可能加一些向后兼容的功能。这个阶段最考验版本管理能力。
4. 废弃阶段：官方宣布 deprecate，最终不再维护（End of Life）。我见过不少团队把 SDK 丢在废弃期不管，结果用户还在旧版本上踩坑。

每个阶段对应的版本号也有讲究。往下看版本号规范，你就明白了。

1.3 SDK 版本号规范

版本号不是随便写的。业界最通用的是语义化版本（Semantic Versioning，简称 SemVer）。格式很简单：MAJOR.MINOR.PATCH。

• MAJOR：不兼容的 API 更改。比如改了接口签名、删了方法、改了返回类型。
• MINOR：新增功能，但向后兼容。旧代码不用改也能跑。
• PATCH：修 bug，不改变接口。只改内部实现。

举个例子：某个图库 SDK，从 2.1.3 升级到 2.2.0。说明它加了个滤镜功能，但之前调用的代码不用动。如果升级到 3.0.0，那就意味着你现有的初始化代码可能得重写。

版本号	含义	影响范围
0.1.0	开发初期，接口不稳定	不推荐外部使用
1.0.0	第一个正式版	API 稳定，可依赖
1.1.0	新增功能	向后兼容，可平滑升级
1.1.1	修复了一个崩溃	仅内部改动，直接替换
2.0.0	不兼容重构	需要迁移代码

除了 SemVer，有些 SDK 也用日期版本（比如 2024.03.01）或自增数字。但说实话，日期版本很难判断兼容性。我个人的建议是：能用 SemVer 就用 SemVer，它能让版本兼容判断变得清晰。

// 一个简单的版本比较逻辑（伪代码）
function compareVersion(v1, v2) {
  // 按 '.' 拆分为数组
  const parts1 = v1.split('.').map(Number);
  const parts2 = v2.split('.').map(Number);
  // 逐级比较 MAJOR → MINOR → PATCH
  for (let i = 0; i < 3; i++) {
    if (parts1[i] > parts2[i]) return 1;
    if (parts1[i] < parts2[i]) return -1;
  }
  return 0;
}

1.4 把知识串起来——SDK 生命周期与版本号的关系

下面这张图概括了 SDK 从出生到退役的全过程，以及每个阶段对应的版本号变化。

从图里你可以看到，版本号跟生命周期是绑定的。开发阶段用 0.x.x，第一个正式版用 1.0.0，后续的 MINOR/PATCH 小版本走维护阶段，直到官方宣布废弃。嗯，这也是我做版本兼容测试时最主要的依据——知道某个版本处于什么阶段，就能判断该不该升级、风险多大。