VS Code C++编译调试完全指南：详解tasks.json与launch.json配置

写在前面

平时在群里看到最多的C++新手提问，不是语法不会、不是算法不懂，而是“我这代码在VS Code里怎么跑不了？”或者说“我明明装了VS Code，怎么写个Hello World都报错？”说实话，这类问题99%都不是代码本身的问题，而是编译器和调试器的配置没有理顺。

VS Code本身只是个编辑器，它不管编译，也不管调试。真正替你干活的是编译器（把源码变成机器码）、调试器（让你能断点、单步、看变量）和构建工具（把多个文件链接成可执行文件）。VS Code只是起到一个“遥控器”的作用，通过tasks.json调起编译器，通过launch.json调起调试器。

而C++世界里编译器不止一种，Windows上常见的有MSVC（Visual C++ 编译器）、MinGW-w64（GCC的Windows移植版）、Clang；Linux上几乎清一色是GCC或Clang；macOS上则是Apple Clang。不同编译器有不同的参数、不同的输出格式、不同的调试器协议，所以“怎么配”这件事，按编译器分类讲是最清晰的方式。这篇文章就按编译器类型，把VS Code编译调试C++这件事从头到尾讲明白。

1. 为什么用 VS Code 搞 C++，按编译器分类到底在分什么

1.1 先搞清楚“编辑器 + 编译器 + 调试器”的分工

很多人第一次用VS Code写C++，会产生一个错觉：既然我是个“集成开发环境”，那我装好了就应该能跑。但VS Code严格来说只是编辑器，它比记事本多了语法高亮、代码补全、终端集成、插件机制而已。真正完成从源码到可执行文件这一步的是编译器，真正帮你调试的是像GDB或LLDB这样的调试器。

举一个生活化的例子：编辑器就是你写字用的纸和笔，编译器是把你写好的稿子拿去印刷的印刷厂，调试器则像一个放大镜，能让你逐字逐句检查印刷出来的书里哪里出了问题。VS Code把这三者拼在一个工作台上，但印刷厂得你自己去请。

我见过不少新手在VS Code里写了一上午代码，最后才发现自己电脑上根本没有编译器。这一步不解决，后面所有的配置都无从谈起。

1.2 为什么非要“按编译器分类”来讲

因为不同编译器的配置方式天差地别。

• GCC/MinGW-w64 用g++命令编译，调试器是GDB，配置时MIMode要写gdb；
• MSVC（Visual C++） 用cl.exe编译，调试器是VS Code 内置的 Visual Studio Debugger，配置时挂的是cppvsdbg；
• Clang 在 Linux下通常搭配lldb或gdb，在macOS下默认是lldb；
• 不同系统下的命令路径不同，Windows下还得关心中间没有空格的风险、环境变量是否生效。

如果不分编译器，只给一个通用配置，那你大概率会踩到“编译命令不对”“调试器起不来”“路径找不到”之类的坑。这篇文章把每种编译器的配置独立讲清楚，你只需要照着对应的那一段去配，就不会乱。

1.3 这三个编译器在实测中的差异

我自己平时三类编译器都会用到，简单说下体会：

• MinGW-w64（GCC）：Windows下最亲民的选择，免费、开源、安装快、命令行友好。适合绝大多数学习场景和中小型项目。
• MSVC：Windows平台的专业选择，和Windows API、Visual Studio生态无缝衔接。缺点是需要装的东西比较重，且cl.exe不像g++那样直接全局可用，必须借助开发者命令行环境来调用。
• Clang：编译速度快、报错信息友好，是macOS用户的事实标准。在Windows下也有MinGW-builds和LLVM官方构建版，但稍微小众一些。

一句话总结选型原则：你最终要部署到哪个平台，就用哪个平台默认的编译器；你是纯学习语法，MinGW-w64 最省事；你要写Windows桌面程序或者大量调用Windows API，MSVC会少很多折腾。

2. 环境准备：三平台、三类编译器逐一说清楚

2.1 Windows 上安装 MinGW-w64，别用太老的版本

先说Windows下的经典方案：MinGW-w64。注意这个名字后面带了“w64”，它和老的MinGW（32位为主）不太一样，安装时要选对。

