接手任何一个三方SDK，我做的第一件事永远是先扒它的底裤——搞清楚这个SDK到底依赖了哪些库。这不是洁癖，是血泪教训换来的习惯。你想想，编译链接都过了，代码也没写错，结果一运行程序弹窗告诉你“找不到xxx.dll”，或者Linux下直接给你一个“error while loading shared libraries”，这时候你才知道，SDK文档里写的“简单集成”四个字有多虚。
就拿最近的典型场景来说：一个Qt程序从开发机拷贝到另一台机器，明明把依赖库都拷过去了，目录结构一模一样，程序还是起不来。还有人在Ubuntu上灌了一个32位的SDK，运行时报一堆“cannot open shared object file”，一看就是32位库没装全。这些问题绕来绕去都指向同一个核心：你根本没摸清SDK的完整依赖链，只处理了表面那一层。
这篇不打算讲虚的，直接把我平时排查三方SDK依赖库的完整方法、常用工具、递归分析思路，以及那些文档里不会写的坑，一次性说清楚。适合正在跟SDK集成的兄弟们、做软件交付部署的同学，以及所有被“缺库”俩字折磨过的开发者。
1. 为什么必须查清楚三方SDK的依赖库
1.1 一个让人头疼的真实场景
想象一个经典得不能再经典的现场。你从厂商那边拿了一个example_sdk.dll，配套了一个example_sdk.lib（Windows）或者libexample_sdk.so（Linux），还有一个头文件。一切都按指南操作：头文件include进来了，导入库链接上了，程序编译通过，没报错。但把程序部署到一台干净的机器上，双击运行，立刻弹窗：“由于找不到libcurl.dll，无法继续执行代码”。
你心想：libcurl明明拷了啊。于是把libcurl.dll复制到exe旁边，再运行，好家伙，又弹窗说找不到libssl-3-x64.dll。再拷贝，再运行，又说找不到zlib1.dll。这种“打地鼠”式的补库操作，我相信所有做过软件交付的人都经历过。
为什么会出现这种连环缺库？因为三方SDK本身很少是孤立的。一个商业SDK，内部可能自带了对libcurl、OpenSSL、zlib、protobuf这些基础库的依赖，而这几家库之间还有互相依赖关系。你以为拷了SDK就完事，实际上SDK还在等它的小弟们到场。
1.2 依赖库分析到底解决什么问题
把依赖关系查清楚，解决的不止是“启动报错”这一件事。我总结下来，至少值四个应用场景。
第一是打包交付。你交付给客户的程序，能不能在对方机器上直接跑起来，取决于你给的依赖是否完整。多拷库不会坏事，少拷一个库就是事故。提前把SDK的完整依赖树拉出来，交付包该放什么就一清二楚。
第二是版本冲突排查。机器上可能已经有了系统自带的某个库，版本比SDK要求的低，或者不兼容。这时候你得知道SDK到底用哪个版本的依赖，才能决定是用系统库还是把SDK自带的库带过去做私有化。
第三是了解SDK的真实行为。三方SDK的营销材料吹得天花乱坠，说一句“纯原生、无外部依赖”，结果一查依赖树发现里面挂着几十个开源库，连OpenSSL都有。这种事在业内太常见了。依赖树分析能让你看清SDK用的是不是自己宣传的“完全自研”。
第四是供应链风险评估。你接了一个SDK，它里面引用了古老的zlib版本或者带已知CVE的OpenSSL，这个风险就传递到了你的产品上——不管你有没有直接使用那些接口。做安全检查的时候，这份依赖清单就是你最硬的一手证据。
1.3 先明确一个概念：运行时依赖不等于编译时依赖
这里必须澄清一个最容易混淆的点。链接器和运行器对“依赖”的理解不一样。
编译阶段，你只需要给链接器提供导入库（Windows的.lib）或动态库本身（Linux的.so），让链接器确认调用的符号存在。但编译通过只代表链接器找到了定义，不代表运行时动态加载器能找到。
到运行阶段，Windows的加载器会按照DLL搜索顺序去找动态库，Linux的动态链接器会扫LD_LIBRARY_PATH、缓存文件和系统目录。一旦找不到，程序就拒绝启动。所以你会发现，在开发机上编译好的程序，跑到别人机器上就崩——开发机上的依赖可能靠系统路径就能找到，但干净机器上没这套环境。
尤其要注意静态库。很多SDK在Windows下给的是.lib，如果这是静态导入库，那它内部依赖的其他三方库可能已经被“绑”进了某个.dll里，也可能需要你自己再带上一堆.dll。有一个判断技巧：用dumpbin /headers看导入库的Machine节，再打开.dll看导出符号，基本能确定.lib是不是只是壳。这个问题不搞清楚，后面全是在猜。
2. 分析依赖库的常用工具与核心原理
2.1 Windows平台：从dumpbin到Dependencies
Windows下查依赖，我推荐的第一个工具是dumpbin。它随Visual Studio自带，需要在“Developer Command Prompt”里执行，最简单的用法是：
dumpbin /dependencies example_sdk.dll输出会列出这个DLL的导入表，也就是它直接引用了哪些DLL。注意，它只显示“直接依赖”这一层，不会递归展开。如果你想看完整的间接依赖，需要手动对每一个依赖项再跑一次dumpbin。
dumpbin输出的末端还有一段函数符号列表，信息量比纯工具名称多得多。比如打开一个SDK的DLL，你可以直接看到它导入了CryptDecrypt、CertGetNameStringW这些函数，那这个SDK多半跟证书加解密有关系；看到curl_easy_perform，说明它内部在发HTTP请求。这相当于不花钱做了一次轻量级行为预判。
第二个强烈推荐的工具是Dependencies（原Dependency Walker的现代重制版，开源免费）。它用图形化方式展示DLL之间的依赖树，支持递归展开，还能高亮出缺失的模块。比在命令行里一层层dumpbin快得多。拿来检查“开发机能跑、新机器起不来”的问题，几乎是一看就知道缺哪个库。
第三个是Process Explorer（Sysinternals工具集）。有依赖在编译时根本没记录导表，靠着LoadLibrary在运行时按路径加载。这时候静态分析看不到，Process Explorer能实时显示进程当前加载的DLL清单。操作很简单：打开Process Explorer，找到目标进程，右键Properties，切到Image标签，里面就是它实际加载的所有模块。
2.2 Linux平台：ldd、readelf和objdump
Linux下最被滥用的命令就是ldd。
ldd libexample_sdk.so它会把依赖库递归解析出来，并且显示最终在系统里匹配到的路径，非常直观。但ldd有两个坑必须提醒。
一个坑是它是在当前环境里动态解析的，所以显示结果受运行环境搜索路径影响。在你机器上能解析到的库，在别人机器上可能找不到。ldd其实是一个包装脚本，本质上会调用动态链接器去模拟加载，它存在的正义是对的，但使用场景是“调当前环境”，不是“判断跨环境部署”。
另一个坑是ldd存在安全风险：对不可信的三方库执行ldd，理论上可能触发动态链接器执行构造好的代码。现在很多安全基线都要求用readelf替代ldd做静态分析。
readelf的用法是看动态段里的NEEDED条目：
readelf -d libexample_sdk.so | grep NEEDED这个输出同样只列“直接依赖”，干净、稳定、不递归，也不受环境变量影响。另一种等价的查法是用objdump：
objdump -p libexample_sdk.so | grep NEEDED两个工具的输出完全等价，选哪个顺手用哪个。
Linux依赖分析的正确姿势是做两层动作：第一层，用readelf看二进制自己声明的依赖；第二层，用ldd在当前环境里看可解析到的最终路径。前一层回答“它要什么”，后一层回答“当前机器能给它什么”。
另外补充一个技巧，查某个动态库到底导出了哪些符号，用：
nm -D libexample_sdk.so配合这个结果，你可以判断SDK是否依赖了某个特定版本的符号接口，比如某个加解密函数。
2.3 运行时追踪法：真正权威的答案
前面说的静态分析是基于PE/ELF文件里的导入表，能覆盖绝大多数情况。但三方SDK的世界里永远不缺脏活：有的SDK用GetProcAddress拿到函数指针调用，有的在配置文件里指定插件目录运行时才LoadLibrary，还有的会在运行到某个分支时才加载某个依赖库。静态分析对这类“按需加载”是无能为力的。
所以遇到那种怎么看都找不到“问题库”的情况，就直接上运行时追踪。
Windows下我用API Monitor或者Process Monitor。Process Monitor先配置过滤条件，填上进程路径，然后再看记录里的LoadImage事件，就能看到进程每次尝试加载DLL的完整路径列表。最妙的是，它连加载失败的动作也会记录，如果你看到一个加载记录后面跟着NAME NOT FOUND，那你立刻就能锁定是哪个路径下的哪个DLL没找到。
Linux下的运行时追踪就简单奔放了。动态链接器支持调试输出，设置环境变量就能把搜索过程打出来：
LD_DEBUG=libs ./your_program输出里会逐条打印链接器去哪些路径找过、找到了哪个版本、加载了哪个库。搜索路径里有一堆trying file=/usr/lib/x86_64-linux-gnu/libxxx.so.6类似的信息，一目了然。
如果你要看程序自己触发的动态加载调用，就配合strace：
strace -f -e trace=openat,open ./your_program 2>&1 | grep -E "\.so|\.dll"它能捕获所有成功或失败的加载尝试，把整个依赖的“实际运行图”描出来。这个方法唯一的缺点是比较慢，适合静态分析搞不定的时候用来兜底。
3. 实操：分析一个Qt三方SDK的依赖关系
3.1 先用ldd/dumpbin拿到表面依赖
拿一个典型的Qt场景当例子。假设你拿到一个thirdparty_qt_sdk.dll，它是基于Qt 5.15.2编译的SDK，同时还依赖网络模块和一个本地加密库。在Windows下第一步永远是：
dumpbin /dependencies thirdparty_qt_sdk.dll输出大概长这样：
Dump of file thirdparty_qt_sdk.dll File Type: DLL Image has the following dependencies: Qt5Core.dll Qt5Network.dll Qt5Gui.dll libcrypto-3-x64.dll KERNEL32.dll USER32.dll这里头有一个关键信息：除了Windows系统DLL之外，它还直接依赖了Qt5Core、Qt5Network、Qt5Gui，以及OpenSSL的libcrypto库。这就意味着，你把thirdparty_qt_sdk.dll丢进exe目录还不够，Qt运行库和OpenSSL的DLL都得跟着。
Linux下同理，直接：
readelf -d libthirdparty_qt_sdk.so | grep NEEDED你会看到：
0x0000000000000001 (NEEDED) Shared library: [libQt5Core.so.5] 0x0000000000000001 (NEEDED) Shared library: [libQt5Network.so.5] 0x0000000000000001 (NEEDED) Shared library: [libQt5Gui.so.5] 0x0000000000000001 (NEEDED) Shared library: [libssl.so.3]这些都是直接依赖。拿到这层数据，别急着打包，后面几层才是坑。
3.2 为什么拷贝了依赖库还是跑不起来
这个问题几乎人人都会碰到：我明明把Qt5Core.dll、依赖库都拷到exe同目录了，为什么程序还是起不来？这里我按照排查经验的频率排个序，原因不外乎下面四类。
第一类，也是最常见的：依赖库的传递依赖缺失。Qt5Core.dll本身还要依赖其他基础库，比如ICU、zlib、libpng等等。你拷了Qt5Core.dll，但它依赖的ICU数据没拷过去，那加载照样失败。这类问题的排查方法就是把dumpbin /dependencies递归一层层做下去，直到尽头。
第二类，你确认系统里存在同名库，但拷过去的版本不对。Windows下有一个典型的坑：系统目录里也有一个libssl或者libcrypto，但版本不是SDK要求的那个。程序启动时按搜索顺序先去exe同目录找，你拷对了就没事；一旦拷错了，加载进去的API对不上号，程序要么直接崩溃，要么跑到某个函数就莫名挂掉。我见过最离谱的是把32位的Qt5Core.dll拷到了64位程序目录里，加载器直接报“%1 不是有效的 Win32 应用程序”，排查了半天才发现位数不对。
第三类是VC运行库缺失。如果你的SDK是用Visual Studio编译的，它链接了MSVC的运行时库，那么目标机器上得有相应的msvcp140.dll、vcruntime140.dll、vcruntime140_1.dll。机器如果没有装过Visual C++ Redistributable，即使你拷了SDK本体也没用。顺便说一句，解决这类问题最简单的方法不是手工拷贝，而是把对应的Redistributable安装包含进交付物里。
第四类，也是最隐蔽的：Qt平台插件缺失。Qt程序在启动时会动态加载platforms/qwindows.dll这个插件，这个加载动作不走常规依赖表，不在dumpbin输出里。你可能把所有依赖库都带齐了，程序还是报“could not find or load the Qt platform plugin windows”。这是Qt应用部署时最经典的一个坑。三方SDK虽然不直接暴露Qt插件，但内部创建了QApplication的话，它一定也需要这套插件。
3.3 递归解析的一层：依赖的依赖
直系依赖只是进门，真正的分析主体是递归层。你的SDK依赖了libcurl.dll，而libcurl.dll自己又依赖libssl-3-x64.dll和zlib1.dll；libssl-3-x64.dll可能还会依赖libcrypto-3-x64.dll。这个链条必须一层层走下去，直到所有节点都是系统库为止。
我平时习惯写一个小循环来做这个事。Linux下最省事的方式：
function dep_tree() { for lib in "$@"; do readelf -d "$lib" 2>/dev/null | grep NEEDED | awk '{print $NF}' done } dep_tree libthirdparty_qt_sdk.so | sort -u意思就是先读出libthirdparty_qt_sdk.so的NEEDED，把所有依赖项排重。然后对每一个依赖项再次调用readelf。循环条件是以“没有新的、未分析过的库被加入”作为终止标准。名义上整套代码不超过十行，但我实际用下来很稳。
这里有个细节值得专门说明：NEEDED条目里有时候看到的是带版本号的动态库名（比如libssl.so.3），而磁盘上的文件往往是普通链接名（比如libssl.so）。判断是否需要把软链接一起拷走，看部署目标的发行版即可。最稳妥的做法是用apt-cache depends或者dpkg -S去反查这个文件是哪个包提供的，直接给目标机器装对应版本包。
Windows下没有现成的循环命令，我一般直接靠Dependencies工具递归展开。这个软件好用就好用在它把间接依赖、缺失项直接标成红色，不用自己一层层翻dumpbin。
3.4 插件与动态加载：最隐蔽的坑
依赖分析最容易被忽略的部分，不是.dll/.so文件，而是“运行到中途才发生的加载”。三方SDK在这个问题上花样百出。
第一种是绝对路径硬编码。SDK内部写死了某个插件目录，比如C:\Program Files\Common Files\Alchemy\Plugins\xxx.dll，部署到非默认路径就加载失败。这种问题静态分析完全看不到，只能靠Process Monitor或者LD_DEBUG=libs追踪实际加载行为才抓得到。
第二种是插件机制的整体目录依赖。还是拿Qt讲，platforms/目录下有几个插件，imageformats/下有一堆图像格式插件。很多SDK调用了图像处理能力，加载imageformats目录里的qjpeg.dll时，搜索引擎按默认规则去找，但如果这个目录跟你exe的相对关系不对，它就找不到。这也是为什么Qt官方提供了windeployqt工具，它做的事情就是顺着二进制依赖树把Qt运行库、插件、翻译文件统统拉到目标目录。
第三种是“可选依赖”的缺失。某些SDK的接口会检查某个库是否存在，检查不到就降级，但降级后的状态不安全，甚至会在特定调用路径上崩溃。这种比直接缺库更恶心，因为程序能起，但某个业务一执行就挂。我之前遇到过SDK依赖一个老版本zlib1.dll做解压，目标机器上恰好有系统自带的zlib，但符号版本过旧，SDK拿老接口去调，结果在一个高版本符号上调崩了。
所以在分析依赖树的时候，永远不要停在“静态能检查到的直接依赖”上，应该把手伸到“动态加载”这个层面。Windows用Process Monitor和Process Explorer双管齐下，Linux用LD_DEBUG和strace组合拳，把运行时行为样本采集下来，问题才漏不掉。
4. 实战记录：从“缺库”到“依赖树”的完整排查
4.1 一次典型的“缺DLL”排查
用一次真实经过复刻的记录来走一遍完整流程。
场景是这样的：有个内部工具，基于某个三方SDK写的，开发机上一切正常。交付到客户虚拟机，虚拟机干净得连Visual C++ Redistributable都没有。双击exe，抬出“由于找不到msvcp140.dll，无法继续执行代码”。
排查步骤其实很固定，但每一步都有讲究。
第一步，用dumpbin /dependencies看exe和SDK的依赖表，发现exe直接依赖了SDK的dll和Qt5Core.dll，但SDK的依赖表里没有列出msvcp140.dll这个条目——为什么？因为MSVC运行时库在编译时默认采用动态链接方式，这个依赖关系是编译器注入到exe的导入表里的，不经过SDK。换句话说，exe本身依赖了MSVC Runtime，但SDK的dll没有把这层依赖显式传给客户机。
第二步是确认搜索路径。在干净虚拟机上，msvcp140.dll应该放在系统目录C:\Windows\System32或者exe同目录。因为修改系统目录不现实，交付方案是把这三个运行库文件直接放进exe同目录。这里有一条铁律：Windows的DLL搜索顺序是先exe目录，再系统目录，再PATH路径。所以把MSVC运行库放进exe同目录是合法且稳妥的。
第三步，规避“带库跑”的潜在风险。我建议的最好做法不是手动拷贝几个DLL，而是把Visual C++ Redistributable安装包放进安装脚本里让客户静默安装。这样不仅解决msvcp140.dll，连vcruntime140.dll、vcruntime140_1.dll这些一个不漏，还避免了一个极隐蔽的坑——拷贝的DLL版本如果跟系统补丁冲突，反而会出现奇怪的崩溃。
4.2 当三方SDK是32位时：Ubuntu与库依赖
有一个热度很高的具体话题：Ubuntu下装了Steam这类32位应用，结果系统死活报缺库，甚至有人拿着32位SDK去Linux下做集成，报错报出一大串error while loading shared libraries。这其实是Linux依赖库里一个非常经典的特殊场景：32位与64位库的并存问题。
搞清楚一件事：64位的Ubuntu系统可以运行32位程序，但动态链接器在加载32位ELF文件时，只会去32位的库路径找，也就是/lib/i386-linux-gnu。系统默认如果没有开启多架构支持，/lib/i386-linux-gnu这个目录里是空的，那自然什么都找不到。
分析步骤也应该是固定的。
先确认目标文件确实是32位：
file libexample_sdk_x86.so输出里会明确标注ELF 32-bit LSB shared object。看到“32-bit”两个字，就直接进入多架构排查模式。
然后用readelf -d看它的NEEDED条目，比如需要libc.so.6、libX11.so.6、libGL.so.1这些。但因为系统当前没有32位库，readelf本身不会报错，它只是列出名称。接着用ldd在当前环境里看解析结果，几乎每一个条目都会挂上“not found”。
解决办法是启用32位架构支持并安装对应库。Debian/Ubuntu系的标准操作是：
sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install libc6:i386 libx11-6:i386 libgl1:i386这里有几个坑要特别提醒。一是必须apt-get update刷新索引，否则安装任何i386包都会提示找不到。二是不要试图一次性把列出来的所有NEEDED库都装上，先用ldd跑一遍，它会明确输出每个库的状态，缺哪个装哪个，省事还不容易出问题。三是如果SDK依赖的某个库只有64位版本、没有i386版，你装再多东西都没用，这种情况要么找厂商要32位版本，要么让整条链路切换成64位。
这个场景也侧面说明了一个经验：拿到一个Linux SDK，第一反应先file一把，确认架构位数，再谈依赖分析。架构不一致导致的问题，静态依赖工具一概救不了你。
4.3 把依赖清单固化下来
排查分析做完了，掌握了完整的依赖树，别用完就忘了，一定要把结果固化下来，变成自己项目的长期资产。
我一般的做法是在项目里建一个third_party_deps.md或者DEPENDENCIES.md，里面用表格把每一层依赖、版本、来源、许可证全部列清楚。举个格式例子：
| 库名 | 依赖方 | 版本要求 | 来源/包 | 备注 |
|---|---|---|---|---|
| Qt5Core.dll | thirdparty_qt_sdk.dll | 5.15.2 | windeployqt | 含plugins/platforms 必须同目录 |
| libcurl.dll | thirdparty_qt_sdk.dll | 7.80.0 | SDK自带 | 递归依赖libssl |
| libssl-3-x64.dll | libcurl.dll | 3.x | SDK自带 | OpenSSL 3.x |
| msvcp140.dll | 本程序exe | Visual Studio 2019 | Redistributable | 建议安装器统一安装 |
这个表的价值在什么地方？交付一个新版本的时候，拿表和新的依赖树对着跑一遍，很快能发现哪里多引入了一个库、哪里少了一个库。排查历史问题时，这个表就是第一排查参考，省得重新把流程走一遍。
Qt项目还有个顺手的办法，用windeployqt的JSON输出：
windeployqt --dump-json your_program.exe > deps.json它会输出你的程序、依赖库以及插件列表，虽然不是100%精确的三方SDK递归依赖，但Qt运行库那部分基本不丢。剩下的非Qt依赖，再用dumpbin或Dependencies补查一遍即可。
5. 常见问题速查表与续坑经验
5.1 常见报错与对策
我把实际排查中碰到的高频问题整理成一张速查表，按出现频率排序。对照着看，能省下不少排查时间。
| 现象 | 大概率原因 | 排查方向 |
|---|---|---|
| Windows下报“找不到xxx.dll” | 直接依赖缺失或搜索路径不对 | 用dumpbin查exe导入表，确认被依赖库是否存在；确认目标机器的DLL搜索顺序 |
| Linux下报“error while loading shared libraries” | 动态库没有加入搜索路径或不存在 | ldd定位具体缺失库，LD_LIBRARY_PATH或写入/etc/ld.so.conf.d/ |
| “%1 不是有效的 Win32 应用程序” | 架构位数不匹配 | file检查exe和dll位数，全部统一到x64 |
| Qt程序报“could not find the Qt platform plugin” | Qt插件目录缺失 | 用windeployqt部署完整Qt运行时，确认platforms/目录与exe的相对位置 |
| 同一依赖库出现了多个版本，行为异常 | 版本冲突 | 优先使用exe同目录私有化部署，避免混用系统目录库 |
| 32位Linux程序缺一堆库 | 系统没开i386多架构 | dpkg --add-architecture i386 后安装i386库 |
| 程序能起，但某个功能突然崩溃 | 运行的库版本与编译时接口不一致 | 用nm -D对比编译时和运行时符号版本 |
还有一个容易被忽略的：很多三方SDK的核心文件并不只有你直接链接的那一个DLL/so。比如加密狗的SDK还带了一堆驱动程序和后台服务，Qt的SDK会附带插件目录。这些不属于“依赖库”范畴，但缺失时的表现跟缺库一模一样。所以排查时不仅看动态库依赖，还要看SDK的安装目录结构里有没有额外的子模块没部署到位。
5.2 几个值得养成的习惯
这些习惯不是某一次排查总结出来的，是我踩了无数坑之后固化下来的“反脆弱”流程。
第一个习惯是拿到SDK的第一天就先跑依赖分析，而不是等到集成快完成才开始。一个SDK背后到底带了多少依赖，直接影响你这个项目的交付形态。如果它在Linux下需要三个特定的系统库，你就要提前确定目标机器能不能满足，满足不了就要调整交付方案，而不是等客户现场炸锅后再补救。
第二个习惯是永远不要依赖目标机器的全局环境。如果SDK自带了一版动态库，尽量把它放到exe同目录做私有化部署。Windows的DLL搜索顺序本身就优先exe目录，这个机制你绕过了反而容易出问题。Linux下的做法是设置LD_LIBRARY_PATH，或者在编译时通过RPATH指到私有目录。两个平台下的目标一致：让程序只在自己可控的目录里找依赖，不跟系统里的同名库发生冲突。
第三个习惯是记录构建环境和工具链版本。很多情况下，开发机能跑、新机器不能跑，根本原因是构建时链接了某个开发环境独有的库，而那个库没有进入交付物。所以记录依赖分析结果时，一定要把构建机的CMake版本、编译器版本、Qt版本、SDK版本一起记下来。等排查问题的时候，这份记录能直接帮助你判断到底是不是环境差异导致的兼容性问题。
第四个习惯是使用隔离环境验证交付物。Windows上开一台干净的虚拟机，Linux上用Docker跑一个最小镜像，把程序丢进去，直接看能不能运行。这个验证五分钟就能完成，却能把“缺库”这个最大的不确定性提前暴露掉。
5.3 从依赖分析延伸出来的检查清单
最后说一个可以持续积累的经验，把依赖分析从“救火”变成“日常体检”。
我现在每集成一个三方SDK，都会顺手生成一份依赖检查清单，包含四个固定动作。第一，确认SDK的架构位数和主目标平台，排除最基础的错配；第二，用dumpbin/readelf拿直接依赖列表；第三，用递归方法拿到完整依赖树，标记出所有非系统库节点；第四，做一次运行时追踪验证，确保没有隐藏的动态加载依赖。这四个动作做完了，SDK的依赖画像基本不会有大的遗漏。
这套方法不仅能用在三方SDK上，也能用在排查自己团队写的老代码上。很多老项目的构建脚本里堆了一堆历史遗留的依赖，早就没人说得清为什么还需要它们。用同样的工具分析一遍，再把没用的依赖顺手清理掉，交付包能瘦一大圈，启动速度也会有肉眼可见的提升。
我个人的体会是，依赖分析这个活儿，看起来是个手艺活，其实核心就是三个字：别犯懒。一次性把依赖树做完整，后面能避免无数个半夜救火的苦逼夜晚。每次拿到新SDK，先花十来分钟把家底盘一遍，这笔时间投资是绝对不会亏的。
