Windows 平台集成要点
做桌面端 SDK 集成，Windows 平台始终绕不开。我刚开始接触这活儿时，觉得不就是配个 Visual Studio 项目、选个 SDK 版本、决定用 DLL 还是静态库吗？后来被坑了几回才明白，每个细节都能让你排查一整天。这一节我把自己的经验梳理出来，你跟着走，能少踩很多坑。
Visual Studio 配置要点
拿到一个 SDK，第一件事就是打开项目属性。别看界面密密麻麻，核心就几项。我个人习惯先确认三件事：平台、字符集、CRT 链接方式。
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| 平台（x86 / x64 / ARM） | 与 SDK 提供的库匹配 | 32 位 SDK 不能用在 64 位项目里，反之亦然。我见过有人直接把 x64 库丢进 x86 项目，链接报错找半天 |
| 字符集 | 使用 Unicode 字符集 | 现在 Windows API 基本都是 Unicode 版，用多字节字符集容易遇到函数签名不匹配 |
| CRT 链接方式 | 视 SDK 要求而定 | 动态链接（/MD、/MDd）或静态链接（/MT、/MTd），错了就会 CRT 冲突 |
| 预处理器定义 | 添加 _CRT_SECURE_NO_WARNINGS 等 | 很多旧版 SDK 用到了被标记为 deprecated 的 CRT 函数，不加这个编译不过 |
我的习惯：在解决方案里单独建一个“SDK 配置”属性表（.props），把所有 SDK 相关的宏、库目录、附加依赖项集中放在里面。项目引用了哪个 SDK，就加载对应的 props。这样换 SDK 版本或切换配置时，改一个地方就行。
还有附加包含目录、附加库目录，一定要用环境变量或属性宏，别写路径。我在项目中遇到过，同事把路径写死到 C 盘，结果别人拉下来代码编译就崩。
Windows SDK 版本兼容
你开发的 SDK 到底要支持哪些 Windows 版本？这个问题直接影响你该用哪个 Windows SDK。举个例子：你用 Windows 11 SDK 编译了一个 DLL，里面调用了 GetTickCount64，这个函数在 Vista 以后才支持。如果你的客户还在用 Win7，那直接崩。
Windows SDK 版本靠两个宏控制：
_WIN32_WINNT– 指定目标 Windows 版本WINVER– 应用程序的 Windows 版本，一般和_WIN32_WINNT保持一致
常见取值：
| 宏值 | 对应 Windows 版本 |
|---|---|
| 0x0600 | Windows Vista |
| 0x0601 | Windows 7 |
| 0x0A00 | Windows 10 |
| 0x0B00 | Windows 11 |
怎么设？在预处理器定义里加一行：_WIN32_WINNT=0x0601。这样编译器就知道，你只调 Windows 7 及以后版本的 API。如果你误用了需要 Win10 的 API，编译器会报错，而不是等到运行时崩溃。
注意：别把 SDK 版本设得太高。我曾经接手过一个项目，为了用上某个新 API 把 _WIN32_WINNT 改成 0x0A00，结果客户在 Win7 上直接蓝屏。最终解决方案是动态加载 API，运行时判断系统版本，再决定调用哪个函数。
DLL 与静态库链接方式
这是 Windows 集成最纠结的地方。我把它拆成三个问题：
- 你的 SDK 是作为 DLL 还是静态库提供？
- 你的应用程序用什么方式链接？
- CRT 怎么配才不会冲突？
首先，SDK 是 DLL，你得带上 .lib（导入库）和 .dll。.lib 是给链接器用的，.dll 是给运行时用的。这里有个误区：有人以为只拷一个 .dll 就能工作——不行，链接阶段需要 .lib。我在项目中遇到过，测试人员只拷贝了 .dll，编译报“无法解析的外部符号”。
其次，静态库（.lib）直接嵌进你的 exe 里。好处是部署简单，一个 exe 搞定；坏处是多个模块如果都用了同一个静态库，会导致代码重复，还可能引发全局变量多实例问题。
| 链接方式 | 优点 | 缺点 |
|---|---|---|
| 动态链接（DLL） | 节省内存，可独立更新 SDK | 部署时需要带 DLL，容易 DLL Hell |
| 静态链接（LIB） | 无外部依赖，部署简单 | 二进制体积大，无法热更新 |
最后——也是坑最多的——CRT 链接方式必须一致。你的 SDK 用 /MD（动态 CRT），你的应用程序也必须用 /MD，否则两个模块各自有各自的 CRT，内存申请和释放跨越模块边界就会崩溃。我见过一个典型案例：SDK 用 /MT 编译，生成一个 std::string 对象返回给主程序（主程序用 /MD），主程序析构这个 string 时直接堆损坏。那次查了整整两天。
铁律：SDK 和你应用的 CRT 链接方式 必须完全一致。如果不一致，要么全部 /MD，要么全部 /MT。别幻想混着用能正常。
还有一个细节：如果 SDK 提供的是 DLL，它的导出函数签名里如果包含 CRT 类型（比如 std::string、FILE*），那 CRT 链接方式也必须对齐。最好的做法是让 SDK 只对外暴露纯 C 接口，或者用 COM 风格的接口，避免 CRT 类型暴露出去。
这张图从左到右梳理了三个环节的决策链：先定 VS 配置，再定 SDK 版本，最后根据场景选择链接方式。三个环节互相影响——比如你选了 /MT 静态 CRT，那就不能指望 SDK 是 /MD 动态 CRT 的 DLL，必须统一。
嗯，最后再加一句：如果你的 SDK 同时提供 DLL 和静态库两套版本，我建议优先测试 DLL 方案，因为它可以独立更新，而且出问题时容易排查——换个 DLL 就知道是不是 SDK 的问题。静态库一旦合进 exe，出了问题你得重新编译整个应用。