核心原因是运行时动态库加载失败，而非编译失败；必须在launch.json的env字段中显式配置path，如"env": {"path": "c:mingw64in;${env:path}"}，确保调试器加载正确版本的dll。
Windows 下 VSCode 运行 C++ 程序报“找不到 DLL”或“无法定位程序输入点”，核心原因不是编译失败，而是运行时加载动态库失败——路径没对、版本冲突、或环境变量没生效。
launch.json 的 env.PATH 必须显式覆盖
VSCode 调试器（如 GDB 或 Windows 默认调试器）不会继承系统 PATH 的全部内容，也不会自动读取终端里你手动 set PATH 的结果。它只认 launch.json 里 env 字段定义的环境变量。
- 必须在
launch.json的配置项中写死 MinGW / MSVC 的bin路径，例如："env": {"PATH": "C:\mingw64\bin;${env:PATH}"} - 路径分隔符用双反斜杠
\，不能用单斜杠或正斜杠（Windows 下/在 JSON 字符串里可能被误解析） - 不要只写
${env:PATH}—— 它可能为空，或指向错误的旧工具链 - 如果项目依赖多个 DLL（比如
libstdc++-6.dll、libgcc_s_seh-1.dll），确保它们全在该bin目录下，且没有同名文件混在项目根目录或build/目录里
CMakeLists.txt 中设置 VS_DEBUGGER_ENVIRONMENT 不够用
这个属性只影响 Visual Studio 生成器（MSVC），对 Ninja + MinGW 组合完全无效。你在 CMakeLists.txt 里写 set_target_properties(... PROPERTIES VS_DEBUGGER_ENVIRONMENT "PATH=...")，VSCode 的 CMake Tools 插件根本不会读它。
- 真正起作用的是
launch.json和tasks.json里的env配置 -
tasks.json的options.env控制构建过程的环境，launch.json的env控制运行/调试过程的环境，二者要一致 - 如果你用
cmake --build构建，但调试时用 GDB 启动，而两者环境不一致，就会出现“编译成功、运行失败”
别信“把 DLL 拷到 exe 同目录就万事大吉”
这个办法看似简单，但会掩盖真实问题，而且在工程变大后极难维护。更麻烦的是：它可能引入隐性冲突。
- 如果项目同时依赖两个不同版本的
libstdc++-6.dll（比如 Qt 和你自己写的库各带一个），放在同目录下只会加载第一个，另一个被静默忽略 - 某些 DLL（如
vcruntime140.dll、ucrtbase.dll）是 Windows 系统级 CRT，不能随便替换；报错指向这些名字时，说明系统运行时损坏，得走sfc /scannow或DISM修复 - 用 Dependencies 打开你的
.exe，右键看每个 DLL 的 “Open containing folder”，才能确认它实际加载的是哪个路径下的文件
Linux/macOS 下用 LD_LIBRARY_PATH 或 DYLD_LIBRARY_PATH
VSCode 在 Linux/macOS 上不自动设置运行时库路径，即使你终端里 export LD_LIBRARY_PATH=... 成功，调试器仍可能看不到。
- 在
launch.json的env字段里加："env": {"LD_LIBRARY_PATH": "/home/yourname/mylib:/usr/local/lib:${env:LD_LIBRARY_PATH}"} - macOS 用户注意：
DYLD_LIBRARY_PATH在较新系统上默认被禁用（出于安全），需在终端启动 VSCode：env DYLD_LIBRARY_PATH=/path/to/lib code . - 如果用 CMake + Ninja，也可以在
CMakeLists.txt中用set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib")让可执行文件自带查找逻辑，比硬编码环境变量更可靠
最常被忽略的一点：VSCode 的集成终端、任务构建、调试器三者环境变量来源不同，launch.json 是唯一能 100% 控制运行时 DLL 查找路径的地方。其他地方写的 PATH，只是看起来有效而已。
