includepath必须指向真实头文件目录而非源码或安装根目录，如opencv预编译包头文件在d:/opencv/build/include，mingw自编译在.../install/include/opencv4，linux用pkg-config --cflags opencv4获取准确路径，并需补全系统标准头路径。
c_cpp_properties.json 的 includePath 必须指向真实头文件位置，不是源码路径也不是安装包根目录
VSCode 的 C/C++ 扩展靠 c_cpp_properties.json 里的 includePath 做语义检查和跳转，但这个配置和编译能否通过完全无关。常见错误是把 D:/opencv 或 D:/opencv/sources 直接塞进 includePath，结果 #include <opencv2></opencv2> 一直报红。
- 预编译包（如
opencv-4.9.0-vc17.exe）解压后，头文件实际在D:/opencv/build/include，不是/sources下 - MinGW 自编译安装后，头文件默认落在
D:/opencv/build/mingw64-build/install/include，且通常含opencv4/前缀，所以得加D:/opencv/build/mingw64-build/install/include/opencv4 - Linux/macOS 源码编译后，用
pkg-config --cflags opencv4输出的路径最准，一般是/usr/local/include/opencv4 - 别漏掉系统标准头路径，比如 MinGW 下要加
D:/mingw64/x86_64-w64-mingw32/include，否则stdint.h这类会标黄
compilerPath 必须与链接器、运行时 ABI 严格一致
Windows 上选错 compilerPath 是“头文件不报错但链接失败”的主因。VSCode 的 IntelliSense 用它推导符号，而 CMake 或手动 g++ 命令行也依赖同一套 ABI 规则。混用就炸。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用 MinGW-w64 编译 OpenCV，
compilerPath就必须是g++.exe，不能是clang++.exe—— 即使都装了，ABI 不兼容 - VC 系列预编译包（
vc17）只能配 Visual Studio 工具链，compilerPath设成cl.exe，且c_cpp_properties.json中intelliSenseMode得设为msvc-x64 - 检查是否匹配：运行
g++ -v和你compilerPath指向的路径是否一致；再确认 OpenCV 的.lib或.a文件名后缀（如opencv_world490.dll.a对应 MinGW，opencv_world490.lib对应 MSVC）
tasks.json 里 -I 和 -L 参数不能只靠 includePath 推导
c_cpp_properties.json 只管编辑时提示，tasks.json 才决定真实编译行为。很多用户改完 includePath 就以为万事大吉，结果 g++ 编译时报 “undefined reference to cv::imread”。
-
tasks.json的args字段中，-I必须显式写头文件路径，且和includePath保持一致；-L要指向.a或.lib所在目录，比如-LD:/opencv/build/mingw64-build/install/lib - MinGW 下链接需加
-lopencv_core -lopencv_imgproc -lopencv_imgcodecs（或-lopencv_world），顺序不能反：依赖项放后面 - Windows 下若用 DLL，
tasks.json不负责复制 DLL，得靠脚本或手动把opencv_world490.dll放到./或./Debug/下，否则运行时报错
最容易被忽略的是：C++ 头文件路径、链接库路径、运行时 DLL 路径，这三者来源可能完全不同——预编译包、自编译安装、vcpkg 三者路径结构差异极大，硬套模板必踩坑。每次换 OpenCV 版本或编译器，都得重新核对这三个路径的实际落点。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
