企业官网建设流程全解析

如果你还在用老一代IDE写C语言作业，或者在大型开发套件里被一堆用不上的功能淹没，那我强烈建议你试试VSCode。我最早接触C/C++时也老老实实跟着教程用老牌IDE，界面又旧，补全又弱，后来转到VSCode，前后折腾了一个晚上才把环境彻底跑通。回头看，这套配置的核心其实非常清楚：装好编辑器、装好编译器、配好调试器，三者打通就完事了。这篇博文要解决的，就是帮你把这套流程走通，照着做二十分钟就能开始写代码，而不是把时间浪费在“配置环境”这件事本身上。

先说清楚这篇内容适合谁。正在上C/C++课程、需要在电脑上完成作业和练习的学生；从重量级开发套件迁移到轻量编辑器、不想再背全家桶负担的开发者；以及需要写算法Demo、嵌入式上位机小工具、本地测试程序的工程师。无论你用的是Windows、Linux还是macOS，核心思路完全一致，区别只在编译器怎么装。

还有一点必须提前讲明白：VSCode本身只是一款编辑器，它不会把源代码变成可执行文件。你需要一个编译器，例如gcc、g++或者clang，还需要一个调试器，例如gdb。编辑器负责写代码，编译器负责翻译，调试器负责在程序出错时帮你定位问题。这三者配合起来，才算一个完整的C/C++开发环境。

1.1 开发环境里的每个角色分别负责什么

• 编辑器（VSCode）：负责写代码、高亮语法、自动补全、显示错误提示，还有日常的项目文件管理。
• 编译器（gcc/g++）：把.c或.cpp文件翻译成可执行文件，文法错误在这里会被报出来。
• 调试器（gdb）：让程序在断点处停下来，逐行执行，查看变量、寄存器和调用堆栈的变化。
• 构建工具（Make/CMake）：在源文件多起来之后，把一堆.c/.cpp文件按照规则组织成最终程序。单文件阶段可以先不碰，但工程大了之后绕不开。

打一个生活化比方：VSCode是灶台和菜板，编译器是燃气灶，负责把食材做熟，调试器则是温度计和切菜时的检查工具，让你知道是哪一步煮老了、哪一步切错了。很多新手刚接触时只盯着灶台看，忘了还得接燃气，这就是环境搭不起来的核心原因。

这套方案对比大型开发套件的优势非常明显，编辑器启动速度快、扩展生态丰富、跨平台配置逻辑统一。你在这台机器上学会的JSON配置思路，换到Linux服务器、macOS笔记本上依然适用，不会因为换了开发工具就推倒重来。

1.2 先想清楚几个方案，别盲目抄配置

网上关于“VSCode配置C/C++环境”的教程一抓一大把，但你如果只抄代码不看不理解，很容易死在“环境变量没生效”或者“IntelliSense找不到头文件”这种问题上。常见的方案大概有下面这些，我先给一张对比表，再解释为什么Windows上我会首选MinGW-w64。

Windows上我推荐MinGW-w64而不是用大型IDE自带编译器，原因是它足够简单。你只需要下载一个绿色压缩包，解压之后把bin目录加到环境变量，命令行里就能直接使用gcc、g++和gdb，没有注册组件、没有COM对象、没有一堆后台服务。对于初学者来说，少一个干扰项，就少一分踩坑概率。

如果你在Linux上开发，那不需要纠结，apt或者dnf直接装GCC和GDB就好。macOS 用户先装命令行工具，再酌情用Homebrew安装新版GCC，或者直接用系统自带的clang。VSCode配置文件的写法基本通用，不同之处主要是编译器路径。

2. 方案选型背后的原理，以及每个组件为什么这样选

我见过不少同学把配置代码抄进去还是编译失败，原因往往不是配置文件写错了，而是没理解组件之间的依赖关系。环境搭建的第一步不是打开VSCode，而是先把工具链在命令行里跑通。这一步的优先级高于任何配置文件的编写。

为什么这么说？因为tasks.json里的编译命令最终会调用g++，launch.json里的调试命令最终会调用gdb，c_cpp_properties.json里的compilerPath最终决定智能提示。这三个关键入口全部都指向底层的编译器。如果编译器本身没装好，那VSCode这边怎么折腾都是白费力气。

