企业官网建设流程全解析

简介：这是一套面向Windows 64位平台的OpenSSL开发组件包，集中提供C语言开发SSL/TLS与加密功能所需的头文件、动态链接库和静态库，适合在Visual Studio或MinGW工程中直接引用OpenSSL的开发者，也适合需要快速搭建安全通信环境的初中级C/C++程序员。压缩包约22.58MB，共778个文件，除了SSL与EVP等头文件、对应的静态库和动态库之外，还包含大量PEM证书、CNF配置模板、密钥文件、编译好的工具程序以及证书请求样例，可同时满足代码编译、证书生成、配置调整和运行调试等需求。目前已有507人学习下载，可作为Windows下快速启用OpenSSL的常用素材。通过这套组件，能省去手工编译64位OpenSSL的繁琐过程，减少环境配置与链接报错；附带的配置文件、测试证书、密钥与工具程序令工程对接更直接，能让开发者更专注于SSL/TLS调用与加解密逻辑本身，适合需要快速集成安全通信能力的C/C++项目参考使用。

1. OpenSSL 在 64 位系统下的 lib/dll 与头文件：为什么你拷走的三个文件总是差一个

很多人在 Windows 64 位环境下用 OpenSSL，卡住的第一关不是算法，而是“文件凑不齐”。从官网下载预编译包，解压出来有 include、lib、bin 三个目录，bin 里的 dll 拷到系统目录了，头文件也放进工程了，一编链接却报“无法解析的外部符号”。回头一看，lib 目录里躺着的是 libssl.lib 和 libcrypto.lib，但链接器根本不认。真正的原因很简单：OpenSSL 在 64 位系统下生成的导入库和动态库，命名规则和 32 位时代完全不同，而且静态库、动态库、导入库必须和头文件的版本严格对应，混一套就翻车。这篇笔记就讲清楚 lib/dll/头文件三者之间的依赖关系，再给出从零编译到集成进你工程的完整落地路径，顺带把我踩过的坑都标出来。

2. 先弄懂 OpenSSL 在 Windows 下的产物布局：lib、dll、头文件各自负责什么

2.1 为什么 64 位系统的 OpenSSL 会把库拆成 libcrypto 和 libssl 两个部分

OpenSSL 的 Windows 构建产物核心是两个库：libcrypto 和 libssl。前者是底层算法库，包含 AES、RSA、SHA 等全部对称和非对称算法实现；后者是 SSL/TLS 协议层，依赖前者。你在自己的程序里调 SSL_CTX_new 这类函数，链接的是 libssl；调 EVP_aes_256_cbc 或 RSA_generate_key 这类函数，链接的是 libcrypto。即使你只用到其中一个，两个库的文件也要同时就位，因为 libssl 的导入表里硬性依赖 libcrypto 的导出符号。

64 位系统下，预编译包的 include 目录里是头文件，按 openssl 子目录组织；lib 目录里是后缀为 .lib 的导入库或静态库；bin 目录里是运行时需要的实际 dll。关键坑在于：当构建配置选择动态库方式时，lib 目录里的 .lib 文件不是完整的代码，只是“导入库”，它只包含跳转桩和符号表，真正的代码在 bin 目录的同名 dll 里。很多人把 lib 文件当成静态库直接链接，运行时提示“找不到 libcrypto-3-x64.dll”，就是没搞清这一层。

2.2 预编译包里 lib 下的命名规则：静态库、动态库导入库怎么区分

64 位系统的 OpenSSL 预编译包，bin 目录下的 dll 命名通常类似 libcrypto-3-x64.dll 和 libssl-3-x64.dll。注意这里的 “3” 是 OpenSSL 3.x 主版本号，x64 表示 64 位。而 lib 目录下会出现两套命名：一套是 libcrypto.lib 和 libssl.lib，另一套是 libcrypto_static.lib 和 libssl_static.lib。

前者对应动态库的导入库，链接时配合 bin 里的 dll 使用；后者是真正把代码编进你的 exe 的静态库。如果你用的是 Visual Studio 的 dumpbin /headers 查看 libcrypto.lib，能看到它实际上是个“胶水文件”，里面每条记录都指向 dll 的导出函数。确认一个 .lib 到底是导入库还是静态库，最快的方式是看文件大小：导入库通常只有几百 KB，静态库动辄几十 MB。64 位系统上尤其要注意，绝不能把 32 位的 lib 和 64 位的 dll 混用，否则链接器会报 LNK1112——这是我在帮同事排查时见过频率最高的错误之一。