最靠谱的安装方式是去MinGW-w64的官方GitHub仓库（WinLibs或niXman维护的构建）下载压缩包，解压到一个没有中文和空格的目录，比如C:\mingw64。解压完成后把C:\mingw64\bin加入系统PATH。

这里有个很经典的坑：如果你只装了“MinGW-w64 GCC 8.1.0”这类老版本，那么它的g++对C++17甚至C++11的新特性支持都不够好，跑std::filesystem这类库会报错。建议直接上较新的版本，WinLibs提供的构建会同时包含GCC和Clang，还能选择UCRT运行时，对中文路径的支持也更好。

装完后在命令行执行：

g++ --version

如果能看到类似g++ (MinGW-W64 x86_64-ucrt-posix-seh) 13.2.0的输出，就说明环境没问题。这一步是后面的所有操作的基础，建议先跑通再开VS Code。

2.2 Windows 上安装 MSVC 编译器，必须走“开发者命令行”

MSVC不能像g++一样直接全局使用，它藏在Visual Studio Build Tools的安装目录里，而且需要一堆环境变量才能正常工作。这些环境变量包括INCLUDE、LIB、PATH，手动设比较痛苦，微软其实提供了一个现成的入口，叫“Developer Command Prompt”或者“x64 Native Tools Command Prompt”。

安装方式有两种：

• 安装完整版Visual Studio（体积大，但省心）；
• 只安装“Visual Studio Build Tools”（约2-3GB，够用）。

装完之后，在开始菜单里找到“x64 Native Tools Command Prompt”，点开试一下：

cl

如果提示找不到命令，说明没装“使用C++的桌面开发”工作负载，回到安装器里把这个组件勾上。

MSVC编译C++时，一套最基本的编译命令是：

cl /EHsc hello.cpp

/EHsc表示启用C++异常处理，这个参数在MSVC下几乎是必须的。不建议在Linux或MinGW习惯下用-o那套参数来套MSVC，MSVC输出文件的参数是/Fe:name.exe，输入源文件不需要指定扩展名之外的内容，默认就能生成.exe。

2.3 Linux 与 macOS 上的 GCC/Clang 准备

Linux下一般自带GCC，检查一下：

g++ --version gdb --version

如果你的系统是精简版，可能没有g++也没有gdb，Debian/Ubuntu系执行：

sudo apt update sudo apt install build-essential gdb

macOS非常特殊：它默认的g++实质上重定向到了clang++，而且调试器不能用GDB（除非自己签名，很麻烦），要装Xcode Command Line Tools：

xcode-select --install

装完自带的编译器是Apple Clang，调试器是lldb。你在VS Code里配置时，MIMode要写lldb，和Linux下写gdb不一样。这个细节非常容易被人忽略，导致从Linux换到macOS的人配置照着写却跑不起来。

3. 从编译到调试：tasks.json 与 launch.json 的完整配置

3.1 tasks.json 是怎么被“调度”起来的

VS Code里编译这个动作是通过tasks.json来完成的。打开方式很简单：按Ctrl+Shift+P打开命令面板，输入Tasks: Configure Default Build Task，然后选择Create tasks.json file from template，再选择Others会生成一个空模板，我们手动往里填。

一个最基础的、适用于MinGW-w64的tasks.json如下：

