企业官网建设流程全解析

能把事情干完的 C++ exe 工程，到了需要复用的边界上，几乎都会遇到同一个很现实的问题：别人要的只是某个算法模块、某个解析逻辑、某个数据处理流程，根本不需要整个程序界面，也没兴趣把你的源码全部合到他的工程里。这时候把 exe 工程改造成动态库 dll，或者静态库 lib，就是最合理的工程化出路。这篇文章会完整记录我从一个能跑的 exe 控制台工程入手，一步步改成 dll / lib，并新建调用方项目成功跑通的全过程。文中涉及工程配置、符号导出、导入库生成、隐式链接、显式加载、运行时库一致性这几个核心环节，适合已经能写出简单 C++ 工程、但还没有系统碰过“库化改造”的开发者参考。

我分成三块来讲：第一块讲清楚动态库、静态库和可执行程序的差异，以及什么场景才值得动手；第二块是完整的 dll 改造和两种调用方式实操；第三块是 lib 静态库改造及常见报错速查。整个过程中我会把每一步操作背后的原因都说清楚，尽量不给“照着抄也报错”的机会。

1. 为什么非要把 EXE 改成 DLL / LIB

1.1 动态库和静态库到底差在哪里

首先把三个名词摆到一起看。exe 是最终可执行程序，双击就能跑，通常带 main 或 WinMain 入口；dll 是动态库，编译后是一个 PE 文件，里面装着可执行代码、数据、资源，但它不能自己独立运行，必须由某个 exe 或其他模块加载它；lib 则分成两种，一种是静态库，本质是多个 .obj 目标文件的打包集合，链接时会被整体复制进 exe；另一种是导入库，它本身基本没有代码，只记录 dll 里导出了哪些符号、符号在哪个函数里，供链接器在生成调用方 exe 时做“对表”用的。

我以表格形式把我们最关心的差异列出来：

看到这里你大概能明白，改造过程的关键不是“把工程后缀改一下”，而是想清楚你希望外界怎么使用这份代码。如果将来可能频繁更新功能，dll 优先；如果只是把代码稳定地分离出去、不打算单独更新某个模块，静态库 lib 更省事。

1.2 适合动手改造的几种场景

从我个人接触过的项目看，这类改造常出现在下面几种场景：

第一，一个大的 exe 里有一部分算法逻辑比较独立，比如图像处理、协议解析、数据校验，别的项目也要用同一段逻辑，又不想复制粘贴，因为复制粘贴会导致同一个 bug 修三遍。把独立模块抽出来做成 dll 或 lib，所有调用方共用同一份实现，是标准解法。

第二，项目想插件化，希望新增功能时不用重新编译整个主程序，只要放一个新的 dll 到目录里，主程序扫描目录动态加载即可。这是典型的动态库显式调用场景，背后靠的就是 LoadLibrary / GetProcAddress 这类运行时加载能力。

第三，写单元测试时不想把被测代码全编译进测试框架，而是把被测模块单独做成 lib 或者 dll，测试工程链接它，这样被测代码的编译粒度更清晰，换编译选项也方便。

第四，给非 C++ 语言调用。比如 C# 通过 P/Invoke 调用 C++ dll，Python 通过 ctypes 或 cffi 调用 C++ dll，都需要 dll 提供 C 语言风格导出接口。这类跨语言调用要求导出符号不做过多的 C++ 名字修饰，我们在后面讲导出方案时会反复强调这一点。

动手之前先确认自己手里有完整源码以及可用的编译环境。没有源码、只有 exe 的情况下做不了这种改造，因为库必须从源码重新编译产物。想直接从别人的 exe 中“抠”出代码，那是逆向工程的范畴，不在本文讨论范围内。

2. 动手前必须搞清楚的三个关键概念

2.1 编译期符号、导入库和运行时查找

很多刚开始接触库化改造的人会对“库文件里到底有没有代码”感到混乱。其实这里藏着两个完全不同的阶段：编译链接期和运行期。

在链接阶段，调用方 exe 如果需要调用 dll 里的函数，它的链接器必须提前知道这个函数叫什么名字、参数列表长什么样、去哪个库文件里找，所以你会看到投递 .dll 时通常要附带的导入库 .lib。这个 .lib 不是实现，而是“地址簿”，它记录了 dll 里导出的符号和重定位信息。调用方链接时拿着地址簿生成了一个桩，真正实现代码还在 dll 里，只有在程序启动加载 dll 后才会建立最终关联。

