简介围绕 VSCode 编辑器入门与 C/C 开发环境搭建整理的图文教程资料包面向刚接触 VSCode 的学生、自学者以及需要从其他 IDE 迁移的开发者重点解决插件选择、编译调试配置与任务终端联动等常见卡点。压缩包共 1132 个文件约 230.42MB以 png、jpg 操作截图和 md 图文笔记为主体辅以 sh 脚本、yaml/json 配置、go 示例代码及 dockerfile 环境描述文件便于边看边对照实践。已有 4844 人学习下载。内容覆盖界面布局与快捷键、插件生态与主题设置、工作区管理并逐步讲解 GCC 编译器安装、头文件路径、构建任务与调试启动三类配置文件的写法配合断点调试、变量监视与终端编译运行演示另附 cast 录屏与配置样例方便复现环境、排查编译报错。1. VSCode 配 C真正卡住新人的从来不是写代码在 VSCode 里写 C第一次按 F5 弹出来的往往不是程序输出而是一行「miDebuggerPath 指向的路径不存在」或者「preLaunchTask 已终止」。这份「VSCode 基本使用 配置 C/C 环境」的完整讲解拆的就是这一类问题从命令面板、快捷键、工作区设置讲起再逐字段解释 c_cpp_properties.json、tasks.json、launch.json 这三份配置最后落到 CMake 多文件工程和断点调试。它不假设你已经会 Makefile也不要求先装一整套重型 IDE。刚接 C 课设的人、从别的编辑器迁过来的人、以及「代码能跑但换个目录就崩」的半熟手都能顺着走一遍。下面按我自己实际配环境的顺序拆开讲。2. 编辑器先调顺工作区、快捷键与命令面板的工程化配置装完 VSCode 直接开写十有八九会在两周内积累出一堆别扭缩进一会 2 空格一会 4 空格、保存后文件换行符变成 CRLF、中文注释在终端里变成方块。这些问题跟 C 编译器一点关系都没有纯粹是编辑器层没配好。这一章先把编辑器调到「不添乱」的状态再谈编译器。2.1 settings.json 分层用户级与工作区级别混着改VSCode 的设置有两层很多人只知道一层。用户级设置存在%APPDATA%\Code\User\settings.jsonWindows或~/.config/Code/User/settings.jsonLinux对所有项目生效工作区级设置存在项目根目录的.vscode/settings.json只对当前文件夹生效而且可以跟着仓库一起提交。我的习惯是凡是跟个人手感有关的字号、主题、自动保存放用户级凡是跟项目契约有关的缩进、编码、C 标准、头文件路径一律放工作区级。理由很实际——你把files.eol塞进用户级换到另一个要求 CRLF 的老项目上就会天天看到整文件 diff。一个够用的工作区settings.json{ editor.tabSize: 4, editor.insertSpaces: true, editor.formatOnSave: true, editor.renderWhitespace: boundary, files.autoSave: onFocusChange, files.encoding: utf8, files.eol: \n, files.trimTrailingWhitespace: true, files.insertFinalNewline: true, files.associations: { *.h: cpp, *.hpp: cpp }, C_Cpp.default.cppStandard: c17, C_Cpp.default.cStandard: c11 }逐项说下为什么这么设。editor.insertSpaces配合tabSize: 4是 C 圈子里最不惹争议的组合混用 Tab 和空格在 code review 时最容易吵起来。files.eol设成\n是为了让 git 里不出现「整个文件都改了」的假 diff——Windows 默认 CRLF一个文件被两个人分别用 CRLF 和 LF 存过diff 就会炸成一片。files.trimTrailingWhitespace和files.insertFinalNewline是两个小动作但能让git diff干净很多。files.associations那行是给.h文件用的VSCode 有时会把.h当 C 头文件处理导致 C 的class、namespace关键字被标成错误绑到cpp语言模式后就正常了。C_Cpp.default.*Standard是给 IntelliSense 的默认值注意它只影响补全和标红不影响真正的编译参数——真正传给 g 的-std在 tasks.json 里这两处不一致是最常见的「编辑器说没问题、编译却报错」来源。提示改完settings.json如果没生效先按CtrlShiftP执行一次Developer: Reload Window比反复关开窗口快。2.2 快捷键与多光标把重复编辑压到一次按键命令面板是 VSCode 的中枢CtrlShiftP打开后输入命令名就能执行任何功能包括那些没绑快捷键的。养成一个习惯想做什么操作之前先在命令面板里搜一下关键词比如build、debug、encoding搜得到就说明有内建支持不用去装插件。我自己的keybindings.json只改三个键都是高频动作[ { key: ctrlaltb, command: workbench.action.tasks.build }, { key: ctrlaltr, command: workbench.action.debug.run }, { key: ctrlshiftaltd, command: editor.action.copyLinesDownAction, when: editorTextFocus } ]第一行把「运行生成任务」绑到CtrlAltB对应的是 tasks.json 里group.kind build的那个任务按一下等于执行一次编译比 F5 更可控F5 会连带启动调试器。第二行CtrlAltR是「不调试直接运行」快速验证输出对不对时用它。第三行复制当前行when条件限定在编辑器有焦点时才生效避免和全局快捷键打架。多光标这块记住四个动作基本就够用CtrlD逐个选中下一个相同单词适合批量改变量名AltClick在任意位置加点CtrlAlt↓向下逐行加光标适合给一批结构体成员加逗号ShiftAlt拖动列选择处理对齐的初始化列表特别顺手。用CtrlD时注意先双击选中单词再按否则它会从光标位置开始选结果经常多选一个字符。2.3 中文编码与换行符跨平台协作的第一道坎编码问题在 Windows 上尤其恶心。VSCode 保存文件默认是 UTF-8无 BOM而 Windows 控制台默认代码页是 936GBK于是printf(中文)在集成终端里就成了一串问号或方块。这不是 VSCode 的锅是终端和源文件编码不一致。处理办法有三层按推荐顺序第一层把文件统一成 UTF-8files.encoding设成utf8就够了。如果打开一个老文件看到右下角显示GBK点它选「通过编码保存」再选 UTF-8一次性转掉。第二层让终端认识 UTF-8。在集成终端里执行chcp 65001把当前会话切到 UTF-8 代码页验证一下再跑程序中文就正常了。这个设置是会话级的关掉终端就失效要持久化得在 PowerShell 的 profile 里加但那属于系统层操作先手动切够用。第三层如果不想动终端就在 tasks.json 的args里加-fexec-charsetGBK让 g 直接把字符串字面量编译成 GBK 字节流跟终端代码页对上。这个办法的代价是源码里一旦有非 ASCII 字符跨平台就废了所以我一般只在临时验证时用。换行符同理。.gitattributes里写* textauto eollf配合files.eol: \n能避免绝大部分「整个文件都被改了」的提交。血泪经验是团队里只要有一台机器没配第一次合并就会产生几百行假 diffreview 的时候根本没眼看。3. 配 C/C 环境编译器选型与三份核心配置文件编辑器调顺之后才轮到真正的环境配置。这块的核心认知是VSCode 本身不是 IDE它不带编译器、不带调试器所有「能编译、能断点」的能力都来自你装的外部工具链外加三份 JSON 把它们串起来。搞不清这个分工就会一直在「为什么装了插件还是不能编译」里打转。3.1 编译器从哪来MinGW-w64、MSVC 与 Clang 的取舍Windows 上能用的 C 编译器主要有三条路选哪条取决于你要干什么工具链获取方式调试器适合场景主要代价MinGW-w64gMSYS2 包管理或独立压缩包gdb课设、刷题、跨平台小项目与 Windows 原生库 ABI 不完全兼容MSVCcl.exe独立 Build Tools 安装器cppvsdbg需要调用 Windows SDK、DirectX只能Windows命令行为非 POSIX 风格Clang/LLVM官方预编译包lldb想统一 macOS/Linux 体验Windows 上仍需 MSVC 的头文件与库新手我一般直接推 MinGW-w64理由是错误信息可读性好、跟 Linux 上的 g 命令几乎一致、gdb 的调试体验也够用。装完之后第一件事是验证g --version gdb --version g -v 21 | findstr Target第三条命令输出的Target: x86_64-w64-mingw32告诉你这是 64 位工具链。如果输出的是i686-w64-mingw32说明装成了 32 位版本后面链接第三方库时会一路踩坑——32 位和 64 位的.a、.lib不能混用。这一步别省我见过不止一个人在这上面耗掉一下午。还有一个隐性问题g --version能跑不代表 VSCode 能找到它。VSCode 的终端和任务用的是系统 PATH如果只在某个 shell 的启动脚本里export PATH任务照样失败。要么把...\mingw64\bin加进系统环境变量要么在配置文件里写绝对路径——我倾向后者路径写在 JSON 里换机器时改一处就够了不用碰系统设置。3.2 c_cpp_properties.json让 IntelliSense 不再乱标红这份文件只管一件事告诉 C/C 扩展去哪找头文件、按哪个标准做语法分析。它不参与编译所以经常出现「编辑器满屏红波浪线但 g 编得过去」的割裂感——原因就是这里的includePath和实际编译时的-I不一致。{ version: 4, configurations: [ { name: Win32, includePath: [ ${workspaceFolder}/**, ${workspaceFolder}/include ], defines: [_DEBUG, UNICODE, _UNICODE], compilerPath: C:/msys64/mingw64/bin/g.exe, cStandard: c11, cppStandard: c17, intelliSenseMode: windows-gcc-x64 } ], version: 4 }关键字段逐个说。compilerPath是整份配置里最重要的一个填了它之后扩展会自动去问编译器要系统头文件路径和预定义宏includePath就只需要补项目自己的目录。很多人不填这一项然后发现vector标红就是因为扩展不知道标准库在哪。路径里的斜杠用/或者转义成\\别直接写单个反斜杠——JSON 里\v是转义字符会直接把配置解析炸掉。includePath里的${workspaceFolder}/**是递归匹配整个工作区小项目省事大项目会让索引变慢那时候把它换成具体子目录更好。intelliSenseMode必须和compilerPath对应的工具链匹配windows-gcc-x64对应 64 位 MinGW写成windows-msvc-x64就会出现一堆莫名其妙的类型不匹配提示。defines里的UNICODE、_UNICODE是给 Windows API 用的纯算法题用不上但一旦碰到TCHAR、LPCWSTR这些类型没有它们就会一片红。写不写取决于项目别照抄。3.3 tasks.json 与 launch.json编译与调试的闭环这两份文件是一对tasks.json 负责「怎么编译」launch.json 负责「怎么启动调试器」中间靠preLaunchTask和label的名字对应起来。{ version: 2.0.0, tasks: [ { label: build-cpp, type: shell, command: g, args: [ -g, -stdc17, -Wall, -Wextra, ${file}, -o, ${fileDirname}/build/${fileBasenameNoExtension}.exe ], options: { cwd: ${workspaceFolder} }, group: { kind: build, isDefault: true }, problemMatcher: [$gcc], presentation: { reveal: always, panel: shared } } ] }参数含义-g生成调试符号没有它断点根本打不上这是新手最常漏的一个-stdc17指定语言标准要和 3.2 里的cppStandard保持一致-Wall -Wextra打开常用告警能提前发现未初始化变量、有符号无符号比较这类隐性问题。${file}是当前打开的单个源文件${fileDirname}是它所在目录${fileBasenameNoExtension}是不带扩展名的文件名。problemMatcher: [$gcc]把 g 的输出按 GCC 格式解析编译错误会直接列在「问题」面板里点一下跳到对应行比在终端里翻滚动条强太多。presentation.panel: shared让多次编译复用同一个终端面板不然每按一次就多开一个很快就乱成一团。注意输出路径里的build/目录必须提前存在g 不会自动创建它。手动mkdir build一次或者在 powershell 里执行任务前加一句判断。接着是调试配置{ version: 0.2.0, configurations: [ { name: gdb 单文件调试, type: cppdbg, request: launch, program: ${fileDirname}/build/${fileBasenameNoExtension}.exe, args: [], stopAtEntry: false, cwd: ${fileDirname}, environment: [], externalConsole: false, MIMode: gdb, miDebuggerPath: C:/msys64/mingw64/bin/gdb.exe, setupCommands: [ { description: 启用整齐打印, text: -enable-pretty-printing, ignoreFailures: true } ], preLaunchTask: build-cpp } ] }program必须和 tasks.json 里的-o输出路径完全一致差一个目录就报「无法找到程序」。cwd决定程序运行时的相对路径基准读文件的代码如果用的是相对路径这一项设错就会「明明文件在却打不开」。externalConsole: false表示输出走 VSCode 内部gdb 下程序的标准输出通常出现在「调试控制台」而不是「终端」标签页第一次用容易找不到——切一下标签页就看到了。preLaunchTask的值必须和 tasks.json 的label一字不差包括大小写。miDebuggerPath指向 gdb 可执行文件本身不是目录。-enable-pretty-printing让 STL 容器在调试面板里显示成可读的键值对不加的话std::vector只能看到一个内部指针地址形同黑匣子。4. 多文件工程与 CMake从单文件玩具到能编译的项目单文件配置跑通只是入门。真正的项目一拆成main.cpp 几个模块前面那套${file}就立刻失效——它只编译当前打开的那一个文件其他.cpp里的函数全部「未定义引用」。这一章把配置从单文件推到多文件再推到 CMake。4.1 头文件搜索路径与 -I 的写法先说清楚#include xxx.h和#include xxx.h的区别引号形式先在源文件所在目录找再找-I指定的路径尖括号形式只找-I路径和系统路径。所以项目自己的头文件放include/目录时两种写法都得配-I。一个典型的多文件目录长这样demo/ ├── include/ │ └── math_utils.h ├── src/ │ ├── main.cpp │ └── math_utils.cpp └── build/对应的一次性编译命令g -g -stdc17 -Wall -Wextra -Iinclude \ src/main.cpp src/math_utils.cpp \ -o build/app.exe-Iinclude是相对路径相对的是命令执行时的当前目录所以这条命令必须在demo/根目录下执行。这就是 tasks.json 里options.cwd要设成${workspaceFolder}的原因——不设的话任务有可能在别的目录下跑-Iinclude就找不到了。更省事的写法是用通配符g -g -stdc17 -Iinclude src/*.cpp -o build/app.exe但这行命令在不同 shell 下行为不一样bash 由 shell 自己展开*.cppWindows 的 PowerShell 不会展开直接把src/*.cpp这个字面量传给 g。MinGW 的 g 内部带了一层通配符处理多数时候能兜住但一旦路径里有空格或者遇上某些版本的构建工具就会翻车成「找不到文件」。我一般不用通配符宁可把文件名列全——列全了还有个好处加文件时你会意识到自己在改构建配置而不是稀里糊涂地被通配符带上。对应的 tasks.json 只需要把${file}换成固定的源文件列表{ label: build-multi, type: shell, command: g, args: [ -g, -stdc17, -Wall, -Wextra, -Iinclude, src/main.cpp, src/math_utils.cpp, -o, build/app.exe ], options: { cwd: ${workspaceFolder} }, group: { kind: build, isDefault: true }, problemMatcher: [$gcc] }4.2 CMakeLists 最小可用模板与 CMake Tools 配置文件数一过五六个手写 tasks.json 就开始难受了加一个文件要改配置改一次配置要重新想一遍参数。这时候上 CMake它的价值不在「高级」在于「把源文件列表和编译参数集中到一个地方」。最小可用模板cmake_minimum_required(VERSION 3.15) project(demo LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_EXPORT_COMPILE_COMMANDS ON) add_library(math_utils STATIC src/math_utils.cpp) target_include_directories(math_utils PUBLIC include) add_executable(app src/main.cpp) target_link_libraries(app PRIVATE math_utils)逐行解释project(... LANGUAGES CXX)显式声明只用 C避免 CMake 去探测 C 编译器浪费时间。CMAKE_CXX_STANDARD_REQUIRED ON很关键不加的话编译器不支持 C17 时 CMake 会默默降级到能用为止最后你在源码里用的新特性就变成一堆语法错误。CMAKE_EXPORT_COMPILE_COMMANDS ON生成compile_commands.jsonC/C 扩展能读它拿到最准确的编译参数从此 IntelliSense 和真实编译彻底对齐标红问题少一大半。add_library(... STATIC ...)把工具代码编成静态库target_include_directories用PUBLIC让依赖它的目标自动继承头文件路径。这个写法比全局include_directories()好后者会把路径泄漏给所有目标项目一大就容易撞名。构建命令cmake -S . -B build -G MinGW Makefiles -DCMAKE_BUILD_TYPEDebug cmake --build build -j 8-S .指定源码目录-B build指定构建目录源码和产物彻底分开build/整个进.gitignore。-G MinGW Makefiles是必须的Windows 上 CMake 默认想用 Visual Studio 生成器没装 VS 就会报「找不到合适的生成器」。-DCMAKE_BUILD_TYPEDebug决定加不加-gRelease 下不带调试符号断点是打不上的。-j 8是并行编译任务数按核数写。如果装了 CMake Tools 扩展在.vscode/settings.json里补两项点状态栏按钮就能构建{ cmake.generator: MinGW Makefiles, cmake.buildDirectory: ${workspaceFolder}/build, cmake.configureOnOpen: true }4.3 断点调试多文件launch.json 里 program 与 cwd 的坑CMake 工程调试时launch.json 的program不再是${fileDirname}/build/xxx.exe而是 CMake 产物的实际位置。上面的模板会把可执行文件放在build/app.exe{ name: CMake 多文件调试, type: cppdbg, request: launch, program: ${workspaceFolder}/build/app.exe, args: [--input, data/sample.txt], stopAtEntry: false, cwd: ${workspaceFolder}, environment: [], externalConsole: false, MIMode: gdb, miDebuggerPath: C:/msys64/mingw64/bin/gdb.exe, preLaunchTask: CMake: build }program写死成build/app.exe是这份配置里最省事的选择。有人喜欢用${command:cmake.launchTargetPath}好处是切换构建类型时自动跟着变坏处是调试器启动时 CMake 扩展没初始化完就会拿到空字符串报「程序不存在」。我一般写死换目录时改一处。cwd设成${workspaceFolder}意味着程序里fopen(data/sample.txt, r)是相对项目根目录找的。如果设成${workspaceFolder}/build同一个路径就会去找build/data/sample.txt然后返回空指针——这个错误不会报错只会让程序行为诡异是典型的「代码没错、配置背锅」。args传命令行参数调试时不用每次手敲。preLaunchTask填CMake: build是 CMake Tools 自动注册的任务名具体名字可以在CtrlShiftP→Tasks: Run Task里看到实际列表照抄过来别凭印象写。多文件断点的实际用法在math_utils.cpp的函数体里打断点F5 启动后单步进入默认 F11只要对应源文件参与了编译且带-g就会正常跳进去。跳不进去的常见原因有两个——构建类型是 Release没有调试符号或者断点打在了头文件的 inline 函数里而实际执行的是另一份编译单元。前者改CMAKE_BUILD_TYPE后者在调试时看「调用堆栈」面板确认实际加载的源文件路径。5. 避坑与排查C 环境配置最常见的五类翻车现场这一章集中处理实际配环境时最容易撞上的五类问题。每一条都按「现象 → 原因 → 解决」写照着对号入座基本能省掉大半折腾时间。顺序按我遇到的频率排。5.1 现象F5 弹「miDebuggerPath 指向的路径不存在」原因launch.json里miDebuggerPath写的是目录比如C:/msys64/mingw64/bin而不是gdb.exe本身或者路径里的反斜杠被 JSON 吃掉了C:\msys64\...里的\m虽然合法但\b、\t会变成退格和制表符还有一种情况是装的 MinGW 版本只带了 g 没带 gdb。解决先在终端里用绝对路径跑一次C:/msys64/mingw64/bin/gdb.exe --version能出版本号说明文件在。然后把路径原样粘进 JSON统一用正斜杠。如果报的是「文件不存在」去bin目录下看一眼有没有gdb.exe没有就补装mingw-w64-x86_64-gdb这个包。改完保存不用重启 VSCode重新按 F5 就行。5.2 现象程序输出里中文全是乱码或问号原因源文件是 UTF-8Windows 控制台代码页是 GBK两边编码不一致。另一种变体是源文件被存成了带 BOM 的 UTF-8某些编译器会把 BOM 当成源码内容报一个莫名其妙的stray \357 in program。解决分两步。第一步在集成终端执行chcp 65001切到 UTF-8再跑程序看是否正常正常就说明是编码不一致持久化的话在 PowerShell profile 里加这行。第二步如果编译就报stray错误用 VSCode 右下角的编码菜单选「通过编码保存」存成不带 BOM 的 UTF-8。临时应付也可以在args里加-fexec-charsetGBK但只适合验证不适合长期用。5.3 现象按 F5 提示「preLaunchTask build-cpp 已终止退出代码 1」原因三种可能。任务本身编译失败了代码有错或者build/目录不存在导致-o写不进去preLaunchTask的名字和 tasks.json 里的label大小写或空格不一致任务被配成了后台任务但没声明problemMatcher的后台模式VSCode 一直等它「结束」等不到最后超时终止。解决先CtrlShiftP→Tasks: Run Task手动跑一遍同名任务看终端里真实的错误信息。如果是cannot open output filemkdir build。如果名字对不上复制label的值贴到preLaunchTask别手打。如果任务本身没问题但一直卡住检查presentation里有没有误设panel: dedicated配合长时间运行的命令。5.4 现象编辑器里string、vector标红但 g 编译完全正常原因c_cpp_properties.json的compilerPath没填或填错了扩展找不到系统头文件目录或者intelliSenseMode和实际工具链不匹配比如用着 64 位 MinGW 却写了windows-msvc-x64。解决把compilerPath指向g.exe的绝对路径intelliSenseMode改成windows-gcc-x64然后CtrlShiftP执行C/C: Reset IntelliSense Database等它重新索引完。如果工程用了 CMake更稳的做法是打开CMAKE_EXPORT_COMPILE_COMMANDS扩展会自动优先读compile_commands.json比手写includePath准得多。5.5 现象项目放在中文或带空格的目录下编译突然失败原因路径里的空格在 shell 调用链上被当成参数分隔符中文路径则在某些工具链的 locale 处理下变成乱码字符串。g 本身多数情况扛得住但 CMake 生成器、Makefile、gdb 的组合里只要有一环没处理好引号就会断在中间。解决最省事的方案是换个纯英文、无空格的路径比如D:/code/demo。如果非留不可在 tasks.json 里给路径加引号包一层——-I\${workspaceFolder}/include\这种写法能救一部分场景但 CMake 生成的 Makefile 那层不好控制。我的做法是项目根目录一律英文短名中文只出现在子目录里的资源文件上且代码里读这些文件时用宽字符 API。后悔药没得吃一开始就别踩。6. 验证环境是否真的通了告警、诊断日志与一份可复用的配置模板配置写完不代表配对了。我判断一套 C 环境是否真的可用看三个信号编译时告警是否按预期出现、调试器是否能停在不带main的源文件里、以及换一个干净目录重新走一遍流程是否还成立。第一个信号最容易被忽略。把告警开满再编一遍g -g -stdc17 -Wall -Wextra -Wshadow -Wconversion \ -Iinclude src/main.cpp src/math_utils.cpp -o build/app.exe如果一行告警都没有反而要怀疑参数没生效——写一个int x;未初始化就用的例子试一下-Wall应该报uninitialized。-Wshadow抓变量遮蔽-Wconversion抓隐式窄化这两个是默认不开的加不加看项目洁癖程度但至少要知道它们存在。第二个信号是调试器真的在工作。在math_utils.cpp里函数第一行打个断点F5 启动看「调用堆栈」面板里显示的是不是math_utils.cpp的真实路径。如果显示的是反汇编或者??说明调试符号没生成缺-g或者加载的是旧的可执行文件构建没跑。第三个信号是干净环境复现。把.vscode/整个删掉只留源码和 CMakeLists.txt按第 3、4 章的步骤重配一遍。能在十分钟内跑通说明这份配置是可移植的如果必须依赖某个记忆里的手动操作那它迟早会在换机器时咬你一口。拿到这份讲解之后比较省时间的用法是先跳到配置章节把三份 JSON 原样抄进.vscode/然后只改两个值——compilerPath里的工具链路径和miDebuggerPath里的 gdb 路径。这两个对上其余字段基本不用动剩下的就是拿一个小main.cpp验证。等单文件跑通了再回头看 CMake 那一节升级成多文件结构会顺很多。验证项判定标准不通过时的第一检查点编译器可见g --version有输出系统 PATH 是否含mingw64\bin调试器可见gdb --version有输出MinGW 是否装了 gdb 组件调试符号断点能停在子模块源码-g与CMAKE_BUILD_TYPEIntelliSense标准库头文件不标红compilerPath是否填了 g.exe运行路径相对路径能读到文件launch.json 的cwd这套东西我到现在还在用只是每次新建工程时都会强制走一遍「删掉 .vscode 重配」的验证不为别的就是想确认自己没有依赖某次偶然点对的设置。环境配置这东西最怕的就是「上次能用」说不清为什么能用也就说不清为什么不能用。希望帮到你。本文还有配套的精品资源点击获取
