前阵子帮一个学弟配置环境他刚换了台MacBook打开终端准备写C语言作业结果连clang都提示找不到。他问我“我在Windows上装个Dev-C就能直接写C语言为什么到了Mac上这么麻烦”这个问题我太熟悉了。很多人以为“VSCode配置C/C环境”就是把编辑器装好、插件按好实际上你需要的是一整套链路的配合编辑器负责写代码编译器负责把代码变成可执行文件调试器负责帮你查问题。这三件事在Windows上被IDE打包成了一个整体在Mac上却被拆开了。这篇文章会从零开始完整记录我在Mac上配置VSCode编写C/C程序的全过程包括每一步命令、每一份配置文件、每个变量的含义以及那些教程里很少写的坑。适合刚转到Mac的C语言新手、准备刷算法题的学生以及打算用Mac写课程设计或者小工具的同学。1. 开工前先想清楚Mac上的C/C工具链到底由谁组成1.1 编辑器、编译器、调试器三者不是一回事我在帮人配环境的时候发现很多人对C/C开发工具链的认知是模糊的。他们觉得“我有VSCode我能写代码那环境就应该好了”直到按下编译键报错才意识到事情没那么简单。在Mac上VSCode只是一个编辑器它负责高亮、补全、跳转、格式化这些“写字”的活。真正把.cpp文件变成可执行文件的是编译器macOS上默认带的是clang也就是LLVM项目里的C语言家族编译器。程序跑起来之后如果崩溃了、或者结果不对你需要断点、变量监视、调用栈这些东西由调试器负责Mac上默认的调试器是lldb。你可以把这三者理解为手术台、手术刀和无影灯VSCode是手术台提供操作空间clang是手术刀负责把源码切成一串机器指令lldb是无影灯让医生看清楚血管和神经。只装VSCode就像买了一张床却指望它能自己做手术显然不现实。所以我们要做的第一步不是打开VSCode装插件而是先确认这台Mac上有手术刀和无影灯。也就是说配置环境的本质是“把编译器装好、让VSCode可以调用它、让调试器可以接管它”理解这一点后面所有配置都不会再显得玄乎。1.2 为什么我坚持用clang而不是先装gcc网上很多教程会教你在Mac上通过Homebrew安装gcc然后配成gcc环境。我不反对但我的建议是在Mac上老老实实用系统自带的clang直到你真的遇到用clang解决不了的问题再换。原因有几个。第一macOS的Xcode Command Line Tools自带的就是clang装完之后立刻能用不需要额外下载最省事。第二Apple对LLVM的贡献很深macOS上的系统库、头文件、链接器跟clang配合得最好换句话说clang就是Mac上的“原配”。第三普通C/C课程作业、算法刷题、入门级项目clang和gcc的语法兼容性极高你基本感知不到区别。如果因为老师要求gcc或者某个库只提供gcc版本你可以再用Homebrew安装比如brew install gcc装完之后的命令名是g-14或者g-13而不是g。这一点很重要因为macOS上g这个命令可能被系统用clang兼容模式占用直接用g不一定是你安装的那一个。所以初期配置我的建议是先不要折腾gcc用/usr/bin/clang跑通全流程之后再按需切换。环境配置的核心不是“哪个编译器更厉害”而是“哪条链路最不容易出问题”。1.3 Intel Mac和Apple Silicon Mac路径差异直接影响成败配置Mac环境必须分清楚芯片架构因为Intel Mac和Apple Silicon Mac的软件路径不一样尤其是Homebrew的安装路径。Intel Mac上Homebrew默认装在/usr/localApple Silicon Mac上Homebrew装在/opt/homebrew。你之后如果要用Homebrew安装第三方库比如json库、opencv、boost这些库的头文件分别位于/usr/local/include和/opt/homebrew/include链接库则在/usr/local/lib和/opt/homebrew/lib。如果你的Mac是M1、M2这种Apple Silicon机器后面的配置示例里请把/opt/homebrew这套路径记牢。VSCode的IntelliSense模式也会有区别Apple Silicon通常使用macos-clang-arm64Intel使用macos-clang-x64。不过大多数情况下VSCode会自动检测不用手动指定。但万一你在配置过程中发现头文件索引一直出错手动指定这个值是解决问题的第一步判断手段。先用uname -m看一下当前机器的架构如果输出arm64就是Apple Silicon输出x86_64就是Intel。这个命令我建议每个刚上手的人都先跑一下后面很多问题都跟架构有关。2. 环境安装三行命令加两个插件别被长教程吓住2.1 第一步永远是安装Xcode Command Line Tools我见过有人为了写C语言直接下载了十几个G的Xcode真的没必要。开发C/C程序用到的编译器、调试器、make、链接器都包含在“Xcode Command Line Tools”这个命令行工具包里它只有几百MB而且完全够用。在终端执行这一条命令即可xcode-select --install执行之后系统会弹出一个窗口提示安装开发者工具点确认然后等它下载安装完成。如果你的Mac是刚激活的全新系统情况会更简单你在终端输入clang --version系统会自动弹出安装提示按提示走就行。安装完成后可以运行下面这组命令验证clang --version lldb --version make --version xcode-select -p如果clang --version能打印出版本信息说明编译器OKlldb --version正常说明调试器OKxcode-select -p应该输出/Library/Developer/CommandLineTools这是命令行工具的安装路径。如果你安装的时候系统提示“already installed”或者“command line tools are already installed”说明之前已经装过了直接验证即可。这里有个容易混淆的地方你不需要安装完整的Xcode也不需要打开Xcode更不需要注册Apple开发者账号。命令行工具是独立于Xcode的一整套基础工具命令行写C/C只需要这套东西。以后如果安装某些需要从源码编译的Homebrew软件也会依赖它。2.2 安装VSCode和两个关键插件VSCode的安装方式我就不展开了直接官网下载dmg拖进Applications或者用Homebrew执行brew install --cask visual-studio-code都可以。装完之后打开VSCode在扩展商店里搜索两个插件“C/C”Microsoft官方出品负责IntelliSense、代码补全、语法高亮、格式化还带基本的调试能力。“CodeLLDB”负责让VSCode调用lldb进行调试。它在macOS上的调试体验比官方扩展内置调试器更稳定尤其断点命中、变量查看这些基础操作不容易翻车。如果你是在一个空文件夹里创建了第一个.cpp文件VSCode会在右下角弹出一个通知提示你安装推荐的C/C扩展这时候点Install就能装第一。第二个CodeLLDB是我自己后来加上的官方C/C扩展在macOS上也能调试但某些版本会出现断点不命中的玄学问题我换成CodeLLDB之后基本再没遇到过。所以我的组合是官方C/C扩展负责代码理解CodeLLDB负责调试执行。至于“C/C Extension Pack”“Include Autocomplete”“Better C Syntax”这些插件我的看法是可装可不装装了也不亏但不要一上来铺一大堆。环境配置阶段插件越少出问题时越容易定位。写C重要的是编译器工作正常不是插件数量多。2.3 用一个小程序验证编译器链路是否打通在正式写配置文件之前先手动确认一下工具链本身没问题。打开VSCode新建一个文件夹比如~/cpp-workspace在里面创建hello.cpp#include iostream int main() { std::cout hello from clang std::endl; return 0; }然后在VSCode的终端里执行clang hello.cpp -o hello ./hello能看到hello from clang就说明编译器这条链路已经通了。这一步看起来多余但它能帮你把问题隔离如果这一步都过不了问题基本出在命令行工具没装好跟VSCode配置没关系。如果这一步已经报错就先回到上一节把命令行工具装好再继续。这里我还建议顺手把code命令装一下。在VSCode里按CmdShiftP输入“Shell Command: Install code command in PATH”然后回车。装完之后在终端里进到任意项目目录输入code .就能直接打开VSCode。这个操作对后面多文件项目的日常开发帮助很大值得在第一步就养成习惯。3. 核心配置文件逐个拆解.vscode里那几个json分别管什么接下来是最容易劝退新手的部分VSCode的C/C配置依赖.vscode目录下的几个JSON文件。很多教程直接甩一整段配置让你复制但从不告诉你每个文件干什么导致出了问题完全不会改。我在这里把每个文件拆开讲清楚。3.1 c_cpp_properties.json管“编辑器看得懂代码”在VSCode里按CmdShiftP输入“C/C: Edit Configurations (UI)”会打开一个可视化界面。先不管里面的选项直接把下面这份JSON写到.vscode/c_cpp_properties.json里{ configurations: [ { name: Mac, includePath: [ ${workspaceFolder}/**, /usr/local/include, /opt/homebrew/include ], defines: [], macFrameworkPath: [ /System/Library/Frameworks, /Library/Frameworks ], compilerPath: /usr/bin/clang, cStandard: c17, cppStandard: c17, intelliSenseMode: macos-clang-arm64 } ], version: 4 }这个文件不负责编译它只负责给VSCode的代码分析引擎提供“代码怎么理解”的信息。举个例子当你在代码里#include vector时VSCode需要知道vector头文件到底在哪里才能帮你补全、跳转、检查写法。compilerPath告诉VSCode“我用的是这个编译器”于是VSCode会按照这个编译器的规则去解析代码。includePath里写的是头文件搜索路径${workspaceFolder}/**表示当前工作目录下所有子目录都会递归搜索/opt/homebrew/include是留给Homebrew安装的第三方库。macFrameworkPath对应macOS的Framework头文件路径一般不用动。如果你在Apple Silicon机器上intelliSenseMode用macos-clang-arm64Intel机器改成macos-clang-x64。不过实际经验是VSCode在检测到/usr/bin/clang之后通常会自动填好这个字段大多数时候不用手工改。真正需要调整的是includePath它决定了编辑器的红色波浪线和补全是否正常。注意这份文件写错了最多就是编辑器提示乱飘程序该编译还是可以编译所以别把它跟编译错误混为一谈。3.2 tasks.json管“把源码变成可执行文件”编译这件事在VSCode里通过Task机制实现。Task可以理解成“在VSCode里预设好的终端命令”你按快捷键它就在后台帮你执行一条命令。我通常把tasks.json配置成这样{ version: 2.0.0, tasks: [ { label: C/C: clang build active file, type: cppbuild, command: /usr/bin/clang, args: [ -fdiagnostics-coloralways, -g, -stdc17, ${file}, -o, ${fileDirname}/${fileBasenameNoExtension} ], options: { cwd: ${fileDirname} }, problemMatcher: [$gcc], group: { kind: build, isDefault: true } } ] }几个变量的含义要记住${file}表示当前正在编辑的文件完整路径${fileDirname}表示当前文件所在目录${fileBasenameNoExtension}表示当前文件名去掉扩展名。所以这条任务执行的实际命令是/usr/bin/clang -fdiagnostics-coloralways -g -stdc17 /path/to/hello.cpp -o /path/to/hello-g选项表示生成调试信息没有它后面调试器断点就失效-stdc17把C标准定在C17课程设计和刷题都够了。group里isDefault设为true意味着你在VSCode里按CmdShiftB时会直接执行这个任务不需要再选一次。我特意用绝对路径/usr/bin/clang而不是clang是为了避免VSCode任务环境里PATH不一致导致找不到命令。这种问题在图形界面启动的应用里经常发生绝对路径是最稳的解法。如果你换了Homebrew gcc把这里改成/opt/homebrew/bin/g-14gcc版本号以你实际安装的为准。3.3 launch.json管“让程序在调试器里跑起来”写代码不是为了编译成功而是要调试找Bug。在VSCode里按F5启动调试时靠的是launch.json。我的通用配置如下{ version: 0.2.0, configurations: [ { name: Debug C/C with LLDB, type: lldb, request: launch, program: ${fileDirname}/${fileBasenameNoExtension}, args: [], cwd: ${fileDirname}, preLaunchTask: C/C: clang build active file, stopAtEntry: false } ] }这里的type: lldb需要CodeLLDB插件支持这也是我推荐它的原因。program指向要调试的可执行文件它必须和tasks.json里编译出来的文件路径完全一致否则会报“program does not exist”。preLaunchTask的值必须和tasks.json里的label完全一致它的作用是在你按F5的那一刻先自动执行编译任务编译成功后再启动调试器。cwd是程序运行时的当前工作目录这个极其关键。如果你程序需要读取同目录下的data.txt而cwd不设置或者设置错了程序会找不到文件报“No such file or directory”。很多课程设计里的文件读取错误根子就在这个地方。stopAtEntry设为false的意思是启动调试器后不停在第一行直接跑到你设置的断点。如果你希望在程序入口处立刻停住看变量初始化情况可以把它改成true。刚开始学调试时我建议保留false按自己的节奏打断点。3.4 settings.json两个顺手做的小优化settings.json保存的是编辑器全局/工作区设置你可以把它放在.vscode目录下也可以放进用户设置。针对C/C开发我特别推荐两处{ editor.formatOnSave: true, C_Cpp.clang_format_fallbackStyle: Google, C_Cpp.default.cppStandard: c17, C_Cpp.default.cStandard: c17 }editor.formatOnSave表示文件保存时自动格式化写代码时手一抖缩进乱了保存一下立刻恢复整齐对新手极度友好。C_Cpp.clang_format_fallbackStyle指定使用Google风格这套风格的空格、缩进、花括号换行规则很符合主流审美。如果你想改成4空格缩进的个人风格最好在工作区根目录放一个.clang-format文件自定义而不是在settings.json里堆一大段对象。后两行是给C/C扩展指定默认的语言标准省得它在没有项目配置的时候瞎猜。4. 从单文件玩具到多文件项目什么时候该升级配置上面那套配置直接适用于一个文件夹里一个.cpp文件的情况很多刷算法题和入门课程设计到这个程度已经够用了。但写真实项目时代码很快会拆成多个文件这时就需要对配置做升级。4.1 单文件模式已经能覆盖八成刷题场景刷算法题、写LeetCode、做简单的单文件练习其实用不着什么复杂的工程化配置。你只需要在题目文件夹里新建一个.cpp写完按CmdShiftB编译在终端里输入几组测试数据发现问题打几个断点按F5调试。整个过程非常轻。这套单文件模式的另一个好处是每个.cpp文件编译出来的可执行文件都跟源文件同名互不覆盖。你今天写a.cpp明天写b.cpp编译出来的就是a和b互不干扰这对频繁换题刷题的学生来说很舒服。唯一要提醒的是单文件模式下每次编译只处理当前活动文件。也就是说如果你开了a.cpp按CmdShiftB编译的是a.cpp即使编辑窗口里还有个b.cpp。很多人在这里困惑觉得“我明明改了b编译运行还是老样子”其实是你没有把b设为活动标签页。4.2 多文件项目先试最简单的Makefile当你的项目变成main.cpp、sort.cpp、tree.cpp多个文件时继续用单文件tasks就不合适了因为每个文件单独编译成独立可执行文件没有任何意义。多文件项目需要把它们整体编译成一个程序。我用过很多方式最务实的是直接在项目根目录写一个MakefileCXX /usr/bin/clang CXXFLAGS -stdc17 -g -Wall -Iinclude TARGET main SRCS $(wildcard src/*.cpp) $(TARGET): $(SRCS) $(CXX) $(CXXFLAGS) $(SRCS) -o $(TARGET) clean: rm -f $(TARGET) run: $(TARGET) ./$(TARGET)然后在VSCode终端里执行make run就能编译并运行整个多文件项目。Makefile的处理逻辑很简单把src目录下所有.cpp文件都找到用clang一起编译成main可执行文件-Iinclude告诉编译器头文件在include目录下。这条路不需要折腾tasks.json代码规模上来了依然清晰而且make在命令行工具里已经自带不用额外安装。如果你想保留“按F5直接调试”的体验也可以给launch.json加一个配套任务preLaunchTask改成执行makeprogram指向${workspaceFolder}/main。但我个人觉得多文件项目直接终端make run更符合直觉调试时再集中精力用F5。4.3 CMake是更稳的下一步如果项目进一步扩大比如要引入第三方库、要跨平台、要给别人源码共同开发再手写Makefile就有点原始了。这时候应该上CMake。它不直接编译而是根据CMakeLists.txt生成一套适合当前系统的构建配置再由make或ninja执行编译。我第一次迁移到CMake时觉得多此一举直到项目要同时维护几十个源文件才发现CMake的生成器和依赖管理确实香。一个最基础的CMakeLists.txt长这样cmake_minimum_required(VERSION 3.16) project(cpp_project) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(main src/main.cpp src/tree.cpp src/sort.cpp ) target_include_directories(main PRIVATE include)配合VSCode的CMake Tools扩展你可以在扩展面板里直接选择构建目标、配置参数、查看输出。但这里我给个诚恳的建议如果你只是为了过一门C语言课程设计完全可以先不学CMake用Makefile足够了如果你之后会参与真实项目、写开源代码CMake越早接触越好。4.4 实际课程设计中文件怎么组织拿常见的“植物百科数据管理与分析”这类数据结构课程设计举例很多同学的代码会越写越长最终几百行全堆在main.cpp里。其实更好的组织方式是main.cpp放菜单和核心流程tree.cpp放植物信息的索引树操作sort.cpp放按高度、按科属的排序算法data.cpp负责从文件读入植物记录include目录里放对应的头文件。这样一个项目拆成四个源文件加若干头文件用前面那个Makefile直接管理清晰也不会互相干扰。拆分之后别忘了去c_cpp_properties.json里检查includePath把你自己的include目录加进去。否则VSCode虽然能通过Makefile正常编译但编辑器里的跳转和补全会找不到头文件红色波浪线会一直伴随你这也是非常典型的一个问题。5. Mac上特有的五个坑我一个个踩给你看配置过程中我踩过的坑比想象中多很多问题跟Windows完全不同。这里挑五个Mac上最高频的把症状、原因、解决路径都写出来希望你不用再走一遍弯路。5.1 “xcrun: error: invalid active developer path”是命令行工具坏了的信号这个报错我见过好几次症状是你在终端运行clang、git、make等命令时突然冒出来一行xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at /Library/Developer/CommandLineTools/usr/bin/xcrun这句话的本质是系统知道命令行工具应该装在/Library/Developer/CommandLineTools这个位置但这个位置的命令已经缺失或者损坏了。最常见的原因是macOS系统升级之后旧版本命令行工具和新系统不匹配或者你之前下载过Xcode Beta把系统工具链指向了不存在的路径。解决办法是先把路径重置再重新安装sudo xcode-select --reset xcode-select --install如果--install提示“command line tools are already installed”可以先删除旧的再装sudo rm -rf /Library/Developer/CommandLineTools xcode-select --install这个命令会彻底删掉命令行工具不影响其他个人文件放心执行。装完后再跑clang --version基本就恢复了。记住一点不要手动去改xcode-select的路径变量除非你清楚知道目标路径存在。5.2 编译报头文件找不到和编辑器波浪线是两个不同的问题遇到fatal error: iostream file not found很多人第一反应是去改includePath结果改了半天没变化。实际上编译阶段报这个错尤其iostream、stdio.h这种系统头文件都找不到九成是命令行工具没装好或者损坏了而不是VSCode的includePath问题。因为系统头文件路径/Library/Developer/CommandLineTools/usr/include是编译器自带的搜索路径不依赖VSCode配置。只要这个路径坏了无论你在c_cpp_properties.json里填什么clang都找不到。反过来如果你的终端里clang hello.cpp -o hello能编译通过但VSCode编辑器里全是红色波浪线那才是c_cpp_properties.json的锅。此时按CmdShiftP搜索“C/C: Edit Configurations (UI)”在Include path里把缺失的目录补上波浪线立刻消失。这两种场景让我踩过很多次坑后来总结成一句话编译错误找编译器编辑器报错找IntelliSense配置不要混着排查。现象根本原因排查方向编译时stdio.h not found命令行工具缺失/损坏xcode-select --installVSCode内波浪线但终端编译正常includePath缺失编辑c_cpp_properties.jsonHomebrew库编译时找不到头文件缺少-I参数在tasks/CMake里加include目录5.3 launch时报“program does not exist”多半是路径或任务名不一致按F5调试时VSCode弹出一句program does not exist很多人立刻去怀疑调试器坏了。其实这个报错的含义很直白launch.json里的program指向的那个可执行文件不存在。最常见的三个原因依次是preLaunchTask没有触发编译任务导致可执行文件根本没生成tasks.json编译失败程序路径从未诞生program拼写和tasks编译输出的路径不一致。排查顺序建议如下先打开VSCode终端手动执行一次编译命令确认可执行文件能生成再按CmdShiftB手动运行tasks.json里的任务看终端输出有没有报错最后检查launch.json里的program路径和tasks的-o参数是否完全一致。由于我们前面统一用了${fileDirname}/${fileBasenameNoExtension}单文件场景下这两者天然一致所以只要你不是手打路径基本不会出这个错。手打路径是万恶之源变量能解决的事不要自己拼字符串。5.4 程序能跑但断点一直没反应这个问题曾经困扰我一整个下午编译正常、程序运行正常、按F5也能启动但我在代码里打的断点要么显示空心圆要么程序直接跑完根本不停。后来发现就两类原因。第一编译时没有加-g参数。调试器靠编译产物里的调试符号表来定位源代码行号没有-g它就是个只有机器码的裸程序当然停不下来。检查一下tasks.json的args里有没有-g。第二调试扩展用混了。C/C官方扩展和CodeLLDB同时在项目里出现时偶尔会因为“由谁接管调试会话”的问题表现异常。我的处理方式很暴力但有效在launch.json里明确指定type: lldb让CodeLLDB接管关掉官方扩展的调试入口只保留它的IntelliSense功能问题从此消失。还可以在launch.json里加一行stopAtEntry: true做测试如果程序启动后仍然不停在main入口说明调试器压根没有正确加载符号表这时优先检查编译参数和扩展冲突而不是继续打断点。5.5 Apple Silicon下报“architecture x86_64 not found”之类的问题不少人在M系列Mac上配环境编译一个简单程序突然报一堆architecture not found或symbol(s) not found for architecture x86_64。这里要先理解一个背景macOS存在两套架构arm64是本机原生架构x86_64是Intel的架构Apple Silicon可以通过Rosetta 2运行x86_64程序但混用会出问题。如果你系统里装的是arm64的Homebrew库却用了一个x86_64的编译器去链接链接器就会在库文件里找不到对应架构的符号。排查这个问题就三步uname -m看当前shell架构file $(which clang)看编译器到底是arm64还是x86_64file main看编译出来的可执行文件架构。只要三者不一致就会出问题。解决办法通常是让编译器回到系统自带的/usr/bin/clang它默认会编译当前架构的原生代码。另外如果你的终端是从Rosetta模式启动的也会影响后续环境变量尽量让VSCode和终端都运行在原生arm64模式下。6. 这套配置的实际工作流和我最后的建议6.1 写刷题或课程设计的日常路径环境配好之后我日常的开发流程已经固定下来了。新建一个文件夹终端code .打开VSCode在src目录写.cpp文件写完按CmdShiftB编译按CmdShift呼出终端运行程序丢测试数据。如果结果不对回到代码里在可疑行打一个断点按F5启动调试观察变量变化和调用栈。整个过程中我基本不需要碰鼠标去点菜单所有动作都靠快捷键完成。这套流程最核心的体验就是“短路径”。从写出代码到看到结果中间只隔一次按键。如果还要打开另一个软件、再点几下按钮才能编译你的学习阻力会大很多。有时候环境配置的问题看起来是技术问题其实是心理问题——路径越长越不想动手。这也是我坚持把配置文件做到最少的原因。6.2 我的极简配置原则不为用不到的功能买单现在我帮人配置Mac下的VSCode C/C环境默认只做四件事装命令行工具、装VSCode和两个插件、放好三个JSON、验证一个hello world。c_cpp_properties.json用来自动生成并检查includePathtasks.json负责编译launch.json负责调试最多再往settings.json里写四行格式化设置。全部配置加起来不到三十行却能覆盖刷题、课程设计、小型工具开发全部场景。我不推荐一上来套用网上那种七八十行的全套配置又是波浪线美化、又是自动缩进、又是头文件浏览看着厉害其实大部分普通项目根本用不上。配置文件的每一行都是维护负担。用不到的配置一旦出了问题你都不知道是哪一行引起的。等真的碰到“这个库需要C20”“这个项目要跨平台”再针对性地加配置一点都不晚。6.3 环境配置不是一次性的保持随时能重建的习惯还有一个经验想分享环境配置完成后最好把配置文件保存一份到自己的配置仓库里。因为macOS升级、VSCode升级、插件升级都可能导致某一天环境突然出问题。我有一个专门存放dotfiles和.vscode配置的备份目录每次重装系统后只需要几分钟就能还原整套C/C开发环境。这不光是为了省时间更是保证学习节奏不被环境问题打断。比如我新换一台Mac后完整的操作顺序固定成这样安装命令行工具、安装VSCode、安装C/C和CodeLLDB插件、创建.vscode目录并把备份的四个JSON文件放进去、跑一次hello world验证。到这一步整个环境就算齐了。之后再装Homebrew装需要用的第三方库项目按需增加make或CMake配置。到现在我还保留这个习惯每个课程设计或算法练习文件夹单独放一套.vscode不让全局配置背锅。你的电脑最终配置成什么样得由你的实际项目说了算而不是那些照搬来的长教程。
