企业官网建设流程全解析

1. 项目概述：为什么一个“看了就会”的C++配置教程，反而让多数人卡在第一步？

你点开这个标题，大概率正坐在电脑前，手边摊着一本《C++ Primer》，或者刚下载完VS Code，心里盘算着：“今天必须把环境配好，明天就开始写Hello World。”结果呢？安装完插件，打开tasks.json，看到那一堆"args"参数像天书一样堆在那儿；改完c_cpp_properties.json，编译器却报错说找不到<iostream>；好不容易跑通了，换个项目路径又全崩——不是头文件路径错，就是g++版本不匹配，再或者终端里敲g++ --version返回“command not found”。这不是你手笨，是绝大多数人根本没意识到：VS Code本身不是IDE，它是个高度可定制的编辑器壳子，而C++编译环境配置，本质是一场跨工具链的“协议对齐”工程。

核心关键词——VS Code、C++、编译环境、g++、MinGW、Clang、tasks.json、c_cpp_properties.json、launch.json——每一个都不是孤立存在。它们之间要完成三重握手：第一，编辑器得知道“C++代码长什么样”，靠C/C++插件解析语法和语义；第二，构建系统得明白“怎么把.cpp变成可执行文件”，靠tasks.json调用真实编译器（比如g++）；第三，调试器得搞清“程序运行时内存布局是啥”，靠launch.json把VS Code的调试界面和GDB/LLDB底层指令桥接起来。这三者稍有错位，轻则红波浪线满屏，重则编译通过但运行崩溃，还查不出原因。

我带过不少刚从图形化IDE（比如Dev-C++或Code::Blocks）转过来的同学，他们最常问的一句是：“为什么我在Dev-C++里点一下‘编译运行’就出结果，到了VS Code却要写三个JSON文件？”答案很实在：Dev-C++把g++调用、头文件路径、调试器启动全给你打包好了，藏在按钮背后；而VS Code把所有控制权交还给你——它不替你做决定，只提供精准的杠杆。所以这个教程叫“看了就会”，不是因为它简单，而是因为它的每一步都对应一个可验证、可打断、可回溯的真实动作：你改一行args，就能立刻看到终端输出变化；你加一个"-I"路径，就能马上验证#include "myheader.h"是否通过；你改"miDebuggerPath"，就能确认GDB是否真正接管了进程。它不教你怎么“背配置”，而是带你亲手拧紧每一颗螺丝。适合谁？适合想真正理解C++构建流程的初学者，也适合被老旧教程坑过、想重建知识框架的进阶者。只要你愿意花30分钟，跟着终端输出一步步确认，而不是复制粘贴完就关页面——这个环境，你今天就能配稳。

2. 整体设计思路：为什么放弃“一键脚本”，坚持手动配置三份JSON？

很多人会疑惑：网上不是有各种“VS Code C++一键配置包”吗？甚至还有GitHub上Star过万的自动化脚本。我试过，也推荐给学生用过，最后全部弃用。原因很直接：那些脚本本质上是在帮你预设一个固定解法，而C++开发环境的变量太多——你的操作系统是Windows还是macOS？是Intel芯片还是Apple Silicon？你装的是MinGW-w64还是WSL2里的g++？你用的是Clang还是GCC？你项目里有没有自定义的第三方库路径？一旦你的实际环境和脚本预设的路径、版本、架构出现哪怕一个字符的偏差，整个配置就变成黑盒：你既不知道哪步失败了，也不知道该去哪修。这就像给人装假牙，如果技师不量你牙弓尺寸，只按标准模型硬塞，咬合不上、牙龈发炎是必然的。

所以我坚持手动配置三份核心JSON文件，不是为了炫技，而是因为这是唯一能让你建立“因果链”的方式。我们来拆解这三份文件各自承担的不可替代角色：

• c_cpp_properties.json：它不参与编译，只负责告诉编辑器“代码该怎么被理解”。比如你写了#include <vector>，编辑器得知道vector的定义在哪个头文件里，这个头文件又在系统哪个目录下。它配置的是IntelliSense的“知识图谱”，影响的是代码补全、跳转、错误提示的准确性。这里填错路径，你写代码时会一直看到红色波浪线，但编译可能完全没问题——因为编译器压根不看这个文件。