{ "version": "2.0.0", "tasks": [ { "label": "C/C++: g++.exe build active file", "type": "cppbuild", "command": "C:/mingw64/bin/g++.exe", "args": [ "-fdiagnostics-color=always", "-g", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": [ "$gcc" ], "group": { "kind": "build", "isDefault": true }, "detail": "编译器: C:/mingw64/bin/g++.exe" } ] }

注意几个关键点：

• ${file}代表当前打开的源文件，${fileDirname}是当前源文件所在目录，${fileBasenameNoExtension}是没有扩展名的文件名。
• -g表示生成调试信息，不加这个，后面调试器就无法精确定位断点和变量。
• -o是指定输出文件名，Windows下生成.exe，Linux下一般生成同名文件。
• problemMatcher里$gcc是VS Code内置的GCC编译错误解析器，这样编译报错能直接在“问题”面板里点跳转。

如果你是Linux系统，把command改成/usr/bin/g++即可；macOS下如果用的Apple Clang，理论上也可以用g++命令（它指向clang），但对于一些只在GCC上支持的库会踩坑，更稳妥起见command写/usr/bin/clang++。

3.2 MSVC 的 tasks.json 配置有什么不同

MSVC的配置和GCC有个很大的区别：你不能在tasks.json里直接写cl完事，因为cl.exe依赖一堆环境变量，而这些环境变量是在开发者命令行里被初始化的。VS Code的解决方案是让任务直接通过开发者命令行的方式启动。

一种可靠的写法是：

{ "version": "2.0.0", "tasks": [ { "label": "MSVC build", "type": "process", "command": "cmd", "args": [ "/c", "\"C:\\Program Files\\Microsoft Visual Studio\\2022\\BuildTools\\Common7\\Tools\\VsDevCmd.bat\" -arch=x64 && cl /EHsc /Zi /Fe:${fileDirname}\\${fileBasenameNoExtension}.exe ${file}" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": [ "$msCompile" ], "group": { "kind": "build", "isDefault": true } } ] }

这段命令做的事情是：先用cmd /c启动一个命令行窗口，在里面执行VsDevCmd.bat设置好MSVC环境变量，然后再执行cl编译命令。/Zi是生成调试信息（等价于GCC的-g），/Fe:指定输出exe名称。这个写法在VS Code里实测可用，但对批处理转义敏感，反斜杠和引号只要错一个，任务就会起不来。

如果你觉得这样写太绕，还有一个更省事的思路：装一个叫“MSVC Environment”或“CMake Tools”的VS Code扩展，让扩展帮你去初始化环境。但既然是“完全指南”，我建议还是把原理弄明白，扩展只是帮你省掉手写命令的麻烦，底层的逻辑是一样的。

3.3 launch.json 是调试器的遥控器

编译配好之后，按F5会触发“调试(Launch)”，这时VS Code会读一个叫launch.json的文件，来决定用哪个调试器、加载哪个可执行文件、在哪个目录下启动。

下面这个配置适用于GCC/MinGW-w64环境：

{ "version": "0.2.0", "configurations": [ { "name": "C/C++: g++.exe build and debug active file", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "C:/mingw64/bin/gdb.exe", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "C/C++: g++.exe build active file" } ] }

要点逐个说：

• program：你要调试的可执行文件路径，必须和tasks.json里生成的文件一致。否则调试器会去执行一个不存在的文件。
• preLaunchTask：在启动调试之前先执行哪个任务。这里写的是上面tasks.json里的label，这样就实现了“按F5 → 先编译 → 再调试”的联动。
• miDebuggerPath：GDB调试器的具体路径。如果GDB不在PATH里，这里必须写全路径。
• externalConsole：设成false表示在VS Code内置终端里运行程序，适合调试控制台输出。如果程序需要交互输入（比如cin），建议设成true，会弹出一个独立的命令行窗口。
• setupCommands里启用pretty-printing，这样STL容器（vector、string等）在调试时能更友好地显示元素。

如果是Clang/lldb环境，需要改动的点有：MIMode改成lldb，miDebuggerPath改成/usr/bin/lldb或/usr/bin/lldb-mi，setupCommands里那条GDB专属配置删掉或保留也基本不影响启动。

如果是MSVC环境，type要换。MSVC对应的调试器不是GDB，而是VS Code内置的Visual Studio调试器，配置如下：

{ "name": "MSVC build and debug active file", "type": "cppvsdbg", "request": "launch", "program": "${fileDirname}\\${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "console": "integratedTerminal", "preLaunchTask": "MSVC build" }

注意type是cppvsdbg，没有MIMode，没有miDebuggerPath，因为这条调试链根本不经过GDB/lldb，而是直接走VS Code自己的Windows调试机制。

3.4 配置好之后实际跑一遍完整流程

配置文件的字面理解是一回事，真正跑起来又是另一回事。我以MinGW-w64环境为例，演示一个最简单的完整流程。

先写一个main.cpp：

#include <iostream> #include <vector> int main() { std::vector<int> nums = {1, 2, 3, 4, 5}; int sum = 0; for (int n : nums) { sum += n; } std::cout << "sum = " << sum << std::endl; return 0; }

保存文件，让VS Code当前活动文件是它。按Ctrl+Shift+B，你会看到VS Code在终端里执行tasks.json里定义的g++命令。如果编译成功，会在同目录下生成main.exe。

接着按F5，此时会执行preLaunchTask再次编译，然后启动GDB，程序运行到main函数入口处停住（因为我们没设断点，且stopAtEntry是false，所以直接跑到结尾）。如果你在sum += n;这一行打上断点并再次按F5，调试器会在断点处暂停，左侧“变量”栏里能看到nums的每个元素、sum的当前值，顶部的调试工具条可以执行“单步跳过”“单步进入”“继续”等操作。

这个流程跑通之后，你再看任何网上五花八门的配置，都会觉得不过如此。

4. 常见问题与排查技巧实录

4.1 “编译器未包含 main 类型”之类提示到底错在哪

很多新手在VS Code的“问题”面板里看到红色报错，里面写着“编译器未包含 main 类型”或者类似的信息，第一反应是看自己的代码，反复检查int main()写没写对。但实际上这个报错根本不是你代码的问题。

这个报错的根源通常有两个：一是编译器没有正确安装，或者PATH没有配置好，导致VS Code调用g++时找不到可执行文件；二是tasks.json里的command路径写错了，指向了一个不存在的编译器。解决思路是：先回到终端里手动执行g++ --version，确认编译器本身可用；然后在tasks.json里把command改成绝对路径，比如C:/mingw64/bin/g++.exe，注意路径分隔符在JSON里用正斜杠或双反斜杠都可以。

我曾经见过一个很隐蔽的情况：电脑上同时装了多个编译器，PATH里排前面的那个是坏的，导致VS Code调用到错误版本。这种时候在task里写死绝对路径反而最稳。

4.2 中文乱码问题：GBK 与 UTF-8 的边界战

在Windows下用VS Code写C++，中文乱码几乎是必然遇到的坎。根源在于Windows简体中文版的命令行默认代码页是GBK（936），而VS Code默认保存文件用的是UTF-8，两者的编码不一致。

处理方式有三种：

第一种，源代码编码统一用UTF-8，然后在程序开头加：

system("chcp 65001");

这个方案简单粗暴，但是换到Linux就不需要这行代码，属于平台相关写法。

第二种，在tasks.json里给编译器加一个选项，让编译出的程序以UTF-8模式运行。MinGW-w64新版一般默认就是UTF-8，但MSVC需要加/utf-8编译选项：

"args": ["/utf-8", "/EHsc", ...]

第三种，把VS Code终端设置成UTF-8：

"terminal.integrated.profiles.windows": { "PowerShell": { "source": "PowerShell", "args": ["-NoExit", "-Command", "chcp 65001"] } }

这个设置会让VS Code打开终端时自动切到UTF-8代码页。实测下来，第三种最通用，也不会影响代码本身的可移植性。

4.3 常见问题速查表

下面这张表是我根据这几年的实操经验整理的，遇到问题时直接对照着改就行。

4.4 两个独家的排查技巧

排查这类配置问题时，我习惯做两件事，每次都能把问题范围缩小一半以上。

第一件事是在VS Code里打开“终端”面板，手动执行tasks.json里那行编译命令。因为tasks.json本质上是把命令丢给shell去执行，你在终端里跑一遍，就能看到真正的报错信息。很多时候VS Code的“问题”面板只展示解析后的错误，但编译器的原始输出在终端里是完整的，包括路径错误、头文件缺失、链接失败这些细节。

第二件事是安装C/C++扩展后，多看看它的“C/C++配置(UI)”界面。这个界面的“编译器路径”一项会显示当前正在使用的编译器，如果VS Code识别出来的路径和你预期的不一样，你大概率能在这一步发现问题。我遇到过一个人，他电脑上装了两套MinGW，UI界面识别到了旧版，编译也一直用的旧版，但他以为自己在用新版，反复调代码也不对，就是这个原因。

5. 多文件项目、任务联动与调试实战

5.1 单个文件搞不定了，多文件项目怎么组织

前面所有的配置都建立在“编译单个源文件”的基础上。但真实项目很快就会拆分成多个.cpp和.h文件，你不能按F5只编译当前活动文件，否则就会看到一堆“未定义引用”的链接错误。

最常见也最轻量的方案是：先构建一套自己的tasks.json命令，把多个源文件一次性传给编译器。

以MinGW为例，把tasks.json里的参数改成这样：

"args": [ "-g", "${workspaceFolder}/*.cpp", "-o", "${workspaceFolder}/program.exe" ]

这里把${file}换成了${workspaceFolder}/*.cpp，意思是编译“工作区文件夹里所有.cpp文件”。要注意的是，用通配符编译时，如果某个cpp文件只是声明了类但还没实现对应函数，链接阶段照样会报错，这不是配置的锅，而是代码本身就不完整。

更规范的方案是用CMake。用CMake组织项目后，VS Code里装一个“CMake Tools”扩展，它会自动在 tasks.json 和 launch.json 之间协调编译和调试，你只需要在设置里指定CMAKE_C_COMPILER和CMAKE_CXX_COMPILER为你的编译器路径。CMake的好处是跨平台，Windows、Linux、macOS下用同一套CMakeLists.txt构建，免去手动维护tasks.json的痛苦。

5.2 调试实战：用条件断点和监视窗口定位bug

配置完只是万里长征第一步，真正写项目时，调试器才是你最好的朋友。我分享两个日常用得最多的调试技巧。

第一个是条件断点。在断点所在行的红点处右键，选择“编辑断点条件”，可以输入一个表达式，比如n == 3。这样程序只在变量n等于3时停下，其他时候直接略过。在排查循环里的越界、一次性大循环中的异常数据时，这个功能能把调试时间缩短一个数量级。

第二个是监视变量。在调试暂停时，左侧面板选择“监视”，输入nums，就能看到整个容器的内容；输入nums[0]能看到指定元素。配合GDB的pretty-printing，std::string、std::vector、std::map这类STL结构都能以可读方式展开，不用自己去算内存地址。

再补充一个容易忽略的细节：调试时如果发现变量值变化和预期不一致，先确认编译优化级别是-O0，否则编译器可能对代码进行优化，导致变量被优化掉、看不到真实值，甚至断点不命中。tasks.json里目前只写了-g，没有写优化级别，默认就是-O0，这是安全的。如果你手贱加了-O2，调试体验会非常痛苦。

5.3 一站式模板：把 tasks.json 和 launch.json 固化下来

为了让这篇文章真正可落地，我把一套在Windows + MinGW-w64环境下实测通过的完整配置放在这里，你可以直接复制进.vscode目录下的文件里。

tasks.json：

{ "version": "2.0.0", "tasks": [ { "label": "build", "type": "cppbuild", "command": "C:/mingw64/bin/g++.exe", "args": [ "-g", "-std=c++17", "${workspaceFolder}/*.cpp", "-o", "${workspaceFolder}/program.exe" ], "options": { "cwd": "${workspaceFolder}" }, "problemMatcher": [ "$gcc" ], "group": { "kind": "build", "isDefault": true } } ] }

launch.json：

{ "version": "0.2.0", "configurations": [ { "name": "Debug (gdb)", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/program.exe", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": true, "MIMode": "gdb", "miDebuggerPath": "C:/mingw64/bin/gdb.exe", "preLaunchTask": "build" } ] }

这套配置的优点是：不管你在工作区里打开哪个文件，按F5都会编译整个工作区的所有源文件，然后启动调试。适合试验阶段的小项目。缺点是你无法控制编译顺序和链接顺序，如果真的引入第三方库，还是得回归到CMake或Makefile体系。

如果你的项目引入了第三方库，比如OpenCV、Boost等，需要在编译命令里补充头文件路径-I和库路径-L以及具体库名-l，格式如下：

"args": [ "-g", "-std=c++17", "-IC:/opencv/build/include", "-LC:/opencv/build/x64/mingw/lib", "-lopencv_core", "${workspaceFolder}/*.cpp", "-o", "${workspaceFolder}/program.exe" ]

这里-I告诉编译器去哪里找头文件，-L告诉链接器去哪里找库文件，-l后面跟的是具体的库名。这个语法在GCC/Clang和MinGW下通用，MSVC下对应的是/I和/link /LIBPATH:，差异不小，但理解了原理之后迁移起来也很快。

6. 从编译到调试之外：提升效率的几个小习惯

6.1 用代码片段自动生成 tasks.json 和 launch.json

配置写多了之后，你会发现每次新建项目都要重新手动创建.vscode目录和两个JSON文件，其实很繁琐。我的做法是把这两份配置存成用户代码片段，通过VS Code的Preferences: Configure User Snippets创建一个名为cpp-project.json的片段，输入cpps就能自动生成完整配置。

片段内容大致如下：

{ "C++ Project Config": { "prefix": "cpps", "body": [ "{", " \"version\": \"0.2.0\",", " \"configurations\": [", " {", " \"name\": \"Debug (gdb)\",", " \"type\": \"cppdbg\",", " \"request\": \"launch\",", " \"program\": \"${workspaceFolder}/program.exe\",", " ...", " }", " ]", "}" ], "description": "Insert C++ debug config" } }

这样每次新建项目，输入cpps回车，配置就出来了，改一下编译器路径就能用。我测试过，这个习惯能让配置时间从10分钟压缩到1分钟以内，尤其是对经常用VS Code开新项目的人来说，非常划算。

6.2 用“问题”面板配合编译错误速览

VS Code的“问题”面板在编译时非常有价值。它会解析tasks.json里的problemMatcher，把编译器的报错结构化地列出来。你可以直接点击错误条目，跳到对应源码位置。

这里有个使用技巧：当编译报出一大堆错误时，先看第一个，改完重新编译，往往后面的一堆错误都会消失。因为C++的编译错误经常是“连带”的，一个头文件写错，会导致后面所有使用这个头文件的地方都报错。如果你逐条修，效率极低；只修最前面的，然后让编译器重新报，才是正确节奏。

6.3 配置项与系统环境到底怎么配合

最后想说一个容易被忽略的概念：VS Code里的很多路径和你系统的PATH是两套逻辑。你在系统环境变量里配置了C:\mingw64\bin，意味着在cmd和PowerShell里可以直接敲g++，但VS Code的tasks.json里command如果不写全路径，它会依赖自己的shell环境来查找。这个查找顺序通常是：VS Code继承的PATH → 用户PATH → 系统PATH。

所以如果你按照我的示例配置，command写成C:/mingw64/bin/g++.exe绝对路径，就彻底绕开了PATH查找顺序的问题。同理，如果你的GDB不在PATH里，launch.json的miDebuggerPath也要写绝对路径。别怕路径里有反斜杠或者空格，JSON里用双反斜杠转义，或者干脆用正斜杠，都是没问题的。

我记得有次帮一个朋友远程看问题，他配置里写的g++能编译但gdb起不来，我一看，他的GDB没装到MinGW目录里，而是单独装了个独立版，路径完全没加到PATH。最后把miDebuggerPath改成他独立GDB的全路径，问题立刻解决。这种“编译器在、调试器不在”的情况非常典型，建议配置完成后第一时间验证两件事：g++ --version和gdb --version，两个都能通过，再进行调试，否则后面全是坑。

结尾

编译和调试环境配置这件事，刚开始确实比较劝退。但只要你把“编辑器、编译器、调试器”这三者职责搞清楚了，再按编译器分类去理解各自的配置方式，你会发现VS Code的这套任务机制其实非常透明——tasks.json就是编译方案的说明书，launch.json就是调试方案的说明书。

我自己在Windows、Linux、macOS之间来回切换了几年，踩过的坑全部集中在环境变量、路径分隔符、调试器协议这三类问题上。这篇文章尽可能把每一种情况都覆盖到了，希望能帮你省下当初我省掉的那些时间。最后还是那句话：配置完成的第一时间，先到命令行手动确认编译器和调试器各自能运行，再进VS Code折腾，顺序反了的话，你会在配置里绕很久很久。