2.1 编译器到底选gcc还是g++还是clang

先说结论：写C语言用gcc，写C++用g++，这是同类工具在不同语言场景下的两个入口。gcc和g++的后端其实都是同一套编译过程，区别在于g++会自动链接C++标准库，也会把.c文件当C++处理。你要是写.cpp文件却用了gcc命令，经常会报undefined reference to std::cout，一看就是少了C++运行时库的链接。

clang和gcc在语法标准上各有细微差别，但对于课程作业和日常Demo来说没有本质区别。我建议初学的同学直接跟着教程用gcc/g++，因为搜索资料时这类关键词命中率最高。minGW-w64就是GCC在Windows上的移植版本，它把编译器、链接器和基本的构建工具打包在一起，解压就能用。

下载时还有一个容易踩坑的点：版本分支、线程模型和异常模型的组合。以x86_64架构为例，常见的有posix线程模型配seh异常模型，较新的版本都是这种组合。如果你的旧教程里让选win32线程模型加dwarf异常模型，那就得考虑是否匹配当前环境。尽量选较新的、带posix关键字的版本，后面如果要用C++标准库的线程功能会省很多事。

2.2 环境变量的原理，为什么非配不可

Windows系统在执行命令时，会按照一个叫PATH的环境变量中列出的目录顺序去查找可执行程序。你安装MinGW-w64之后，如果不把C:\mingw64\bin这个目录加进去，那在任意路径下输入gcc都会提示“不是内部或外部命令，也不是可运行的程序”。相反，如果配好了，任何位置都能直接启动gcc。

添加环境变量的操作步骤很简单：右键“此电脑”进入属性，打开高级系统设置，点击环境变量，在系统变量里找到Path，编辑它并新增MinGW的bin目录。需要注意，配置完成后必须重新打开终端窗口，否则环境变量不会在已有进程里生效。很多人配完环境变量仍然报错，大概率就是这里出问题。

我在本地实际测试时，更喜欢把MinGW装在C:\mingw64这种固定路径下，而不是默认解压到Downloads目录。因为之后所有配置文件里都要引用编译器路径，一个简短、没有空格的路径会让后续工作轻松很多。下载目录一旦被清理，整个环境就跟着崩了。

2.3 VSCode里的扩展选哪几个

VSCode本身是平台，C/C++的能力全靠扩展提供。最核心的是官方发布的C/C++扩展，它提供代码补全、IntelliSense、调试适配和编译任务识别，相当于把VSCode接上底层工具链的中介。没有它，你的.cpp文件就只是一个普通文本文件，连语法高亮都残缺。

第二个推荐安装CMake Tools扩展。虽然纯单文件教学阶段用不到，但只要进入多文件工程，CMake就是最通用的组织方式。与其到时候再装，不如一开始就装好。第三个是Code Runner，它可以一键运行当前文件，适合快速验证小片段，但注意它的运行方式默认不经过调试器，出了问题还是得回到官方插件。

还有一类扩展不建议跟风装一堆。有些同学刚开始就想把AI补全、代码统计、主题美化全套安排上，结果VSCode启动变慢，错误提示来源混乱，反而干扰学习。基础阶段保持轻量，先搞懂核心链路，之后想加再逐个加。

3. 实操：从零把环境跑通

进入实操环节。我会把Windows作为主讲述平台，中间穿插Linux和macOS的差异。你不需要背命令，照着敲一遍，理解每一步在做什么，第二遍就能自己完成。

3.1 安装VSCode和基础插件

去VSCode官方网站下载对应系统的安装包，Windows用户建议选64位版本。安装过程一路默认就可以了，比较值得关注的是“添加到PATH”这个选项，尽量勾选，这样之后在终端里输入code就能直接启动VSCode。把主题和语言随意改一改，如果英文界面不习惯，可以装中文语言包，但代码和配置文件名建议保持英文。

打开扩展面板，搜索C/C++，认准官方扩展并安装。再搜CMake Tools安装，然后安装Code Runner。装完之后重启VSCode，扩展才会激活。此时VSCode还无法编译C/C++，因为你机器上还没有编译器，别急着新建项目，下一步才是重点。

3.2 Windows下MinGW-w64安装与环境变量设置

操作分为四步，我拆开写。

