VSCode中#include错误主因是c_cpp_properties.json的includePath配置错误或未生效，需确保路径准确、格式规范（用正斜杠、禁用/**）、权限正常，并与实际编译器路径一致；改后须重启IntelliSense引擎。
VSCode里出现 #include 错误，不是代码写错了，也不是编译器坏了，而是IntelliSense没拿到正确的头文件地图——c_cpp_properties.json 里的 includePath 没配对，或者根本没生效。
为什么改了 includePath 还是红波浪线？
常见现象：手动往 includePath 里加了 /usr/include 或第三方库路径，保存后红色波浪线纹丝不动。这通常是因为：
- 没选中刚配置的 configuration：右下角状态栏显示的是 “Linux”、“Win32” 或 “clang-x64”，但你改的是另一个 platform 下的配置，得点它 → 选择对应项
-
includePath末尾写了/**：VSCode C/C++ 扩展不支持 glob 递归，"/usr/include/**"是无效写法，必须写成"/usr/include" - 路径本身不存在或拼错：比如 MinGW 安装在
C:/msys64/mingw64，却填了网上抄的C:/MinGW；Linux 下用g++ -v -E -x c++ /dev/null查真实系统头路径更可靠 - 没重启 IntelliSense：改完 JSON 文件后，必须按
Ctrl+Shift+P→ 输入C/C++: Restart IntelliSense Engine，否则缓存还在用旧配置
includePath 该填哪些路径？
不能只靠猜，得按来源分层填。顺序无关，但缺一不可：
- 项目内头文件：
"${workspaceFolder}/include"、"${workspaceFolder}/src"（如果头文件和源码混放） - 编译器自带标准库：
/usr/include/c++/11（Ubuntu 22.04 + g++ 11）、/usr/lib/gcc/x86_64-linux-gnu/11/include、/usr/include（注意不是/usr/include/**） - 第三方库（如 OpenCV）：
/usr/include/opencv4（Linux apt 安装）、C:/opencv/build/install/include（Windows 自编译） - 交叉工具链（如 ARM）：
C:/gcc-arm-none-eabi/arm-none-eabi/include，别漏掉cxx和sys子目录
路径里一律用正斜杠 /，Windows 也别用反斜杠；变量只认 ${workspaceFolder}、${env:HOME} 等少数几个，${fileDirname} 不生效。
立即学习“C++免费学习笔记（深入）”；
用 CMake 的项目，别手动配 includePath
如果你的项目有 CMakeLists.txt 且已用 CMake Tools 插件成功 configure 过，就别碰 includePath 手动填了。直接在 c_cpp_properties.json 里加这一行：
"configurationProvider": "ms-vscode.cmake-tools"
这样 IntelliSense 会自动读取 compile_commands.json 或 CMake 缓存里的真实包含路径，包括 target_include_directories()、find_package() 导出的路径，比人肉维护准得多。前提是 CMake Tools 插件已安装，并且右下角状态栏显示 “CMake: Ready”。
远程开发（WSL/SSH）时头文件全红
本地 VSCode 打开 \wsl$Ubuntuhomeuserproject 这种路径，IntelliSense 无法访问 WSL 内部的 /usr/include，填绝对路径也没用。正确做法是：
- 装 Remote-WSL 或 Remote-SSH 插件
- 用插件直接连接到 WSL/远程机器，在远端环境里打开项目文件夹
- 此时
c_cpp_properties.json中的路径全部按远端视角填写（如/usr/include），IntelliSense 引擎也在远端运行，路径自然可达
切记：不要在本地 VSCode 里“打开文件夹”指向 WSL 路径，这是最常被忽略的硬伤——编辑器和 IntelliSense 运行环境分离，路径永远对不上。