2.3 三件套版本匹配自查：用 PowerShell 快速核对当前环境的 lib/dll/头文件一致性

拿到一套 OpenSSL 产物后，我建议先做一次“三件套体检”。创建一个工作目录，把 include、lib、bin 三个文件夹都放进去，然后写一个简单的 PowerShell 脚本来核对版本。常见做法是：用 openssl version 从 dll 所在目录直接执行，获取运行库版本；再在头文件 opensslv.h 里读 OPENSSL_VERSION_TEXT 宏；最后对比两者主版本号是否一致。如果 dll 是 3.0.x，而头文件是 1.1.1，你的程序编出来就算能编过，运行也大概率崩在握手阶段。

# 三件套体检：检查 OpenSSL 头文件版本与 dll 版本是否一致 $includePath = "C:\openssl\include" # 头文件目录 $binPath = "C:\openssl\bin" # dll 目录 # 从头文件读取版本宏 $verHeader = Get-Content "$includePath\openssl\opensslv.h" | Select-String "OPENSSL_VERSION_TEXT" Write-Host "头文件版本: $($verHeader.Line -replace '.*"([^"]+)".*','$1')" # 从 dll 版本信息读取文件版本 $dll = Get-Item "$binPath\libcrypto-3-x64.dll" $fileVersion = $dll.VersionInfo.FileVersion Write-Host "dll 文件版本: $fileVersion" # 两者不一致时给出警告 if ($dll.VersionInfo.ProductVersion -and $verHeader.Line -notmatch $dll.VersionInfo.ProductVersion.Split('.')[0..1] -join '.') { Write-Host "警告: 头文件与 dll 版本不一致，建议重新下载匹配的预编译包" -ForegroundColor Yellow }

这段脚本的原理很简单：opensslv.h 里的版本宏是源码编译时固定下来的，dll 的文件版本是链接器写进去的。只要两个来源的大版本号对不上，就说明你手里的文件根本不是同一次构建出来的。参数方面，如果你用的是 1.1.1 版，dll 文件名会是 libcrypto-1_1-x64.dll，脚本里对应的文件名也要改。更稳妥的方式是把 bin 目录加到 PATH，然后直接跑 openssl version -a，输出里能看到 OPENSSLDIR 和编译参数，那个信息比文件版本属性更可靠。

3. 在 64 位 Windows 上自己编译 OpenSSL：从 Perl 环境到生成 lib/dll/头文件的最小命令集

3.1 为什么推荐自己编译而不是直接下载预编译包

预编译包虽然省事，但有几个现实问题：一是官方提供的 Windows 预编译二进制更新节奏比源码慢，遇到安全公告必须等；二是预编译包默认的编译选项是通用配置，不包含你需要的特定功能，比如某些国家算法套件或定制证书存储路径；三是最关键的一点——如果你要在自己的程序里静态链接 OpenSSL，预编译包通常不提供静态库，或者提供的静态库和你用的 CRT 运行时（/MD 还是 /MT）不匹配。静态链接时 CRT 不匹配会在运行时出现内存分配崩溃，这种问题极难排查。

自己编译还能拿到完整的符号文件（.pdb），出问题可以用 WinDbg 直接看崩溃栈，这在生产环境排障时就是后悔药级别的存在。我一般会在 Windows 10/11 64 位系统上采用以下这套环境：Visual Studio 2022 的“适用于 VS 的 C++ 生成工具”装好，Perl 用 Strawberry Perl 64 位版本，NASM 装 64 位版并加入 PATH。OpenSSL 2.x 及以后的构建系统基于 Perl 脚本，不再提供 .sln 工程文件。如果你还在用 1.0.2 老版本的那套 VC-WIN64A 命令，现在就要切换到新的 Configure + nmake 流程。

3.2 完整编译步骤：解压、配置、nmake 全流程，附带 OpenSSL 3.x 的 64 位构建参数说明