静态库 .lib 则完全不同，链接器会把静态库中需要的目标文件直接复制到最终 exe 里，所以拿到静态库编译出的 exe 不需要再额外携带那个 lib。理解这个区别后，你就不会在调用 dll 时奇怪“为什么还要链一个 lib”。

运行期加载存在两种方式，本文后面都会实操：

• 隐式链接：编译链接调用方时就指定导入库，程序启动时系统自动加载 dll。这是常规情况默认首选。
• 显式加载：调用方编译时不提供导入库，运行到某一行代码时才用 LoadLibrary 加载 dll，再用 GetProcAddress 拿函数地址。这种方式灵活，适合插件系统，但开发时要自己维护函数指针类型，比较麻烦。

2.2 工具准备和工程结构规划

实践中我用得最多的就是 Windows 平台下 VS 开发环境和 MSVC 编译器，这里先以 VS 工程为例解释。当然用 CMake 也可以改造成动态库工程，本质思路相同，只是配置方式从图形界面变成脚本，为了不把篇幅无限拉长，我会把重点放在 VS 工程上，后面也会简要补充 CMake 的等价配置。

开始之前需要准备好三样东西：

• 一份能正常编译成 exe 的 C++ 源码工程，这是改造的起点；
• 一个可用的 C++ 开发环境，版本不必很新，能编 32 位和 64 位 Release/Debug 即可；
• 一个用于验证调用的新工程，小的空控制台程序就行，后面所有调用演示都在它上面做。

规划结构时我建议不要直接把原有源码全部塞进库工程。除非你的工程天生就是那种“一个文件包含所有逻辑”的小玩具，否则更稳的做法是：把公共接口单独抽到一个头文件，比如 api.h，里面只放外部需要使用的函数声明或类声明；实现文件留在内部。这样改造之后的发布物就非常干净：库文件 + 头文件 + 对应的导入库/静态库。

2.3 工程的“配置类型”到底是什么

VS 工程里有一个很不起眼的设置项，叫“配置类型”。默认新建的应用程序项目里，这个值被设置为“应用程序(.exe)”，链接器输出的是一个带 exe 后缀的 PE 文件。我们要做的第一步就是把这个值改成“动态库(.dll)”或“静态库(.lib)”。

很多人会问：直接改这个下拉框就能生成 dll 吗？答案是可以生成，但能不能被正确调用还要看符号导出。原因很简单：exe 工程生成可执行文件时不需要输出对外接口清单；而 dll 必须明确告诉外面的世界“我这里有哪些函数是可以被调用的”。如果没有导出任何符号，生成的 dll 就是个大空壳，链接时你会得到一个:LNK4197: 未导出任何内容的警告，调用方无论如何也链接不进来。

所以配置类型只是第一步，真正决定能不能调用的是如何导出符号。下面进入核心实操部分。

3. 从 EXE 改造到 DLL 的完整实操

3.1 步骤一：修改工程配置，生成 dll

打开原本能编译通过的那个 exe 工程，找到工程属性页，确认当前活动配置是自己需要的平台，比如 Release x64。在左侧依次进入“配置属性” → “常规”，把“配置类型”从“应用程序(.exe)”改为“动态库(.dll)”。

改完配置后顺手做两件事，避免后面编译报不必要的错误：

1. 检查字符集设置。如果原工程用多字节字符集，调用方可能用 Unicode，两种情况下字符串处理方式不同，建议统一改成“使用 Unicode 字符集”，接口里字符串参数尽量使用宽字符类型，或者明确约定使用 UTF-8 字节流。

2. 检查运行库设置。进入“配置属性” → “C/C++” → “代码生成” → “运行库”，可以看到 /MT、/MTd、/MD、/MDd 四个选项。dll 工程推荐使用“多线程 DLL(/MD)”，这和后面调用方工程保持一致，否则容易出现“堆被另一头分配、另一头释放”的经典崩溃。静态库工程则要格外注意调用方也要选同样的运行库方式，这个我放到静态库一节详细说。

此时直接编译大概率能生成 dll 文件，同时你会在输出目录看到三个文件：xxx.dll、xxx.lib、xxx.exp。这个自动生成的 xxx.lib 就是导入库，xxx.exp 是导出文件，用于记录导出信息的中间产物，通常我们不需要对外发布它。

