dumpbin仅显示PE导入表中的显式依赖DLL，不包含LoadLibrary动态加载的模块；完整依赖分析应使用Dependencies工具递归扫描，并注意排除API-MS-WIN-*.DLL等系统别名。
用 dumpbin 查看 EXE 依赖的 DLL 列表
Windows 下 C++ 可执行文件的直接依赖（即 PE 文件头中 Import Table 记录的 DLL）可以用微软自带的 dumpbin 快速列出。它不依赖第三方工具，也不需要运行程序，适合集成进构建脚本。
在 VS 开发者命令行或已配置好环境变量的终端中执行：
dumpbin /dependents your_app.exe
输出里会显示类似这样的内容：
dumpbin
- 下载地址：https://github.com/lucasg/Dependencies/releases（选带
vc_redist的版本，避免运行时报 VC 运行库缺失） - 直接双击打开你的
.exe，它会自动递归扫描所有层级依赖，并标出「Missing」或「Not Found」项 - 右键节点可「Copy full path」，方便批量复制缺失 DLL 路径
- 关键设置：勾选
Scan also indirect dependencies和Resolve delay-loaded imports
常见误判点：API-MS-WIN-*.DLL 和 EXT-MS-WIN-*.DLL 是 Windows 10+ 的 API 集合别名，实际不需打包——它们由系统 api-ms-win-core-* 实现，只要目标机器系统版本够新就自动映射。打包这些反而会导致运行失败。
用 windeployqt？不，那是 Qt 专用的
如果你没用 Qt，别碰 windeployqt。它只识别 Qt 自己的模块依赖（Qt5Core.dll、Qt5Gui.dll 等），对普通 C++ 项目完全无效，还可能把无关的 platforms/qwindows.dll 之类拷进来，误导交付包结构。
同理，macdeployqt 或 linuxdeploy 也都不适用于 Windows 原生 C++ 交付场景。
真正通用的做法是：先用 Dependencies 扫出完整 DLL 列表 → 检查每个 DLL 的来源（VS 安装目录、Windows SDK、第三方 SDK）→ 手动或脚本复制到输出目录 → 最后验证是否所有 LoadLibrary 调用都能成功。
自动化打包脚本的关键检查点
写一个 PowerShell 或批处理脚本来自动收集 DLL，容易漏掉几个硬伤：
- 没区分 Debug/Release 版本：
VCRUNTIME140D.dll（Debug）不能发给用户，必须用VCRUNTIME140.dll（Release），否则报错0xc000007b或找不到模块 - 忽略架构一致性：x64 程序混入 x86 DLL（如
MSVCP140.dll的 x86 版）会导致LoadLibrary失败且无明确提示 - 遗漏运行时重分发包（vcredist）：即使你拷了
VCRUNTIME140.dll，某些系统仍要求安装vcredist_x64.exe（尤其是 Server 系统或精简版 Win10），因为部分 CRT 函数依赖注册表或全局策略 - 没处理相对路径逻辑：如果代码里写的是
LoadLibrary("libfoo.dll")，那这个 DLL 必须和 EXE 在同一目录，或在PATH中；若用绝对路径或子目录，则要按实际路径结构组织交付包
最稳妥的交付方式不是“拷全所有 DLL”，而是：确认目标机器已安装对应版本的 vcredist + 仅拷贝你的程序直接依赖且非系统自带的 DLL（比如 OpenSSL、FFmpeg、自研 DLL），其余交给系统或运行库处理。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