第一步，从 openssl 官网的 source 目录下载对应版本的源码压缩包，解压到纯英文路径。目录路径里绝对不能有中文或空格，Perl 的 Configure 脚本对路径里的空格处理有缺陷，这个细节能省下大量排查时间。第二步，打开“x64 Native Tools Command Prompt for VS 2022”，进入源码目录，依次执行以下命令。

:: 进入源码目录，请改成你自己的实际路径 cd C:\work\openssl-3.2.0 :: 配置 64 位动态库构建，安装到 C:\openssl\release perl Configure VC-WIN64A --prefix=C:\openssl\release --openssldir=C:\openssl\ssl :: 生成 Makefile 并编译 nmake :: 编译测试，验证生成的 lib 和 dll 可用 nmake test :: 把头文件、lib、dll 安装到指定目录 nmake install

Configure 命令里的 VC-WIN64A 是 OpenSSL 在 64 位 Windows 下使用 MSVC 编译器的标准目标平台标识，它决定了汇编代码用 NASM 编译、C 代码按 64 位 ABI 生成。如果不加这个标识，Configure 默认按本机平台猜测，在某些环境会猜成 32 位。--prefix 是安装目录，--openssldir 是运行时默认的证书和配置文件目录。nmake test 这步一定要跑，OpenSSL 的测试套件会验证生成的 dll 能被正确加载、算法自检通过，跳过这步直接集成到自己的工程，出了问题很难分清是库的问题还是你代码的问题。

3.3 编译产物定位：nmake install 之后你的 lib、dll、头文件分别去了哪里

nmake install 执行完后，C:\openssl\release 下会出现三个子目录：include、lib、bin。include\openssl 里是头文件，lib 里是导入库和静态库，bin 里是运行时 dll。但注意，如果你只想把 OpenSSL 用在自己的项目里、不做系统级安装，不需要 nmake install，编译完直接在源码目录的根目录下就能找到 libcrypto-3-x64.dll 和 libssl-3-x64.dll，lib 目录里也有现成的 .lib 文件。用源码目录里的产物，配合 include 目录，足以完成日常开发。

我个人习惯是把这三个目录原样复制到项目里的 third_party\openssl 下，而不是直接放进 C:\Windows\System32。按照自己的经验，很多人喜欢把 dll 复制进 System32 图省事，但这样会导致 PATH 里的 OpenSSL 和你项目里的 OpenSSL 版本相互打架，运行时加载到哪个版本全看运气，这就是经典的“玄学崩溃”。把 OpenSSL 作为项目私有依赖放在项目目录下，bin 目录加入项目的工作目录或用绝对路径加载，环境隔离性会好很多。

4. 把 lib/dll/头文件集成进你的工程：Visual Studio 与 MinGW 两条路的配置参数

4.1 Visual Studio C/C++ 项目引入 OpenSSL 的包含目录、库目录和附加依赖项设置

拿到三件套之后，第一步是在 VS 工程属性里配置附加包含目录，指向 include 目录。第二步是配置库目录，指向 lib 目录。第三步是在链接器的“输入 → 附加依赖项”里填上 libssl.lib 和 libcrypto.lib。每一步都在 64 位配置下做，注意看上方的解决方案平台是否选的是 x64，Win32 平台会直接忽略你配置的 64 位 lib，报 LNK2019 链接错误。

// 在你的 C/C++ 源文件顶部，按顺序包含头文件，顺序不能乱 #include <openssl/ssl.h> #include <openssl/err.h> // 只需要调用算法则包含 evp.h // #include <openssl/evp.h> #pragma comment(lib, "libssl.lib") #pragma comment(lib, "libcrypto.lib") // 如果你的 lib 是静态库版本，把上面两行改成下面这样 // #pragma comment(lib, "libssl_static.lib") // #pragma comment(lib, "libcrypto_static.lib")

头文件包含顺序是有讲究的。ssl.h 内部会引用 evp.h 和 x509.h 等，虽然它自身会通过相对路径拉取依赖，但如果你在包含 ssl.h 之前先包含了其他版本的 openssl 头文件，就会出现宏定义冲突。比如你在代码里先 include 了一个老项目的 openssl/rsa.h，再 include openssl/ssl.h，两个版本的 OPENSSL_VERSION_NUMBER 宏不同，编译器会报一堆“重定义”错误。这段代码建议放在一个单独的 openssl_inc.h 里，所有需要 OpenSSL 的 .c 文件统一包含它，维护起来方便。

