简介：面向在 Ubuntu 22.04、GCC 11.4 环境下搭建 WonderTrader 量化交易开发环境的 C++ 开发者，这份依赖库集中整理了 Boost 等第三方组件所需的头文件依赖。WonderTrader 涉及多模块协同，常规搭建需逐一处理外部依赖，版本不匹配或环境差异常导致 CMake 配置失败；使用该依赖包可大幅降低这类成本。压缩包共 2000 个文件，其中 1856 个 hpp、144 个 h，大小仅 14.5MB，绝大多数为模板头文件与接口声明，适合直接并入工程编译路径；已有 238 人学习/下载。作者同时给出 CMakeLists.txt 的修改思路：通过设置 MyDependsGcc 环境变量指定依赖目录，替换原有硬编码 /home/mydeps，并在编译输出中同步显示依赖路径，方便不同机器快速复用。包内头文件涵盖格式化输出、时间处理、文档解析、指针与编码等常用模块，对需要快速跑通 WonderTrader 构建流程、减少环境配置时间的中高级 C++ 开发者，具有直接参考价值。
1. WonderTrader 依赖库：从编译通过到换台机器就崩，问题出在哪
做量化交易的同行八成遇到过这种场景：本地把 WonderTrader 编译得妥妥当当，回测跑得飞起，兴冲冲把程序连同几个看着像依赖的 DLL 一起拷到服务器或同事机器上，双击一运行，要么弹窗提示“找不到 VCRUNTIME140.dll”，要么 QT 程序直接报“应用程序无法正常启动 0xc000007b”。这时候你会开始怀疑人生：依赖库明明都拷了，怎么还是不能运行？WonderTrader 作为一套 C++ 写的开源交易框架，编译产物涉及编译器运行时、第三方库（boost、mysql-connector、libcurl）、Qt 运行库三大类依赖，这三类依赖的部署逻辑完全不同。这篇文章只干一件事：把这些依赖从“拷过去能用”往上推一层，讲清楚 WonderTrader 依赖库的本质、最小依赖集的判断方法、以及“拷了依赖库还是不能跑”的完整排查路径。新手照着做能半小时内解决部署问题，熟手也能在这里确认几个平时容易忽略的边界。
2. WonderTrader 依赖库到底包含什么：三类运行时缺一不可
2.1 编译器运行时依赖：VCRUNTIME 与 MSVC 版本强绑定
WonderTrader 在 Windows 下通常用 Visual Studio 编译，产出的 exe 和 DLL 会链接到 MSVC 运行时库。这不是 WonderTrader 自己的代码，而是微软提供的 C/C++ 运行库，文件名常见为 VCRUNTIME140.dll、MSVCP140.dll、concrt140.dll 等。很多人以为这是“系统自带的”，其实 Windows 10/11 原版系统并不内置新版 VC++ 运行库，需要单独安装。
判断方法很简单：用 Dependency Walker 或 Dependencies（新一代工具）打开 WonderTrader.exe，查看导入表里是否有 VCRUNTIME140.dll。如果有，对应的 VC++ Redistributable 版本必须在目标机器上存在。这里有个容易踩的坑：编译用的 VS2019 和 VS2022 生成的运行时库文件虽然都叫 VCRUNTIME140.dll，但内部版本号不同，VS2022 编译的产物在只有 VS2019 运行库的机器上依然会报错。所以最稳妥的做法不是拷贝 DLL，而是直接静默安装对应版本的 vc_redist.x64.exe。
提示：不要手工把 VCRUNTIME140.dll 拷到 exe 同目录。虽然这个做法“看起来能用”，但不定哪天系统补丁更新后版本冲突，你的程序就成玄学故障了。正确做法是安装 VC++ Redistributable，让系统级的 DLL 解析机制管理版本。
再看一下实际排查中怎么确认链接类型。在 Visual Studio 里，项目属性 C/C++ -> 代码生成 -> 运行库 有四个选项：多线程(/MT)、多线程调试(/MTd)、多线程 DLL(/MD)、多线程调试 DLL(/MDd)。WonderTrader 官方预编译包通常用 /MD 编译，意味着依赖 VC 运行时 DLL；如果你自己从源码编译，改成 /MT 静态链接运行时，exe 体积会大几十 KB 到几百 KB，但目标机器上就不再需要装 VC++ Redistributable。量化部署场景下，我一般建议统一用 /MT 静态链接，少一个变量。
2.2 第三方依赖库：boost、mysql-connector、libcurl 的版本匹配
WonderTrader 的 C++ 核心依赖了 boost（用于文件系统、线程、日期时间等）、libcurl（HTTP 请求）、以及可选的高性能 mysql-connector-cpp 或 redis 客户端。这些依赖库在编译 WonderTrader 时被链入，但链接方式决定了它们是否成为运行期依赖。
如果 WonderTrader 链接的是这些库的静态版本（.a 或 .lib），那运行时不额外需要 DLL；如果是动态链接（.dll），则目标机器必须存在对应版本的 DLL。实际情况是：WonderTrader 官方预编译包的 bin 目录里通常带着 libcurl.dll、libmysql.dll、boost_*.dll 等文件，但这些 DLL 之间存在内部依赖关系。比如 libcurl.dll 可能依赖 openssl 的 libssl-3-x64.dll 和 libcrypto-3-x64.dll——这层“依赖的依赖”就是问题高发区。
某次我把 bin 目录里的所有 DLL 都拷到一台新装的 Windows Server 2019 上，运行回测程序，结果报错提示无法定位程序输入点于 libcrypto-3-x64.dll。查下来原因是：我拷的 libcurl 是 openssl 1.1 编译的，而 bin 目录里却放了一份 openssl 3.0 的 libcrypto——版本错配，程序根本起不来。
所以拷第三库依赖有两个检查点：一是版本号一致，二是位数一致（x64 程序必须配 x64 DLL，混进 x86 的 DLL 会报 0xc000007b）。判断 DLL 位数可以用工具 readelf（MinGW 环境）或直接用 Visual Studio 自带的 dumpbin 命令：
# 在 Visual Studio Developer Command Prompt 里执行 dumpbin /headers C:\path\to\libcurl.dll | findstr "machine" # 输出 x64 则位数正确；输出 x86 则说明这是 32 位 DLL这个命令在排查 0xc000007b 报错时是首选手段——这个错误码 90% 的情况是 x64 程序加载了 x86 依赖，或者反过来。
2.3 Qt 运行库依赖：windeployqt 和“拷了依赖却不行”的高频坑
WonderTrader 的界面部分（如果用了 WonderTrader UI 或内置的 Qt 看盘端）依赖 Qt 运行库。Qt 的部署机制比普通 DLL 复杂得多，它不只是几个 DLL 的事，还涉及 plugins、qml、translations 目录和平台插件（如 platforms/qwindows.dll）。
这里就是开头那段“qt程序考到其他目录且考了依赖库为什么还是不能运行”的最典型答案：你拷了 Qt 的 DLL，但没拷 platforms 目录，Qt 程序在 main 函数创建 QApplication 时会去 exe 同级的 platforms 目录里找 qwindows.dll，找不到直接崩，而且连错误弹窗都未必有，只在 stderr 输出一行“qt.qpa.plugin: Could not find the Qt platform plugin 'windows' in ''”。
无界面跑 WonderTrader 策略是可以完全绕开 Qt 的——如果你的部署环境只需要回测引擎和实盘交易接口，压根不用装 Qt。但如果你用了附属的图表界面或手工交易终端，Qt 部署就没法回避。正确做法是使用 Qt 自带的部署工具 windeployqt.exe，而不是手工挑 DLL 拷：
# 假设 Qt 安装在 C:\Qt\6.5.3\msvc2019_64 # 在 Release 构建完成后执行 C:\Qt\6.5.3\msvc2019_64\bin\windeployqt.exe --release --no-translations --no-opengl-sw C:\deploy\WonderTrader.exewindeployqt 会自动拷贝 Qt6Core.dll、Qt6Gui.dll、Qt6Widgets.dll、platforms/qwindows.dll、styles 目录等必要文件。参数说明：--no-translations 表示跳过多语言翻译文件（用不到就省体积）；--no-opengl-sw 表示不包含软件渲染的 OpenGL 库；--release 匹配你的编译模式。执行完看一眼输出目录，windeployqt 会在当前目录生成 platforms、styles 等子目录，这些子目录里的 DLL 才是 Qt 插件，必须和 exe 保持相对路径关系——它们是按相对路径查找的，这就是“拷了依赖库但目录结构不对所以不能运行”的深层原因。
3. 用 dumpbin 和 Dependencies 定位 WonderTrader 的完整依赖清单
3.1 三步生成依赖树：从 exe 出发逐层展开
排查依赖问题不能靠猜。第一步先拿到 WonderTrader.exe 的直接依赖清单，第二步检查每个依赖 DLL 的自身依赖，第三步对比目标机器缺失项。Windows 上最实用的工具是老牌的 Dependency Walker（x64 版本）和新出的微软官方维护的 Dependencies（开源，GitHub 项目名是 dependencies）。
用命令行做快速检查其实更顺手。Visual Studio 自带的 dumpbin 除了看 DLL 位数，还能列出导入表：
# 查看 WonderTrader.exe 导入了哪些 DLL 和函数 dumpbin /imports C:\WonderTrader\bin\WonderTrader.exe > imports.txt # 查看某个 DLL 依赖了哪些其他 DLL dumpbin /dependents C:\WonderTrader\bin\libcurl.dll > dependents.txtimports.txt 和 dependents.txt 就是排查的依据。先打开 imports.txt 看前几十行，里面列出的 DLL 是直接依赖；再对每个直接依赖跑一次 /dependents，就能拿到二级依赖。手工做很繁琐，所以如果目标机器有网，建议直接在目标机器装上 Dependencies 工具，把 WonderTrader.exe 拖进去，它能自动递归展开完整依赖树，还能标红缺失模块。
这里要提醒一个边界：dumpbin 显示的依赖是“编译链接时记录的导入表”，如果 WonderTrader 用 LoadLibrary 延迟动态加载某个插件 DLL（比如加载自定义的指标库），就不会出现在静态导入表里。这类依赖只能靠运行时日志或 Process Monitor 抓取。
3.2 整理最小部署文件集：不是把所有 DLL 都拷过去
拿到依赖树后，下一步是判断“哪些文件需要跟着程序走，哪些文件应该用系统级安装解决”。我的分类原则是：
第一类，编译器运行时（VCRUNTIME140.dll 等）。不拷，直接装 VC++ Redistributable 安装包，原因前面说了，避免系统级版本冲突。第二类，第三方库 DLL（libcurl、openssl、mysql-connector）。跟程序走，放在 exe 同目录或专门的 libs 子目录并配置 PATH。第三类，Qt 插件的 DLL。跟程序走，且目录结构必须维持（platforms 在 exe 同级目录下）。第四类，WonderTrader 自己的模块（WtDtLib.dll、WtExecApi.dll 等）。跟程序走，这些是框架内部运行时依赖。
如果有装 Redis 客户端或 MySQL 客户端的支持，还需要确认目标机器上是否存在对应的服务端组件——比如连接 MySQL 需要 mysql.dll，但连接 Redis 走 hiredis 静态链接的话就不需要额外 DLL。
实操中我一般把部署目录整理成这样的结构：
deploy/ ├── WonderTrader.exe # 主程序 ├── config.yaml # 策略配置 ├── WtDtLib.dll # 数据模块 ├── WtExecApi.dll # 交易接口模块 ├── libcurl.dll # HTTP 客户端 ├── libssl-3-x64.dll # openssl 依赖 ├── libcrypto-3-x64.dll # openssl 依赖 ├── platforms/qwindows.dll # Qt 平台插件 └── styles/qmodernstyle.dll # Qt 样式3.3 目标机器上的验证命令：复制后 5 分钟跑通清单
复制到目标机器后，不要直接双击 exe 试运气。按顺序做三个验证：
首先是命令行运行主程序，把错误输出打到终端：
# 在 deploy 目录下打开 cmd set PATH=%~dp0;%PATH% WonderTrader.exe --help > startup.log 2>&1如果 exe 缺依赖，Windows 加载器会弹窗或向 stderr 写错误，startup.log 里能看到线索。正常情况下 --help 会打印版本和用法说明，然后退出，这证明主程序能加载全部依赖。
其次是验证 Qt 插件路径：
# 设置 Qt 插件的查找路径（如果不想用相对目录的话） set QT_PLUGIN_PATH=%cd%\plugins # Qt 插件目录一般在 deploy\plugins 而不是 platforms 同级这一步是玄学高发区。windeployqt 默认生成的结构是 exe 同级目录下有 platforms/，如果手动整理过目录，Qt 会按“exe 所在目录/platforms”查找，也支持 QT_PLUGIN_PATH 环境变量重定向。检查环境变量值和实际目录是否一致，别在这上面翻车。
4. 用 Process Monitor 和日志验证运行期加载路径
4.1 抓取 DLL 加载记录：Process Monitor 三步过滤法
如果你找不到缺失的 DLL，用 Process Monitor 抓运行期加载路径，这是 Windows 部署排查的终极手段。下载 Procmon.exe，设置过滤条件为“进程名包含 WonderTrader”，然后启动程序，过程中 Procmon 会记录每一个文件访问操作，包括失败的 DLL 查找路径。
操作步骤是这样的：先打开 Procmon，在 Filter 菜单里设置“Process Name is WonderTrader.exe”，然后点 Capture 按钮暂停捕获；接着双击运行 WonderTrader.exe 让它崩溃；停止捕获后，在结果列表里搜索"NAME NOT FOUND"的结果——那些就是失败的 DLL 查找记录。每条记录都有完整的路径列，比如 C:\Windows\System32\VCRUNTIME140.dll 显示 NAME NOT FOUND，说明系统目录里没有这个文件，这就是根因。
Process Monitor 还有一个厉害用法：看 DLL 的实际加载路径。有时候依赖文件存在，但加载的是错误版本（比如从系统目录加载了老版本，而不是你放在 exe 目录的新版本），这也能从 Procmon 记录里看到，文件路径列会清楚写出加载的是哪个目录下的哪份文件。
4.2 WonderTrader 自身模块加载逻辑：工作目录与 PATH 的优先级
WonderTrader 的模块加载机制沿用 Windows 标准的 DLL 搜索顺序：exe 所在目录 -> 系统目录 -> 当前工作目录 -> PATH 环境变量中的目录。这里最容易翻车的是“当前工作目录不等于 exe 所在目录”。如果你在别的目录下通过绝对路径或快捷方式启动 WonderTrader.exe，Windows 把当前工作目录排在 exe 目录之后，但如果 exe 目录里缺 DLL，就会退回工作目录找——找了也可能找到旧版本。
所以部署要养成两个习惯：第一，任何时候都用相对路径启动：cd /d C:\deploy && WonderTrader.exe；第二，所有 DLL 都放 exe 同级目录，不要在 exe 目录里再套一层 bin 子目录（除非你用 PATH 环境变量指向它）。WonderTrader 的 WtExe 模块在加载策略 DLL 时会按相对路径 .\plugins\ 查找，这个目录也不能缺席。
4.3 日志优先原则：先看 WtLog 再动手
WonderTrader 自己的日志系统会输出核心模块的加载过程。启动时如果依赖缺失，日志里会出现“load library failed”或“cannot find module”字样。这个日志默认在运行目录的 logs\ 子目录下，按日期生成文件。排错顺序应该是：先看 WonderTrader 日志 -> 再看 Windows 事件查看器（应用程序日志，记录模块加载失败的 Exception Code）-> 再上 Procmon。前两步能解决的就不用走最后一步。
养成这个顺序能省大量时间。有一次我花了一整天才定位到一个问题：某个环境变量在系统设置里存在，但通过服务方式启动时环境变量不生效，导致依赖库加载路径错误。这种问题用日志几分钟就能看出来是加载失败，而不是程序逻辑 bug。
5. WonderTrader 依赖库部署避坑：换目录不能运行的六个常见原因
5.1 拷了依赖库还是报 0xc000007b：x86 与 x64 混入
现象：程序启动直接弹窗“应用程序无法正常启动 0xc000007b”，控制台没有任何输出。
原因：这个错误码的本质是 Windows 加载器尝试解析 DLL 的导出函数时，发现机器码位数不匹配。最常见的是 64 位主程序加载了 32 位依赖库，或者反过来。WonderTrader 官方预编译包是 x64 的，但如果你的 QT 插件目录里混进了一份 x86 的 qwindows.dll（比如从 32 位安装包里解压出来的），就会触发这个错误。
解决：用前面给的 dumpbin /headers 命令检查所有 DLL 的 machine 类型，确保都是 x64。批量检查最方便：
# 在 deploy 目录批量检查 DLL 位数 for %f in (*.dll) do @dumpbin /headers %f 2>nul | findstr /c:"machine" | findstr /v "x86" && echo %f OK这里要注意：dumpbin 输出里 "machine (x64)" 是正常的，如果你看到 "machine (x86)"，对应的 DLL 就是 32 位的，需要替换。排除混入的 x86 DLL 后，0xc000007b 基本能解决。
5.2 拷了 Qt DLL 但没拷 platforms 目录，程序闪退无日志
现象：Qt 界面程序启动后一闪而过，没有任何错误弹窗，WonderTrader 日志也干干净净。
原因：QApplication 初始化需要请求平台插件。Windows 平台插件默认从 exe 所在目录的 platforms\qwindows.dll 加载。你只拷了 Qt6Core.dll 和 Qt6Gui.dll，但没带 platforms 目录，Qt 在运行时才发现找不到插件，直接 abort。因为 Qt 插件加载失败默认只打 stderr，而 Windows 图形程序没有控制台，你根本看不到错误输出。
解决：最好的办法是重新跑一次 windeployqt 生成完整部署目录。如果只想手工补，在 exe 同级创建 platforms\ 目录，把 qwindows.dll 放进去。另外可以在 main.cpp 里加一行调试输出（在公司项目里这是血泪经验）：qputenv("QT_DEBUG_PLUGINS", "1")，这样启动时 Qt 会把插件扫描过程和加载失败原因打到 stderr 或调试输出窗口。
5.3 依赖库版本齐全但程序还是提示缺入口点
现象：程序启动报“无法定位程序输入点 Xxx 于动态链接库 YYY.dll”。
原因：你有了 YYY.dll，但版本不对。这个函数是较新版本才引入的，而系统里的 YYY.dll 是旧版本。运行时序排在前面的 DLL 会把高版本的 YYY.dll 加载进内存，你的程序找到的入口点是旧版本的，函数不存在就报这个错。典型场景是 libcurl.dll 依赖 openssl 的高版本函数，但系统 PATH 里先找到了老的 libcrypto.dll。
解决：首先确保所有第三方 DLL 都放 exe 目录，不要依赖系统 PATH 里的同名文件。然后下载对应版本的 openssl 库，分别检查 libcurl.dll 的依赖版本。如果实在无法确定版本，就换一个思路——用 Process Explorer 查看加载的 DLL 实际路径，确认是不是从 exe 目录加载的，如果不是，优先解决路径优先级问题。
5.4 服务方式启动（如计划任务）找不到共享目录的 DLL
现象：命令行运行正常，但通过 Windows 计划任务或注册成 Windows 服务后启动，报找不到 DLL。
原因：Windows 服务启动时的当前目录是 C:\Windows\System32，而不是你的 exe 目录；PATH 环境变量也可能不包含你手动添加的路径。更隐蔽的是，很多服务进程在 Session 0 下运行，访问网络路径（如 \server\libs）还需要额外的权限配置，你本地测试环境根本不会触发这个问题。
解决：在服务的启动命令中以绝对路径设置工作目录，并把 DLL 路径加入服务的环境变量（Windows 服务不支持直接设 PATH，一种绕法是脚本先 set PATH，再启动程序；更稳妥的是把所有 DLL 拷到 exe 目录，完全依赖 exe 目录优先的搜索顺序，绕开 PATH）。
5.5 VC++ 运行库版本冲突：装了新版运行库反而更糟
现象：安装最新的 VC++ 2015-2022 Redistributable 后，程序反而从“找不到 VCRUNTIME140.dll”变成了“0xc000007b”。
原因：VC++ 运行库的多版本共存机制是“大版本号兼容、具体版本按需解析”。安装新版 Redistributable 会在 System32 下放置新版本的 VCRUNTIME140.dll，但如果你的程序依赖的是更早的版本（比如 VS2015 编译的），加载器会尝试从 System32 找新版本 DLL，新版本对老接口做的兼容处理在某些函数上有差异——这个概率不高，但碰到一次就足以让人记住。
解决：直接 /MT 静态链接彻底绕开这个问题。如果实在改不了编译方式，卸载掉所有 VC++ Redistributable，重新安装和编译器版本精确匹配的老版本，比如 VS2015 Update 3 的 Redistributable，不要追求“最新版万能”。
5.6 部署目录做了精简，少了 WonderTrader 内部插件
现象：主程序能启动，但在初始化某个交易接口或数据模块时报错，比如“CTP 接口加载失败”或“找不到 WtDtLite.dll”。
原因：WonderTrader 的模块加载遵循插件机制，核心 exe 不会把所有功能静态链进去——这是设计如此，不是为了给部署添麻烦。你按最小依赖清单精简目录时，把策略插件或交易接口 DLL 也裁掉了，导致功能初始化失败。
解决：精简部署目录前，先看 WonderTrader 启动日志里加载了哪些模块，通常以“load module xxx success”形式出现。按日志里的模块名对照部署目录里的文件，缺哪个补哪个。这是一个反复校准的过程，不能只做一次。
6. 进阶验证：用清单脚本让部署目录“文件自检”
到这个阶段，你已经能把 WonderTrader 部署到任何 Windows 机器上了。最后教一个我常用的收尾技巧——写一个一键自检脚本，把“人工核对部署目录”变成“脚本输出缺失文件清单”。核心原理是：根据 exe 的导入表生成期望文件列表，再和目标目录比对。
先写一个 Python 脚本，用 pefile 库读取 exe 的导入表，输出依赖的 DLL 文件名列表：
# 依赖清单生成器：读取 exe 导入表，生成期望文件清单 import pefile import json import os import sys from collections import deque def get_dependency_tree(exe_path): """递归解析 PE 文件的依赖树，返回重复出现的 DLL 文件名集合。""" visited = set() queue = deque([exe_path]) needed = set() while queue: pe_path = queue.popleft() if pe_path in visited: continue visited.add(pe_path) try: pe = pefile.PE(pe_path, fast_load=True) pe.parse_data_directories( directories=[ pefile.DIRECTORY_ENTRY['IMAGE_DIRECTORY_ENTRY_IMPORT'] ] ) # 遍历每个导入的 DLL，记录文件名并继续解析其自身依赖 for entry in pe.DIRECTORY_ENTRY_IMPORT: dll_name = entry.dll.decode('utf-8') needed.add(dll_name) # 如果这个 DLL 也在扫描目录里，就递归展开；否则标记为系统 DLL 跳过 local_path = os.path.join(os.path.dirname(pe_path), dll_name) if os.path.exists(local_path) and local_path.lower() not in visited: queue.append(local_path) pe.close() except Exception as e: # 不是有效的 PE 文件或读取失败，跳过不阻塞 print(f'skip {pe_path}: {e}') return needed # 用法：python gen_deps.py C:\deploy\WonderTrader.exe if __name__ == '__main__': exe = sys.argv[1] deps = get_dependency_tree(exe) # 过滤系统 DLL（已知的 Windows 系统文件清单） SYSTEM_DLLS = {'KERNEL32.dll', 'USER32.dll', 'GDI32.dll', 'ADVAPI32.dll', 'SHELL32.dll', 'OLE32.dll', 'WS2_32.dll', 'SHLWAPI.dll', 'NTDLL.dll', 'COMDLG32.dll', 'COMCTL32.dll', 'IMM32.dll'} missing = deps - SYSTEM_DLLS print(json.dumps(sorted(missing), indent=2))这段代码的逻辑说明：先从 exe 的导入表拿到直接依赖，然后对每个能在 exe 目录找到的 DLL 递归读取它自身依赖，直到遇到系统 DLL 或找不到的项。sys.argv[1] 是传入的 exe 路径。SYSTEM_DLLS 集合是手动维护的“系统自带，不用部署”清单，这些文件在 Windows 上由系统保证存在，不用拷贝。
执行这个脚本后，输出的 JSON 数组就是“程序运行缺了必挂的文件集合”——把这当作部署清单的期望值。再写一个校验脚本对比实际目录：
# 部署自检：检查 deploy 目录中是否包含所需 DLL @echo off setlocal enabledelayedexpansion cd /d C:\deploy rem 从 gen_deps.py 的输出中提取文件名（这里用 python 生成缺失清单） python gen_deps.py WonderTrader.exe > expected.json rem 再执行一个简单的循环检查，Windows 下没有 jq，直接用 python 处理 python -c "import json,os;\ e=json.load(open('expected.json'));\ m=[f for f in e if not os.path.exists(f)];\ print('\n'.join(m) if m else 'ALL DEPS OK')" pause这套脚本我每次部署新环境都跑一遍。它看起来微不足道，但省掉的是“下好了三个 DLL 却发现少拷贝了 libcrypto 的第四层依赖”这种连续翻车的反复折腾。我自己的习惯是把 gen_deps.py 收进公司的内部工具库，后续 WonderTrader 升级到新版本时，只要重新生成一次期望清单再跑校验，部署目录有没有缺一目了然。
最后说个以“前人的亏”换来的习惯：任何依赖库部署方案都不要完全依赖 DLL 拷贝，能选静态链接的（Qt 可以静编、VC 运行库可以 /MT、curl 可用静态库）就静编，实在静编不了的把对应的安装包（vc_redist、Qt 在线安装包）放进公司的内部软件仓库，不留“我希望这台机器碰巧有运行库”的余地。依赖问题在设计阶段解决十分力，到部署阶段解决要百分力。记住这个比例，希望帮到你。
本文还有配套的精品资源，点击获取