但注意，如果我们不改任何源码，这个 dll 通常是空的，断言方式是看编译日志里的警告。所以迈入下一步：让代码真正导出可用符号。

3.2 步骤二：导出函数和类的两种主流方式

在 Windows 上导出符号最直观的方式是使用__declspec(dllexport)。为了让同一个头文件既能被 dll 内部使用，又能被外部调用方使用，一般会配合__declspec(dllimport)写一个宏，模式如下：

// api.h #ifdef MYLIB_EXPORTS #define MYLIB_API __declspec(dllexport) #else #define MYLIB_API __declspec(dllimport) #endif MYLIB_API int Add(int a, int b); #ifdef __cplusplus extern "C" { #endif MYLIB_API int Multiply(int a, int b); #ifdef __cplusplus } #endif

这个模式理解起来不难：MYLIB_EXPORTS 是工程里定义的预处理器宏。在 dll 工程内部编译时，MYLIB_EXPORTS 存在，MYLIB_API 被展开为 dllexport，告诉编译器“这些函数是向外部公开的”；在调用方工程里，MYLIB_EXPORTS 不存在，MYLIB_API 变成 dllimport，告诉链接器“这些函数在外部 dll 里，先在导入库里对表”。

extern "C"的作用很多人第一次接触会忽略。C++ 编译器为了支持函数重载，会把函数名和参数类型揉成一个修饰名，比如 Add 可能变成?Add@@YAHHH@Z，V 到调用方这边，如果两边编译器版本或调用约定不一致，这个修饰名很难对得上。加上 extern "C" 后，函数采用 C 语言命名规则，导出名就是干净的 Add，调用方通过导出名查找也容易得多。跨语言调用、显式 LoadLibrary 时，强烈建议所有导出函数都用 extern "C" 包起来。

如果你的函数要导出的是整个类，就不能用 extern "C" 了，类成员函数的修饰名由编译器统一处理。只要调用方和 dll 用同一套编译器体系，通常没问题。类导出写法是：

class MYLIB_API MathHelper { public: int Add(int a, int b); int Subtract(int a, int b); };

写成这样，类的所有非私有成员函数会被默认导出。要注意的是，导出类会连带要求类的内部结构对外可见，一旦类内部增减成员变量，所有调用方都要重新编译，所以导出类通常适合内部使用，不适合跨度很大的跨语言场景。

第二种导出方式是用模块定义文件（.def）。如果你有一些历史原因不方便在代码里写导出宏，或者希望精确控制导出序号，可以新建一个文本文件，后缀改成 .def，然后在工程属性里把它加进链接器的“模块定义文件”选项，内容大致如下：

EXPORTS Add Multiply

采用 .def 文件后，是否加 extern "C" 就不那么关键了，因为 .def 明确列出了要导出的符号名。这种方式对大型存量代码改造更友好，不需要改头文件里的每个声明。缺点是 .def 文件要求开发者自己维护符号清单，漏一个符号就会导致调用方链接失败。

我个人的建议是：新项目优先用宏导出，因为声明和导出动作放在一起，天然同步；老项目或跨语言场景，如果名字修饰让你头疼，用 .def 文件直接钉死导出名会更省心。

3.3 步骤三：验证生成的 dll 确实导出了符号

编译通过后，在输出目录里找到 dll，先别急着调用，用一个命令行工具看一眼导出表。VS 环境自带的 dumpbin 可以做到：

dumpbin /exports xxx.dll

输出里会列出 dll 中所有导出符号。如果 Add 和 Multiply 以导出名形式出现在列表中，说明导出成功。用 .def 文件时，这里会看到 MANUAL 格式的干净名字；用默认 C++ 而非 extern "C" 时，会看到类似?Add@@YAHHH@Z的修饰名。看到修饰名不用慌，这说明编译器按 C++ 规则处理了，调用方如果也用 C++ 链接，理论上能找到，但显式调用时写函数指针就需要查修饰名，非常不直观，所以我还是建议大家能加 extern "C" 就加。

到这里，一个合格的 dll 发布物已经生成：xxx.dll、导入库 xxx.lib、公共头文件 api.h。

4. 调用 DLL 的第一种方式：隐式链接

4.1 什么是隐式链接

所谓隐式链接，就是在调用方工程编译阶段就告诉链接器“我要用某个 dll 的某个函数”，让系统在程序启动时自动加载 dll。调用方代码里不需要出现 LoadLibrary，只需要吃两个东西：函数的声明头文件，以及一个导入库 lib 文件。