认清一个常见误区：用动态库方式时，libssl.lib 只在编译链接阶段起作用，程序运行时用的是 bin 目录里的 libssl-3-x64.dll。如果你的程序部署到一台没装 Visual Studio 运行库的机器，且 dll 没有放在 exe 所在目录，系统会弹“找不到 libssl-3-x64.dll”，这不是 OpenSSL 的问题，是库搜索路径的问题。解决办法是：发布时把三个 dll 跟 exe 放同一目录，或把 bin 目录加入系统 PATH。推荐前者，后者容易被其他软件改了 PATH 导致加载错版本。

4.2 动态链接与静态链接的取舍：CRT 运行时一致性是 64 位系统上最容易忽略的坑

动态链接 OpenSSL（使用 libcrypto.lib 导入库）的优点是 exe 体积小、升级 OpenSSL 不用重新编译你的程序、多进程间共享一份代码。缺点是目标机器上必须存在对应版本的 dll，部署动作多一步。静态链接（使用 libcrypto_static.lib）的优点是部署简单、一台机器上多套 OpenSSL 共存互不干扰。但静态链接的坑在于：必须保证你编译 OpenSSL 时用的 CRT 选项和你编译自己工程时的一致。

具体来说，Visual Studio 的 CRT 分为多线程调试、多线程 DLL、多线程静态等几种模式。OpenSSL 源码编译时，如果你用 nmake 默认配置，它默认使用动态 CRT（/MD）。而你自己的工程如果设置成静态 CRT（/MT），链接 OpenSSL 静态库时会报“LIBCMT.lib 和 msvcrt.lib 冲突”或类似错误。即使通过某种方式强编过去，程序运行时也可能在内部分配和释放内存时崩溃。我见过最隐蔽的一次是：两个模块，一个用静态 OpenSSL 和一个用动态 OpenSSL 的另一个库，在同一个进程里同时运行，SSL 握手随机失败。最后用 dumpbin 逐个检查依赖才定位到 CRT 冲突。结论：64 位系统下，要么全链路动态 CRT，要么全链路静态 CRT，混搭就是在给自己埋雷。

4.3 MinGW-w64 环境下使用 OpenSSL：与 MSVC 导出符号的差异和编译选项

如果你用的是 MinGW-w64 而不是 MSVC，情况稍有不同。MinGW 的链接器可以直连 .a 后缀的静态库或导入库，但 OpenSSL 官方源码不直接提供 MinGW 预编译产物，你需要用 msys2 的 pacman 包管理器安装。msys2 64 位环境下，OpenSSL 会安装在 /mingw64/lib 和 /mingw64/include，库文件是 libcrypto.dll.a 和 libssl.dll.a，这个 .dll.a 就是给 MinGW 用的导入库，运行时对应 /mingw64/bin 下的 libcrypto-3-x64.dll。

# MinGW-w64 环境下编译时，用 -I 指定头文件，-L 指定库目录，-l 指定库名 gcc -I/mingw64/include -L/mingw64/lib client.c -lssl -lcrypto -o client.exe # 如果链接报找不到 -lssl，检查库文件是否完整 ls /mingw64/lib/libssl.dll.a

在 MinGW 下链接时，库文件名的映射规则是：-lssl 会找 libssl.dll.a 或 libssl.a。另一个坑是：MSVC 编译的 OpenSSL 预编译包里的 .lib 文件，MinGW 的链接器不认。把两者混用时，ld 会报“file format not recognized”。反过来，用 MSVC 也链接不了 MinGW 生成的 .dll.a。在 Windows 64 位系统上，MSVC 和 MinGW 这两条生态链的库文件格式互不兼容，这是一个必须确认清楚的边界。另外，MinGW 版本与 Windows SDK 的版本要匹配，我用的是 UCRT64 版本的 msys2 环境，这是目前官方推荐的 64 位运行时。

5. 避坑手册：64 位 OpenSSL 开发中 lib/dll/头文件相关的常见问题和排查路径

5.1 现象：编译链接时报 LNK1112，提示“模块计算机类型 x86 与目标计算机类型 x64 冲突”

原因：你的 lib 目录里混入了 32 位版本的 OpenSSL 库文件，或者 VS 工程当前处于 Win32 平台配置。这是 64 位系统下最常见的错误，没有之一。解决：用 dumpbin /headers 查看该 lib 文件的机器类型。

