第三章 桌面平台SDK差异：Windows、macOS、Linux
桌面三巨头——Windows、macOS、Linux，每个都有一套自己的脾气。很多新手觉得“跨平台不就是写一遍代码到处编译吗？”嗯，真这么想，后面肯定掉坑里。我入行第三年接手过一个金融客户端适配项目，Windows跑得飞起，一上macOS就崩，查了两天才发现是文件路径分隔符的锅。今天咱们把这些差异掰开揉碎讲清楚。
3.1 文件系统与路径的“三国演义”
| 维度 | Windows | macOS | Linux |
|---|---|---|---|
| 路径分隔符 | 反斜杠 \ | 正斜杠 / | 正斜杠 / |
| 大小写敏感 | 不敏感（NTFS默认） | 不敏感（APFS默认，但可开启） | 敏感（ext4默认） |
| 驱动盘概念 | 有（C:, D:） | 无（挂载点 /Volumes） | 无（挂载点 /mnt 或 /media） |
| 最大路径长度 | 260字符（如需支持长路径需特殊API） | 1024字符 | 4096字符 |
你想想看，如果SDK里硬编码了反斜杠，在macOS/Linux上直接崩。我建议在代码里统一用正斜杠，然后用QDir::toNativeSeparators()（Qt系）或os.path.join()（C++建议自己写一层封装）在最后一步转换。
核心原则：代码内部全部用正斜杠 /，只在系统调用前做一次适配转换。
我曾经遇到一个项目，开发人员在Windows上生成了一堆带反斜杠的硬编码资源路径，提交到Git后Linux同事拉下来直接报错。后来我们给CMake加了一行规则：所有路径变量在构建时自动转换成平台原生格式。
3.2 动态库的加载与命名差异
SDK集成绕不开动态库。Windows叫DLL，macOS叫dylib，Linux叫so。命名规范和加载方式五花八门。
- Windows：
LoadLibrary("mylib.dll")，无需前缀，后缀固定.dll - macOS：
dlopen("libmylib.dylib")或dlopen("libmylib.framework/libmylib")，通常加lib前缀 - Linux：
dlopen("libmylib.so")，同样加lib前缀，有时还有版本号如libmylib.so.1.0.0
我最开始写跨平台加载逻辑时，直接写死在代码里。后来换了个SDK版本，库名加了个so后缀版本号，直接找不到。现在的习惯是做一层宏封装：
#ifdef _WIN32
#define SDK_LIB_NAME "sdk_core.dll"
#elif __APPLE__
#define SDK_LIB_NAME "libsdk_core.dylib"
#else
#define SDK_LIB_NAME "libsdk_core.so"
#endif
void* handle = dlopen(SDK_LIB_NAME, RTLD_LAZY);小技巧：macOS 里还有一种 .framework 包结构，本质上是个目录，里面包含动态库和头文件。如果你SDK厂商打包成framework，在CMake里用 find_library 配合 FRAMEWORK 属性最稳妥。
3.3 线程模型与同步原语的细微差别
Windows用 CreateThread 或 _beginthreadex，POSIX系用 pthread_create。C++11之后标准库统一了std::thread，但SDK底层可能还是原生API。
我这里重点说一个容易忽视的点：线程栈大小。Windows默认1MB，Linux默认8MB。我记得有个SDK在Windows上跑得好好的，移植到Linux后出现栈溢出，就是因为它内部开了一个超大的局部数组。解决方法是显式指定栈大小：
// Windows
DWORD stackSize = 4 * 1024 * 1024; // 4MB
CreateThread(NULL, stackSize, ThreadFunc, param, 0, NULL);
// Linux
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setstacksize(&attr, 4 * 1024 * 1024);
pthread_create(&thread, &attr, ThreadFunc, param);注意：Windows上 CreateThread 用多了会内存泄漏，建议用 _beginthreadex，它在C运行时里做了清理工作。Linux的 pthread 只要 pthread_join 或 pthread_detach 处理得当就没问题。
3.4 图形与窗口系统：API的并行宇宙
| 平台 | 原生窗口API | OpenGL支持 | Vulkan支持 | 常用SDK抽象层 |
|---|---|---|---|---|
| Windows | Win32 / UWP | 原生（WGL） | 原生 | GLFW / SDL / Qt |
| macOS | Cocoa (NSWindow) | 原生（CGL / NSOpenGLView） | 通过MoltenVK | GLFW / SDL / Qt |
| Linux | X11 / Wayland | 原生（GLX / EGL） | 原生 | GLFW / SDL / Qt |
如果你做的SDK要显示界面，千万别直接用Win32或NSWindow。除非你写底层引擎。我见过太多团队自己封装窗口，结果在Wayland上跑不起来。我个人习惯：优先用Qt，它对跨平台窗口、事件循环、HiDPI缩放都做好了抽象。如果SDK只需要轻量渲染，用GLFW或SDL也行。
有一个细节：macOS从10.14起删除了OpenGL传统模式，强制要求Core Profile。如果你的SDK用了旧版OpenGL API，在macOS上直接黑屏。必须检查SDK是否支持现代的着色器管线。
一句话总结：GUI类SDK尽量选带“跨平台”标签的封装库；如果需要原生窗口句柄（例如注入第三方渲染），必须写三个平台的条件编译。
3.5 系统特性差异速查表
这一节把平时容易漏掉的小差异列出来，避免你翻车。
- 注册表 vs plist vs 文本配置：Windows喜欢把SDK配置塞注册表（
HKEY_LOCAL_MACHINE），macOS用plist文件，Linux通常用/etc/xxx.conf。装载时记得分清路径。 - 换行符：Windows是
\r\n，macOS和Linux是\n。SDK如果生成日志或配置文件，一定要统一。 - 环境变量：Windows用
%PATH%，Linux/macOS用$PATH。SDK初始化时如果需要添加搜索路径，写getenv/GetEnvironmentVariable分开处理。 - UUID：Windows用
CoCreateGuid，Linux/macOS用/proc/sys/kernel/random/uuid或CFUUIDCreate。不过现在推荐统一用boost::uuids或C++17的std::mt19937自己生成。
3.6 本章核心：桌面SDK差异全景图
下面这张图把上面提到的几个核心维度串起来，方便你快速回顾。每个分支都代表一个你在集成时必须考虑的点。
嗯，基本就是这个骨架。以上五个大方向，每一个在真实集成中都是容易踩坑的地方。后面几章我们会深入到编译工具链、CMake配置、包管理器等更细的环节，但记住今天这张图，你就抓住了桌面SDK集成的七寸。