3. SDK 的基本概念
SDK 这个词，做前端的兄弟应该不陌生。但说实话，很多人用了一两年，还是把它当个黑盒——拿到手就往上糊。我个人习惯把 SDK 理解成「功能模块的快递箱」：你不需要自己造轮子，拆开箱子调用接口就行。
这一章我们就聊三件事：SDK 到底能干什么、怎么把它接进来、版本号该怎么管。这三点是后面所有测试的基础。
3.1 SDK 的作用
说白了，SDK 就是「别人封装好的能力集合」。你想想看，如果不是为了省时间，谁会愿意往项目里塞第三方依赖？
我归纳了 SDK 最核心的四个作用：
- 提供现成功能：比如浏览器兼容性 SDK，你不需要手写 polyfill，它已经帮你覆盖了主流浏览器。
- 封装复杂性：不同浏览器对同一个 API 的实现可能有细微差别，SDK 在内部帮你做了适配，对外暴露统一的调用方式。
- 降低维护成本：当浏览器更新或废弃某个 API 时，你只需要升级 SDK 版本，不需要改业务代码。
- 统一错误处理：好的 SDK 会内置 fallback 机制和日志收集，出问题时能快速定位。
你在微信浏览器里调
window.fetch，低版本根本不支持。如果没用 SDK，你得自己写 XMLHttpRequest 的降级方案。用了 SDK 之后，一行 sdk.fetch(url) 就搞定，底层自动判断环境。
我在项目中遇到过一种情况：团队自己写了个工具库，测试时 Chrome 和 Safari 都没问题，结果一上国内某 X5 内核浏览器就炸了。嗯，后来我们换了个成熟的兼容性 SDK，省了大半个月的适配时间。
3.2 接入方式
接入方式就那么几种。我个人习惯先看文档里有没有 CDN 地址，再看是否支持 NPM 安装。如果是老项目，可能还得手动下载文件放本地。
3.2.1 CDN 引用
最常见的方式，适合传统页面或不想用构建工具的场景。直接往 HTML 里插一个 <script> 标签：
<script src="https://cdn.example.com/browser-compat-sdk/1.2.3/sdk.min.js"></script>记得把版本号写死。我曾经见过有人写 latest，结果某天 CDN 自动更新了主版本，页面直接白屏。避坑指南：你最好在发布前用 semver 锁定大版本。
3.2.2 NPM 安装
适合现代前端项目。一条命令解决问题：
npm install browser-compat-sdk@1.2.3然后在代码里引入：
import sdk from 'browser-compat-sdk';这样做的好处是，你可以在 package.json 里看到所有依赖的版本，方便后续管理和升级。
3.2.3 手动集成
有些企业内部网络禁用外链，或者需要定制化裁剪 SDK。这时就得把源码或打包好的文件放到项目目录里：
project/
├── libs/
│ └── sdk.js
├── src/
│ └── app.js这种方式后期升级比较麻烦，我建议尽量自动化。
3.3 版本管理
版本号看起来是个小事，但实际上坑很多。你没见过那种「测试环境跑得好好的，一上线就报错」的情况？很可能是版本不对。
3.3.1 语义化版本号
当前主流 SDK 都遵循 MAJOR.MINOR.PATCH 的规则：
| 示例 | 说明 | 升级影响 |
|---|---|---|
1.0.0 |
主版本，API 可能不兼容 | 需要修改接入代码 |
1.2.0 |
次版本，新增功能，向后兼容 | 一般不影响现有代码 |
1.2.3 |
补丁版本，修 bug | 安全升级 |
我建议你在接入时就把版本号记清楚。很多项目出问题，就是因为没人知道当初接的是哪个版本。
3.3.2 版本升级策略
当你准备升级 SDK 时，别直接改个版本号就部署。我一般会这么做：
- 先看 CHANGELOG，确认是否有破坏性变更。
- 在分支上升级，跑一遍现有的测试用例。
- 如果有兼容性测试环境（比如 BrowserStack），多测几个浏览器。
- 灰度发布，观察日志里有没有新增的报错。
记住：大版本升级相当于换了一个 SDK，千万别当小补丁来处理。
sdk@1.2.0 和 sdk@0.9.8 两个版本，因为不同模块各自安装了自己的依赖。结果全局对象被覆盖，功能全乱套。接入时一定做好版本单一性检查。
3.3.3 依赖锁与更新节奏
用 package-lock.json 或 yarn.lock 锁住版本，避免同事或 CI 环境安装到不同的次要版本。至于更新节奏，我个人的习惯是：
- 补丁版本：看到就升，大概率是安全修复。
- 次版本：读一下 changelog，如果新增的功能你用不到，可以等批量升级时一起处理。
- 主版本：不要急着升，等第一个小版本（比如
1.1.0）出来再说，通常第一版会有没修完的坑。
这张图把整个章节的逻辑串起来了：SDK 是中心，向外延伸出「作用」「接入方式」「版本管理」三条线，最后汇到测试关注点。你在实际做兼容性测试时，其实就是在检查这三个维度有没有出问题。