:: 在 VS 的 x64 Native Tools 命令行里执行 dumpbin /headers C:\openssl\lib\libssl.lib :: 输出里看 FILE HEADER VALUES 一节的 machine 字段 :: 如果是 x64 表示是 64 位库，如果是 x86 则要从 64 位预编译包重新提取

我在实际排查中遇到过一种更隐蔽的情况：工程里的 lib 目录配置正确，但工程里某个第三方静态库是 32 位编译的，它反过头来引用了 32 位 OpenSSL。这时即使 OpenSSL 的 lib 选对了，LNK1112 照样触发。解决方法是把所有依赖项的机器类型全部检查一遍，一个都别漏。用 VS 的“生成 → 重新生成解决方案”时，输出窗口里会显示是哪个 .obj 或 .lib 触发了 LNK1112，顺着路径去找就行。

5.2 现象：程序启动时弹窗“找不到 libcrypto-3-x64.dll”，但 dll 明明放在 exe 旁边的目录里

原因：Windows 加载 dll 的顺序是：exe 所在目录 → 系统目录 → PATH 目录，这一条对大多数情况有效。但如果你把 dll 放在 exe 的某个子目录下，比如 bin\debug 或 lib\x64，系统默认不会去那里找。解决：要么把 dll 复制到 exe 同级目录，要么在工程配置里把 dll 的路径加入 PATH。我更推荐把 dll 直接放到输出目录，并在 Post-Build 事件里加一条复制命令。

:: 在 VS 工程属性 → 生成事件 → 生成后事件里加一行 xcopy /y "$(SolutionDir)third_party\openssl\bin\*.dll" "$(OutDir)" :: 注意 $(OutDir) 末尾的斜杠不要丢，xcopy 对路径分隔符敏感

另外检查一种异常情况：你用 Process Explorer 或 ListDLLs 查看实际加载的 dll 路径，如果加载的不是项目目录下的 dll，而是 C:\Windows\System32 下另一个版本，说明 PATH 里有旧版本或者系统目录里的同名校验值被改名覆盖。Windows 的 DLL 搜索顺序中，系统目录优先级高于 PATH，如果旧 dll 已经在系统目录里，exe 旁边的 dll 反而不一定被用到。我遇到过因为装某个软件把旧版 OpenSSL 带进了 System32，导致新项目 dll 加载失败的案例，把系统目录里的同名文件清理掉就恢复。

5.3 现象：运行时 SSL 握手报错 “no shared cipher”，但程序编译链接都正常

原因：这个现象和 lib/dll/头文件本身无关，而是客户端和服务端各自主推的加密套件没有交集。但很多人会误以为是 OpenSSL 库文件装错了。解决：用 openssl ciphers -v 查看当前 dll 支持的加密套件列表，然后检查代码里是否通过 SSL_CTX_set_cipher_list 做了硬性限制。如果一端只支持 TLS 1.3 的套件，另一端连接参数里还强制 TLS 1.2，握手必然失败。

:: 查看当前 openssl dll 支持的 TLS 套件 openssl ciphers -v 'ALL:@SECLEVEL=1' :: 如果需要看到 TLS 1.3 套件，用下面命令 openssl ciphers -s -tls1_3 -v

值得注意的一个细节：OpenSSL 3.x 从默认安全级别 2 起，把低于 112 比特安全强度的套件全部禁用。如果你在旧系统对接老设备，对方只支持 3DES 或 RC4，这时即使库文件版本完全一致，也连不上。处理办法是在 SSL_CTX 创建后调用 SSL_CTX_set_security_level(ctx, 0)，把安全级别降下来。这是一个典型的、与头文件版本无直接关系但最终要回到库属性上排查的问题，定位方式就是一步步确认 dll 的实际能力和配置值。

5.4 现象：include 头文件时大量语法错误，报错指向 openssl/xxx.h 内部，或者函数未声明

原因：你的工程编译选项里启用了某些宏，例如 WIN32_LEAN_AND_MEAN，它把 windows.h 里的一部分内容裁剪掉，导致 openssl/ssl.h 依赖的底层类型定义缺失。另一个常见原因是你没有定义 OPENSSL_API_COMPAT 或 OPENSSL_NO_DEPRECATED 宏，3.x 版本下部分旧 API 默认不可见。解决：在包含 OpenSSL 头文件之前，先包含 windows.h，然后按需定义版本宏。

