VSCode本身不识别工程结构，只依赖tasks.json、launch.json和c_cpp_properties.json等配置文件实现编译、调试和头文件查找；多文件夹仅是路径组织，非架构识别。
直接说结论：VSCode本身不“识别工程结构”，它只认tasks.json怎么编译、launch.json怎么启动调试器、以及c_cpp_properties.json怎么找头文件——多文件夹只是路径问题，不是架构问题。
为什么tasks.json里编译多个源文件容易出错
很多人把main.cpp和src/utils.cpp、include/worker.h放在不同目录后，直接在tasks.json的args里写"${file}"，结果只编译了当前打开的文件，链接时报undefined reference。
-
args数组必须显式列出所有要参与编译的.cpp文件，或改用构建系统（如make、cmake）统一管理 - 如果用
g++手动编译，推荐写成："g++", "-g", "-std=c++17", "src/main.cpp", "src/utils.cpp", "-Iinclude", "-o", "build/app" -
-Iinclude是关键：它告诉编译器去include/目录下找#include "worker.h"，否则c_cpp_properties.json里写的includePath只影响智能提示，不影响实际编译 - 输出路径建议用
build/子目录，避免生成文件污染源码树
launch.json中program路径填错的典型表现
常见错误是写成"./app"或"app"，但实际可执行文件在build/app，导致F5时提示Cannot launch program ... because corresponding source file cannot be found或直接报Could not find the task "g++"（其实是找不到program）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 务必用
${workspaceFolder}/build/app这种绝对路径写法，不要依赖当前工作目录 - 如果用了
preLaunchTask，确认该task的output字段和program指向同一路径 - Linux/macOS注意可执行文件无扩展名；Windows下如果是MinGW，得写
build/app.exe - 首次运行前先终端手动执行一遍
./build/app，验证它真能跑起来——GDB不会帮你修复编译错误
c_cpp_properties.json里includePath没配对，智能提示就失效
比如src/main.cpp里写了#include "utils.h"，而utils.h实际在include/utils.h，但includePath只写了"${workspaceFolder}/src"，VSCode就会标红、跳转失败、补全不出Utils::xxx。
立即学习“C++免费学习笔记（深入）”；
- 每个头文件所在目录都要加进
includePath数组，例如："${workspaceFolder}/include", "${workspaceFolder}/src" - 别漏掉标准库路径：GCC用户加
/usr/include/c++/11（版本号按g++ -v输出调整），Clang用户加/usr/lib/clang/14.0.0/include -
intelliSenseMode必须匹配你用的编译器，gcc-x64对应g++，clang-x64对应clang++，配错会导致宏定义解析异常 - 改完保存后，右下角点“C/C++ Configurations” → “Reconfigure IntelliSense”，否则缓存不刷新
最常被忽略的一点：tasks.json和launch.json里的路径变量（如${fileDirname}）只在触发那一刻求值，它们不会自动感知你切换了编辑器里打开的文件。多文件夹项目一旦依赖${file}，就等于放弃自动化——老老实实用cmake或make，然后在tasks.json里调用cmake --build build，才是稳的。
