1. 编译前准备环境、依赖与工具链1.1 为什么需要自己编译libcurl很多人在Windows下做C/C网络编程时第一反应是去官网或者vcpkg拉一个编译好的libcurl库直接用省时省力。但实际项目落地后你就会发现预编译包往往是最容易埋坑的环节。我最早也是直接用curl官网提供的Windows安装包那个包默认是动态库版本且只支持一部分协议很多还绑定着特定的VC运行时版本。集成到项目里容易出现几类问题运行时缺DLL、Debug和Release配置不匹配、SSL功能没启用、想裁剪协议但库已经编译死了。真正到了要交付给客户做内网部署的时候这些麻烦全都会冒出来。自己编译libcurl的核心价值其实就三点一是能把openssl、zlib这些依赖链统一起来保证HTTPS功能可用二是可以选择静态链接还是动态链接和你的项目运行时模式完全对齐三是可以按需裁剪协议和特性让产物体积更小、更安全。这篇文章适合所有在Windows下做C/C开发的工程师尤其是那些准备把libcurl作为网络库集成进自己项目的朋友。1.2 整体方案选型为什么用CMake而不是其他方式libcurl在Windows下编译有几种路线可以选择。老一套的做法是直接用curl源码包里的buildconf.bat配合nmake来编译这种方式在早期很流行但它依赖Perl脚本生成配置头文件过程比较黑盒遇到问题排查起来痛苦。而且它生成的配置文件不能灵活切换特性开关比如你要开启某个协议的编译就得手动去改curl_config.h维护成本很高。vs2019之后libcurl官方对CMake的支持已经非常成熟官方仓库里直接带有CMakeLists.txt还支持了-DUSE_OpenSSLON这种非常明确的选项开关。整个流程的统一性、可维护性都比nmake方式好了太多。还要提一下vcpkg。vcpkg虽然能帮你装好依赖但它解决的是“安装依赖”的问题而不是“你真正理解自己用了什么”的问题。一旦你需要在特殊环境比如离线内网、特定的VS版本、特定架构下构建或者需要定制编译选项还是得回到源码编译这条路。所以我的推荐路线是工具链VS2022 CMake Perl NASM Git全部开源免费。下面我会把每个环节需要的工具、版本选择、配置要点逐步拆开讲清楚。1.3 工具准备与安装要点这一节里的每一个组件都会在编译过程中被真正用到缺一个都会导致卡壳。Visual Studio 2022首先确保你的VS2022已经安装了“使用C的桌面开发”工作负载这个必须勾上。VS的安装器会默认帮你装好MSVC编译器和Windows SDK这两个是硬性依赖。另外一个细节建议勾选“适用于最新v143生成工具的C ATL”相关的组件虽然libcurl编译不直接依赖ATL但后续你集成到项目里做Debug/Release调试时避免因为缺少调试组件而浪费时间。Git用于获取curl和openssl的源码。如果你在国内网络环境下建议直接用HG或者代理下载压缩包即可不需要刻意依赖Git。但从更新的粒度讲Git还是方便很多。CMakeVS2022自带CMake支持但建议单独安装一个最新的CMake。为什么因为VS自带的CMake版本往往滞后而新版本curl的构建配置有可能用到了比较新的CMake语法。直接在cmake官网下载Windows安装包安装时勾选“Add CMake to system PATH”这样后续在命令行里直接用cmake --version验证。Perl这个很容易被忽略但openssl在Windows下编译必须要Perl来执行Configure脚本。推荐装Strawberry Perl原因很简单它自带了一整套Windows下Perl运行环境不像ActivePerl那样有商业授权方面的限制而且包管理比较省心。NASMopenssl编译汇编优化的过程会调用NASM。没有NASM编译也不会直接报错而是会默默退回到没有汇编优化的状态性能下降很明显。更重要的是在一些openssl 3.x版本里缺失NASM可能导致某些模块编译失败。直接下载NASM的Windows版把nasm.exe所在目录加到系统PATH里。装完之后建议先在命令行验证一遍环境perl -v nasm -v cmake --version三个命令都能正常输出版本信息再进入下一步。2. 编译openssl整个流程最容易踩坑的环节2.1 openssl版本选择与源码准备openssl目前主流的发行分支是1.1.1系列和3.x系列。1.1.1系列在2023年9月已经停止长期支持新项目强烈建议直接用3.x系的LTS版本比如3.0、3.3安全更新会持续维护很多年。下载源码时建议去openssl官网的GitHub仓库拉取release tag或者直接下载tar.gz/zip压缩包。这里有一个非常重要的操作习惯源码路径不能有空格不能有中文。我曾经把源码放在D:\Program Files\openssl-src这种路径下结果Perl脚本执行的时候直接报路径解析错误浪费了半个小时。建议统一放到C:\openssl-src或D:\build\openssl-src这样的纯英文路径下。2.2 打开正确的开发者命令行很多新手在这步翻车编译openssl必须在“Visual Studio 2022的开发者命令行”环境里进行因为这个环境已经帮你设置好了MSVC编译器路径、Windows SDK路径和一系列环境变量。开始菜单中找到x64 Native Tools Command Prompt for VS2022这个对应的就是64位编译环境。需要明确一点你现在想编译64位的库就用x64那个命令行想编译32位库就用x86 Native Tools Command Prompt for VS2022。两个环境混用后面肯定出问题。打开命令行后先切换进openssl源码目录然后执行配置命令。2.3 64位编译配置与安装命令在源码目录下依次执行以下命令perl Configure VC-WIN64A --prefixC:\OpenSSL这里解释一下几个关键参数VC-WIN64A指定使用MSVC编译器编译Windows 64位版本。--prefix指定安装路径编译产物最终会被安装到这个目录下包含bin、include、lib三个子目录。测试阶段建议先装到C:\OpenSSL这种简短路径方便后续配置libcurl使用。如果系统变量中已经有其他架构的OpenSSL配置残留建议加上no-asm来禁用汇编优化——但这是万不得已的降级方案正常情况必须开启汇编。配置成功后执行nmake这一步会编译好一会儿。如果是首次编译建议耐心等待不要中途打断。编译的输出会滚屏显示如果你看到MAKE结束并且没有红色error信息基本就成功了。接下来执行测试可选nmake test这个测试环节会花很长的时间但强烈建议不要跳过。openssl的测试套件很完善能帮你提前发现编译环境导致的隐性错误。我自己遇到过编译能通过、但跑测试必挂的情况最后定位到是NASM版本太旧导致某些加密算法模块计算错误——这种问题如果不测试后面集成到curl里做HTTPS请求时偶发崩溃排查难度直接翻倍。最后安装nmake install执行完后检查C:\OpenSSL\bin下有没有openssl.exe如果有在命令行里执行C:\OpenSSL\bin\openssl.exe version能正常输出openssl版本号说明openssl编译安装成功。2.4 32位编译补充说明如果你的项目后续需要同时支持x86和x64那openssl也要编译两份。32位分支的操作流程和上述完全一样区别在于使用x86 Native Tools Command Prompt for VS2022进入编译环境。Configure参数改为VC-WIN32并修改--prefix为C:\OpenSSL32或者其他区分目录避免和64位产物混在一起。编译完之后第二份libcurl还会用到。2.5 openssl配置避坑经验根据我反复编译openssl的实操经验下面几条是高频踩坑点大家提前避开找不到nasm即使你安装了NASM也可能在Configure阶段报“NASM not found”。原因通常是环境变量没有生效新开的命令行窗口不会加载你刚修改过的PATH必须完全关闭终端再重开或者手动执行set PATHC:\nasm;%PATH%。Perl报错common crypto not found这个通常是因为Strawberry Perl环境没装好或者你用了ActivePerl。建议直接卸载重装Strawberry Perl安装时勾选“Add Perl to PATH”。编译过程中出现“cannot open include file winbase.h”这类错误几乎都是因为命令行环境没有加载Windows SDK环境变量。确认你用的是“Developer Command Prompt”而不是普通的CMD窗口。安装目录权限不足Windows下C:\OpenSSL默认需要管理员权限才能写入。如果你不想提权就直接把prefix改成用户目录比如--prefix%USERPROFILE%\OpenSSL。值得注意的是这个路径不能带空格C:\Users\YourName\OpenSSL这种没问题但如果用户名带空格建议还是老老实实用C:\OpenSSL并配合管理员权限。3. 编译libcurl从CMake配置到安装3.1 获取libcurl源码libcurl源码可以直接从GitHub克隆git clone https://github.com/curl/curl.git如果你只是想用稳定版切到最新的release tag即可git checkout curl-8_7_1或者直接去curl官网下载对应的zip压缩包。同样地源码目录不能有空格和中文比如放在C:\curl-src。3.2 CMake配置一条命令讲清楚所有关键选项在curl源码目录下新建一个build目录用来存放CMake的缓存和中间文件避免污染源码目录。然后执行cmake .. -G Visual Studio 17 2022 -A x64 -DCMAKE_USE_OPENSSLON -DOPENSSL_ROOT_DIRC:\OpenSSL -DOPENSSL_INCLUDE_DIRC:\OpenSSL\include -DOPENSSL_LIBRARYC:\OpenSSL\lib\libssl.lib -DOPENSSL_CRYPTO_LIBRARYC:\OpenSSL\lib\libcrypto.lib -DCURL_ZLIBOFF -DBUILD_SHARED_LIBSOFF -DCMAKE_INSTALL_PREFIXC:\CURL逐个解释这些参数-G Visual Studio 17 2022 -A x64指定生成VS2022的64位工程。如果编译32位将-A x64改为-A Win32。-DCMAKE_USE_OPENSSLON这是整个编译流程的核心开关。curl通过这个开关来决定是否编译HTTPS支持。如果为OFF编译出来的curl只能走HTTP协议访问HTTPS站点会报协议错误。-DOPENSSL_ROOT_DIR指向openssl安装根目录CMake会基于它去搜索头文件和库文件。-DOPENSSL_INCLUDE_DIR明确指定openssl头文件目录。-DOPENSSL_LIBRARY和-DOPENSSL_CRYPTO_LIBRARY分别指定libssl.lib和libcrypto.lib的完整路径。有的CMake版本用了OPENSSL_ROOT_DIR就能自动找到但为了保险强烈建议把这两个库路径也显式指定出来避免CMake搜索时误判版本。-DCURL_ZLIBOFF先关掉zlib支持。如果后续项目需要处理gzip压缩响应可以再编译zlib库并打开此选项这一步不影响核心流程。-DBUILD_SHARED_LIBSOFF生成静态库。如果你想要动态库DLL就改为ON。静态库集成更简单不牵扯DLL部署问题。-DCMAKE_INSTALL_PREFIX指定安装路径。配置完成后build目录里会生成curl.sln解决方案以及CMakeCache.txt等文件。检查一下CMake的输出日志确认这一行-- Enabled features: SSL -- Enabled protocols: HTTP HTTPS只要带有HTTPS说明openssl已经成功链接进来了。3.3 正式编译与安装继续在build目录执行cmake --build . --config Release --parallel 8--parallel 8表示8线程并行编译能明显加快速度。编译结束后执行安装cmake --install . --config Release安装完成后C:\CURL目录下会出现include、lib、bin三个子目录。lib目录里有libcurl.libRelease静态库include目录里有curl头文件目录。到这里libcurl已经编译完成了。如果你想在VS里手动打开curl.sln调试某个模块也可以直接双击解决方案在VS里面选择Release配置再生成。但是命令行方式更干净出错了也容易重来。3.4 Debug版本怎么处理项目开发过程中肯定需要Debug版本的库来做调试。在相同build目录下再执行一次cmake --build . --config Debug --parallel 8 cmake --install . --config Debug注意一个问题Debug和Release库会安装到同一个lib目录文件名都是libcurl.lib后者会覆盖前者。更稳妥的做法是分开两个build目录比如build-debug和build-release分别配置、编译、安装到不同的前缀目录最终得到两套独立的库文件C:\CURL-DebugC:\CURL-Release开发阶段用Debug库发布阶段用Release库两者互不干扰。3.5 动态库版本与运行时依赖说明如果你选择-DBUILD_SHARED_LIBSON编译动态库最终会产出libcurl.dll和libcurl.lib。部署时需要把dll和exe放在同一目录或者把dll放到系统PATH里。动态库方案的好处是各模块独立升级、减少静态链接的体积坏处是和项目所在机器的VC运行时时序绑定紧密一旦客户机器缺少对应的运行时就是经典的“缺少VCRUNTIME140.dll”错误。静态库方案则更省心所有代码都打进exe里部署时只需要一个exe。代价是如果同时链接了libcurl、openssl的静态库最终exe可能偏大且所有的依赖库必须使用相同的运行时模式/MT或/MD这个我们在集成环节详聊。4. 集成到VS2022项目链接配置与使用示例4.1 在VS2022中配置libcurl路径打开你的VS2022项目打开项目属性页找到“VC 目录”设置在“包含目录”里添加C:\CURL\include在“库目录”里添加C:\CURL\lib然后找到“C/C - 预处理器 - 预处理器定义”根据你的编译模式添加CURL_STATICLIB注意如果你是静态链接libcurl这个宏必须加。curl的头文件会根据这个宏决定是否声明__declspec(dllimport)不加它会导致链接阶段报一堆无法解析的外部符号让人误以为库没链接对。接着在“链接器 - 输入 - 附加依赖项”里添加libcurl.lib libssl.lib libcrypto.lib ws2_32.lib crypt32.lib wldap32.lib normaliz.lib最后三个ws2_32.lib、crypt32.lib、wldap32.lib、normaliz.lib是Windows系统的网络和加密相关库libcurl和openssl在Windows下会依赖它们。漏掉任何一个链接阶段都会以LNK2019的形式提醒你哪个符号找不到。4.2 一个完整的HTTP GET请求示例下面写个最小可运行的例子演示libcurl集成成功后发起一个最简单的HTTP请求#include iostream #include string #include curl/curl.h static size_t WriteCallback(void* contents, size_t size, size_t nmemb, void* userp) { std::string* body static_caststd::string*(userp); body-append(static_castchar*(contents), size * nmemb); return size * nmemb; } int main() { CURL* curl curl_easy_init(); if (!curl) { std::cerr curl_easy_init failed std::endl; return -1; } std::string response; curl_easy_setopt(curl, CURLOPT_URL, https://example.com); curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, WriteCallback); curl_easy_setopt(curl, CURLOPT_WRITEDATA, response); curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L); curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L); CURLcode res curl_easy_perform(curl); if (res ! CURLE_OK) { std::cerr curl_easy_perform() failed: curl_easy_strerror(res) std::endl; curl_easy_cleanup(curl); return -2; } std::cout HTTP response body: response std::endl; curl_easy_cleanup(curl); return 0; }这里两个SSL_VERIFYPEER选项暂时设置为0目的是先跑通流程不验证服务器证书。生产环境不要这么做要么配置证书文件要么使用系统根证书存储否则安全性为零。编译运行后如果能打印出example.com的HTML内容说明libcurl已经完整集成成功openssl的HTTPS链路也通了。4.3 静态库模式下运行时库/MT vs /MD的匹配规则这是很多人在集成阶段真正卡住的地方也是最容易被忽略的坑。VS项目里配置的“运行时库”选项会在编译时决定程序使用的是静态版CRT/MT还是动态版CRT/MD。问题在于libcurl静态库和openssl静态库本身也是用某种模式编译的。如果你在编译libcurl时为Release用了默认的/MD而你的项目配置的是/MT链接时就会爆出这样的错误LNK2038 mismatch detected for _ITERATOR_DEBUG_LEVEL: value 0 doesnt match value 2或者类似的RuntimeLibrary mismatch错误根本原因就是运行时不匹配。解决办法很简单不折腾。编译libcurl时在CMake配置阶段加上-DCMAKE_MSVC_RUNTIME_LIBRARYMultiThreadedDLL或者用Debug就加MultiThreadedDebugDLL确保和你项目里的一致。通常的企业项目为了交付方便会要求静态链接CRT也就是/MT那libcurl编译时就要用MultiThreaded。经验之谈确定好自己的项目用哪种运行时模式然后把libcurl、openssl全部按照同一个模式编译。这是所有静态库集成共有的规律libcurl只是其中之一。4.4 证书校验与常见运行问题如果你在运行示例时设置了CURLOPT_SSL_VERIFYPEER, 1L默认也是1但没有配置CA证书文件那么curl请求HTTPS站点时就会报curl_easy_perform() failed: SSL certificate problem: unable to get local issuer certificate这是因为curl无法找到系统根证书库。Windows下处理这个问题有几种常见方式第一种在请求前手动指定证书文件curl_easy_setopt(curl, CURLOPT_CAINFO, C:\\path\\to\\cacert.pem);这个cacert.pem可以从curl官网下载或者直接从你安装的openssl目录里找到cert.pem把它拷贝到一个固定路径下。第二种在编译libcurl时启用Windows的证书存储让curl直接对接Windows证书管理器。这个需要额外编译选项配置稍复杂。对于一般内网项目先设置SSL_VERIFYPEER为0跑通流程是合理的但面向公网环境的正式产品必须做证书校验否则中间人攻击可以轻松解密你的全部流量。4.5 同时集成Debug和Release库时的注意点如果你同时编译了Debug和Release两套库在VS项目里切换编译配置时务必同步切换库路径。推荐的做法是在项目属性里给“库目录”使用宏区分。比如Debug模式下用C:\CURL-Debug\libRelease模式下用C:\CURL-Release\lib。也可以使用VS的调试和发布配置结合$(Configuration)等内置宏做一个条件目录C:\CURL-$(Configuration)\lib这样的好处是切换编译配置时链接器自动找到对应版本的库不会出现“Debug程序链接了Release库”这种看似能跑、实则偶尔崩溃的诡异问题。5. 常见错误排查与避坑清单5.1 openssl编译阶段问题速查以下是我在openssl编译阶段遇到过的典型问题做成表格方便直接对照。错误信息根本原因解决办法perl: command not foundPerl未安装或未加入PATH安装Strawberry Perl并确认环境变量生效NASM not foundNASM缺失或不在PATH安装NASM重新打开命令行窗口使PATH生效Cant locate Win32/Console.pmPerl环境不完整更换为Strawberry Perl避免其他精简版PerlNMAKE : fatal error U1077编译器环境未正确初始化在VS2022开发者命令行中执行编译且确认架构一致Cannot open include file winbase.hWindows SDK环境变量未加载使用x64 Native Tools Command PromptVC-WIN64A not supportedConfigure参数拼写错误或Perl版本太旧确认openssl版本支持更新Perl到最新稳定版5.2 libcurl的CMake配置阶段问题速查错误信息根本原因解决办法Could NOT find OpenSSLCMake未找到openssl库显式指定OPENSSL_ROOT_DIR及OPENSSL_LIBRARYSSL support is disabledCMAKE_USE_OPENSSL为OFF在CMake配置命令中加-DCMAKE_USE_OPENSSLONCould NOT find ZLIB开启了zlib但未安装对应库先-DCURL_ZLIBOFF或正确配置ZLIB_ROOTerror LNK2019: unresolved external symbol编译器配置缺失或运行时模式不一致确认附加依赖库完整检查/MT与/MD是否一致LNK2038: mismatch detected运行时库不匹配统一libcurl、openssl与项目的CRT模式Cannot open file libcurl.lib库目录配置错误检查VC目录中的“库目录”是否指向正确路径无法打开包括文件: curl/curl.h包含目录未配置在VC目录的“包含目录”里添加C:\CURL\include5.3 编译期宏与链接细节的独家建议如果你在集成时遇到无法解析的外部符号比如__imp_curl_easy_init这类说明头文件认为你在动态链接libcurl但库是静态的。解决办法就是前面说的在预处理器定义里加上CURL_STATICLIB。如果你遇到__imp_curl_easy_init already defined这类重复定义的报错则正好相反说明头文件认为你是静态链接但你的链接器输入里既有静态库又有运行库导入需要检查项目里是不是同时引用了动态和静态两种libcurl。如果你链接时提示缺少libssh2.lib之类的符号说明你在CMake配置时不小心打开了SSH协议的支持但系统里没有对应依赖解决办法是在CMake配置命令里加上-DCURL_USE_LIBSSH2OFF6. 针对不同使用场景的扩展建议6.1 需要支持zlib压缩怎么办如果你的项目需要处理Content-Encoding: gzip响应curl的CURLOPT_ACCEPT_ENCODING功能会很有用。要启用这个功能就需要在编译libcurl时加入zlib库。zlib也需要源码编译流程和openssl类似用CMake生成VS工程安装到C:\zlib目录下。然后在curl的CMake配置命令中加入-DCURL_ZLIBON -DZLIB_ROOTC:\zlib编译完以后代码里设置curl_easy_setopt(curl, CURLOPT_ACCEPT_ENCODING, gzip);curl会自动追加Accept-Encoding: gzip请求头并透明解压响应体。这在很多对接Web API的场景下非常有用能显著减少网络传输量。6.2 需要支持HTTP/2怎么办HTTP/2在curl中默认是不带的需要添加nghttp2库支持。如果你在Windows上编译nghttp2推荐用vcpkg辅助生成或者直接从nghttp2官方仓库下载预编译库。然后在curl的CMake配置命令中加入-DUSE_NGHTTP2ONHS版需要注意开启HTTP/2支持后链接时还需要把nghttp2的库也加入附加依赖项。6.3 多架构产物管理建议如果需要同时提供x86、x64、Debug、Release四个版本的库建议按这样的目录结构组织C:\curl-build\ x64\release\ x64\debug\ x86\release\ x86\debug\每组目录都是独立的CMake构建目录和安装前缀构建时通过-A和--config参数控制目标最后切换项目配置时直接引用对应目录即可。这种管理方式虽然前期多花了一点编译时间但后续的集成开发会非常清爽。6.4 离线环境的扩展示例在离线内网环境编译最大的障碍是源码下载。建议在联网机器上提前把curl、openssl、perl安装包、nasm安装包全部下载好打成压缩包带进去。CMake和VS的安装也建议用离线安装器提前准备。离线环境下编译时所有依赖库都采用本地路径引用不需要改动构建逻辑。openssl和curl都支持源码编译只要工具链齐全离线环境不会有额外问题。7. 编译过程中必须知道的工作原理7.1 为什么openssl编译需要Perl和NASMopenssl的构建系统是基于Perl脚本的。Configure脚本负责生成适配当前平台的编译配置文件它本身是一个Perl脚本所以必须依赖Perl解释器。NASM的作用则是汇编优化。openssl内部大量使用汇编语言实现加密算法如AES、SHA等的关键路径利用CPU的硬件加速指令来提升性能。没有NASM时openssl会退回到C语言实现功能不变但性能下降明显。需要提醒的是不同版本的openssl对NASM版本要求不一样建议安装最新版NASM避免因版本过旧导致的汇编语法不支持错误。7.2 libcurl的SSL支持是怎么工作的libcurl本身不实现SSL/TLS协议而是通过抽象层调用后端的SSL库。openssl是其中最常见的后端之一另外还有Windows自带的Schannel、OpenSSL兼容的LibreSSL等。当你开启CMAKE_USE_OPENSSLON并编译成功后curl代码里的SSL相关函数会被编译为调用openssl API的实现。所以HTTPS请求的过程是curl负责HTTP协议的解析和传输openssl负责TCP连接之上的TLS握手、证书验证和数据加密。二者通过curl内部的SSL backend接口协作这也是为什么openssl编译完成后curl必须重新编译一次才能让改动生效。7.3 静态链接的完整二进制构成静态编译的libcurl最终会被打进exe文件。一个集成了openssl的curl静态链接程序其二进制文件里实际上包含了libcurl自身的HTTP、HTTPS协议实现openssl的libssl和libcrypto代码部分Windows系统库的调用代码所以最终exe体积会从几十KB膨胀到几MB这是正常现象。市面上很多标榜“绿色”的小型exe其实都是砍掉了HTTPS支持的版本这一点在业界是普遍选择。了解这个原理后你就能理解为什么有些所谓“精简版”curl没法访问HTTPS链接了。8. 最后的实践经验总结在整个编译和集成过程中我反复验证过几个关键结论环境一致性决定编译成败架构、CRT模式、Debug/Release三者的匹配是静态链接库永远的命门。openssl和curl必须使用相同的编译配置任何一层不一致最后都能通过链接错误或运行崩溃暴露出来。不要怕命令行CMake的命令行方式比VS界面配置更快更可控。虽然VS里也能配置CMake工程但纯命令行配合CMakeCache.txt的方式出问题后重来只需清空build目录比在GUI里反复点选项高效得多。生成两套库Debug和Release非常值得成本只是多花几分钟编译时间但开发期的调试体验会好很多。Debug库能给你完整的调试符号断点可以进到curl函数内部甚至进到openssl的加密函数内部。最后一个小建议编译好的库一定要写一个简单的README记录编译日期、源码版本号、编译命令和使用的依赖版本。两个月后你自己回来看或者交接给同事时这份记录能省下大量重新摸索的时间。这套流程走通之后后续无论是升级openssl版本、增加zlib支持、还是切换到HTTP/2都只需要在对应环节做很小的改动整个编译链路不会再成为项目里的黑盒。