// 正确做法：先包含系统头文件，再包含 openssl #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <openssl/ssl.h> // 如果仍然有 api 不可见的问题，在编译选项里加 /D OPENSSL_API_COMPAT=0x30000000L

如果你在用 C++ 工程，头文件包含路径里还可能会触发另一个问题：openssl/e_os2.h 内部检查 _WIN32 宏，这个宏 MSVC 会自动定义，MinGW-w64 也会自动定义，但如果你用了 WIL 库或其他设置 _WIN32_WINNT 的头文件，顺序乱了之后会间接影响 OpenSSL 对 Windows 版本的判定。这不是 OpenSSL 的 bug，而是 Windows 头文件依赖顺序的经典冲突。我的习惯是建立一个公共预编译头文件，里面固定包含顺序，所有人都从它开始，不在具体 .c 文件里随意调整。

6. 验证你的 OpenSSL 集成结果：三件套联动自检的实用方法

编译和链接只是第一步，运行时正确加载和调用 OpenSSL 才算真正落地。我通常会在正式写业务代码之前，先写一个最小自检程序：调用 OpenSSL 的版本函数、执行一次 RSA 密钥生成、做一次内存 BIO 上的 TLS 握手。这个自检能一次性覆盖头文件声明、导入库符号解析、dll 运行时依赖三条链路，任何一个环节有问题都会直接暴露。

// openssl_smoke_test.cpp #include <openssl/ssl.h> #include <openssl/evp.h> #include <openssl/err.h> #include <stdio.h> #pragma comment(lib, "libssl.lib") #pragma comment(lib, "libcrypto.lib") int main() { // 打印版本字符串，验证 dll 加载正常、头文件与 dll 版本一致 printf("OpenSSL 版本: %s\n", OpenSSL_version(OPENSSL_VERSION)); // RSA 密钥生成，验证 libcrypto 符号解析和算法可用 EVP_PKEY_CTX* ctx = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL); EVP_PKEY_keygen_init(ctx); EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 2048); EVP_PKEY* pkey = NULL; if (EVP_PKEY_keygen(ctx, &pkey) != 1) { ERR_print_errors_fp(stderr); return 1; } EVP_PKEY_free(pkey); EVP_PKEY_CTX_free(ctx); printf("RSA 密钥生成成功\n"); return 0; }

这段测试代码的逻辑覆盖了三层验证：OpenSSL_version 函数能跑通，说明 libssl 和 libcrypto 的动态加载路径正常，且头文件声明的函数与 dll 里实际导出的符号一致；EVP_PKEY_new_from_name 和 RSA 密钥生成属于 libcrypto 的算法核心功能，能跑通说明 dll 里的算法自检没有被 Windows 的 DEP 拦截，也没有因为缺依赖库而加载失败。如果程序打印出版本字符串但在密钥生成时崩溃，优先检查 CRT 是否混用。

验证 dll 的运行时依赖还有一个工具层面的技巧：打开“开发者 PowerShell”，然后用 dumpbin /dependents 查看你的 exe 到底依赖哪些 dll。在 64 位系统上，这个命令能直接列出你的程序对 OpenSSL 的依赖情况。

:: 查看 exe 依赖的 dll 列表 dumpbin /dependents my_app.exe :: 输出中如果有 libssl-3-x64.dll 和 libcrypto-3-x64.dll，说明 OpenSSL 是被动态依赖的 :: 如果输出中没有，说明你链接了静态库，运行时不需要外部 dll

这里有一个非常重要的边界：如果你的链接用的是导入库 libssl.lib，发布时忘了带 dll，dumpbin 依然会显示依赖存在，程序直接双击运行报错。而如果你链接的是 libssl_static.lib，dumpbin 的结果里没有这两个 dll，程序体积通常会大 5MB 左右。通过这个命令，你可以一眼确认当前构建属于动态还是静态方案，不至于到现场部署时才发现问题。希望这篇笔记能帮你在 64 位系统上玩转 OpenSSL 的 lib、dll 和头文件，少走我走过的弯路。

本文还有配套的精品资源，点击获取