为什么有了 dll 还要额外用 lib？因为链接器在生成 exe 时，需要知道函数地址在哪个模块、调用时怎么生成跳转指令。这个信息记录在导入库 lib 里。编译器从 lib 中提取必要信息，在 exe 的导入表里注册“这个进程需要 xxx.dll”，运行加载器看到导入表条目后自动加载 dll。所以隐式链接的本质是“编译期登记，启动期加载”。

4.2 最小调用 Demo 完整走一遍

新建一个空控制台工程，把 api.h 和 xxx.lib、xxx.dll 都拷贝到合适目录。在调用方工程属性里做两个配置：

1. “配置属性” → “链接器” → “常规” → “附加库目录”，添加 lib 所在文件夹；
2. “配置属性” → “链接器” → “输入” → “附加依赖项”，填写 xxx.lib。

如果不想改工程配置，也可以在源码里用#pragma comment(lib, "xxx.lib")手动指定，这个方法在临时验证时特别方便，不用反复打开属性页。

现在写调用代码：

// main.cpp #include <cstdio> #include <windows.h> #include "api.h" int main() { int sum = Add(3, 4); int product = Multiply(3, 4); printf("Add(3,4) = %d\n", sum); printf("Multiply(3,4) = %d\n", product); return 0; }

编译并运行。如果工程能正常生成 exe，运行后输出正确结果，说明隐式链接成功。整个过程里你不需要关心 Add 的实现代码，它住在 dll 里。

写这段代码时要注意 include 的顺序。Windows.h 和 api.h 一般没冲突，但在一些大项目里，建议先 include 自己的 api.h，再 include windows.h，否则可能出现个别宏重定义的干扰，虽然这个情况不常见。

4.3 隐式链接最容易踩的几个坑

隐式链接阶段最典型的错误是 LNK2019：无法解析的外部符号。这个错误几乎都是“链接器不知道该去哪找符号”导致的。常见原因有三个：

一是忘了挂导入库 lib，或附加依赖项写错名字。这时候链接器在命令行里找不到 xxx.lib，自然报无法解析。

二是导入库文件确实存在，但里面记录的符号名和调用方声明不一致。比如 dll 内部没有加 extern "C"，导出名是?Add@@YAHHH@Z，而调用方声明的是 Add，链接器找?Add@@YAHHH@Z时找不到对应的符号记录，就会报错。解决办法是统一符号处理方式，或改用 .def。

三是调用约定不一致。函数声明里如果默认是 cdecl，但 dll 导出时被某处定义为 stdcall，名字修饰规则就变了。查看函数互相匹配的方式：保持默认 cdecl，或者一方明确用__stdcall、另一方也用一致声明，不要一半默认一半显式指定。

除了链接错误，运行期也可能出现找不到 dll 的黑框弹窗。隐式链接的 dll 必须在程序启动时被加载，系统会按“exe 所在目录 → 系统目录 → PATH 环境变量目录”的顺序搜索。调试时如果 dll 没复制到 exe 所在目录，就一定会报由于找不到 xxx.dll，无法继续执行代码。一开始遇到这个问题别慌，把 dll 复制到 exe 同目录，或者把工程输出目录改成同一个即可。

5. 调用 DLL 的第二种方式：显式加载

5.1 什么时候需要显式加载

隐式链接虽然简单，但它有一个天然约束：程序只要一启动，dll 必须存在、必须能加载，否则整个进程直接失败。这对常驻进程、面板系统、插件系统来说太苛刻了。插件系统通常希望主程序先启动，然后扫描目录，发现有哪个插件 dll 就加载哪个；某个插件损坏了最多跳过，不该让主程序整体崩溃。这种场景就要用显式加载。

显式加载的好处很明显：

• 运行时按需加载，不用的时候不占内存；
• 可以灵活处理加载失败，不至于启动即崩溃；
• 便于实现插件“热插拔”概念（至少加载和释放层面是自主控制的）。

坏处是代码量增加，要手写函数指针类型，还要小心保持函数指针签名与 dll 导出完全一致。

5.2 LoadLibrary + GetProcAddress 的完整写法

还是刚才的 xxx.dll，假设里面有 Add 函数。显式加载的调用代码长这样：

