红色波浪线是intellisense未找到头文件路径所致，需正确配置compilerpath（绝对路径）、includepath（覆盖项目/系统/第三方三类路径），并执行“c/c++: reset intellisense database”生效。
红波浪线不是编译失败，是IntelliSense没找到头文件
VSCode里#include <iostream></iostream>或#include "my_header.h"底下出现红色波浪线，99%不是代码写错了，而是C/C++插件的IntelliSense引擎压根没在对应目录里搜索过。它和g++能不能编译成功完全无关——你改完配置后g++ main.cpp能跑通，但VSCode仍报红，就是典型症状。
根本原因就两个：compilerPath指向错误（导致自动推导的系统路径全失效），或者includePath漏了关键路径（IntelliSense只认这个数组，不读Makefile、不继承shell环境、也不递归扫描子目录）。
compilerPath填错，后面所有配置都白搭
compilerPath不是用来“告诉VSCode用哪个编译器编译”，而是让它调用该二进制执行-v -E -x c++ -来反查系统头文件位置。填错就等于断了自动推导的源头。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须填绝对路径，比如
"/usr/bin/g++"，不能写"g++"或"g++-11"——IntelliSense不走$PATH - 先在终端运行
which g++确认真实路径；交叉编译环境（如xtensa-esp32-elf-g++）也必须填完整路径，并验证xtensa-esp32-elf-g++ -v -E -x c++ - 能正常输出<code>#include search starts here: - 如果
compilerPath指向一个权限不足、损坏或根本不存在的文件，IntelliSense会静默放弃推导，只依赖你手动写的includePath，此时极易漏掉架构子目录（如/usr/include/x86_64-linux-gnu/c++/11）
includePath必须手列三类路径，缺一不可
includePath是IntelliSense唯一信任的“搜索地图”。它不会自动展开**之外的子目录，也不会合并重复项——每一条都得你亲手列清楚、格式对、路径准。
- 项目本地头文件：
"${workspaceFolder}/include/**"（注意末尾/**，漏掉就找不到include/utils/log.h） - 系统标准路径：从
g++ -v -E -x c++ - 输出中复制<code>#include search starts here:下的所有行，每行转为一个字符串，例如"/usr/include/c++/11"、"/usr/include/x86_64-linux-gnu/c++/11"——漏掉架构子目录，#include <thread></thread>必报红 - 第三方库路径：如
libpcl-dev装在/usr/include/pcl-1.10，ROS用户还需加/opt/ros/humble/include；Windows下反斜杠要双写："C:\mingw64\include"
改完配置不重置数据库，等于没改
VSCode不会自动重新索引。你看到的仍是旧缓存，尤其之前配错过、或切换过GCC版本时，残留数据会导致“明明改对了却还报错”。
- 按
Ctrl+Shift+P，输入并执行C/C++: Reset IntelliSense Database - 等右下角状态栏出现
IntelliSense is re-indexing…，直到变成Ready - 如果仍不生效，关闭所有文件夹，再用
File → Open Folder重新打开项目——避免残留旧工作区配置 - 别忽略右下角状态栏：如果显示
No config或当前name和你编辑的配置不一致（比如你改的是ESP32 Development，但右下角显示Linux），得先点它手动切换
最常被跳过的一步是验证compilerPath是否真实可用——很多人复制粘贴路径时多了一个空格，或没注意到符号链接实际指向已卸载的旧版本。一旦compilerPath失效，IntelliSense就彻底失去自动推导能力，只能靠你一条条手填includePath，而人眼极难穷举所有系统路径变体。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