第一步，下载MinGW-w64。建议去它的GitHub Release页面找最新的独立压缩包，一般叫x86_64-posix-seh之类，直接下载解压。也可以使用开源包管理器安装，例如Windows下的Scoop安装后执行一行命令即可，本质也是把工具链放到约定目录并配好环境变量。手动解压更能让你理解目录结构，这里以手动为主。

第二步，把解压后的文件夹移动到固定位置，比如C:\mingw64。这里强调不要放在中文目录或者带空格的目录，否则后面编译器路径出问题的概率极高。我以前见过一位同学把MinGW解压到了“软件安装”目录下，结果VSCode里引用路径时反复出错，最后重装才解决。

第三步，配置环境变量。按照前面说的方式打开PATH设置，新增一行C:\mingw64\bin。配好后打开一个新的命令提示符或PowerShell窗口，输入gcc --version，如果能看到版本号，就说明编译器已经被系统找到。再输入gdb --version，同样看到版本号，说明调试器也就绪了。

第四步，顺手测试编译能力。在任意目录新建一个hello.c，写入最简单的Hello World代码，然后在命令行执行gcc hello.c -o hello.exe，再执行hello.exe。这一步如果成功，说明你的机器已经具备了完整的C/C++编译能力，剩下的就是让VSCode把这些命令包装成可视化的按钮。

3.3 Ubuntu和macOS的快速安装

Ubuntu用户打开终端执行sudo apt update，然后安装build-essential和gdb。build-essential这个包会帮你装好gcc、g++、make等常用工具，相当于MinGW-w64里面那套核心组件的Linux版。安装完成后同样用gcc --version验证。

macOS用户先执行xcode-select --install安装命令行工具，系统会提供clang编译器和一些基础工具。如果你必须使用gcc，再用Homebrew执行brew install gcc安装新版GCC。注意macOS上gcc命令可能会指向clang，执行gcc --version的输出里能看到明显区别，多数情况下clang已经完全够用。

Linux和macOS不需要配置环境变量，因为包管理器会把可执行程序链接到系统标准目录。这也是很多人觉得在Windows上配置更麻烦的根本原因。后面的VSCode配置文件在三者之间基本通用，只需把编译器路径按平台分别调整。

3.4 验证命令行环境的完整示例

我想强调一种排查思路：所有VSCode层面解决不了的问题，最后都要回到命令行来验证。比如你写了一个程序，在VSCode里点运行没反应，这个时候打开系统终端，手动敲一版完整的编译命令，看看到底是编译器路径错了、还是源文件语法错了、还是输出路径不存在。命令行是最底层的事实来源，配置JSON只是调用了这些命令而已。

下面是一个完整流程参考：

mkdir cpp-demo cd cpp-demo code .

然后在VSCode里新建hello.cpp，写入：

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

