用 MinGW-w64 静态链接生成免依赖的 exe
Windows 上 C++ 生成的 exe 默认动态链接 msvcrt.dll 或 libgcc_s_seh-1.dll、libstdc++-6.dll，一运行就报“缺少 DLL”——根本原因不是没打包，而是链接器没强制静态化。MinGW-w64 支持通过 -static 和 -static-libgcc -static-libstdc++ 三参数组合实现真正静态链接。
实操建议：
- 必须用
x86_64-w64-mingw32-g++（或i686-w64-mingw32-g++）工具链，MSVC 工具链不支持-static-libstdc++ - 编译命令末尾加：
-static -static-libgcc -static-libstdc++，缺一不可；只写-static时，GCC 运行时仍可能动态加载 - 若用 CMake，需在
set(CMAKE_EXE_LINKER_FLAGS ...)中显式追加这三个标志，且确保CMAKE_BUILD_TYPE=Release（Debug 下静态链接 stdc++ 可能失败） - 链接 OpenCV、Boost 等第三方库时，必须使用其**静态版本**（如
opencv_world480.lib要换成opencv_world480.a），否则链接器会回退到动态导入
检查生成的 exe 是否真静态：用 ntldd 或 Dependencies
光看文件大小没用。一个 5MB 的 exe 仍可能依赖外部 DLL——得验证导入表。
推荐做法：
- 下载轻量工具 Dependencies（比旧版
depends.exe支持 Win10/11 新 API） - 直接拖入你的
exe，左侧树状图中如果只显示ntdll.dll和kernel32.dll（系统级强制依赖，无法消除），其余第三方 DLL 全部消失 → 静态成功 - 命令行快速筛查：
ntldd -R your_app.exe | grep -E "(libstd|libgcc|libwinpthread)"，无输出即干净 - 注意：若出现
libwinpthread-1.dll，说明漏了-static-libgcc（该库被 GCC 用于线程封装，非 Windows 原生 pthread）
VS2022 + MSVC 工具链下无法真正静态链接 stdc++
MSVC 没有 libstdc++，它用的是 MSVCP140.dll / VCRUNTIME140.dll。你能在项目属性里勾选“多线程静态链接 (/MT)”，但这只静态链接 C 运行时（libcmt.lib），C++ 标准库（如 std::string、std::thread）仍需 DLL 支持。
这意味着：
-
/MT生成的exe仍需同目录放MSVCP140.dll和VCRUNTIME140.dll（对应 VS2022 是MSVCP143.dll等） -
微软官方不提供静态版 C++ 标准库分发许可，强行用
/MT+ 第三方静态 stdlib 会导致 ABI 不兼容、std::vector析构崩溃等未定义行为 - 若坚持 MSVC 工具链且要免部署，唯一合规方案是：用
InstallUtil或WiX打包时附带对应 VC++ Redistributable，而非试图“提取 DLL”
别信“DLL 提取神器”：手动复制 DLL 是陷阱
网上很多教程教你怎么用 Process Explorer 查进程加载的 DLL，再把它们全拷进程序目录——这看似能跑，实则危险。
问题在于：
- 同一 DLL 多版本共存（如
libstdc++-6.dllv11 vs v12）会因符号解析冲突导致随机 crash - 某些 DLL（如
Qt5Core.dll）依赖特定初始化顺序，裸拷贝后调用QApplication构造函数直接 abort - Windows SxS（Side-by-Side）机制下，部分 DLL 必须通过
manifest文件声明才能正确加载，手动复制无效 - 真正可靠的依赖提取只有一种：用
windeployqt（Qt）、macdeployqt（macOS）、或linuxdeploy（Linux）这类官方工具，它们理解框架依赖图谱
静态链接不是银弹，但它是 Windows 下 C++ 小工具免部署最可控的路径。关键在工具链选择、标志完整性、第三方库匹配——而不是事后补 DLL。
