用 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）

VS2025 + MSVC 工具链下无法真正静态链接 stdc++

MSVC 没有 libstdc++，它用的是 MSVCP140.dll / VCRUNTIME140.dll。你能在项目属性里勾选“多线程静态链接 (/MT)”，但这只静态链接 C 运行时（libcmt.lib），C++ 标准库（如 std::string、std::thread）仍需 DLL 支持。

这意味着：

• /MT 生成的 exe 仍需同目录放 MSVCP140.dll 和 VCRUNTIME140.dll（对应 VS2025 是 MSVCP143.dll 等）
• 微软官方不提供静态版 C++ 标准库分发许可，强行用 /MT + 第三方静态 stdlib 会导致 ABI 不兼容、std::vector 析构崩溃等未定义行为
• 若坚持 MSVC 工具链且要免部署，唯一合规方案是：用 InstallUtil 或 WiX 打包时附带对应 VC++ Redistributable，而非试图“提取 DLL”

别信“DLL 提取神器”：手动复制 DLL 是陷阱

网上很多教程教你怎么用 Process Explorer 查进程加载的 DLL，再把它们全拷进程序目录——这看似能跑，实则危险。

问题在于：

• 同一 DLL 多版本共存（如 libstdc++-6.dll v11 vs v12）会因符号解析冲突导致随机 crash
• 某些 DLL（如 Qt5Core.dll）依赖特定初始化顺序，裸拷贝后调用 QApplication 构造函数直接 abort
• Windows SxS（Side-by-Side）机制下，部分 DLL 必须通过 manifest 文件声明才能正确加载，手动复制无效
• 真正可靠的依赖提取只有一种：用 windeployqt（Qt）、macdeployqt（macOS）、或 linuxdeploy（Linux）这类官方工具，它们理解框架依赖图谱

静态链接不是银弹，但它是 Windows 下 C++ 小工具免部署最可控的路径。关键在工具链选择、标志完整性、第三方库匹配——而不是事后补 DLL。