• tasks.json：它不参与调试，只负责把编辑器的“运行”操作，翻译成终端里的一条真实命令。比如你按Ctrl+Shift+B，它就调用g++，传入你指定的源文件、输出路径、优化选项、宏定义等。它配置的是构建流程的“执行引擎”，影响的是能否生成可执行文件。这里写错"args"，你按快捷键后终端会直接报错，比如g++: error: unrecognized command line option '-std=c++17'，说明你用的g++版本太老。

• launch.json：它不参与编译，只负责把VS Code的调试界面，和底层调试器（GDB/LLDB）的控制指令打通。比如你点左侧断点，它得告诉GDB“在第15行下个断点”；你按F10单步，它得转发“next”指令给GDB。它配置的是调试会话的“通信协议”，影响的是能否查看变量、单步执行、调用栈追踪。这里配错"program"路径，你点调试按钮，VS Code会弹窗说“找不到可执行文件”。

这三者分工明确，互不越界。手动配置的过程，就是强迫你直面每个环节的输入输出：你改c_cpp_properties.json里的"includePath"，就去终端里echo $CPATH验证；你改tasks.json里的"args"，就把它完整复制到终端里手动执行一遍；你改launch.json里的"miDebuggerPath"，就先在终端里which gdb确认路径。这种“所见即所得”的反馈，是任何一键脚本都无法提供的。它让你从“配置使用者”变成“配置设计者”。后续哪怕你接手一个大型CMake项目，看到CMakeLists.txt里一堆target_include_directories()，你也能立刻反应过来：“哦，这玩意儿最终是要映射到c_cpp_properties.json的includePath里的。”

提示：别急着复制网上的JSON模板。先打开你的VS Code，按Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入“C/C++: Edit Configurations (UI)”，用图形界面生成一个基础版c_cpp_properties.json。这是最安全的起点——它会自动探测你系统里已有的编译器，并填入合理的默认路径。之后你再根据项目需求，手动增删"includePath"或"defines"。这样既避免了手敲JSON的语法错误，又保留了全程可控。

3. 核心细节解析：c_cpp_properties.json里那几个关键字段，到底在指挥什么？

很多初学者盯着c_cpp_properties.json里密密麻麻的JSON字段，第一反应是“这玩意儿跟编译有啥关系？我编译又不靠它”。这种误解非常危险。它不参与编译，但它决定了你在写代码时，VS Code能不能给你准确、及时、无干扰的智能支持。想象一下：你正在写一个网络程序，需要#include <sys/socket.h>，但编辑器一直标红，提示“无法打开源文件”。你反复检查拼写，确认无误，最后发现是c_cpp_properties.json里漏配了"/usr/include"路径——于是你花了20分钟排查，其实问题早在你打开文件那一刻就注定了。下面我逐个拆解最常被误配的五个字段，告诉你它们背后的真实作用和典型陷阱。

3.1"configurations"数组：不是选一个，而是按需切换

这个字段是一个数组，里面可以放多个配置对象，比如"Win32"、"Linux"、"Mac"。很多人以为这是让你“选一个操作系统”，然后删掉其他两个。大错特错。它的真正作用是为不同目标平台提供独立的头文件路径和宏定义。比如你开发一个跨平台项目，Windows下用WinSock2.h，Linux下用sys/socket.h，那你就可以在"Win32"配置里加"defines": ["WIN32"]，在"Linux"配置里加"defines": ["__linux__"]。VS Code会根据你当前打开的文件夹（或工作区设置）自动选择匹配的配置。更实用的场景是：你同时在本地Windows开发，又通过SSH连接到远程Linux服务器调试。这时你可以保留"Win32"配置用于本地编辑，再新增一个"Remote-Linux"配置，专门指向远程服务器的头文件路径。这样，你在本地写代码时享受Windows的IntelliSense，连上远程后自动切到Linux的头文件索引——不用每次手动切换。

3.2"includePath"：路径不是越多越好，而是要“精准覆盖”

