Visual Studio Code配置C/C++环境，这件事在很多新手看来很麻烦，因为VSCode本身只是一个编辑器，真正负责编译和调试的是另外一套工具链。如果只装了VSCode和插件，却不知道还要装编译器，那不管你配置多久，最后都会卡在“找不到gcc”或者“无法打开cpp文件”。这篇文章就把整个流程拆开讲：从VSCode安装、C/C++扩展安装、MinGW编译器配置，到tasks.json和launch.json的完整写法，再到常见的中文乱码、调试器不启动、输出窗口不显示结果等坑。内容适合刚接触C/C++编程、想从Dev-C++或旧版IDE换到VSCode的读者，也适合已经在用VSCode但调试一直没跑通的开发者。
1. 先搞清楚VSCode跑C/C++到底需要哪几样东西
1.1 VSCode本身不负责编译，它不是传统意义上的IDE
很多刚入门的人会把Visual Studio Code理解成一个自带编译器的集成开发环境，实际上不是。VSCode的定位是“代码编辑器”，它通过文件夹组织代码，通过扩展来补全语法、跳转、格式化等功能。你写出来的C代码想变成可执行文件，需要调用编译器；想单步执行、看变量值，需要调用调试器。这两样东西，VSCode默认都没有自带。
所以配置C/C++环境，本质上就是做三件事：
- 安装一个能写代码的编辑器，也就是VSCode。
- 安装一个能编译C/C++的编译器，比如MinGW-w64或MSVC。
- 安装VSCode官方C/C++扩展，让编辑器能和编译器、调试器沟通。
理解这个逻辑之后，配置流程就不再神秘。很多人配置失败，不是因为哪一步特别难，而是因为不知道编译器、调试器、编辑器三者之间的关系。比如你只装了VSCode和插件，编译时会提示“g++不是内部或外部命令”，这就是系统里没有注册编译器路径。反过来，只装了MinGW但没装插件，VSCode也能当普通文本编辑器用，但没有任何语法提示和调试能力。
1.2 2026年选编译器有什么讲究
C/C++编译器选择，主要看操作系统和学习阶段。Windows环境里，最常见的方案是MinGW-w64，它提供了Windows版本的GCC和G++，也有配套的GDB调试器。网上很多教程里写的MinGW，实际上指的就是MinGW-w64，早期32位版本已经很少用了，新机器建议直接找64位版本。
如果是在Linux环境，系统通常自带GCC和GDB，安装命令一般是sudo apt install build-essential gdb。macOS上则用Clang，命令是xcode-select --install。
Windows还有一种选择是MSVC，也就是Visual Studio那套C++编译工具链。它的优点是调试体验和Windows API支持很好，缺点是体积大、命令行习惯和GCC不同，新手配置起来容易懵。早期教程里常见的Dev-C++，用的其实是老版MinGW，虽然开箱即用，但编辑器本身很老，补全和调试体验已经跟不上现在的主流工作流了。
我的建议是，2026年从零开始学C/C++，Windows上优先用MinGW-w64 + GDB，配合VSCode，整体体积小、调试够用、命令行习惯也跟Linux一致。如果是做Windows桌面图形程序、或者要用微软官方库，再切换到MSVC也不迟。
1.3 需要提前准备的软件和版本
在正式配置之前，先把自己机器上的条件确认一遍：
- 操作系统：Windows 10或Windows 11，64位系统优先。
- 网络环境：能够访问VSCode官网和扩展市场，下载扩展和编译器安装包需要网络。
- 可用磁盘：VSCode安装包约100MB，MinGW-w64解压后约1GB，扩展插件只占几十MB，整体不大，但建议留出2GB以上空间避免安装中断。
- 管理员权限：安装VSCode和配置环境变量，通常需要管理员权限操作。
如果你电脑上已经装过其它版本的GCC、Clang或者Visual Studio，安装时要注意环境变量里的路径顺序。多个编译器同时存在时，系统会按PATH变量顺序找到第一个匹配的gcc命令。曾经遇到过装了新版MinGW之后，命令行输入的却是旧版gcc，就是因为旧版路径排在前面。这种情况卸载旧编译器之后重新配置就能解决。
2. VSCode安装和C/C++扩展配置
2.1 VSCode安装时要注意什么
VSCode官网直接下载Windows版安装包，双击启动。安装过程中有几个选项值得留意：建议勾选“添加‘打开文件夹’到Windows资源管理器上下文菜单”，以及“将‘通过Code打开’操作添加到目录上下文菜单”，这样以后右键文件夹就能直接用VSCode打开项目。如果安装时忘了勾选，进入VSCode后通过“文件 - 添加文件夹到工作区”也能达到同样效果。
安装完成后第一件事不是急着装插件，而是打开一个空白文件夹，把这个文件夹作为后续C/C++项目的根目录。VSCode的配置是基于工作区的，你在某个文件夹里写的.vscode配置，只对这个文件夹生效。如果不建立文件夹，直接打开单个.c文件写代码，也能编译，但调试配置存放位置会很别扭，不适合后面扩展成多文件项目。
安装VSCode时如果提示磁盘空间不足，或者安装过程卡死，最常见的原因是系统临时目录没有写权限。建议关闭杀毒软件实时监控后再安装，安装目录也尽量不要用中文路径或者带空格的路径，虽然新版本VSCode对中文目录兼容性已经好了很多，但编译器对中文路径的支持仍然不稳定，后面调试时容易出奇怪问题。
2.2 推荐安装哪几个扩展
打开VSCode左侧扩展商店，搜索“C/C++”，认准微软官方发布的C/C++扩展，发布者名称是Microsoft，图标是蓝底C++。这个扩展负责语法高亮、IntelliSense代码补全、调试器接口、错误波浪线提示，是整个环境中最关键的一个插件。
除了官方C/C++扩展之外，还有几个实用的：
- Code Runner：选中或右键直接运行单文件，方便刷题和快速测试。
- Chinese (Simplified) Language Pack：中文界面，没用过英文界面的可以装。
- CMake Tools：如果后面要管理多文件项目，这个插件能简化CMake配置。
- Bracket Pair Colorizer 或 VSCode内置的彩色括号：当函数嵌套比较深的时候，方便看对应关系。
不要一次性装太多插件。我在实际使用中发现，有些插件会抢占快捷键，比如Code Runner默认使用Ctrl+Alt+N，而某些输入法或截图软件会占用类似快捷键，需要去快捷键设置里改掉冲突。插件不是越多越好，C/C++开发核心就一个官方扩展，Code Runner是提升效率的辅助。
2.3 安装扩展后先检查什么
安装完C/C++扩展之后，打开任意一个.cpp文件，VSCode右下角应该会提示选择编译器和调试器。如果没有提示，可以通过命令面板执行“C/C++: Edit Configurations (UI)”来手动设置。需要注意，这个阶段即使提示找不到编译器也没关系，因为编译器还没安装，重点是看扩展能不能正常加载。
如果写完代码后没有语法高亮，或者#include <stdio.h>下面出现红色波浪线，说明IntelliSense没有找到编译器路径。这个问题通常不是扩展坏了，而是编译器路径还没有配置好。等MinGW-w64安装完，配置好环境变量，再重新加载窗口（Ctrl+Shift+P中输入 “Developer: Reload Window”），红色波浪线一般就会消失。
3. MinGW-w64安装与环境变量配置
3.1 怎么下载和安装MinGW-w64
MinGW-w64的下载方式主要有两种。一种是去SourceForge或GitHub找最新发布包，另一种是使用包管理器，比如MSYS2。对新手来说，我更推荐通过MSYS2安装，因为MSYS2会帮你处理版本依赖和路径，避免下载到旧版或缺失文件的工具链。
如果使用MSYS2，流程是这样的：
- 到MSYS2官网下载安装包，安装到
C:\msys64。 - 打开MSYS2终端，执行
pacman -S mingw-w64-x86_64-gcc。 - 再执行
pacman -S mingw-w64-x86_64-gdb，安装调试器。 - 最后把
C:\msys64\mingw64\bin添加到系统PATH环境变量中。
安装完成后，打开命令提示符，输入gcc --version，如果能看到版本信息，说明编译器已经可以被系统找到。输入gdb --version，能看到调试器版本，说明调试器也装好了。
如果不想用MSYS2，网上也有叫“MinGW-W64-builds”的独立压缩包。下载后解压到固定目录，比如C:\mingw64，然后手动把C:\mingw64\bin加入PATH。手动解压的好处是干净，缺点是没有自动升级机制，后续更新工具链都要自己来。
3.2 环境变量配置容易踩哪些坑
配置环境变量时，最容易出问题的不是找不到系统设置入口，而是把路径写错。很多人的MinGW实际装在D:\software\mingw64，但环境变量里写的是C:\mingw64\bin，命令提示符当然找不到。另一种情况是只配置了用户变量，没有配置系统变量，于是只有当前用户能用，如果是共享电脑或者需要服务运行，就很容易踩坑。
配置完成后，一定要重新打开终端再验证。我见过不少人在配置完环境变量后，忘了关掉旧的命令行窗口，直接输入gcc，结果提示找不到命令。这不是配置没生效，而是旧窗口没有重新读取环境变量。解决办法是关闭所有CMD和VSCode窗口，重新打开。
另外，检查gcc --version时，如果显示的版本和你刚安装的不一致，说明PATH里存在多个GCC路径，系统优先找到了旧的。我建议进入“系统属性 - 高级 - 环境变量”，把所有可能和MinGW相关的路径都整理一遍，把你要用的版本路径移动到最上面。
3.3 安装完成先写一个最小的C程序验证
编译器安装完，第一步不是急着配置VSCode，而是先在命令行手动编译一次。新建一个文件夹，比如D:\cpp_demo，在文件夹里新建hello.cpp，输入以下内容：
#include <iostream> using namespace std; int main() { cout << "Hello, VS Code" << endl; return 0; }在命令行切换到该目录，执行：
g++ hello.cpp -o hello.exe ./hello.exe如果命令行输出“Hello, VS Code”，说明编译器没问题。这个步骤很关键，它能区分问题是出在编译器安装上，还是出在VSCode配置上。命令行能编译，但VSCode里编译失败，那问题一定在VSCode端的配置；命令行都编译不了，那就要回头查环境变量，而不是继续折腾launch.json。
4. 创建C/C++项目并配置编译任务
4.1 VSCode工作区结构和项目目录
VSCode打开一个文件夹之后，这个文件夹就是一个工作区。你可以在这个文件夹下自由创建.c、.cpp文件，也可以创建include、src等子目录存放头文件和源文件。VSCode的配置文件统一放在根目录下的.vscode文件夹里，这个文件夹默认是隐藏的，你不需要手动创建，配置编译和调试保存时，VSCode会自动生成。
这里要养成一个习惯：一个项目对应一个文件夹。不要把所有练习代码都堆在桌面上的同一个文件夹里，否则当你在VSCode里按Ctrl+Shift+B编译时，它不知道你要编译哪个文件。虽然可以手动指定编译哪个文件，但文件多了以后容易混乱。我见过很多初学者在同一个文件夹里放了几十个练习程序，最后分不清哪个是当前要跑的，调试时启动的是不是最新编译的可执行文件，也因此很难排查问题。
针对写C语言题目的场景，你可以建一个根目录叫C语言练习，然后在里面按课程、章节建子文件夹。编译配置放在根目录，比如01_C基础这个子目录，只放题目对应的源文件，这样就比较清晰。
4.2 配置tasks.json实现编译
在VSCode中按Ctrl+Shift+P，输入“Tasks: Configure Default Build Task”，VSCode会尝试扫描系统里的编译器，并生成一个tasks.json文件。如果扫描不到，可以手动创建.vscode/tasks.json，写一个最简单的编译配置。
以下是一个兼容大多数MinGW环境的tasks.json配置：
{ "version": "2.0.0", "tasks": [ { "label": "C/C++: g++ build active file", "type": "shell", "command": "g++", "args": [ "-g", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": ["$gcc"], "detail": "编译当前文件" } ] }解释几个关键字段：
command：要执行的命令，这里是g++。args：传给g++的参数。-g表示生成调试信息，后面调试器才能使用断点；${file}表示当前打开的源文件；-o指定输出文件名。group：把该任务设置为默认编译任务，按Ctrl+Shift+B就能触发。problemMatcher：让VSCode能解析gcc输出的错误信息，并在编辑器中显示红色波浪线和错误列表。
注意，上面这个tasks.json是“编译当前打开文件”的写法，适合单文件学习和刷题。如果项目里有多个.cpp文件，就需要改用CMake或者把所有源文件都列在args里，否则会漏掉部分源文件导致链接阶段报错。
4.3 编译任务配置完怎么验证
保存tasks.json后，打开hello.cpp，按Ctrl+Shift+B触发编译。如果一切正常，可以看到终端窗口执行了g++命令，并且没有任何报错输出。此时项目根目录下会生成一个hello.exe文件。
如果终端提示'g++' 不是内部或外部命令，说明编译器没装好，或者PATH没配置对。如果提示错误信息是undefined reference to main，说明你可能忘了写main函数，或者当前打开的文件不是源文件。需要注意，tasks.json里的${file}变量取的是当前激活的编辑器文件，如果你的活动标签页是别人的代码，或者是一个头文件，编译结果就会非常奇怪。
5. 配置launch.json实现调试
5.1 为什么需要launch.json
只配置tasks.json，能解决“编译”问题，但还不能解决“调试”问题。调试意味着你需要下断点、单步执行、查看变量数值、查看调用栈。C/C++扩展在调试器中会调用GDB，而GDB需要知道可执行文件路径、编译时是否带调试信息、当前工作目录等。这些配置放在launch.json里。
点开hello.cpp，按F5，VSCode会弹出调试配置选择界面。如果之前装了C/C++扩展，通常会自动出现“C++ (GDB/LLDB)”选项。选择之后，VSCode会生成一个.vscode/launch.json文件，然后你可以把配置改成下面这样：
{ "version": "0.2.0", "configurations": [ { "name": "C/C++: g++ debug active file", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "gdb", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "C/C++: g++ build active file" } ] }关键字段的作用：
program：要调试的可执行文件路径，这里和tasks.json的输出路径对应。miDebuggerPath：GDB调试器路径。如果已经配置好环境变量，直接填gdb就能找到。如果找不到，就填GDB的完整路径，比如C:\\msys64\\mingw64\\bin\\gdb.exe。preLaunchTask：在调试之前自动编译，也就是按F5时先执行编译任务，这样保证你调试的程序是最新的。externalConsole：是否使用外部控制台窗口。设成false时，程序输出会在VSCode终端里显示；Set成true时，会弹出一个黑色控制台窗口，适合需要交互输入的程序。stopAtEntry：是否在main函数入口暂停，适合观察程序刚启动时的状态。
5.2 多文件、命令行参数和Debug模式
当项目有多个文件时，上述配置中preLaunchTask需要修改。tasks.json不能只编译当前文件，要么把所有这些源文件都列到args里，要么升级为CMake。如果你想快速上手，可以这样改tasks.json里的args：
"args": [ "-g", "${workspaceFolder}/*.cpp", "-o", "${workspaceFolder}/main.exe" ]这条命令会把当前工作区根目录下所有.cpp文件都交给g++编译。但如果.cpp文件分布在多个子目录，或者你只想编译一部分源文件，这种做法就不够用了，建议学习CMake。
调试程序如果需要命令行参数，比如你写了一个排序程序，需要从终端传入数据文件路径，就在launch.json的args字段里添加参数，例如：
"args": ["input.txt", "output.txt"]5.3 调试界面的基本操作
按F5启动调试后，编辑器左侧边缘点击即可设置断点，红点表示断点。程序运行到断点处会暂停，此时可以查看“变量”面板，C/C++扩展会把局部变量、全局变量、函数参数分门别类显示。你还可以在“监视”窗口中输入表达式，比如输入a + b，程序暂停时会实时计算值。
单步操作有几个常用快捷键：F10是单步跳过，F11是单步进入，Shift+F11是单步跳出。调试是理解C/C++指针、引用和函数调用栈的最佳工具。比如数组越界这种很难直接看出来的问题，用调试模式观察变量值变化，定位会比反复printf快很多。
6. 最常见的问题排查清单
6.1 编译成功但终端没有输出、中文乱码
编译成功了，但程序没有任何输出，最常见的原因是把可执行文件当成了当前编译对象。比如你打开的是a.cpp，但tasks.json配置的是编译另一个目录的代码；或者你按F5前，没有把包含main函数的文件设置为活动文件。检查方法很简单：看终端中g++实际编译的是哪个文件路径。
中文乱码是C/C++在Windows环境中的经典问题。根源在于Windows控制台默认代码页是GBK，而VSCode里的源文件通常保存为UTF-8。在输出中文的代码里，可以先在main函数开头添加设置：
#include <iostream> #include <windows.h> using namespace std; int main() { SetConsoleOutputCP(CP_UTF8); cout << "中文输出" << endl; return 0; }这能解决一部分Windows下UTF-8输出的乱码问题，但要注意这段代码在Linux下不能编译，因为windows.h不跨平台。如果你希望代码同时能在Windows和Linux上编译，需要加宏判断，或者直接改用C语言风格输出并保持系统代码页一致。更稳妥的做法是统一把源文件保存为UTF-8 with BOM，这样Windows编译时会保留BOM，编译器能识别编码。
6.2 调试器启动失败、无法打开exe
按F5之后，如果弹出“无法找到gdb”或“Unable to start debugging”，优先检查两处。第一，确认GDB安装且可以在命令行中使用，输入gdb --version验证。第二，确认launch.json里miDebuggerPath的路径与实际安装路径一致。如果用的是MSYS2环境，路径中要写成C:\\msys64\\mingw64\\bin\\gdb.exe，注意在JSON中反斜杠需要写两个。
还有种情况是，编译生成了exe，但调试时GDB提示“可执行文件不存在”。这通常不是文件真不存在，而是路径里面设置了特殊符号。比如工作目录路径包含#、空格或中文，某些GDB版本对路径解析会有问题。解决办法是把项目目录移到C:\或D:\根目录下的纯英文目录。
6.3 “无法打开包括文件: iostream.h”或“no such file”
这个问题严格来说不是VSCode的锅，而是源文件本身写错了。C++标准库头文件不带.h后缀，正确写法是#include <iostream>。有些老教材还会写#include <iostream.h>，那是很早期的Turbo C++和VC 6.0时代的写法，2026年的GCC和MinGW早就把它移除了。同理，C语言中标准头文件虽然保留.h后缀，但也应该包含系统标准头文件路径。
如果确认头文件写法没问题，却还是报找不到，就检查编译器安装是否完整。MSYS2环境下，可以用pacman -S mingw-w64-x86_64-gcc重新安装一遍，确认没有缺少包。VSCode的IntelliSense报找不到可以暂时不理会，因为那是编辑器侧的索引问题，只要实际编译通过，就说明编译器能找到。
6.4 快捷键冲突和插件冲突
之前提到过Code Runner和输入法快捷键冲突，在开发过程中确实烦人。如果按下Ctrl+Alt+N没反应，按Ctrl+Shift+P打开命令面板，输入“首选项：打开键盘快捷方式”，搜索运行相关命令，改成你自己的习惯键位。C/C++扩展本身的一些命令，比如“C/C++: Run Code Analysis”，也可能占用快捷键，导致无法使用其他功能，在快捷键设置里逐个检查即可。
还有一个常见问题：同时安装了C/C++和Code Runner，按F5时弹出的调试配置界面可能会变成Code Runner的菜单。需要在launch.json里明确当前配置文件，或者在启动调试时选择正确的配置。通常按F5后，VSCode右下角会弹出配置选择下拉框，不要急着按回车，看清是不是C++ GDB配置。
7. 从单文件练习到多文件与CMake
7.1 什么时候该从单文件切到CMake
如果只是刷算法题、写课程作业、编程竞赛练习，单文件的tasks.json完全够用。但当你开始做课程设计、项目实战，代码文件超过三五个，单文件编译就变得难以维护。你不仅要手动把所有文件列在编译命令里，还要处理头文件搜索路径、链接外部库、区分Debug和Release等。这时候，应该切换为CMake工具链。
CMake不是一个编译器，它是一套“项目构建系统”，用来描述项目里有哪些源文件、依赖哪些库、生成什么可执行文件。VSCode里安装CMake Tools扩展后，可以直接通过配置文件生成、编译、调试，省掉了手写tasks.json编译命令的步骤。
7.2 MInGW和CMake的典型配合
在项目根目录创建CMakeLists.txt，内容至少包含：
cmake_minimum_required(VERSION 3.10) project(MyProject) set(CMAKE_CXX_STANDARD 17) add_executable(main main.cpp utils.cpp)然后按Ctrl+Shift+P，执行“CMake: Configure”，选择GCC工具链，VSCode会自动生成build目录和编译配置。之后按F7编译，按F5调试，注意此时要让CMake Tools接管调试，而不是走之前的单文件launch.json。
调试时，程序路径会变成build/main.exe，launch.json里的program字段需要改为${workspaceFolder}/build/main.exe。如果你使用CMake Tools扩展，它可以在C++扩展启动调试时自动设置正确的路径，不一定需要手动改。
7.3 如何组织代码让调试更顺利
无论用单文件还是CMake，代码组织都会直接影响调试体验。建议尽早把声明和定义分开：头文件放函数声明、类定义和结构体定义，源文件放具体实现。调试时，你可以直接跳到某个函数的实现处打断点，不用在巨型main函数里翻来翻去。
对新手来说，写代码时一定要把main函数放在最后一个，或者至少不要放在文件中间。早期常见的报错是函数声明靠后，调用在前，导致编译报错“未声明的标识符”。调试时，一个文件只要有一个编译错误，整个程序就跑不了。所以先保证代码能通过编译，再谈调试断点。
8. 我个人的配置建议和日常习惯
8.1 新环境配置的推荐顺序
每次我换电脑或者重装系统，配置新环境的顺序都有固定的步骤，分享出来供参考：
- 安装VSCode。
- 安装MinGW-w64或MSYS2，并配置环境变量。
- 在命令行验证
gcc --version和gdb --version。 - 安装C/C++扩展和Code Runner。
- 新建一个项目文件夹，写一个hello.cpp，先命令行编译，再VSCode编译。
- 配置tasks.json和launch.json，按F5验证断点调试。
- 全部跑通后，再考虑装其他扩展，比如Git、CMake、文档美化主题。
这个顺序的好处是，每一步的依赖关系都是清晰的。如果在第五步卡住，你会明白到底是编译器没装好，还是VSCode配置有问题。我见过有人一开始就装了十几个扩展，结果编译失败后，把所有问题都归结为“扩展冲突”，实际上只是编译器路径没配置。
8.2 写C/C++时保持好用的代码习惯
调试是工具，代码习惯才是让工具发挥作用的根本。VSCode中配置好clang-format后，我通常会在保存文件时自动格式化代码，避免括号和缩进间距不一致影响阅读。在C/C++扩展设置中搜索“Format On Save”，打开保存时自动格式化，Esc和Tab会自动调整。
写代码时尽量做到一个函数只做一件事，变量命名不要用a、b、tmp这类无意义词。调试排查问题时，清晰的命名能让你在变量窗口里一秒分辨哪个变量是哪个。还有一个小习惯是，每写一个逻辑块就立刻测试一次，不要等写了几百行再一次性编译，否则报错信息成堆，新手很容易失去信心。
8.3 遇到报错先不要急着删配置
VSCode配置C/C++环境，很多错误不是一次性能弄好的。最常见的情况是，你照着某篇文章配置好后，因为编辑器找不到编译器就怀疑配置有问题，然后去网上找另一个方案，配置覆盖来覆盖去，最后反而更难排查。
我自己处理这类问题的思路是：先看终端里最上面一行的命令是什么，看它有没有执行成功。如果命令报的是“不是内部或外部命令”，说明是系统和编译器路径的问题，跟VSCode无关。如果命令执行了，但编译报错，那就把报错信息逐行读完，第一行往往指明了出错文件和行号。真正需要重装VSCode的情况极少，大部分问题都在工具链和路径上面。
如果你的launch.json、tasks.json改来改去都没效果，也不用急着重装软件。可以先新建一个空文件夹，用最简配置跑通一次hello程序，再把原来项目里多余的文件逐步加进来。排查这种“干净环境能跑，项目里跑不了”的问题，往往最后会定位到某个特殊命名的文件，或者某个只在这个项目里出现过的头文件依赖。保持耐心，按照从简到繁的顺序排查，会比反复搜索各种教程高效很多。