按`Ctrl+Shift+``呼出终端，执行：

g++ hello.cpp -o hello ./hello

看到输出Hello from C++，说明工具链完全正常。接下来要做的，是把编译和调试这两条命令固化成VSCode里的配置文件，这样以后只需要按快捷键就能完成操作。

4. 工程化配置：四个JSON文件详解

VSCode会在项目文件夹下生成一个.vscode目录，里面通常会放tasks.json、launch.json、c_cpp_properties.json和settings.json。这四个文件就是C/C++环境搭建的核心配置文件。你不需要背下来，但必须理解每个文件是干什么的，否则换个目录又不会配了。

很多人喜欢复制别人的配置，这没问题，但复制前最好逐行看一遍。我下面的配置会配合注释和说明，解释每个字段的作用。

4.1 tasks.json：告诉VSCode怎么编译

打开你的C/C++源文件后，按Ctrl+Shift+P打开命令面板，输入Tasks: Configure Default Build Task，如果之前没有配置过，VSCode会列出可用的编译器模板，例如“g++ build active file”。选择后会生成一个基础的tasks.json，但你最好按照下面的例子补全参数。

{ "version": "2.0.0", "tasks": [ { "label": "build active file", "type": "shell", "command": "g++", "args": [ "-g", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe", "-std=c++17", "-Wall", "-fdiagnostics-color=always", "-fexec-charset=GBK" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": ["$gcc"], "detail": "使用 g++ 编译当前活动文件" } ] }

逐项拆开看。label是这个任务的名字，launch.json里会引用它，必须保持一致。type设成shell表示通过命令行执行，整条命令等价于你在终端里手动输入g++ -g 当前文件 -o 输出文件 ...。command是编译器入口，写C++用g++，如果只写C语言，建议改成gcc。

args是编译参数。-g要求生成调试信息，没有它，后续调试器将无法定位到源码行。${file}是VSCode内置变量，表示当前活动文件的完整路径。-o指定输出文件，这里生成一个与源文件同名的.exe。-std=c++17按C++17标准编译，如果你用的旧教程要求c++14也可以自行改。-Wall打开常见警告，建议保留。-fdiagnostics-color=always让编译错误在终端里彩色显示。-fexec-charset=GBK这个参数我在Windows下十分推荐，它让生成的可执行文件内部的字符编码匹配Windows控制台，能解决大量中文乱码问题。

group里把任务设为默认构建任务，这样按Ctrl+Shift+B就能直接触发。problemMatcher用来把编译器输出文本转换成VSCode的“问题”面板，方便点击跳转到出错行。写到这里你可能会发现，所谓配置VSCode环境，本质上就是把你在命令行里敲过的命令结构化保存到JSON里。

4.2 launch.json：告诉VSCode怎么调试

调试功能的入口是launch.json。最简单的生成方式：在源文件界面按F5，VSCode会提示选择环境，选择C++ (GDB/LLDB)，再选择g++ build active file，它会自动生成一个初步配置。然后你需要按照下面的示例微调。

{ "version": "0.2.0", "configurations": [ { "name": "C/C++ 调试当前文件", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "gdb", "setupCommands": [ { "description": "为 gdb 启用整齐打印", "text": "-enable-pretty-printing", "ignoreFailures": true }, { "description": "设置反汇编风格为 Intel", "text": "-gdb-set disassembly-flavor intel", "ignoreFailures": true } ], "preLaunchTask": "build active file" } ] }

这里最关键的是program和preLaunchTask。program告诉调试器去运行哪个可执行文件，它必须和tasks.json里-o的参数保持一致，否则会报“找不到文件”。preLaunchTask表示开始调试前需要先执行哪个编译任务，填的还是tasks.json里那个label。

MIMode表示调试器接口类型，这里用gdb。miDebuggerPath填写gdb命令，如果已经加入环境变量，直接写gdb即可；如果没有，就要写完整的路径，比如C:/mingw64/bin/gdb.exe。externalConsole设为false时，程序在VSCode集成终端里运行，新手这样比较方便；如果程序需要交互输入，且遇到输入不灵敏的问题，再考虑改成true弹出独立控制台。

setupCommands里的两项属于锦上添花。第一项为gdb启用pretty-printing，调试时查看std::vector和std::map会更友好；第二项把反汇编风格设为Intel，看汇编时更通用。ignoreFailures为true表示这些命令失败也不影响调试启动。

4.3 c_cpp_properties.json：让智能提示认识你的编译器

这个文件是很多新人困惑的来源。它的作用是告诉VSCode的C/C++扩展：你的编译器在哪、C和C++标准是什么、头文件去哪找。如果配置不对，代码可能编译正常，但编辑器里一行行红色波浪线，让人误以为代码写错了。

打开方式：在命令面板输入C/C++: Edit Configurations (UI)，会打开图形化配置界面，底层生成的就是c_cpp_properties.json。也可以手动创建，示例配置如下：

{ "version": 4, "configurations": [ { "name": "Win64", "includePath": [ "${workspaceFolder}/**", "${default}" ], "defines": [], "compilerPath": "C:/mingw64/bin/gcc.exe", "cStandard": "c11", "cppStandard": "c++17", "intelliSenseMode": "windows-gcc-x64" } ] }

includePath告诉IntelliSense扫描哪些目录来找头文件，${workspaceFolder}/**表示当前工作区所有子目录，${default}保持扩展自身的默认路径。compilerPath指向gcc可执行文件，注意斜杠要统一为正斜杠或双反斜杠，建议填绝对路径。部分教程会让填"compilerPath": "gcc"，这在环境变量正常时也能工作，但没有绝对路径稳定。

intelliSenseMode要与编译器匹配。Windows上的MinGW-w64填windows-gcc-x64，Linux填linux-gcc-x64，macOS填macos-clang-x64或macos-gcc-x64。如果填错了，代码补全和错误提示的准确性都会打折扣。

4.4 settings.json：全局和工作区的其他偏好

settings.json管理编辑器行为，可以在用户级别配置，也可以在工作区.vscode/settings.json里配置。我习惯在工作区放一份，这样整个项目共享相同的代码风格。

{ "files.encoding": "utf8", "editor.formatOnSave": true, "C_Cpp.default.compilerPath": "C:/mingw64/bin/g++.exe", "C_Cpp.default.cppStandard": "c++17", "C_Cpp.default.cStandard": "c11", "C_Cpp.errorSquiggles": "enabled", "C_Cpp.autocomplete": "default" }

files.encoding设为utf8是现代项目的主流做法，但要注意结合之前tasks.json里的-fexec-charset=GBK，编译出来的程序才能正确处理中文。editor.formatOnSave控制在保存时自动格式化代码，依赖clang-format插件或扩展内置格式化器。C_Cpp.errorSquiggles设为enabled让代码错误提示波浪线始终显示，排查问题时可以临时设为disabled排除干扰。

这里要提醒一句：全局用户设置影响所有项目，工作区设置只影响当前文件夹。新手在别人的电脑上或者换新项目时，经常会发现配置明明在，但代码提示没生效，十有八九是配置在了不该配置的层级。

5. 进阶一点：真实工程该怎么组织

单文件配置跑通后，你会很快进入多文件工程阶段。这是从“会写题”到“会做项目”的一道坎，我建议尽早建立用CMake组织工程的习惯。

5.1 多文件编译的底层逻辑

一个C/C++工程通常会有多个.cpp文件和一堆头文件。编译器处理时，需要把所有源文件都编译为目标文件，再链接成可执行文件。#include只是把头文件的内容展开到源文件里，并不会自动帮你编译另一个.cpp。

新手常见的错误是：有两个文件main.cpp和utils.cpp，main.cpp中#include "utils.h"，然后命令行只执行g++ main.cpp -o main，结果链接报错找不到某个函数的定义。原因很简单，你忘了把utils.cpp一起参与编译。正确的传统命令行写法是：

g++ main.cpp utils.cpp -o main

在VSCode的tasks.json里，如果仍然是单文件编译模式，就需要手动调整。一个偷懒的办法是把args里的${file}换成${workspaceFolder}/*.cpp，让它把当前目录下所有C++源文件都编译进去。这样做对小工程有效，但文件一多、依赖变复杂，最好还是用CMake。

5.2 用CMake统一管理项目

CMake是跨平台构建工具，它不直接编译，而是根据一个CMakeLists.txt文件生成对应平台的构建配置。它的优势是工程结构清晰、团队协作统一、第三方库集成方便。一个最小的CMake配置如下：

cmake_minimum_required(VERSION 3.10) project(MyProject) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(main main.cpp utils.cpp)

把这份文件放在项目根目录，然后在VSCode里安装的CMake Tools扩展会自动识别。点击界面底部状态栏的“Build”按钮就能完成构建，调试时的launch.json也可以通过生成相应的配置来对接。如果工程越来越复杂，比如引用了第三方库，只需要在CMakeLists里增加target_include_directories和target_link_libraries即可。

5.3 调试中很容易被忽视的实操技巧

配置好launch.json之后，按F5就能启动调试。很多人只会点“继续”和“停止”，其实几个高频动作值得熟练掌握：按F9在当前行打断点，按F10单步跳过，按F11步入函数内部，按Shift+F5停止调试。在左侧“运行和调试”面板里，可以添加监视表达式，实时查看变量变化。

调试C++的容器类型时，默认的变量展示常常不够直观。这里分享一个经验：在监视窗口里输入类似arr这样的数组名时，可以尝试把它强制转换为指针加长度，比如*(int(*)[5])arr，这样gdb会按数组方式展示内容。虽然写法看起来令人头疼，但在处理原生数组和底层数据时非常管用。

5.4 代码格式化和静态检查不能忽视

代码风格统一这件事，越早养成越好。VSCode里安装C/C++扩展之后，自带的clang-format能力足够日常使用。可以在settings.json中设置默认风格，例如"C_Cpp.clang_format_fallbackStyle": "{ BasedOnStyle: Google, IndentWidth: 4 }"。保存时自动格式化，团队里大家都用同一套规则，diff看起来也清爽很多。

静态检查方面，不用一开始追求太多工具。先用好编译器自带的-Wall，把警告当成错误一样重视。后续需要再引入clang-tidy或cppcheck，但别让工具列表占据学习的注意焦点，写代码的基本功才是第一位。

6. 常见问题与排查实录

下面是几个我实际遇到过的高频问题，按现象、原因、解决办法整理成速查表，再挑几个展开讲。

第一个典型案例：gcc在VSCode终端里不识别，但系统命令提示符里能用。这通常是因为你先启动VSCode，然后才修改的环境变量。解决方案是关闭VSCode重新打开，或者直接打开新的系统终端验证。如果新终端里能用，VSCode重启后也一定能用。

第二个典型案例：报错“无法打开源文件stdio.h”。命令行编译明明没问题，但编辑器里还是乱飘红。这个问题的根源是c_cpp_properties.json里的includePath没有指向编译器自带的头文件目录。既然stdio.h是编译器自带的，最简单的办法就是确保compilerPath指向正确的gcc.exe，然后把includePath中加一个${default}，让扩展自动追踪。

第三个典型案例：preLaunchTask“build active file”已终止，退出代码为2。这个提示只告诉你编译那个环节失败了，具体原因要看终端面板的编译输出。常见于路径中包含空格、源文件里语法错误、或者tasks.json里的command不在环境变量中。把编译命令复制到系统终端手动执行一遍，通常立刻能看出哪里出错。

关于“C/C++扩展二进制文件不兼容或不匹配”这种比较特殊的报错，通常和扩展自身的原生模块有关。解决办法是去扩展面板卸载掉C/C++扩展，然后重新安装最新版本。如果系统中既有32位又有64位程序的混乱情况，优先确认VSCode本身和你下载的MinGW版本都是64位，避免架构不一致。

中文乱码问题我在Windows上遇到最多。本质原因在于：你的源码文件是UTF-8编码，而Windows控制台默认代码页是GBK，运行时两个阵营就“打”起来了。我在tasks.json里加的-fexec-charset=GBK正是解决这个问题，它让可执行文件在运行时使用GBK编码输出中文，与Windows控制台保持一致。如果你的编译器参数里没有这个选项，也可以在终端里手动执行chcp 65001切换到UTF-8代码页，或者把源码另存为GBK编码，殊途同归。

还有一个容易忽略的问题：调试时输入中文偶尔会卡住。这种情况可以先把externalConsole临时改成true试试，让程序在没有VSCode介入的独立控制台里运行，交互体验通常会更好。不过独立控制台窗口样式比较原始，不是最优体验，实际项目一般用本地回显也够用。

7. 最后再分享一点个人经验

这套环境配置我已经在Windows、Ubuntu和macOS上分别搭过很多次，最深的感受是：永远不要跳过命令行验证这一步。无论你在VSCode里看到多么奇怪的问题，先把源文件在终端里手动编译一遍，能编译成功就说明工具链没问题，剩下的一定是配置文件的问题。这个顺序能帮你把问题范围快速缩小，而不是在扩展设置里乱翻。

另一个小技巧：把.vscode目录当作项目配置的一部分，提交到版本管理里。这样你换电脑或者同事克隆项目时，编译和调试配置直接就带过来了。但要注意settings.json里不要放只有本机才有的绝对路径，编译器路径用C:/mingw64/bin/g++.exe这种方式写还好，一旦大家都用同一套约定就不会出问题。

如果不希望每次安装都重新折腾扩展和设置，可以了解一下VSCode的便携版功能。把整个VSCode安装目录和数据目录放在一个U盘里，插到任何一台电脑上都是一样的配置。我后来在临时电脑上救急时就靠这一招，省掉了大量重复配置的时间。

最后说一个重要提醒：如果你发现自己卡在环境配置超过半小时还没有头绪，建议把当前所有配置文件全部删掉，回到命令行从零走一遍。很多时候不是配置复杂，而是网上找到的教程版本太老、组件不匹配，才让你越配越乱。把基础打牢，让编辑器回归编辑器，让编译器回归编译器，这套环境其实很清爽。