1. 从零到一为什么要在Ubuntu上配置C环境如果你是一个刚接触Linux开发的C程序员或者从Windows/Mac转战过来面对Ubuntu终端里空空如也的编辑器第一反应可能就是“我该从哪里开始”。网上教程千千万但很多要么是蜻蜓点水要么是版本过时要么就是一股脑把命令扔给你却不告诉你为什么。结果就是你跟着敲完环境是起来了但心里没底遇到点小问题就抓瞎。我经历过这个阶段也帮不少同事和学员搭建过环境。今天我就把在Ubuntu上为VSCode配置C开发环境的两种主流方式——GCC直接编译和CMake项目构建——掰开揉碎了讲清楚。这不是一个简单的命令列表而是一个“授人以渔”的过程。我会告诉你每一步背后的逻辑两种方式各自的适用场景以及我在实际使用中踩过的坑和总结的技巧。目标是让你不仅能搭起来更能理解它从而能独立解决未来可能遇到的大部分环境问题。为什么选择Ubuntu和VSCode这个组合对于C开发尤其是涉及系统编程、高性能计算或嵌入式交叉编译时Linux环境几乎是绕不开的。Ubuntu以其友好的社区和丰富的软件源成为了最受欢迎的入门发行版。而VSCode凭借其轻量、插件生态强大以及微软在C工具链上的持续投入已经成为了跨平台C开发的事实标准IDE之一。这个组合能让你在享受Linux强大命令行和开发库的同时拥有接近现代IDE的流畅编码体验。2. 基石准备系统环境与VSCode的安装与基础配置在开始配置C环境之前我们需要一个干净、准备好的起点。这个阶段看似简单但很多问题都源于这里没做好。2.1 Ubuntu系统的基本更新与编译工具链安装首先打开你的终端。无论你用的是Ubuntu桌面版还是服务器版第一步永远是确保你的系统软件包列表是最新的。sudo apt update这个命令本身不升级任何软件它只是从配置的软件源服务器比如官方的archive.ubuntu.com或国内的镜像源拉取最新的软件包列表信息。这就像你去图书馆前先查一下最新的图书目录。接下来进行系统升级sudo apt upgrade这个命令会根据上一步获取的列表将系统中所有已安装的软件包升级到仓库中的最新版本。对于新安装的系统这一步可能耗时较长。这里有个小技巧如果你在upgrade时遇到某些包因为依赖问题无法升级可以尝试使用sudo apt full-upgrade它会更智能地处理依赖冲突有时会删除一些旧包来满足新依赖但通常更有效。现在安装最核心的C/C编译工具链sudo apt install build-essential这个build-essential是一个元数据包它本身不包含太多内容但它依赖了一系列编译软件所必需的基础工具。安装它就等于一次性安装了gcc: GNU C编译器g: GNU C编译器make: 经典的构建自动化工具用于解析Makefilelibc6-dev: C标准库的开发文件头文件和链接库以及其他一些如dpkg-dev用于打包的工具。安装完成后验证一下gcc --version g --version make --version你应该能看到相应的版本号输出。至此你的系统已经具备了最基础的编译能力可以在终端里用g main.cpp -o main这样的命令直接编译单个文件了。2.2 VSCode的安装与必须的C插件在Ubuntu上安装VSCode我强烈推荐通过官方渠道。虽然Ubuntu软件中心也有但版本可能滞后。最稳妥的方式是下载.deb安装包或者添加微软的官方软件源。方法一推荐通过APT仓库安装这种方法便于后续更新。# 1. 导入微软GPG密钥用于验证软件包签名 wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor packages.microsoft.gpg sudo install -o root -g root -m 644 packages.microsoft.gpg /etc/apt/trusted.gpg.d/ # 2. 添加VSCode的APT源 sudo sh -c echo deb [archamd64,arm64,armhf signed-by/etc/apt/trusted.gpg.d/packages.microsoft.gpg] https://packages.microsoft.com/repos/code stable main /etc/apt/sources.list.d/vscode.list # 3. 更新源并安装 sudo apt update sudo apt install code方法二直接下载.deb包去VSCode官网下载最新的.deb包然后使用以下命令安装sudo dpkg -i 下载的.deb文件 # 如果提示依赖问题运行以下命令修复 sudo apt install -f安装完成后在终端输入code或者在应用菜单中找到Visual Studio Code打开。第一次启动VSCode我们需要安装最关键的C插件C/C这个插件是由微软官方维护的提供了代码智能感知IntelliSense、调试、代码浏览等核心功能。在VSCode左侧活动栏点击“扩展”图标或按CtrlShiftX搜索“C/C”认准微软发布的那一个点击安装。仅仅安装这个插件还不够。为了让VSCode能“理解”你的项目、帮你调试和构建我们还需要进行项目级的配置。这就是接下来两种方式要解决的核心问题。3. 方式一基于GCC和VSCode任务系统的轻量级开发这种方式适合小型项目、快速原型、单文件或文件数量很少的练习。它的核心思想是利用VSCode的“任务(Tasks)”功能将我们在终端里手动敲的编译命令如g main.cpp -o main包装成一个可一键触发的快捷操作。3.1 创建项目与理解VSCode的配置文件结构首先为你C项目创建一个独立的目录并用VSCode打开这个目录。mkdir my_cpp_project cd my_cpp_project code .在项目根目录下创建一个简单的main.cpp文件写入经典的Hello World代码。现在关键来了。为了让VSCode管理这个项目的构建行为我们需要在项目根目录下创建一个隐藏文件夹.vscode并在里面放置配置文件。VSCode会优先读取这个文件夹下的配置。mkdir -p .vscode在.vscode目录下我们通常会创建三个核心配置文件tasks.json: 定义构建编译、清理等任务。launch.json: 定义调试配置。c_cpp_properties.json: 定义编译器路径、包含路径、C标准等主要影响代码智能感知。对于简单的GCC直接编译方式tasks.json和launch.json是必须的c_cpp_properties.jsonVSCode通常会尝试自动生成。3.2 配置tasks.json将编译命令自动化在VSCode中按CtrlShiftP打开命令面板输入“Tasks: Configure Task”然后选择“Create tasks.json file from template”再选择“Others”。这会创建一个最基础的tasks.json文件。我们需要把它修改成适合C编译的样子。一个典型且功能完整的配置如下{ version: 2.0.0, tasks: [ { label: build with g, // 任务名称在命令面板中显示 type: shell, // 任务在shell中执行 command: g, // 执行的命令 args: [ -g, // 生成调试信息 -stdc17, // 使用C17标准 -Wall, // 开启大部分警告 -Wextra, // 开启额外警告 -o, // 指定输出文件名 ${workspaceFolder}/build/${fileBasenameNoExtension}, // 输出路径 ${file} // 要编译的当前活动文件 ], group: { kind: build, isDefault: true // 设为默认构建任务 }, presentation: { echo: true, reveal: always, // 总是显示终端 focus: false, panel: shared // 使用共享输出面板 }, problemMatcher: [$gcc] // 使用GCC问题匹配器能将编译错误链接到代码行 }, { label: run program, type: shell, command: ${workspaceFolder}/build/${fileBasenameNoExtension}, // 运行编译好的程序 dependsOn: build with g, // 依赖构建任务运行前先构建 group: test, presentation: { echo: true, reveal: always } }, { label: clean build, type: shell, command: rm, args: [ -rf, ${workspaceFolder}/build ], group: build } ] }逐项解析与避坑指南label: 这是任务的标识符你可以通过CtrlShiftP输入“Run Task”然后选择它来运行。我习惯用描述性的名字。type:shell: 这意味着任务将在终端shell中执行。这是最通用的类型。args参数详解:-g:至关重要。它告诉编译器在可执行文件中加入调试符号如变量名、行号信息。没有这个参数后续的调试功能将无法正常使用断点无效无法查看变量。-stdc17: 指定使用的C语言标准。根据你的项目需求可以改为c11,c14,c20等。-Wall -Wextra: 开启编译器警告。良好的编程习惯是从严对待警告它们常常能帮你发现潜在的逻辑错误。你甚至可以加上-Werror将警告视为错误强制自己解决。-o: 指定输出文件路径。这里我使用了${workspaceFolder}/build/${fileBasenameNoExtension}。这是一个VSCode的变量。${workspaceFolder}: 当前打开的工作区根目录。${fileBasenameNoExtension}: 当前活动文件的主文件名不含路径和扩展名。例如当前打开的是src/main.cpp这个变量就是main。为什么要输出到build目录这是一个很好的实践将生成的文件可执行文件、中间文件与源代码分离保持项目目录的整洁。你需要先在项目根目录手动创建一个build文件夹或者让清理任务来创建但首次运行前需存在。${file}: 当前活动文件的完整路径。这意味着这个任务是针对当前正在编辑的文件进行编译的。这非常适合单文件项目。group: 将任务分组。kind: build, isDefault: true使得这个任务成为默认的构建任务。之后你可以直接按CtrlShiftB来执行它而不需要从命令面板选择。problemMatcher:[$gcc]: 这是效率提升的关键。当编译出错时GCC会在终端输出错误信息。这个“问题匹配器”会解析这些输出提取文件名和行号然后直接在VSCode的“问题Problems”面板和代码编辑器的侧边栏显示红色波浪线。点击错误可以直接跳转到对应代码行。多任务与依赖: 我定义了三个任务。run program任务依赖于build with g这意味着当你运行run program时它会先自动执行构建任务。clean build任务则用于清理build目录。实操验证保存tasks.json打开你的main.cpp按CtrlShiftB。你应该会在终端看到编译过程并在build目录下生成一个可执行文件。如果有语法错误问题面板会直接显示。3.3 配置launch.json实现一键调试编译成功了接下来是调试。按F5或点击左侧的“运行和调试”图标VSCode会提示你选择环境选择“C (GDB/LLDB)”。它会自动生成一个launch.json文件但通常需要修改。我们需要配置的是使用我们刚刚编译好的、带调试信息的程序。一个配置好的launch.json如下{ version: 0.2.0, configurations: [ { name: (gdb) Launch, // 配置名称 type: cppdbg, // 调试器类型 request: launch, // 启动调试 program: ${workspaceFolder}/build/${fileBasenameNoExtension}, // 要调试的程序路径必须和tasks.json输出路径一致 args: [], // 程序命令行参数 stopAtEntry: false, // 是否在main函数入口处暂停 cwd: ${workspaceFolder}, // 程序运行的工作目录 environment: [], externalConsole: false, // 使用VSCode内置终端而非外部终端 MIMode: gdb, // 使用GDB调试器 setupCommands: [ { description: 为 gdb 启用整齐打印, text: -enable-pretty-printing, ignoreFailures: true } ], preLaunchTask: build with g, // 调试前自动执行的任务必须和tasks.json中的label一致 miDebuggerPath: /usr/bin/gdb // GDB路径通常是这个 } ] }核心配置项解析program:这是最重要的路径必须和tasks.json中-o参数指定的输出路径完全一致。如果路径不对VSCode会提示找不到可执行文件。preLaunchTask: 设置为tasks.json中构建任务的label这里是build with g。这样每次你按F5开始调试时VSCode都会先自动执行编译任务确保你调试的是最新的代码。如果编译失败调试会自动停止。externalConsole: 我设置为false这样调试时的输入输出都在VSCode下方的“调试控制台”或集成的终端中进行体验更统一。如果你需要更复杂的终端交互比如某些需要cin的程序可以尝试设为true但可能会遇到一些窗口管理的问题。MIMode: 指定调试器为gdb这是GNU项目调试器与GCC配套。现在在你的main.cpp中设置一个断点在行号左侧点击然后按F5。你会看到程序自动编译如果代码有变动然后启动并在断点处暂停。此时你可以查看变量值、调用堆栈进行单步调试等。3.4 方式一的优缺点与适用场景总结优点简单直观配置过程直接映射了命令行操作易于理解。快速灵活对于单文件或少量文件的项目配置速度快修改方便。依赖少只需要系统安装GCC和GDB不需要额外的构建系统。缺点难以管理多文件项目tasks.json中的${file}变量只针对当前文件。如果你的项目有多个.cpp文件需要一起编译就需要修改args手动列出所有文件或者编写更复杂的shell脚本非常麻烦且容易出错。缺乏依赖管理如果a.cpp依赖b.h当b.h改变时GCC命令不会自动重新编译a.cpp。你需要自己管理编译依赖或者每次都全部重新编译效率低下。配置不易复用这个配置是项目特定的在.vscode文件夹下虽然可以复制但对于结构不同的新项目调整起来依然有工作量。适用场景学习C语法、刷算法题单文件、编写小型工具或脚本、快速验证某个代码片段。个人心得在早期学习或处理微型项目时我强烈建议从这种方式开始。它能让你清晰地看到从源代码到可执行文件的每一步理解编译和调试的基本流程。把tasks.json和launch.json当成可复用的模板保存下来以后新建类似项目直接复制修改关键路径即可能省不少时间。4. 方式二基于CMake的现代化项目构建与管理当你的项目规模增长涉及多个源文件、目录、第三方库时GCC直接编译的方式就显得力不从心了。这时我们需要一个构建系统来管理复杂的编译流程。CMake是目前C生态中事实标准的跨平台构建系统生成器。它本身不直接构建项目而是根据你编写的CMakeLists.txt文件生成对应平台的原生构建文件如在Linux上生成Makefile在Windows上生成.sln再由底层的构建工具如make,ninja,MSBuild来执行构建。这种方式的核心思想是VSCode通过CMake Tools插件与CMake深度集成将CMake的配置、构建、调试、测试等命令无缝接入到IDE的UI和快捷键中。4.1 CMake的安装与核心概念速览首先安装CMake。Ubuntu仓库中的版本可能较旧建议通过Kitware官方APT仓库安装或下载预编译包。# 移除旧版本如果有 sudo apt remove --purge --auto-remove cmake # 安装依赖 sudo apt update sudo apt install -y software-properties-common lsb-release # 添加Kitware官方签名密钥和仓库 wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2/dev/null | gpg --dearmor - | sudo tee /etc/apt/trusted.gpg.d/kitware.gpg /dev/null sudo apt-add-repository deb https://apt.kitware.com/ubuntu/ $(lsb_release -cs) main # 安装CMake sudo apt update sudo apt install cmake # 验证安装 cmake --version安装完成后你还需要一个构建工具。通常make已经随build-essential安装了。你也可以安装更快的ninjasudo apt install ninja-buildCMake核心概念CMakeLists.txt: 这是CMake的“食谱”你在这个文件中用CMake的语法描述你的项目叫什么名字、需要什么C标准、有哪些源文件、生成什么目标可执行文件或库、链接哪些库等等。生成Configure: 运行cmake -B build -S .命令。CMake会读取当前目录的CMakeLists.txt在指定的build目录中生成对应的构建系统文件如Makefile。构建Build: 进入build目录运行make如果你用Ninja则是ninja。构建工具会根据生成的Makefile调用编译器如g来编译和链接你的项目。“外部构建”Out-of-source build: 这是最佳实践。即在项目根目录下创建一个独立的目录如build来存放所有生成的文件。这能保持源码树的纯净也方便同时维护多个构建配置如build_debug,build_release。4.2 安装与配置VSCode的CMake Tools插件在VSCode扩展商店中搜索“CMake Tools”安装由Microsoft发布的版本。这个插件提供了CMake项目的全生命周期管理。安装后打开你的CMake项目文件夹或新建一个。插件会自动在底部状态栏激活一系列按钮。但在这之前我们需要先创建一个CMakeLists.txt文件。在项目根目录创建CMakeLists.txt一个最基础的内容如下cmake_minimum_required(VERSION 3.10) # 指定CMake最低版本 project(MyCppProject VERSION 1.0.0 LANGUAGES CXX) # 定义项目名、版本和语言CXX即C set(CMAKE_CXX_STANDARD 17) # 设置C标准为C17 set(CMAKE_CXX_STANDARD_REQUIRED ON) # 要求编译器必须支持该标准 set(CMAKE_CXX_EXTENSIONS OFF) # 禁用编译器扩展保证代码可移植性 # 添加可执行文件目标 add_executable(my_app main.cpp) # 如果你的项目有多个源文件 # add_executable(my_app main.cpp src/foo.cpp src/bar.cpp) # 查找并链接库例如链接线程库 # find_package(Threads REQUIRED) # target_link_libraries(my_app PRIVATE Threads::Threads)4.3 使用CMake Tools插件进行配置、构建与调试保存CMakeLists.txt后CMake Tools插件会自动检测到它。此时注意VSCode底部状态栏选择工具包Kit: 状态栏可能会显示“No Kit Selected”或一个编译器名称。点击它会弹出可用的编译器工具包列表。这里会列出系统检测到的GCC、Clang等。选择一个例如“GCC x.x.x ...”。这个工具包决定了CMake将使用哪个编译器。选择变体Variant: 通常显示“Debug”。点击可以选择构建类型如Debug包含调试信息不优化、Release优化无调试信息、RelWithDebInfo优化且带调试信息等。Debug适合开发阶段。配置Configure: 点击状态栏的“Configure”按钮或者按CtrlShiftP输入“CMake: Configure”。插件会自动执行cmake -B build -DCMAKE_BUILD_TYPEDebug ...等命令在项目根目录下生成一个build文件夹或你指定的其他文件夹并在其中生成构建文件。常见问题如果配置失败查看VSCode的“CMake/Build”输出面板里面会有详细的错误信息。常见原因包括CMakeLists.txt语法错误、找不到依赖的包等。构建Build: 配置成功后点击状态栏的“Build”按钮或按F7或CtrlShiftP输入“CMake: Build”。插件会调用cmake --build build命令开始编译你的项目。编译进度和错误信息会显示在“CMake/Build”输出面板。这里的错误同样会被问题匹配器捕获显示在问题面板中。调试Debug: 这是CMake Tools最方便的地方。你不再需要手动配置launch.json插件会帮你自动生成。确保活动编辑器打开的是项目中的某个源文件然后直接按F5。插件会自动执行构建如果代码有更改。找到当前活动文件所属的CMake目标即my_app。使用正确的路径build/下的可执行文件和调试器启动调试会话。你可以在CMakeLists.txt中通过target_compile_options为特定目标添加-g标志但通常Debug构建类型会自动包含调试信息。4.4 进阶配置多目录、库与更复杂的CMakeLists.txt随着项目复杂我们需要更好的组织代码。假设项目结构如下my_project/ ├── CMakeLists.txt (根目录) ├── app/ │ ├── CMakeLists.txt │ └── main.cpp ├── src/ │ ├── CMakeLists.txt │ ├── foo.cpp │ └── foo.h └── lib/ ├── CMakeLists.txt ├── bar.cpp └── bar.h我们可以使用add_subdirectory()命令来构建一个模块化的项目。根目录CMakeLists.txtcmake_minimum_required(VERSION 3.10) project(MyLargeProject VERSION 1.0.0 LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) # 添加子目录CMake会去执行子目录中的CMakeLists.txt add_subdirectory(src) # 构建一个库 add_subdirectory(lib) # 构建另一个库 add_subdirectory(app) # 构建可执行文件并链接上面的库src/CMakeLists.txt(构建一个静态库):# 创建一个名为 foo_lib 的静态库 add_library(foo_lib STATIC foo.cpp foo.h) # 为这个库目标设置包含目录这样其他目标链接它时能自动找到头文件 target_include_directories(foo_lib PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})lib/CMakeLists.txt(构建另一个静态库):add_library(bar_lib STATIC bar.cpp bar.h) target_include_directories(bar_lib PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})app/CMakeLists.txt(构建可执行文件并链接库):add_executable(my_app main.cpp) # 将可执行文件 my_app 与两个库链接 target_link_libraries(my_app PRIVATE foo_lib bar_lib) # PRIVATE 意味着链接关系仅作用于 my_app 本身。 # 如果 foo_lib 的头文件需要被 my_app 使用因为我们在 foo_lib 中使用了 PUBLIC 包含了目录所以这里会自动生效。这样当你修改src/foo.cpp后构建系统只会重新编译foo_lib和依赖它的my_app而不会重新编译bar_lib实现了增量编译大大提升了大型项目的构建效率。4.5 CMake方式的优缺点与适用场景总结优点强大的项目管理能力天然支持多文件、多目录、库管理、条件编译、安装规则等是管理复杂项目的利器。跨平台一份CMakeLists.txt可以在Linux、macOS、Windows上生成对应的构建系统是跨平台C项目的标配。依赖管理通过find_package()、FetchContent或ExternalProject可以相对方便地集成第三方库。与IDE深度集成CMake Tools插件提供了近乎“一键式”的配置、构建、调试、测试体验无需手动维护tasks.json和launch.json。高效的增量编译构建系统如Make能自动处理文件依赖只编译改动过的文件及其依赖项。缺点学习曲线较陡CMake语法自成一体高级功能复杂需要时间学习。配置过程稍慢首次配置需要生成整个构建系统比直接调用GCC慢。抽象层它隔在你和编译器之间有时调试构建问题需要理解CMake生成的中间文件如Makefile。适用场景任何超过几个文件的中大型C项目、需要跨平台的项目、需要集成多个第三方库的项目、团队协作项目。踩坑实录早期使用CMake时我最常犯的错误是在CMakeLists.txt中错误地设置变量作用域。比如用set(CMAKE_CXX_FLAGS “-Wall”)全局设置标志可能会覆盖掉CMake或插件自动设置的重要标志如-g。正确做法是使用target_compile_options(my_target PRIVATE -Wall)来针对特定目标设置。另一个坑是忘记使用“外部构建”导致源码目录被污染git status一片红。养成cmake -B build -S .的习惯至关重要。5. 两种方式的对比与选择策略为了更清晰地展示两种方式的区别我将其核心特点总结如下表特性维度GCC VSCode Tasks (方式一)CMake CMake Tools (方式二)配置复杂度低直接对应命令行中高需要学习CMake语法项目规模小型、单文件项目中大型、多文件、多目录项目文件依赖管理无需手动管理或全量编译有自动增量编译跨平台支持差配置与平台/编译器强相关优秀一份配置多平台生成第三方库集成困难需手动管理编译和链接标志相对容易有find_package等机制与VSCode集成通过tasks.json/launch.json手动配置深度集成插件提供UI和自动化构建流程可见性高命令透明中被CMake抽象了一层调试体验需手动配置launch.json但配置好后与方式二无异近乎自动按F5即可适用阶段学习、原型、微型工具正式项目、产品开发、团队协作如何选择我的建议是如果你是C初学者从方式一GCCTasks开始。它能帮你牢固建立“编辑-编译-链接-调试”这个基础工作流的概念理解每一步在做什么。用一两个小项目熟悉这个过程。当你的项目文件超过3个或者开始使用自己写的头文件/源文件分离时就应该认真考虑切换到方式二CMake。初期可能会觉得CMake麻烦但这是必由之路。从一个简单的单目录CMakeLists.txt开始逐步学习add_executable、target_include_directories、target_link_libraries等基本命令。对于任何计划长期维护、与他人协作或需要跨平台的项目无条件选择CMake。它是现代C生态的通用语言早学早受益。6. 共享配置与团队协作的最佳实践无论采用哪种方式项目中的.vscode文件夹和CMakeLists.txt对于方式二都是项目配置的核心。为了团队协作你通常需要将这些文件纳入版本控制如Git。对于方式一GCCTasks将.vscode/tasks.json和.vscode/launch.json提交到仓库。但要注意里面可能包含绝对路径或与机器相关的设置如miDebuggerPath。尽量使用VSCode的预定义变量如${workspaceFolder},${file}来保持路径的相对性。对于编译器路径等如果团队环境统一可以写死否则可能需要每个成员根据自己环境稍作修改或者不提交launch.json让成员自己生成。对于方式二CMakeCMakeLists.txt是必须提交的核心文件。.vscode文件夹下的配置通常不需要提交因为CMake Tools插件能根据CMakeLists.txt自动配置大部分环境。团队每个成员打开项目选择好自己的Kit和Variant即可。你可以提交一个.vscode/settings.json文件来统一团队的一些编辑器设置如格式化工具、编码风格但调试和任务配置由CMake管理。一个常见的.vscode/settings.json配置示例用于统一C代码风格{ C_Cpp.default.cppStandard: c17, C_Cpp.default.intelliSenseMode: linux-gcc-x64, editor.formatOnSave: true, C_Cpp.clang_format_fallbackStyle: { BasedOnStyle: LLVM, UseTab: Never, IndentWidth: 4, TabWidth: 4 }, files.associations: { *.cpp: cpp, *.h: cpp } }最后也是最重要的经验环境配置是开发的第一步但不要陷入配置的泥潭。如果某种方式在半小时内还搞不定停下来查查文档、看看错误信息或者用一个更简单的例子验证。无论是GCC直接编译还是CMake其最终目的都是为了让编译器把你的代码变成可运行的程序。理解了这个本质任何工具都只是帮助你更高效到达目的地的路径而已。从简单开始逐步深入你的Ubuntu VSCode C开发环境一定会成为你高效的创作利器。