#include <cstdio> #include <windows.h> typedef int (*AddFunc)(int, int); int main() { HMODULE hDll = LoadLibraryW(L"xxx.dll"); if (hDll == NULL) { printf("加载 dll 失败，错误码: %u\n", GetLastError()); return 1; } AddFunc add = (AddFunc)GetProcAddress(hDll, "Add"); if (add == NULL) { printf("找到 Add 函数失败\n"); FreeLibrary(hDll); return 1; } int sum = add(3, 4); printf("Add(3,4) = %d\n", sum); FreeLibrary(hDll); return 0; }

关键点有三个。

第一，LoadLibraryW 而不是 LoadLibrary。在 Unicode 工程里，宽字符版本是推荐写法，避免遇到中文路径时出现 ANSI 转换问题。调用之前确认 dll 路径正确；如果 dll 不在当前目录，最好传完整绝对路径，或者用相对路径仔细核对。

第二，函数指针类型必须和 dll 内部实现一致。如果 Add 原型是 int Add(int, int)，函数指针就定义成 int (*)(int, int)。如果约定不匹配，轻则拿回错误结果，重则栈不平衡导致崩溃。C++ 的调用约定默认 cdecl，这也是为什么我在导出代码里特意强调 extern "C" + 默认调用约定比较好。

第三，GetProcAddress 查找字符串是导出名，不是 C++ 修饰名。所以导出时需要注意命名一致性。若你用 .def 文件指定导出名，那显式加载时填的字符串也必须是 .def 里的那个名字。

5.3 显式加载的常见崩溃点和调试技巧

显式加载比隐式链接更容易出现“看似调用成功，结果数据全错”的诡异问题，根源大多是调用约定。比如 dll 导出时用了 __stdcall，却忘了在函数指针类型上标注 __stdcall，调用方按 cdecl 方式清理栈，系统内存布局就会错乱。所以一旦出现返回值莫名其妙，第一件事就是检查组里的调用约定标记是否一致。

另一个经常踩的坑是 dll 内部的依赖。假设你的 dll 依赖了另一个第三方 dll，磁盘上只有 xxx.dll 而没有它的依赖文件。隐式链接时启动就报缺 dll，显式加载时 LoadLibrary 也会失败，返回 NULL，但很多人会误以为是 xxx.dll 本身有问题。这时候可以用工具查看 xxx.dll 的导入表，或者试着把依赖库放到同一目录，再试一次 LoadLibrary。

调试建议：在 LoadLibrary 返回 NULL 后马上调用 GetLastError 看错误码，这能大幅缩短排查时间；在 GetProcAddress 返回 NULL 后检查导出名拼写以及导出类别，必要时再用 dumpbin 查看当前 dll 实际的导出名。我之前就遇到过把“Add”误写成分号后面带空格的情况，导出名没有空格，但 GetProcAddress 参数里多了空格，迟迟找不到函数。这种细节问题肉眼很难发现，用 dumpbin 对一遍就清楚了。

6. 再从 EXE 改造到静态库 LIB 并调用

6.1 动态库和静态库在实际工程里的定位差异

讲完 dll，再回来看静态库 lib。静态库不像 dll 那样有一个“加载时间”，它是在链接期被直接合并进调用方 exe 的。链接完成后的 exe 不再对 lib 有任何运行时依赖，这是它最大的优势：部署简单、没有路径问题、也不怕缺 dll。代价是发布体积变大、任何静态库内部改动都需要完整重链。

如果你的代码是稳定底层逻辑，比如公司内部一个公共数学库、公共加密库，合进 exe 没问题；但如果这个模块本身更新频率高，或者外部有多个团队需要独立升级它，静态库就不太合适，应该考虑 dll。

6.2 把 exe 改造成静态库的操作步骤

在原有 exe 工程里，再次打开工程属性，配置类型改成“静态库(.lib)”。这里有一项必须注意：链接器阶段不再需要“生成 DLL”相关的设置，同时代码里如果还写着__declspec(dllexport)，对应宏建议改成空定义，因为在生成静态库时 dllexport 没有意义，甚至会在个别编译器版本里引发告警。

项目如果原先有#ifdef MYLIB_EXPORTS那种宏，可以在静态库构建时不定义 MYLIB_EXPORTS，让 MYLIB_API 展开为空，这样头文件在外部调用方和静态库构建方看到的都是纯声明，不涉及导入导出指令。