这是最容易被滥用的字段。常见错误是把网上搜来的“万能路径列表”全粘进去，比如["/usr/include/**", "/usr/local/include/**", "${workspaceFolder}/**"]。结果呢？IntelliSense变得极其缓慢，甚至卡死。原因很简单：**是递归通配符，/usr/include/**意味着要扫描整个/usr/include目录下的所有子目录、所有头文件，动辄上万个文件。VS Code的IntelliSense引擎不是搜索引擎，它需要为每个头文件建立符号索引，海量无关路径会严重拖慢响应速度。

正确做法是只添加你项目实际依赖的路径。比如你用OpenCV，那就只加"/usr/include/opencv4"；你用Boost，那就只加"/usr/local/include/boost"；你项目里有个lib/目录放了自定义头文件，那就加"${workspaceFolder}/lib"。注意${workspaceFolder}是VS Code内置变量，代表当前打开的文件夹路径，它比硬编码绝对路径安全得多——换台电脑、换个项目位置，配置依然有效。另外，路径末尾不要加斜杠，"/usr/include/opencv4/"和"/usr/include/opencv4"在某些系统上会被视为不同路径，导致索引失败。

3.3"defines"：宏定义不是摆设，它直接影响条件编译

这个字段定义预处理器宏，比如["NDEBUG", "MY_PROJECT_VERSION=1.0"]。它的作用远不止“让#ifdef NDEBUG生效”。举个真实例子：你引用了一个C库，它的头文件里有这样一段：

#ifdef __linux__ #include <sys/epoll.h> #elif _WIN32 #include <winsock2.h> #endif

如果你的"defines"里没加"__linux__"，那么VS Code在Linux系统上编辑时，会认为<sys/epoll.h>永远不可用，于是#include <sys/epoll.h>这行永远标红——尽管你用g++编译时完全没问题。这就是典型的“编辑时错误”和“编译时正确”脱节。解决方法就是在"Linux"配置的"defines"里加上"__linux__"。同理，Windows下加"_WIN32"，macOS下加"__APPLE__"。这些宏名不是我瞎编的，它们是GCC/Clang编译器在对应平台上自动定义的标准宏，你可以在终端里执行g++ -dM -E - < /dev/null | grep linux来验证。

3.4"intelliSenseMode"：选错模式，等于给导航仪输错坐标系

这个字段值通常是"gcc-x64"、"clang-x64"、"msvc-x64"。很多人随便选一个，觉得“反正都是x64”。但它的含义是：告诉IntelliSense引擎，用哪种编译器的语义规则来解析你的代码。比如gcc-x64模式下，它会识别GCC特有的扩展语法，如__attribute__((packed))；而clang-x64模式下，它会识别Clang的[[nodiscard]]属性。如果你用的是Clang编译器，但intelliSenseMode设成了gcc-x64，那么当你写[[nodiscard]]函数时，IntelliSense会报错“未知属性”，尽管Clang编译完全通过。更隐蔽的问题是标准库版本：gcc-x64默认按GCC 9.x的libstdc++头文件解析，而clang-x64默认按Clang 12+的libc++解析。如果你项目里用了std::span（C++20特性），而你的GCC版本是8.3（不支持std::span），但intelliSenseMode设成了gcc-x64，那么VS Code就会一直标红，告诉你span不存在——尽管你用Clang编译时一切正常。所以，务必确保这个值和你tasks.json里实际调用的编译器一致。

3.5"browse.path"：它是IntelliSense的“缓存加速器”，不是主路径

这个字段常被忽略，但它对大型项目的响应速度至关重要。"includePath"是“我要解析哪些路径”，而"browse.path"是“请预先扫描并缓存这些路径下的符号”。它的值通常和"includePath"高度重合，但可以更宽泛。比如你的"includePath"只写了["${workspaceFolder}/include", "/usr/include/opencv4"]，那么"browse.path"可以设为["${workspaceFolder}/include", "${workspaceFolder}/src", "/usr/include"]——多加了/src和/usr/include的顶层。这样，IntelliSense在后台扫描时，会把/usr/include下所有头文件的符号都建好索引，当你在代码里跳转到<string>时，就能秒开，而不是卡顿几秒。但要注意："browse.path"不能包含**通配符，否则VS Code会报错。它只接受具体路径或单层通配（如/usr/include/*）。

注意：修改完c_cpp_properties.json后，不要立刻写代码。按Ctrl+Shift+P，输入“C/C++: Reset IntelliSense Database”，强制重建索引。否则旧的缓存还在，你改了路径也看不到效果。这个操作耗时10-30秒，但能避免90%的“改了配置没反应”问题。

4. 实操过程：从零开始，手把手配置tasks.json与launch.json

现在我们进入真正的“动手环节”。前面讲c_cpp_properties.json是让代码“看得懂”，接下来这两份JSON，是让代码“跑得起来”和“调得清楚”。我会以一个最简但最典型的场景为例：你在Windows上用MinGW-w64编译一个单文件hello.cpp，目标是按Ctrl+Shift+B编译，按F5调试。整个过程不依赖任何外部构建系统（如CMake），纯粹用VS Code原生能力驱动。所有步骤都基于真实终端输出验证，拒绝“复制粘贴就完事”的幻觉。

4.1 前置准备：确认g++真的在系统PATH里

这是90%配置失败的根源。很多人以为“我装了MinGW，就等于g++可用”，但实际可能是：MinGW装在D:\mingw64，而你没把D:\mingw64\bin加到系统环境变量PATH里。验证方法极其简单：打开Windows终端（CMD或PowerShell），输入：

g++ --version

如果返回类似g++.exe (Rev5, Built by MSYS2 project) 13.2.0，说明OK。如果返回'g++' is not recognized as an internal or external command，那就必须先解决这个问题。别跳过！我见过太多人在这里卡住，然后回头怪VS Code配置复杂。解决方法：右键“此电脑”→“属性”→“高级系统设置”→“环境变量”，在“系统变量”里找到Path，点击“编辑”，新建一行，填入你的MinGW的bin目录完整路径（比如D:\mingw64\bin）。然后关闭所有已打开的终端窗口，重新打开一个新的，再试g++ --version。记住：环境变量修改后，旧的终端进程不会自动继承新PATH，必须新开。

4.2 创建tasks.json：把“编译”这个动作，翻译成一条可执行命令

按Ctrl+Shift+P，输入“Tasks: Configure Task”，选择“Create tasks.json file from template”，再选“Others”。VS Code会生成一个空的tasks.json骨架。现在，我们把它替换成以下内容（请逐字敲入，不要复制粘贴，因为路径要和你实际环境一致）：

{ "version": "2.0.0", "tasks": [ { "type": "shell", "label": "g++ build active file", "command": "g++", "args": [ "-g", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe", "-std=c++17", "-Wall" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": ["$gcc"], "group": "build", "presentation": { "echo": true, "reveal": "always", "focus": false, "panel": "shared", "showReuseMessage": true, "clear": true } } ] }

关键字段详解：

• "label": "g++ build active file"：这是你在Ctrl+Shift+B菜单里看到的名字，建议保持清晰，比如改成"g++ build (MinGW)"。
• "command": "g++"：明确指定调用g++，而不是clang++或其他。确保它和你终端里验证过的命令一致。
• "args"数组：这是核心。"-g"生成调试信息（launch.json必需）；"${file}"是当前打开的.cpp文件的完整路径；"-o"指定输出文件名；"${fileDirname}/${fileBasenameNoExtension}.exe"是输出路径，fileDirname是文件所在目录，fileBasenameNoExtension是文件名去掉.cpp后缀，所以hello.cpp会输出为hello.exe；"-std=c++17"指定C++17标准；"-Wall"开启所有警告，帮你提前发现隐患。
• "options.cwd"：设置工作目录为当前文件所在目录。这点极其重要！很多项目依赖相对路径读取资源文件（比如"data/config.txt"），如果工作目录不对，程序运行时会找不到文件。
• "problemMatcher": ["$gcc"]：这是VS Code的“错误解析器”。它能自动识别g++编译输出中的错误行号、文件名、错误信息，并高亮显示在编辑器里。没有它，编译报错你只能在终端里手动找。

现在，创建一个测试文件hello.cpp，内容如下：

#include <iostream> int main() { std::cout << "Hello, VS Code C++!" << std::endl; return 0; }

保存后，按Ctrl+Shift+B，选择你刚定义的g++ build active file任务。观察终端输出：应该看到类似g++.exe: warning: ‘-Wl,’ not allowed with ‘-g’这样的警告（可忽略），最后生成hello.exe。如果报错fatal error: iostream: No such file or directory，说明c_cpp_properties.json里的includePath没配对，回到上一节检查。

4.3 创建launch.json：让F5调试键，真正接管你的程序生命周期

按Ctrl+Shift+P，输入“Debug: Open launch.json”，选择“C++ (GDB/LLDB)”，再选“g++.exe (MinGW)”（如果你用的是MinGW）。VS Code会生成一个基础模板。我们精简并强化它，替换为以下内容：

{ "version": "0.2.0", "configurations": [ { "name": "(gdb) Launch", "type": "cppdbg", "request": "launch", "miDebuggerPath": "D:\\mingw64\\bin\\gdb.exe", "program": "${fileDirname}/${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": true, "MIMode": "gdb", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true } ] } ] }

关键字段详解：

• "miDebuggerPath"：必须填你本地GDB的绝对路径。不要用"gdb"，因为VS Code需要精确知道二进制文件在哪。在MinGW安装目录下找gdb.exe，比如D:\mingw64\bin\gdb.exe。填错这里，按F5会直接报错“无法启动调试器”。
• "program"：指定要调试的可执行文件。必须和tasks.json里"-o"生成的路径完全一致。这里用"${fileDirname}/${fileBasenameNoExtension}.exe"，确保和编译输出匹配。
• "externalConsole": true：这个设置至关重要。它让程序在独立的Windows控制台窗口运行，而不是VS Code内置终端。原因有二：第一，std::cin输入需要真正的控制台交互，内置终端有时会卡住；第二，程序崩溃时，外部控制台会保留错误信息（如Segmentation fault），方便你定位。
• "stopAtEntry": false：设为false，表示不一启动就停在main函数入口。你想停在哪，就在哪行左边灰色区域点一下，出现红点断点即可。
• "setupCommands"：启用GDB的“美化打印”功能。没有它，调试时看std::vector或std::string，只会显示一串内存地址；启用后，能直接看到vector里有多少元素、每个元素的值是什么，极大提升调试效率。

现在，在hello.cpp的std::cout这一行左边点一下，设个断点。按F5，选择(gdb) Launch配置。你应该看到一个独立的黑色控制台窗口弹出，程序暂停在断点处。按F10单步，观察变量窗口里std::cout的状态。成功了！这意味着VS Code、GDB、你的hello.exe已经形成闭环。

实操心得：如果你用的是WSL2（Windows Subsystem for Linux），launch.json的"miDebuggerPath"要填"/usr/bin/gdb"，"program"路径要用WSL的Linux路径格式（如"/home/user/project/hello"），并且"externalConsole"必须设为false，因为WSL没有Windows那种外部控制台。这是环境差异带来的必调参数，没有例外。

5. 常见问题与排查技巧实录：那些让你抓狂的“玄学错误”，其实都有迹可循

配置环境最折磨人的，不是大问题，而是那些看似随机、毫无规律的“玄学错误”。比如：昨天还能调试的项目，今天按F5就报错；或者同一个tasks.json，在A电脑上好好的，在B电脑上就找不到头文件。这些问题背后，99%都有清晰的技术原因。我把过去三年帮学员排查的高频问题，整理成一张速查表，并附上我的独家排查逻辑链。记住：所有“玄学”，都是你还没找到那个确定性的触发条件。

除了这张表，我还想分享一个血泪教训：永远不要在项目根目录下，同时存在CMakeLists.txt和tasks.json。VS Code的C/C++插件会优先识别CMakeLists.txt，并自动切换到CMake构建模式，此时你精心配置的tasks.json会彻底失效，而且没有任何提示。解决方案只有两个：要么删掉CMakeLists.txt（如果你不用CMake），要么在VS Code设置里搜索"C_Cpp.autocomplete"，把"default"改成"Disabled"，强制禁用CMake自动检测。这个坑，我踩了三次，每次都要花半小时才想起来。

最后，一个终极排查心法：当所有配置看起来都对，但就是不工作时，请关闭VS Code，删除项目根目录下的.vscode文件夹，然后重新打开项目，从头配置。.vscode文件夹里藏着VS Code为这个项目生成的所有缓存和状态，有时候它会“记错”某些设置，导致新配置不生效。重置它，相当于给VS Code一次“出厂设置”机会。这个操作5秒搞定，却能解决30%的“玄学问题”。

6. 进阶延伸：当单文件编译不够用，如何平滑过渡到CMake项目？

你现在能熟练配置单文件编译了，恭喜，你已经掌握了VS Code C++环境的“最小可行单元”。但现实项目永远不会只有一个.cpp文件。你会遇到头文件分离（.h和.cpp）、多源文件链接、第三方库依赖（如OpenCV、Boost）、甚至跨平台构建。这时候，tasks.json的手动维护会迅速崩溃——你得为每个.cpp文件写一个编译任务，还得手动管理链接顺序。CMake就是为此而生的工业级解决方案。好消息是：VS Code对CMake的支持，不是要你抛弃现有配置，而是把它无缝集成进来。你不需要重学一套东西，只需要在现有知识上，加一层“自动化胶水”。

6.1 为什么CMake不是“另一个配置”，而是tasks.json的超级加强版？

tasks.json的本质，是把“编译一个文件”这个原子操作，封装成VS Code可识别的任务。CMake做的，是把“编译整个项目”这个复杂流程，用一种声明式语言（CMakeLists.txt）描述出来。它不替代tasks.json，而是生成一套更强大、更稳定的tasks.json。当你在VS Code里安装CMake Tools插件，并打开一个含CMakeLists.txt的项目时，插件会自动为你生成tasks.json、c_cpp_properties.json，甚至launch.json的配置——而且这些配置是动态的，会随着你修改CMakeLists.txt而实时更新。你之前手动写的那些路径、宏定义、标准版本，现在都由CMake统一管理。

举个例子：你有一个项目结构如下：

my_project/ ├── CMakeLists.txt ├── src/ │ ├── main.cpp │ └── utils.cpp ├── include/ │ └── utils.h └── third_party/ └── opencv/

对应的CMakeLists.txt可能是：

cmake_minimum_required(VERSION 3.10) project(MyProject) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 添加可执行文件 add_executable(myapp src/main.cpp src/utils.cpp) # 包含头文件路径 target_include_directories(myapp PRIVATE include) target_include_directories(myapp PRIVATE third_party/opencv/include) # 链接OpenCV库 find_package(OpenCV REQUIRED) target_link_libraries(myapp ${OpenCV_LIBS})

看到没？target_include_directories这行，就自动解决了你之前在c_cpp_properties.json里手动填includePath的痛苦；find_package(OpenCV)这行，自动探测OpenCV的头文件和库路径，比你手动写/usr/include/opencv4可靠一万倍；add_executable这行，自动把所有.cpp文件编译链接，你再也不用为每个文件写tasks.json。

6.2 如何用CMake Tools插件，零学习成本接入现有VS Code环境？

安装CMake Tools插件（微软官方出品）后，打开你的项目文件夹，VS Code右下角会弹出一个状态栏，显示“[Not configured]”。点击它，选择“Configure”，插件会自动运行cmake ..，生成构建文件（如build/目录）。完成后，状态栏变成“[Ready]”。这时，你之前的Ctrl+Shift+B和F5依然有效，但背后驱动的，已经是CMake生成的构建系统了。你甚至不需要碰tasks.json——CMake Tools会自动生成一个cmake-build-debug任务，按Ctrl+Shift+B就能编译整个项目。

更妙的是调试：CMake Tools会自动为你生成launch.json，"program"字段直接指向build/myapp，"miDebuggerPath"也自动适配。你唯一要做的，就是在CMakeLists.txt里确保set(CMAKE_BUILD_TYPE Debug)，这样生成的可执行文件才带调试信息。整个过程，你只是多了一个CMakeLists.txt文件，其余操作习惯完全不变。

6.3 一个真实案例：从单文件到CMake的平滑迁移

我指导过一个学生，他用单文件tasks.json写了一个图像处理小工具，后来想加入OpenCV。他最初的做法是：在c_cpp_properties.json里硬编码OpenCV路径，在tasks.json的"args"里加-lopencv_core -lopencv_imgproc。结果在另一台电脑上，OpenCV装在不同路径，所有配置全崩。我让他做了三步改造：

1. 在项目根目录创建CMakeLists.txt，内容就是上面那个例子；
2. 安装CMake Tools插件，点击右下角“Configure”；
3. 把原来的tasks.json和launch.json删掉（CMake Tools会自动生成更好的）。

做完后，他告诉我：“原来#include <opencv2/opencv.hpp>标红，现在不标了；原来cv::Mat img;报错，现在补全出来了；原来Ctrl+Shift+B只编译main.cpp，现在按一下，utils.cpp也一起编译了。”——这就是CMake的价值：它不增加你的认知负担