操作系统兼容性概述
什么是操作系统兼容性
操作系统兼容性，说白了就是你的软件能不能在不同的系统上跑起来，而且跑得稳。我刚开始做SDK那会儿，觉得只要API封装好了，用户在Windows上能编译，那Linux肯定也行——结果你猜怎么着？客户反馈一上来自定义路径带中文就崩，调了三天才发现是文件编码的问题。嗯，从那以后我再也不敢小看兼容性这事了。
更准确地说，操作系统兼容性包含两层意思：功能兼容和运行兼容。功能兼容指的是SDK提供的接口在不同系统上调用的行为一致；运行兼容则指SDK在目标系统上能正常安装、加载、不产生环境冲突。我自己遇到过最夸张的一次，同一个.so库在CentOS 7上跑得好好的，换到Ubuntu 20.04就段错误，最后查出来是glibc版本符号版本化的问题——你想想看，底层库差两个小版本就能让你SDK直接崩。
兼容性问题的常见表现
我整理了一下，大部分开发者踩过的兼容性坑集中在下面几类：
- 系统API差异——比如Windows用
CreateFile，Linux用open，虽然逻辑一样但参数含义和错误码完全不同。 - 运行时库不匹配——不同系统打包的C运行时、C++ ABI、线程模型都可能影响SDK行为。
- 文件系统/路径风格——Windows用反斜杠，Linux用正斜杠，大小写敏感与否也是大坑。
- 权限与安全模型——比如macOS的沙盒机制、Android的权限声明，搞不好就直接拒绝加载。
- 编码与国际化——我早期一个项目在简体中文Windows下没问题，到日文系统上字符显示就乱码，后来才知道API默认用的是系统ANSI编码。
为什么需要SDK接入测试
你可能会问：我开发的时候在Windows上测得好好的，为什么要花额外精力做SDK接入测试？举个例子，我去年帮一家物联网厂商做SDK适配，他们的设备端SDK在Linux编译通过，但嵌入到OpenHarmony后系统调度器行为不一样，导致线程优先级反转。如果没有专门的接入测试，这种问题只能等上线后崩溃日志堆起来才被发现——那时候客户早跑光了。
SDK接入测试的核心目的，就是在软件交付前，验证SDK在目标操作系统上的二进制兼容、行为兼容和性能兼容。我习惯把它拆成三个维度：
| 测试维度 | 要测什么 | 我踩过的坑 |
|---|---|---|
| 二进制兼容 | 链接不报错、符号导出正确、ABI一致 | 曾经因为Release版优化选项不同导致结构体对齐不一致，运行时数据错乱 |
| 行为兼容 | API返回值、异常码、回调时序是否一致 | Windows下GetLastError和Linux下errno的线程安全模型完全不同 |
| 性能兼容 | 资源消耗、延迟、吞吐量在系统间差异可接受 | 一个加密SDK在Linux上很快，到macOS上因为内核随机数生成器不同，慢了20倍 |
SDK接入测试的核心价值
说白了，做SDK接入测试不是为了应付领导，而是为了帮自己省钱省时间。我总结了三个最直接的价值：
- 提前发现平台专有问题——比如某些系统只支持
mmap的特定文件描述符模式，你在Windows上用MapViewOfFile从来不会触发 - 减少线上事故——有一次我因为忘了测试32位系统上的
size_t截断，上线后日志全毁，回滚到凌晨三点 - 降低集成成本——你把兼容性验证标准化成自动化测试，集成方拿到SDK就能一键跑过，不然每次都得手动给客户解释“这个场景我们没测，你试试看”
知识体系：操作系统兼容性SDK测试全景
下面这张图梳理了从SDK开发到接入测试的完整流程，以及每个环节需要关注的兼容性要点。你可以把它当成后面章节的导航地图。
这张图里的每一层，对应后面章节要深入的内容——应用层如何调用、SDK接口如何抽象系统差异、不同操作系统下的运行时细节、测试工具的搭建，以及如何分析结果。你不用一下子全部记住，先有个全局印象就好。