📚 课程目录第3章开发环境准备

3. 开发环境准备：操作系统、编译器与依赖库管理

开发环境这东西，说白了就是你写代码的“工位”。工位不舒服，活儿肯定干不好。我这几年被各种环境坑过，最惨的一次是花了整整两天，就为了搞定一个 vcpkg 的端口配置。

今天就聊聊我怎么搭环境的。先说好，没有的标准，只有适合你的方案。

3.1 操作系统版本要求

每个SDK都有最低操作系统版本要求。别指望Windows 7能跑最新的DX12 SDK——不可能的。

SDK类型	Windows	macOS	Linux
游戏SDK（Steam/Epic）	Win10 1809+	10.15+	Ubuntu 20.04+
音视频SDK（WebRTC）	Win10 1903+	11.0+	Glibc 2.28+
图形SDK（Vulkan）	Win7 SP1+	10.14+	Kernel 4.15+
AI/ML SDK（ONNX Runtime）	Win10 1809+	11.0+	Ubuntu 18.04+

我来说说我的实战建议。做SDK兼容测试的时候，不能只用最新的操作系统。Windows 11很爽，但很多企业客户还在Win10 21H2上。我每次都会准备三台虚拟机：LTSB、最新版、还有预览版。

我的小技巧： 维护一个“操作系统兼容性矩阵”。每测一个新SDK版本，就直接在上面打勾。你会发现，有些SDK在macOS 11.3上会崩溃，但10.15上稳如狗。这种信息，文档里不会写的。

3.2 编译器与IDE选择

接着说编译器。我知道有人爱VS，有人爱CLion，有人爱VS Code。都可以，但得知道各自的坑。

3.2.1 Windows：MSVC 是主流，但别忽略 Clang

Windows下，90%的SDK都是用MSVC编译的。具体怎么选？

Visual Studio 2022 (v143 工具集)：现在的主力。C++20支持完善，调试器强大。
Visual Studio 2019 (v142)：很多老旧SDK的默认目标。我有一次要集成一个2018年的SDK，用2022编译直接报了一堆_MSC_VER宏相关的错误。
LLVM/Clang for Windows：如果你要跨平台，真心建议也测一版Clang编译。很多语法问题会在Clang下暴露。

注意： 别用MinGW！我见过太多人在MinGW上折腾半天，结果SDK依赖了COM组件或Windows API的特定行为。MinGW模拟不了那些。相信我，坑太大。

3.2.2 macOS：Xcode 版本必须对齐

macOS的编译器生态比较封闭。Apple Clang和系统绑定很紧。

Xcode 14.x 对应 macOS Ventura，Clang版本是14.x。
Xcode 15.x 对应 macOS Sonoma，Clang版本是15.x。
重点：SDK的framework头文件有时依赖特定版本的__has_feature特性。

我记得有一次，一个SDK要求在macOS 11上编译，但Clang必须≥13。结果Xcode 12（Clang 12）编译不过，升级Xcode后又把最低系统版本提上去了。来回折腾了一整天。

3.2.3 Linux：GCC 版本与 ABI 兼容性

Linux世界，GCC版本决定了ABI稳定性。GCC 5.1之后引入了新的std::string ABI，这个问题至今还在坑人。

# 查看当前GCC版本和ABI
gcc --version
# 如果需要特定版本的libstdc++，可以用CMake指定
cmake -DCMAKE_C_COMPILER=gcc-9 -DCMAKE_CXX_COMPILER=g++-9 ..

3.3 依赖库管理：vcpkg、Conan 与手艺活儿

这才是今天的重头戏。依赖管理，说白了就是“你的项目需要一堆第三方库，怎么优雅地搞进来”。我见过太多人直接把libcurl.dll扔进工程目录，然后版本一乱就炸了。

3.3.1 vcpkg：Windows 上的“懒人福音”

我个人偏好 vcpkg。它最大的好处就是跟Visual Studio深度集成。你说vcpkg install curl，它自动下载、编译，然后VS直接认。

# 克隆vcpkg
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
.\bootstrap-vcpkg.bat

# 安装依赖（集成到全局）
.\vcpkg install curl:x86-windows curl:x64-windows

# 或者在CMake中集成
cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/vcpkg/scripts/buildsystems/vcpkg.cmake ..

避坑指南——我曾经遇到过vcpkg端口包版本过旧的问题。比如我需要OpenSSL 3.2，但vcpkg默认还是3.1。解决方案：

使用vcpkg install --overlay-ports自定义端口。
或者强制指定版本：vcpkg install openssl:x64-windows@3.2.0。

3.3.2 Conan：跨平台玩家的“瑞士军刀”

如果项目要在Windows、Linux、macOS三个平台下统一依赖，我建议上Conan。它比vcpkg更灵活，profile机制非常强大。

# 安装Conan
pip install conan

# 创建默认profile
conan profile detect

# 编辑profile（例如指定为msvc 17）
[settings]
os=Windows
compiler=msvc
compiler.version=193

# 安装依赖并生成CMake
conan install . -pr=msvc193 -if=build

Conan有个特别厉害的地方——包版本锁定。你可以生成一个conan.lock，保证每个人编译的库版本完全一样，不会出现“我机器上能跑，你机器上不行”的尴尬。

  我的推荐场景：

  - 团队内部统一依赖：用Conan，配合私有仓库Artifactory。

  - 快速原型验证：用vcpkg，省心。

  - 跨平台开源项目：用Conan，因为可以一键conan build。

3.4 避坑指南：我亲自踩过的三个大坑

这些都不是理论，全是血泪教训。

坑一：动态库与静态库混用
我曾经把一个用/MT编译的静态库，跟一个/MD编译的exe链接。结果运行时崩溃，排查了两天。SDK配套的运行时必须统一。
坑二：PATH与LD_LIBRARY_PATH污染
系统里装了多个版本的OpenSSL，结果SDK加载错了。我建议用rpath或@loader_path把库路径锁定在SDK目录内。
坑三：Windows上的Unicode编码
MSVC默认用本地编码（GBK），而SDK文档要求UTF-8。不统一的话，文件路径带中文直接挂掉。解决方案是在CMakeLists.txt里加target_compile_options强制UTF-8。

# 在CMake中强制MSVC使用UTF-8
if(MSVC)
  target_compile_options(target PRIVATE /utf-8)
endif()

3.5 验证环境是否准备就绪

环境搭完，别急着写代码。先跑一遍SDK自带的Sample。我个人的流程是这样的：

编译SDK提供的Hello World示例——确保能编译通过。
运行示例——确保运行时能加载所有DLL/so/dylib。
检查版本兼容性——在3个不同OS版本下测试同样的二进制。
打印关键宏——在代码中输出__cplusplus和_MSC_VER，确认是对的值。