简介：面向Windows平台初学C/C++、希望用轻量编辑器替代传统IDE的开发者与自学者，这份教程围绕VSCode开发环境的完整搭建流程展开，重点解决编译器缺失、插件安装、环境变量设置、调试任务编写等入门阶段常见障碍。压缩包内仅含1个docx文档，体积约7.46MB，以图文步骤组织内容，便于按章节查阅和对照操作；已有1486人学习下载，显示其在同类入门配置资料中具有一定参考价值。文档从VSCode下载安装、中文语言包设置讲起，依次说明MinGW-w64编译器的获取与解压、PATH环境变量配置、C/C++插件安装，以及tasks.json和c_cpp_properties.json的生成与修改，并延伸到单文件代码编译、运行和F5调试。文中还提示项目路径避免中文、调试报错排查等细节，并给出可直接参照的配置片段，适合需要一份可跟随操作的Windows端C/C++环境配置手册、希望少走弯路的读者。
1. 先说结论：Windows 上这套 VSCode + C/C++ 环境，谁该配、谁别碰
在 Windows 上把 VSCode 配成能写、能编、能断点调试的 C/C++ 环境，说到底就是三样东西的拼装：一个编辑器、一套 MinGW-w64 编译器、三份.vscode下的 JSON 配置。市面上流传的 C++ Windows 课程资源大多只给截图，真正值钱的是那几份能直接抄的配置文件，以及踩过之后才知道的路径规矩。这套环境适合已经能自己找文件、改环境变量、看得懂报错行号的人；如果你刚接触编程，连「工作区」和「终端当前目录」都还没概念，那我建议先上一个集成环境把语法跑熟，回头再来碰 VSCode，否则头两周大概率耗在和编译器无关的事情上。下面这套流程我按「先装编译器、再建工作区、最后写配置」的顺序走，每一步都给验证方法。
2. 编译器先落地：MinGW-w64 的包怎么挑、放哪、PATH 怎么验
2.1 把「写代码」和「生成 exe」拆成三件事
很多人第一次配环境失败，根源是把 VSCode 当成了一个 IDE。它不是。VSCode 在这一套里只负责三件事：文本编辑、语法高亮、把外部工具的命令行包装成一个可以点按钮的任务。真正把.cpp变成.exe的是编译器，把.exe跑起来并且能停在断点上的是调试器，两个都不在 VSCode 里。
Windows 上最省事的组合是 MinGW-w64：它把 GCC 编译器套件移植到了 Windows 平台，包含gcc.exe、g++.exe、gdb.exe、mingw32-make.exe这几样必需品。选它而不是 MSVC 的理由很实际——命令行参数和 Linux 上写的gcc -g main.c -o main完全一致，教材、课程、博客里的编译命令可以直接照搬；选它而不是 WSL 的理由也很实际——文件路径还是C:\开头，不用在两套文件系统之间来回倒腾。
所以整条链路是：VSCode 编辑源码 → 调用g++.exe编译链接 → 调用gdb.exe加载调试符号。三份 JSON 配置分别管这三段中的不同环节，后面第 4 章会逐个拆。先把编译器装上，不然后面所有配置都是空转。
2.2 下载包怎么挑：架构、线程模型、异常处理三个维度
进 MinGW-w64 的下载页会看到一堆名字很像的压缩包，x86_64-posix-seh、x86_64-win32-seh、i686-posix-dwarf之类。这不是随便起的，三个字段分别代表 CPU 架构、线程模型、异常处理机制。
| 名称片段 | 含义 | 建议 |
|---|---|---|
x86_64 | 64 位目标程序 | 现在一律选这个，除非要维护 32 位老工程 |
i686 | 32 位目标程序 | 只在必须产出 32 位 exe 时用 |
posix | 使用 POSIX 线程模型 | 常用，兼容std::thread相关写法 |
win32 | 使用 Windows 原生线程 | 少数场景更贴近系统 API |
seh | 结构化异常处理，仅 64 位可用 | 64 位首选，异常开销小 |
dwarf | 基于 DWARF 的异常处理，32 位用 | 32 位包里常见 |
我一般固定选x86_64+posix+seh这一组，日常写 C++ 标准库的线程、异常都不需要额外折腾。页面上那个显眼的下载按钮往往指向的是安装器或者老版本，实际做法是往下滚，进到归档目录里挑对应这一组的压缩包，下载下来是一个.7z或.zip。
提示：包里没有安装程序，解压即用。这意味着后面如果想换版本，直接把文件夹换掉、PATH 指向新目录就行，不会在系统里留下残余。
2.3 解压位置与环境变量：三个容易做错的细节
解压出来是一个mingw64文件夹，里面包含bin、lib、include、x86_64-w64-mingw32等子目录。放到哪里都行，但我建议放一个短路径，比如C:\mingw64，原因是后面三份 JSON 里要反复写这个绝对路径，路径越长越容易在某份配置里写错一个字符。
接下来把C:\mingw64\bin追加到系统环境变量PATH。按Win + S搜「环境变量」，打开「编辑系统环境变量」→「环境变量」→ 在「系统变量」里找到Path→「编辑」→「新建」→ 粘贴C:\mingw64\bin→ 连续确定三层退出。
三个细节值得单独说。第一，追加到「系统变量」的Path而不是「用户变量」，这样换用户登录、或者用管理员权限开的终端都能认到；第二，填的是bin目录，不是C:\mingw64，因为PATH里放的是可执行文件所在目录；第三，路径结尾不要带反斜杠，写成C:\mingw64\bin\在部分解析逻辑里会被当成转义处理，虽然多数情况没事，但没必要赌。
2.4 用三条命令确认编译器真的生效
环境变量改完，最忌讳的就是「我觉得配好了」。开一个新的 PowerShell 或 CMD 窗口，敲下面三条：
gcc --version g++ --version where gcc--version输出的是编译器版本号和构建信息，能看到一行gcc (x86_64-posix-seh-rev...) 13.x.x之类的信息就说明命令能被找到并执行。where gcc输出的是实际被命中的路径，正常情况下应该只有一行，指向C:\mingw64\bin\gcc.exe。
注意：如果你在改环境变量之前就已经打开了 VSCode，VSCode 及其内置终端继承的是旧的环境变量快照，
gcc依然会提示「不是内部或外部命令」。这不是 PATH 没配对，是进程没重启。把 VSCode 完全关掉再开，或者干脆重启一次资源管理器。
如果where gcc输出了多行，说明机器上装了不止一套 GCC（比如之前装过别的 IDE 自带了一份），那么后面c_cpp_properties.json里就必须写绝对路径，不能依赖PATH的解析顺序，否则你改的是 A 编译器、跑的是 B 编译器，那种「明明改了配置却没反应」的玄学就是这么来的。
3. 工作区先立住：中文路径、文件夹打开与扩展三件套
3.1 第一步是建文件夹，不是新建文件
新手最常见的起手式是Ctrl + N新建一个文件，写两行printf，然后直接按运行。在 VSCode 里这条路走不通，因为编译产物要有地方落、.vscode配置要有地方存、调试器要有一个确定的工作目录，这三件事都以「文件夹」为单位。
所以正确的顺序是：先在磁盘上建一个源码文件夹，再让 VSCode 打开这个文件夹（文件 → 打开文件夹），之后所有.vscode/*.json都会自动生成在这个文件夹下面。VSCode 的很多 C/C++ 相关行为——任务的cwd、${workspaceFolder}的取值、调试时程序的工作目录——全部以「打开的文件夹」为锚点。锚点错了，后面写多少配置都白搭。
我一般的做法是在C:\或者某个专门的代码盘下建test_vscode，一个项目一个文件夹，互不干扰。别把所有练习代码塞进同一个目录，因为多文件编译的通配符会把目录下所有源码一起编进去，某个文件里留着一个重复的main函数，链接阶段就会炸给你看。
3.2 中文与空格路径：一类最不值得排查的报错
建文件夹的时候顺手检查一眼路径：不要有中文，不要有空格，不要有&、#、括号这类 shell 有特殊含义的字符。这条规矩不是洁癖，是 GDB 的老毛病——调试器在解析带非 ASCII 字符的路径时可能出现编码错乱，表现是断点能停但变量窗口是空的，或者干脆启动调试就报一个语焉不详的「无法启动程序」。
原文里那张打码的报错截图就是这个场景。麻烦的地方在于，这类报错不会告诉你「你的路径有中文」，它只会给你一个 exit code 或者一句Unable to start debugging，然后你就开始怀疑插件、怀疑launch.json、怀疑编译器版本，一路排查到半夜，最后一改文件夹名就好了——这就是典型的血泪经验，属于知道了一分钟解决、不知道能耗一晚上的类型。
顺带把文件名也统一成英文加下划线，test.c、main.cpp、utils.cpp这种。中文路径的坑只在路径上，但混着来容易漏查。
3.3 扩展安装顺序：中文包、C/C++、以及容易被漏掉的第三个
VSCode 刚装完是英文界面。Ctrl + Shift + X打开扩展面板，搜Chinese，装那个中文语言包，装完右下角会弹一个重启提示，点Restart之后界面就是中文了。这一步纯属体验，不影响功能，先做掉省得后面看着一堆英文菜单心烦。
第二个装的是 C/C++ 扩展，扩展面板搜c/c++，排第一的那个就是。它提供三样东西：IntelliSense（头文件补全、跳转定义、红波浪线检查）、调试适配器（cppdbg类型，launch.json依赖它）、以及一批命令面板里的配置入口（比如「C/C++: 编辑配置 UI」）。没有它，.vscode里的launch.json写了也不会生效，因为找不到cppdbg这个调试器类型。
提示：装完这两个扩展之后重启一次 VSCode。扩展的激活时机不完全一致，有的要等到打开对应语言的文件才加载，重启一次能避免「扩展明明装了但菜单里没有」这种假故障。
还有一个容易被漏掉的：如果你后面打算用 CMake 组织工程，需要额外装 CMake Tools；如果只打算走tasks.json这条路，就不用装。这个选择在第 5 章会讲到边界。
4. 三份 JSON 打通编译与调试：c_cpp_properties、tasks、launch
4.1 c_cpp_properties.json：IntelliSense 的红波浪线归它管
这份文件只影响编辑器里的代码提示和静态检查，不影响实际的编译结果。换句话说，它配错了你照样能编译出 exe，但编辑器里#include <stdio.h>底下会有红波浪线，printf跳不到定义。反过来，它配对了也不代表编译能过。
生成方式是命令面板（Ctrl + Shift + P）里搜「C/C++: 编辑配置」，选编译器路径那一项，然后在弹出的列表里选C:\mingw64\bin\gcc.exe。VSCode 会自动在.vscode下写出这份文件。原文给出的版本里有两个配置块，一个Win32指向gcc.exe，一个C++指向g++.exe：
{ "configurations": [ { "name": "Win32", "includePath": [ "${workspaceFolder}/**" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE" ], "windowsSdkVersion": "10.0.22621.0", "compilerPath": "C:/mingw64/bin/gcc.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "gcc-x64" }, { "name": "C++", "includePath": [ "${workspaceFolder}/**" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE" ], "windowsSdkVersion": "10.0.22621.0", "compilerPath": "C:/mingw64/bin/g++.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "gcc-x64" } ], "version": 4 }字段含义逐个说清楚：compilerPath是 IntelliSense 用来推断系统头文件位置的入口，指向错的头文件列表就全错，这是红波浪线的头号成因——注意这里用的是正斜杠/，JSON 里反斜杠是转义字符，写C:\mingw64\bin\gcc.exe会让解析器把\m、\b、\g当成非法转义，要么直接报错要么静默吞掉。includePath里的${workspaceFolder}/**表示递归包含工作区下所有子目录，自己写的头文件只要在这个文件夹里就能被找到，不需要逐个添加。cStandard和cppStandard决定语法检查按哪个标准走，写c17/c++17意味着auto、结构化绑定、std::optional这些都能正常提示；如果你想用 C++20 的 concepts，改成c++20就行，但编译器那边的-std参数也要跟着改，两边不一致会出现「编辑器认、编译报错」的割裂。intelliSenseMode选gcc-x64跟 MinGW-w64 是 64 位匹配。
C 和 C++ 分两个配置块的用意是：写.c文件时切到Win32那个，写.cpp时切到C++那个，二者的系统头文件集合不同。如果你只写 C++，其实一份就够，直接复制粘贴原文这一整段也能用。
4.2 tasks.json：把 gcc/g++ 命令行固化成任务
编译器装好之后，最朴素的编译方式是开终端手敲：
# 在源码所在目录执行，-g 生成调试符号，-o 指定输出文件名 gcc -g test.c -o test.exe # C++ 换成 g++，其余一致 g++ -g test.cpp -o test.exe能跑通就说明编译器链路没问题，问题只剩「怎么让 VSCode 一键调用」。tasks.json干的就是这件事：把上面那行命令拆成command+args两个字段。
生成方式是先把test.c打开激活，然后走终端 → 配置默认生成任务 → C/C++: gcc.exe 生成活动文件，VSCode 会在.vscode下自动写出类似这样的内容：
{ "version": "2.0.0", "tasks": [ { "type": "cppbuild", "label": "build", "command": "g++.exe", "args": [ "-g", "${file}", "-o", "${fileDirname}\\${fileBasenameNoExtension}.exe" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": [ "$gcc" ] } ] }label是这个任务的名字，界面上显示的就是它，同时它也是launch.json里preLaunchTask要引用的键，两边必须一字不差。command这里写的是g++.exe而不是绝对路径，因为它已经在PATH里了；如果你机器上有多个 GCC，改写成"C:\\mingw64\\bin\\g++.exe"更稳妥。args逐项对应命令行：-g生成调试符号（不带它调试时看不到变量值），${file}是当前激活的源文件绝对路径，-o后跟输出位置，${fileDirname}是当前文件所在目录，${fileBasenameNoExtension}是去掉扩展名的文件名——所以test.c会产出test.exe，和手敲命令的结果一致。group.kind设成build并isDefault: true，它就绑到Ctrl + Shift + B上了。problemMatcher用$gcc，作用是让 VSCode 能解析编译器的错误输出并把问题列到「问题」面板里，点一下能跳到出错行，这一项别漏。
任务生成的exe和源码在同一目录，跑的时候在终端里敲：
.\test.exe注意.\前缀。PowerShell 出于安全策略，不会把当前目录放进命令搜索路径，直接敲test.exe会提示找不到命令，这不是编译失败，是 shell 的规矩。
4.3 launch.json：断点调试必须靠它，不能只靠终端
能编译能运行，不等于能调试。在终端里跑test.exe，scanf卡住的时候你想看变量值，没有任何切入口。要按下F5让程序停在断点上、能看调用栈和局部变量，必须有launch.json。
第一次按F5，如果这个文件不存在，VSCode 会让你选环境，选C++ (GDB/LLDB)，它会生成一份骨架，改完大概是这样：
{ "version": "0.2.0", "configurations": [ { "name": "g++.exe - 生成和调试活动文件", "type": "cppdbg", "request": "launch", "program": "${fileDirname}\\${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "C:\\mingw64\\bin\\gdb.exe", "setupCommands": [ { "description": "为 gdb 启用整齐打印", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "build" } ] }关键字段：type必须是cppdbg，这个类型由 C/C++ 扩展提供，扩展没装或没激活就会报「找不到调试类型」；miDebuggerPath指向gdb.exe，MinGW-w64 的bin目录里自带，写绝对路径并且在 JSON 里用双反斜杠转义；program是待调试的 exe 路径，要和tasks.json里的输出路径严格对应，否则会出现「调试器启动了一个已经过期的 exe」这种诡异现象——源码明明改了，断点就是进不去，实际上 F5 跑的是上一次编译的产物；preLaunchTask填"build"，值必须等于tasks.json里那个label，大小写和各处空格都要一致，不一致时 VSCode 会弹一个「找不到任务 build」的提示，然后跳过编译直接启动旧的 exe，这个降级行为最容易让人误判。
externalConsole设false表示用 VSCode 内置的调试控制台，程序的输出会出现在「调试控制台」里；设true会弹一个独立的黑窗口，适合写scanf交互比较多的练习代码，内置控制台的输入有时不太好用，卡在输入上可以直接改这一项试试。stopAtEntry设true会让程序一启动就停在main函数第一行，对确认「调试器到底有没有连上」很有用。
4.4 多文件工程：把${file}换成通配符之后发生了什么
单文件时代到此结束。一旦你把代码拆成main.c+utils.c+utils.h，${file}就只编译当前激活的那一个文件，链接阶段会报一堆undefined reference to 'xxx'——因为main.c里调用的函数在另一个编译单元里，编译器根本没看到它。
改法是把tasks.json里args的前两项换成目录通配符。原文给出的改造版本是：
{ "version": "2.0.0", "tasks": [ { "type": "cppbuild", "label": "C/C++: g++.exe 生成活动文件", "command": "C:\\mingw64\\bin\\g++.exe", "args": [ "-fdiagnostics-color=always", "-g", "${workspaceFolder}/*", "-o", "${workspaceFolder}\\${workspaceRootFolderName}.exe" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": [ "$gcc" ], "group": "build", "detail": "编译器: \"C:\\mingw64\\bin\\g++.exe\"" } ] }改动点集中在这两处：${file}换成${workspaceFolder}/*，含义是「把工作区根目录下所有文件都交给编译器」；输出路径改成${workspaceFolder}\\${workspaceRootFolderName}.exe，产物名变成文件夹名，好处是不管当前激活哪个源文件，产物路径恒定，launch.json里的program也就能固定下来，不用跟着切换文件改。
-fdiagnostics-color=always是强制彩色诊断输出，终端里错误行会更醒目，属于顺手加的。options.cwd指定命令执行时的工作目录，${fileDirname}表示当前文件所在目录，这对读取相对路径的资源文件有影响——程序运行时找./data.txt是相对于这个目录找的。
通配符这条路的边界必须说清楚：${workspaceFolder}/*只匹配根目录下一层，不会递归进子目录；它会把目录下所有文件都传给编译器，包括.txt、.md甚至.exe，GCC 遇到不认识的文件扩展名会当链接器输入处理，轻则警告重则报错；最要命的是如果两个源文件里都有main函数，链接阶段直接multiple definition of 'main'。所以它只适合「一个小练习目录、源码平铺、只有一个 main」的场景。工程一旦超过十来个文件、开始有子目录分层，就该换 CMake 了——手写通配符的方案维护不下去。
5. 避坑与排查：五类翻车现场的现象、原因与解法
5.1 现象：调试一启动就失败，提示语含糊得看不出问题
原因：工程路径、文件名或用户名目录里含中文、空格或 shell 特殊字符。GDB 在解析路径时对非 ASCII 字符的编码处理不一致，最终表现为「无法启动程序」「找不到指定的文件」，但不会明确指出是路径问题。
解决：把整个项目文件夹挪到纯英文短路径下，比如D:\code\test_vscode，重新用 VSCode 打开这个新文件夹，.vscode配置里的绝对路径同步改掉。改完先在终端手敲gcc -g xxx.c -o xxx.exe确认能编，再按 F5，把「编译」和「调试」两个环节分开验证，不要混在一起排查。
5.2 现象：任务列表里能看到 build，点运行却报「无法解析任务」
原因：tasks.json里写了//注释。原文的示例里就带着//${file}这种注释，那是给人看的说明，JSON 规范不支持注释。部分解析器会容忍，但cppbuild类型的任务用的是严格解析，遇到注释直接抛解析错误，表现就是任务在列表里显示但执行失败，或者干脆不显示。
解决：把所有//注释删干净。想保留说明就写到文件外面去，或者单独建一个README.md记配置意图。这条同样适用于c_cpp_properties.json和launch.json，三份文件都必须是纯 JSON。改完顺手在编辑器里看一眼有没有红色波浪线，VSCode 对 JSON 语法错误会直接标红。
5.3 现象：gcc --version在系统终端能跑，VSCode 内置终端里提示找不到命令
原因：VSCode 进程启动时复制了一份父进程的环境变量快照，之后系统里改PATH，已经跑着的 VSCode 及其终端子进程都看不到更新。同理，先开 VSCode 后装编译器，也必然遇到这个。
解决：完全退出 VSCode（不是关窗口，是任务栏也清掉），重新打开。如果还不行，在 VSCode 内置终端里执行echo $env:PATH（PowerShell）看看C:\mingw64\bin在不在里面，不在就说明PATH加错了位置——检查是不是加到了「用户变量」但当前用管理员权限启动导致环境不一致。极端情况下重启一次系统，比继续猜快得多。
5.4 现象：单文件好好的，拆成多个文件后一堆undefined reference
原因：tasks.json里还用着${file}，只编译了当前激活的那一个源文件。函数声明在头文件里能找到所以编辑器不报错，但定义在另一个.c文件里，链接器没见过那个编译单元，自然找不到符号。
解决：按 4.4 节把args改成${workspaceFolder}/*。改完如果出现multiple definition of 'main'，说明目录里有多个带main的文件被一起编进去了，把不参与本次构建的文件移出目录。这一步做完还是报错的话，看报错里提到的符号名，确认它确实定义在某个.c/.cpp里而没有拼写不一致（C++ 尤其注意命名空间和extern "C"）。
5.5 现象：#include底下全是红波浪线，但编译能过、程序能跑
原因：c_cpp_properties.json里的compilerPath写错或者写反了——用反斜杠导致转义、指到了不存在的路径、或者写 C++ 代码却把路径指向gcc.exe。IntelliSense 拿不到正确的系统头文件目录，就认为所有头文件都不存在。
解决：打开命令面板搜「C/C++: 编辑配置」，用 UI 重新选一次编译器路径，让 VSCode 自己写 JSON，避免手写转义出错。选完在右下角状态栏确认当前配置名（Win32还是C++）和正在编辑的文件类型匹配。改完等几秒让 IntelliSense 重新索引，还不消失就执行一次「C/C++: 重置 IntelliSense 数据库」。
注意：红波浪线属于「编辑器意见」，编译能否通过属于「编译器意见」，两者是两套独立系统。排查时先跑一次命令行编译确定真实状态，再回头处理波浪线，顺序反了会白折腾很久。
6. 进阶：把.vscode变成可复用模板，以及上手前的自检清单
配置这东西配一次就该一劳永逸。.vscode文件夹是纯文本，完全可以复制。我的习惯是建一个vscode-cpp-template的空工程，里面只有.vscode/c_cpp_properties.json、.vscode/tasks.json、.vscode/launch.json三个文件，加上一个空的main.cpp。下次开新练习，直接整个文件夹复制一份改名，打开就能编，省掉每次走一遍配置向导的时间。要注意的是三个文件里凡是写死绝对路径的地方（compilerPath、miDebuggerPath、command），换机器就得改，所以模板里我会统一用C:/mingw64/bin/这个固定前缀，机器换了只改这三处。
下面这份自检清单，是我每次在新机器上配完必走一遍的，按顺序执行，任何一步不过就停下来解决，别往下走：
| 序号 | 检查项 | 通过标准 |
|---|---|---|
| 1 | gcc --version | 输出一行版本信息，无「不是内部或外部命令」 |
| 2 | where gcc | 只有一行，指向你装的那个bin目录 |
| 3 | 工程路径 | 全英文、无空格、无特殊符号 |
| 4 | Ctrl + Shift + B | 生成任务成功，目录下出现对应.exe |
| 5 | 终端.\xxx.exe | 程序正常输出 |
| 6 | F5+ 断点 | 程序停在断点行，变量窗口能展开看到值 |
第 5 步和第 6 步要分开做，这是我最想强调的一点。命令行能跑但 F5 不行，问题一定在launch.json（program路径、preLaunchTask名字、miDebuggerPath）；命令行就跑不起来，问题一定在编译环节（tasks.json的args、源码本身）。把这两类故障的边界划清楚，排查时间能从两小时压到十分钟。
还有一个细节值得固化下来：每次改完源码按 F5 之前，先看一眼终端里编译任务有没有真的执行。preLaunchTask名字对不上时 VSCode 会静默跳过编译，直接调试上一次的 exe，表现是「断点位置和代码对不上」「改了逻辑但输出没变」。我吃过这个亏，改了三行代码调试半天以为逻辑写错，实际上跑的是十分钟前的产物。从那以后我养成一个习惯：每次开调之前先手动按一次Ctrl + Shift + B，确认编译任务真的跑完了、产物时间戳是刚刚，再按 F5。多花五秒，省下的是一晚上的自我怀疑。
这套模板和清单我用了很久，换过三台机器都是照着走一遍就通。希望帮到你。
本文还有配套的精品资源，点击获取
