Linux源码编译安装libcurl库：从configure到静态链接全攻略

1. 换一条路装库为什么有时候必须用源码压缩包说起Linux下安装第三方库很多人第一反应是apt install或者yum install。这确实是最省事的方案但我在做项目时经常发现包管理器这条路走不通最后不得不老老实实下载源码压缩包自己编译。这个场景一点都不罕见尤其是做Linux系统编程的libcurl这个库我就被逼着从压缩包装了好几回。拿libcurl库举例它是最常用的网络传输库支持HTTP、HTTPS、FTP、SMTP等一大堆协议C语言项目里但凡要和远端服务打交道基本绕不开它。但系统自带的版本往往有几个老问题第一是版本太旧。我曾在某服务器上看到自带libcurl还停留在老版本那还是十几年前发布的。老版本对现代TLS协议支持不全调试HTTPS接口时经常握手失败而我又不想为了一个库去动操作系统的整体升级计划。第二是编译选项不可控。发行版预编译的libcurl默认没有带某些协议支持或者带的协议太多了。比如有的嵌入式项目只想要HTTP和HTTPS结果包里还编译进了ftp、telnet这类多余协议库的体积白白多出几百KB。在一些存储空间紧张的场景里这种浪费是不能接受的。第三是静态链接的需求。有些安全要求比较高的项目希望最终交付的二进制不带动态库依赖直接一个可执行文件扔到目标机器上就能跑。系统包管理器给的通常是动态库想拿静态库只能自己从源码编。第四是交叉编译。做嵌入式开发时目标平台的架构和开发机不一样比如开发机是x86目标板是ARM。发行版的源码包根本不会考虑你的自定义交叉编译链只有拿到源码自己configure、自己make才行。所以别看开源压缩包的使用流程这个题目听起来基础它其实是Linux系统编程的一项核心基本功。我见过不少经验不算浅的工程师写代码没问题但一遇到从tar.gz开始装一个库就发怵要么卡在configure选项上要么编译出来了却链接不上折腾半天最后又退回包管理器。这篇文章就以libcurl库的源码压缩包安装为主线把从解压、配置、编译、安装到写第一个Demo程序、解决链接问题、选择动态库还是静态库这整套流程完整跑一遍。每一步我都会说明为什么这么做以及我实际踩过的坑。适合刚入门Linux系统编程的读者也适合那些已经用过包管理器装过库、但没真正从源码编译过库的人。2. 解压之后的第一个选择读懂压缩包里的目录结构拿到一个开源库的源码压缩包最常见的格式是tar.gz或者tar.bz2我以tar.gz为例。解压命令是tar -xzf libcurl-版本号.tar.gz cd libcurl-版本号/解压完成、进入目录后先别急着执行./configure花两分钟把目录结构扫一遍能省下后面大量排查问题的时间。2.1 压缩包里那些藏信息的文件任何正规的开源库压缩包里一定有几个固定的文件它们几乎就是整个项目的说明书README或者README.md项目的简介、特性、快速上手指南。有些还在开头就详细写了依赖要求比如需要OpenSSL 1.1.1以上版本。INSTALL或者INSTALL.md编译和安装的详细说明。这个文件最容易被人忽略但libcurl这类库的INSTALL文件会明确告诉你你可以用./configure --help查看所有选项某些协议需要额外安装开发库默认安装路径是/usr/local。configure一个shell脚本后面要重点说它。Makefile.inMakefile的模板文件。configure脚本会根据你当前系统的实际情况把这个模板转换成最终的Makefile。src/、lib/、include/、docs/这些目录分别对应可执行文件源码、核心库源码、对外头文件、文档。2.2 configure脚本到底在做什么很多新手不理解为什么要跑./configure直接make不行吗这里的关键原因在于不同Linux发行版之间差异很大——编译器版本不同、依赖库的位置不同、某些特性是否可用也不同。如果你拿一份写死的Makefile去编译很可能因为找不到某个头文件或者某个库而失败。configure脚本的作用就是探测你的编译环境然后把探测结果写进生成的Makefile里。它检查的东西包括你的系统里有没有gcc或者cc版本是多少有没有libcurl需要依赖的库比如libssl、libz、libpsl这些库的头文件和库文件分别在哪个目录当前系统是大端还是小端是32位还是64位某些特性该不该编译进去比如要不要支持IPv6、要不要支持HTTP/2。运行./configure --help可以看到这个库支持的全部编译选项。以libcurl为例你会看到--enable-http、--disable-ftp、--with-ssl、--without-ssl这一大串全部看一遍很不现实但有几个是必须搞明白的。2.3 最常用的configure选项prefix和with-ssl--prefix这个选项决定安装路径默认是/usr/local。这意味着编译出来的头文件会装到/usr/local/include库文件装到/usr/local/lib可执行文件装到/usr/local/bin。这里很容易产生一个误解有人以为--prefix是指定源代码的路径其实它是指定安装目标路径。我早期犯过这个错误把prefix指到了源码目录结果make install把编译产物和源码混在一起清理起来非常麻烦。另一个高频选项是--with-ssl。libcurl的核心价值之一就是HTTPS支持而HTTPS需要TLS库。开源的TLS库有好几个最常用的是OpenSSL。如果你的系统里装了OpenSSL的开发包可以这样指定./configure --prefix/usr/local --with-ssl如果你的系统里OpenSSL装在了非标准位置比如自己编译过OpenSSL并装到了/opt/openssl那就要把路径也告诉configure./configure --prefix/usr/local --with-ssl/opt/openssl注意configure脚本检查的是开发库不是运行库。所谓开发库就是除了能运行的so文件之外还需要头文件.h和链接时用的so符号链接或者.a静态库。如果你的机器上只有libssl.so而没有openssl/ssl.hconfigure照样会提示找不到SSL支持。2.4 裁剪功能的选项禁掉不需要的协议前文提到预编译的libcurl带了一堆用不上的协议。如果你有体积或安全方面的要求可以从源码阶段就裁剪。libcurl的协议控制选项很细我以一个实测过的组合为例./configure --prefix/usr/local --with-ssl \ --enable-http --enable-https \ --disable-ftp --disable-telnet --disable-ldap \ --disable-dict --disable-file --disable-imap \ --disable-pop3 --disable-smtp --disable-rtsp \ --disable-tftp --disable-gopher这样编译出来的libcurl只保留HTTP和HTTPS。做出来的库体积小而且攻击面也小因为不支持那些协议自然就不存在那些协议解析逻辑可能带出的安全问题。这里要提醒一句裁剪功能是增量生效的也就是说configure脚本会先按默认值启用所有特性再根据你给的--disable-xxx逐个关闭。所以裁剪的选项写全一点不要只关一两个就以为干净了。3. 从make到make install编译安装全流程与权限陷阱configure执行成功之后会在当前目录生成一个Makefile。接下来就是经典的编译三步走make、make install、ldconfig。这一步看起来简单实际执行中有一堆细节值得说。3.1 make的完整过程和常见报错定位执行make编译器开始工作。libcurl这种体量的库从零编译大概需要几分钟。这个过程中屏幕上会滚动大量编译输出大部分情况下不需要逐行看但如果编译中途失败你需要在报错信息里找到关键行。我第一次编译libcurl时遇上一个看起来莫名其妙的报错类似找不到某个头文件。当时第一反应是这个库有问题后来冷静下来用find命令查了一下发现那是个第三方依赖的头文件路径不在默认搜索范围里。解决办法是在configure阶段就通过CPPFLAGS环境变量把额外的头文件路径传进去./configure --prefix/usr/local CPPFLAGS-I/opt/openssl/include如果你有额外的库文件目录要告诉链接器用LDFLAGS./configure --prefix/usr/local CPPFLAGS-I/opt/openssl/include LDFLAGS-L/opt/openssl/lib这里的思路值得展开说说configure脚本本质上是shell脚本它执行时会继承当前shell的环境变量。所以在执行./configure这条命令时可以临时给这个环境加上额外信息。CPPFLAGS是C预处理的额外参数LDFLAGS是链接阶段的额外参数。这两个变量是编译源码库时最常用的后门用来解决依赖库不在标准位置的问题。make的过程还支持并行编译在多核机器上能明显加速make -j4-j4表示同时跑4个编译任务。如果你的机器是8核可以-j8。不过要注意并行编译偶尔会因为某些库的生成顺序问题而失败如果make -j8失败了先不要慌重新跑一次不带-j的make很多时候就成功了。这是因为并行编译时某些目标文件的依赖关系没有在Makefile里写全串行编译反而能保证顺序。3.2 make install的权限问题root还是sudomake install的默认动作是往/usr/local目录里拷贝文件。如果你用--prefix指定了一个普通用户可写的目录比如/home/用户名/libs或者/opt/xxx那就不需要root权限。但如果你用的默认路径/usr/local大概率会碰到权限不足的报错。这里的正确处理方式是要么用sudo make install要么就换一个自己可写的prefix。我个人更推荐后者原因是在开发机上把自编译的库装到一个独立目录里后续卸载时直接删目录就行不会污染系统目录。但要注意装到自定义目录后使用这个库时得手动告诉编译器和链接器头文件及库文件的位置这个后面讲编译Demo时会具体说。3.3 安装后的验证看头文件、查库文件安装完成后我习惯做三件事验证一下ls -l /usr/local/include/curl/ ls -l /usr/local/lib/libcurl.*第一件事是确认头文件目录存在里面应该有curl.h、curlver.h、easy.h这些文件。第二件事是确认库文件已经生成你会看到几个文件libcurl.a静态库文件libcurl.so动态库符号链接libcurl.so.版本号动态库实体文件。如果你看不到静态库说明configure时用了--disable-static如果看不到动态库说明用了--disable-shared。默认情况是两种都生成既方便开发也方便部署。还有第三件事是查版本用库自带的工具curl-config --version ./curl --versioncurl-config是libcurl源码包附带的一个小工具它能告诉你编译链接这个库时需要什么参数。这两个命令都能看到版本号和编译特性如果看到类似SSL: OpenSSL的信息说明HTTPS支持已经编进来了。3.4 动态库的运行时路径ldconfig与LD_LIBRARY_PATH安装动态库之后还有个系统层面的问题程序运行时系统能不能找到这个动态库。Linux默认的库搜索路径包括/lib、/usr/lib而自编译安装的库在/usr/local/lib这个路径是否在搜索范围里取决于系统配置。如果不做任何处理你编译出一个依赖libcurl的动态链接程序运行时会报错error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory这个报错太经典了几乎所有做系统编程的人都会撞上一次。解决办法有两种第一种是把/usr/local/lib加入系统的动态库搜索缓存echo /usr/local/lib /etc/ld.so.conf.d/libcurl.conf ldconfigldconfig会重建动态库的缓存文件这样系统就能找到新装到/usr/local/lib的libcurl了。第二种是临时环境变量方式export LD_LIBRARY_PATH/usr/local/lib这招适合在开发调试阶段用临时指定运行时的库搜索路径不用动系统配置。但要注意这个环境变量只是在当前终端会话里有效换个终端就没了不适合长期依赖。顺便说一个概念你编译程序时的-lcurl链接选项是在编译链接阶段告诉链接器去哪找库文件而LD_LIBRARY_PATH和控制动态库搜索的行为是在程序运行时才起作用。两者是不同的阶段却经常被混为一谈。很多新手在编译时通过-L/usr/local/lib成功编译了程序运行时却仍然报找不到库就是因为忽略了运行时的路径配置。4. 写第一个libcurl程序编译链接的小细节库装好了接下来要验证它真的能用。写一个最小的HTTP请求程序请求一个公开的测试地址把响应内容打印出来这是最直接的验证方式。4.1 最小Demo的代码框架libcurl的使用方式大致是三步初始化全局环境、设置请求选项、执行并释放。示例代码如下#include stdio.h #include curl/curl.h int main(void) { CURL *curl curl_easy_init(); if (!curl) { fprintf(stderr, curl_easy_init failed\n); return -1; } curl_easy_setopt(curl, CURLOPT_URL, http://example.com); curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L); CURLcode res curl_easy_perform(curl); if (res ! CURLE_OK) { fprintf(stderr, curl_easy_perform failed: %s\n, curl_easy_strerror(res)); } curl_easy_cleanup(curl); return 0; }这段代码做的事情很简单curl_easy_init创建了一个easy会话句柄curl_easy_setopt设置请求的URL和是否跟随重定向curl_easy_perform执行实际请求最后curl_easy_cleanup释放句柄。响应体默认会直接打印到标准输出所以运行这个程序你会在终端里看到一堆HTML内容。关于CURLOPT_FOLLOWLOCATION这个选项多说两句它表示如果服务器返回301/302重定向响应客户端是否自动跟随。不设置的话curl_easy_perform返回时只会拿到一个重定向的响应头而不是最终的页面内容。这个选项在实际项目里几乎必须开否则你请求的地址一换域名程序就扑空了。4.2 编译命令的三种写法编译这个程序最直观的命令是gcc -o demo demo.c -lcurl-lcurl的意思是让链接器去找libcurl.so或者libcurl.a。如果库安装在了默认路径比如/usr/local/lib且这个路径已经在系统搜索范围里这条命令就能直接编译过。但如果你把libcurl装到了非标准目录比如--prefix/home/user/mylibs编译命令必须带上头文件和库文件的位置gcc -o demo demo.c -I/home/user/mylibs/include -L/home/user/mylibs/lib -lcurl-I告诉编译器头文件在哪-L告诉链接器库文件在哪。这个组合是源码安装库之后编译程序必须掌握的。还有第三种写法也是我认为最专业的写法——用pkg-config或者curl-configgcc -o demo demo.c $(pkg-config --cflags --libs libcurl)或者gcc -o demo demo.c $(curl-config --cflags --libs)pkg-config是目前Linux下最标准的库信息查询工具它读取*.pc文件自动输出头文件路径和库文件路径。但curl-config是libcurl自带的天然可用。你可以在终端里直接跑一下curl-config --cflags --libs会看到它输出了类似-I/usr/local/include -L/usr/local/lib -lcurl这样的内容。我强烈建议在Makefile或者构建脚本里使用pkg-config或者curl-config而不是手写-I和-L。原因是路径写死之后一旦换台机器、换了个路径又得手动改用工具查询则能保持灵活性。4.3 编译成功的判断标准和验证手段编译成功之后运行./demo正常情况会打印出example.com的HTML内容。如果一切顺利说明从源码安装libcurl这条路已经彻底跑通了。为了验证HTTPS支持是否真的编进来了把CURLOPT_URL改成https://example.com再编译运行一次。如果SSL/TLS没配置好程序会返回一个CURLE_SSL_CONNECT_ERROR之类的错误码。如果正常输出内容就说明--with-ssl生效了。5. 链接时的三大经典报错从现象倒推问题根源源码安装库之后写代码编译时最容易翻车的就是链接阶段。我总结了三类高频报错每一个都值得单独说透。5.1 头文件找不到类报错报错形式通常是fatal error: curl/curl.h: No such file or directory这个报错发生在编译阶段也就是预处理时找不到头文件。原因基本是头文件路径不在搜索范围里。排查思路是这样的第一步先确认头文件到底装到哪了。用find搜一下find /usr /opt -name curl.h 2/dev/null第二步确认你编译时有没有用-I指定正确的路径或者pkg-config查出来的路径对不对。第三步如果你是用包管理器装过旧版libcurl又自己从源码装了一个到别的路径那么curl/curl.h可能同时有多个版本存在。这时候就看-I指定的顺序第一个匹配到的目录里的curl.h会被编译进去。这种版本混搭是非常隐蔽的坑我遇到过系统里同时存在两个版本编译器用的版本和链接库的版本不一致导致编译过但运行崩溃。5.2 找不到库文件类报错报错形式/usr/bin/ld: cannot find -lcurl-lcurl这个选项在链接阶段会被扩展成去找libcurl.so或者libcurl.a。/usr/bin/ld: cannot find -lcurl这个报错的含义是链接器在这条命令指定的所有搜索路径里都没找到这两个文件。排查思路先确认寄存器目录下有没有库文件ls -l /usr/local/lib/libcurl.*用-L指定目录比如-L/usr/local/lib用curl-config --libs看看它输出的-L路径是否和你实际安装路径一致。这里有个很隐蔽的问题有的系统是64位库文件装在/usr/local/lib64而不是/usr/local/lib。如果configure默认prefix是/usr/local它可能会把库放到lib64目录下。检查的时候要两个目录都看。5.3 undefined reference类报错这类报错是所有链接错误里最让人头疼的demo.c:(.text0x10): undefined reference to curl_easy_init这个报错说明头文件找到了但链接器在处理函数符号时没能找到定义。和cannot find -lcurl不一样的是这个报错通常意味着库文件找到了但库文件里没有你要的那个符号。导致这个问题的常见原因有几种一是你链接的库文件版本太老。老版本的libcurl可能还没有curl_easy_init这个符号或者符号名不对。二是你链接的是静态库但静态库编译时没有把依赖的其他库一起带上。libcurl是一个依赖比较多的库尤其编了SSL之后静态链接时你不仅需要-lcurl还需要-lssl -lcrypto有时还要-lz。这就是静态库的间接依赖问题后面专门说。三是函数声明和实际库版本不匹配。你编译时用的头文件是新的但链接的库是旧的头文件里有的新API旧库里根本没有实现。解决办法是让头文件和库文件来自同一次安装。5.4 静态库链接时的依赖传导问题既然提到了静态库这里稍微展开说说。静态链接时libcurl.a并不会把OpenSSL的代码并进去它只是把自己内部的代码打包了对外部依赖仍然保持引用。所以链接命令需要把所有依赖库按顺序放在后面gcc -o demo demo.c -I/usr/local/include -L/usr/local/lib \ -lcurl -lssl -lcrypto -lz注意这里的顺序-lcurl必须放在引用它的源文件或者目标文件之后而-lssl -lcrypto -lz必须放在-lcurl之后。这是因为链接器处理静态库时是从前向后扫描的它看到demo.o里有一个未解析的curl_easy_init就往后找libcurl.a找到之后发现libcurl.a里又引入了对SSL库的引用就会继续往后找libssl.a。如果顺序写反了比如gcc -o demo demo.c -lssl -lcrypto -lcurl链接器先扫描libssl.a和libcrypto.a时没有发现任何未解析符号需要它们就把它们忽略了等扫描到libcurl.a时才发现需要SSL符号但前面的libssl.a已经错过了根本不会再回头看。于是你会看到一大堆undefined reference to SSL_xxx的报错。这个问题的本质是对链接器工作方式的理解不到位。链接器是单遍扫描的它只管当前正在处理的文件里的未解析符号不会回头再处理已经扫描过的库。这也是为什么-l选项的顺序这么重要。6. 静态库和动态库按业务场景做选择库编译安装完成后你手里同时有libcurl.a和libcurl.so到底用哪个这取决于实际业务场景。6.1 动态库开发体验好部署要操心动态库是默认推荐的方式因为它和可执行程序是运行时才绑定的。这意味着更新库时不需要重新编译程序多个程序可以共享同一个库的副本内存里可以只加载一份编译时链接速度快生成的二进制体积小。但它也有代价。程序运行时依赖目标机器上有正确的动态库而且版本还要匹配。前文提过的cannot open shared object file报错就是动态库依赖最经典的坑。你用ldd demo命令查看某个可执行文件依赖哪些动态库ldd ./demo输出会列出它需要的所有.so文件以及当前系统里能否找到。如果有一行写着not found就说明目标机器的动态库环境有问题。6.2 静态库部署省心折腾在构建期静态库的使用场景是我想交付一个独立的二进制。比如你要把程序部署到一个非常精简的容器镜像里或者交付给客户的一台完全没有开发环境的机器静态链接能避免缺库的烦恼。静态链接的代价是最终二进制体积大很多libcurl加上OpenSSL体积增加是必然的库更新时依赖这个库的所有程序都要重新编译一遍静态链接可能涉及许可证合规性问题比如OpenSSL的开源许可对静态链接有一些额外的开源义务。6.3 怎么在编译时强迫链接器选某一个库当你既有静态库又有动态库时-lcurl默认会优先链接动态库。如果你非要静态链接有几种方式。直接在命令行上写静态库的完整路径绕开-l的搜索逻辑gcc -o demo demo.c /usr/local/lib/libcurl.a \ -lssl -lcrypto -lz或者用-static选项指示链接器全部采用静态链接不仅libcurl静态化连libc、libm这些系统库也静态化。这会带来一个非常纯正的、完全不依赖运行环境的二进制。但-static也有代价程序启动慢一些且某些依赖了动态加载特性的库比如gethostbyname相关的网络解析在静态模式下会出现奇怪问题。一个折中的方案是部分静态化只让libcurl静态链接其他库保持动态gcc -o demo demo.c -Wl,-Bstatic -lcurl -Wl,-Bdynamic \ -lssl -lcrypto -lz-Wl,-Bstatic告诉链接器从这个位置开始后面的库都用静态库-Wl,-Bdynamic又切回动态库模式。这样只有libcurl是静态的程序主体依然是动态链接体积不会膨胀得太过分。6.4 用ldd验证最终链接结果不管怎么链接最后都要用ldd验证一下ldd ./demo如果输出里还有libcurl.so说明它还是动态链接的如果输出里没有libcurl相关条目说明它已经静态编入二进制了。这个方法在任何分发程序前都应该跑一遍确认链接方式符合预期。7. 把源码安装的库用好环境变量、多版本共存与清理卸载拉通全流程之后还有一些和源码安装相关的进阶话题值得多说几句。7.1 PKG_CONFIG_PATH的作用前文提到pkg-config --cflags --libs libcurl可以输出编译参数。但如果你把库装到了一个非标准路径pkg-config可能查不到它因为pkg-config默认只在系统标准目录里搜索.pc文件。解决办法是设置PKG_CONFIG_PATH环境变量export PKG_CONFIG_PATH/usr/local/lib/pkgconfig:$PKG_CONFIG_PATHlibcurl源码安装后会在lib/pkgconfig目录下生成一个libcurl.pc文件。你可以用find确认一下这个文件的位置然后把对应目录加进PKG_CONFIG_PATH。这样各种构建工具只要调用pkg-config就能拿到正确的头文件路径和库路径。7.2 多版本共存的做法如果你在开发中需要同时用到多个版本的libcurl比如一个老项目锁定了老版本新项目想用新版本那么最稳妥的方案是分别用不同的--prefix安装比如./configure --prefix/opt/libcurl/7.x.x make make install然后在使用时分别指定CPPFLAGS、LDFLAGS和PKG_CONFIG_PATH。这个做法虽然笨但非常清晰不会因为覆盖安装把系统搞乱。有人图省事把新版直接装到/usr/local覆盖旧版结果老项目立刻编译不过这种教训我见过太多次。7.3 卸载源码安装的库源码安装的库卸载通常没有标准的uninstall命令因为make install之后系统里并没有一个安装记录来追踪文件清单。最靠谱的卸载方式其实是在configure阶段就留一手——用make uninstall试试看如果Makefile里没有uninstall目标那就只能靠--prefix目录来手工清理了。这也再次证明了选用独立prefix的价值。如果你把库装到/opt/libcurl卸载时直接删这个目录就完事了如果装到了/usr/local卸载时就得小心翼翼地从/usr/local/lib、/usr/local/include里逐一删除文件还容易误伤别的软件。7.4 编译选项的记录与复用最后一个建议每次编译安装开源库把configure的参数记录下来。可以写在部署文档里也可以写成一个简单的shell脚本存到项目目录下。我个人的习惯是建一个build.sh把configure、make、make install的完整命令放在里面注释里写明每个选项的理由。这样做最大的好处是半年后你要在另一台机器上搭同样的环境时不用再从错误中重新学习一遍。而且升级libcurl时只要把这个脚本里的版本号改掉重新跑一遍就行不至于出现这次编译的选项和上次不一样导致行为怪异的问题。8. 开源库通用流程的最后收尾不必迷信GUI工具写到这里整个libcurl源码包的流程已经走完了。其实你回头看会发现这套流程并不是libcurl特有的只要是一个遵循configure/make/make install标准的开源C库不管是libxml2、libevent还是zlib走的路子都一样解压、configure探测环境、make编译、make install安装、设置搜索路径、写代码时用-I和-L定位、运行时用ldconfig或LD_LIBRARY_PATH解决动态库查找。我最后想再分享一个个人的实操体会很多现代开发者在IDE和图形化工具的世界里待久了看到终端里一长串编译输出就发怵。但其实编译源码库这件事手工走一遍的价值远比装好一个库本身大——你会知道头文件、库文件、编译选项、链接选项、运行时路径这几件事是怎么协同工作的以后再遇到类似问题从现象倒推原因的速度会快很多。如果你第一次从源码编译就成功了那说明你的环境很干净如果失败了别急着怪库或者怪自己按报错信息的三个层次——编译期头文件、链接期库文件、运行期共享库——逐层排查大概率能在十分钟内定位问题。这也是我在这上面摔过几次之后总结出来的经验。