改完后直接编译，输出目录只会得到一个 xxx.lib。这个 lib 是真正的静态库，里面包含了所有实现目标文件的字节码。可以再用工具查看里面的目标文件列表：

lib /list xxx.lib

看到列表里有若干 .obj 就证明这是静态库，而不是导入库。这个验证方法很实用，能帮你确认自己拿到的到底是哪种 lib。

6.3 静态库调用 Demo

调用方工程里，只需要以下配置：附加库目录指向 lib 所在目录，附加依赖项填 xxx.lib。源码里和之前类似：

#include <cstdio> #include "api.h" int main() { int sum = Add(5, 6); int diff = Subtract(9, 4); printf("Add(5,6) = %d\n", sum); printf("Subtract(9,4) = %d\n", diff); return 0; }

编译运行，一切正常的话，exe 会完全包含静态库里的实现，之后你再删除 xxx.lib，这个 exe 照样可以运行。这一点和 dll 调用形成鲜明对比，建议读者亲手试一下，体会两类库的部署区别。

6.4 静态库调用最容易踩的运行库一致性大坑

静态库调用有一个比 dll 更敏感的问题：运行库一致性。具体来说，静态库编译时用的运行库选项，必须和调用方 exe 一致。如果库用 /MT（多线程静态链接）编译，调用方却用 /MD（多线程 DLL）编译，链接阶段大概率会报错，提示你在一些 runtime 函数上有冲突定义；就算侥幸链接通过，运行时也可能因为两边各持有一份堆管理数据，出现释放问题。

这一点和 dll 不同。dll 内部即使使用静态运行库，由于它的内存边界相对独立，一般不会直接引发调用方的崩溃；但静态库的代码直接合并进调用方进程，两边运行库不一致就是实打实的隐患。

所以关于静态库，记住一条铁律：库方和调用方的运行库选项必须统一，Debug 版配 Debug，Release 版配 Release，不要把 Release 版静态库拿给 Debug 调用方用，也不要反着来。为保险起见，我一般会在调用方工程属性里手动把运行库选项和静态库工程对齐，而不是依赖默认值。

7. 常见报错与避坑实录

下面把我在实际操作里最常见到的错误按表格整理了一遍，每条都是曾经真正让我卡壳过的例子：

除了报错，还有一种比报错更隐蔽的问题：符号可见性。Windows 下默认只要用 dllexport 就能导出；但在 Linux/Mac 上用 GCC 编译动态库会有隐藏符号默认策略。如果你将来要跨平台，建议从一开始就养成“显式导出”的习惯，用统一的 API 宏，而不是保留默认导出全部符号的老写法。

另外，调试期间如果用 Release 版 dll 去调试 Debug 版调用方，虽然常见运行库不匹配不一定会立即崩溃，但排查问题时非常难受。尽量让 Debug 对应 Debug，Release 对应 Release，开发周期里把两套配置的构建产物分开，能省很多精神消耗。

8. 一些实操心得的最后总结

最后再分享几条我自己在反复折腾 dll / lib 时沉淀下来的经验。

第一，所有对外 API 的头文件，建议只放声明，不放实现。有人为了图方便，直接把函数体也写在头文件里，结果导入库和静态库都用不上，各调用方反而各自编译出一份实现，彻底背离了库化复用的目的。保持声明与实现分离，既能让发布物干净，也能规避一些奇怪的链接冲突。

第二，启动阶段就把 dll 加载策略想清楚。如果调用方工程是长期维护的主程序，我一般优先考虑显式加载，并且在启动时对每个依赖模块做加载检测、打印友好的错误提示；如果是快速验证的小工具，才用隐式链接省事。显式加载虽然代码多一些，但换来的是故障隔离能力，长期维护时很值得。

第三，务必在 CI 或构建脚本里把“拷贝 dll 到输出目录”这一步固化下来。很多调用方工程在本地编译成功后，换台机器就报缺 dll，就是因为没有统一发布流程。在 VS 里可以写后期生成事件命令，或干脆用 CMake 的 POST_BUILD 命令复制文件，这一步投入很小，收益很大。

我最早改造 lib 工程时，因为运行库配置没对齐，折腾了整整一个下午，最后把 /MT 改成 /MD 才解决问题。如果你读完这篇后去动手，一定要记得先检查配置类型、再检查导出符号、最后检查运行库一致性。只要按这个顺序做，大部分坑其实都能避开。