企业官网建设流程全解析

刚在Visual Studio里装好C++环境，兴冲冲敲下#include <bits/stdc++.h>，结果红色波浪线瞬间爬满屏幕，编译输出里弹出fatal error C1083: 无法打开包括文件: “bits/stdc++.h”: No such file or directory。这个场景太熟悉了，几乎每一个从GCC、MinGW、Dev-C++或者各类在线评测平台转到VS的人，都会在第一回合撞上这堵墙。万能头文件在竞赛圈和大学课堂上被用得太顺手，导致很多人以为它是C++语言自带的标准零件，直到换了编译器才发现它原来只是个“特定工具链的赠品”。这篇分享就围绕这个具体问题展开，从根因、方案取舍、手工补全、环境配置到踩坑排查，把在VS里让#include <bits/stdc++.h>正常工作的完整路径拆开讲清楚。不管你是刚学C++的大一新生，还是从Linux服务器代码往Windows桌面项目迁移的老手，都能按图索骥，把这个看起来像“玄学”的问题变成一项可以复现的常规配置。

1. 问题根因：为什么VS找不到bits/stdc++.h

1.1 万能头文件的“万能”到底从哪来

先把这个头文件的身份说清楚。bits/stdc++.h不是C++标准委员会规定的标准头文件，你在ISO C++标准文档里翻不到它。它是GNU libstdc++实现里的一个扩展头文件，最早出现在GCC工具链中，路径通常位于编译器的include目录下，例如include/c++/版本号/bits/stdc++.h。它本身没有任何魔法，打开来看就是一长串#include语句，把C和C++的常用标准库头文件几乎全部聚合到一起：<iostream>、<vector>、<string>、<map>、<set>、<algorithm>、<cmath>、<cstdio>等等，能从里面找到。也就是说，它的“万能”本质是“批量包含”，而不是“语言特性”。

那为什么它会在竞赛和教学里流行？原因很直接：省事。写算法题时不用纠结某个函数在哪个头文件里，不用反复补#include，一行顶几十行。在时间紧张的比赛环境里，这种便利性被无限放大。但便利背后有三个代价：第一，它是非标准扩展，换编译器就可能消失；第二，它会显著增加编译时间，因为每个源文件都要展开大量头文件；第三，它可能引入一些实现特有的符号，降低代码可移植性。这三个代价在刷题时无所谓，在工程里却可能成为麻烦。明白这一点，就能理解为什么VS默认不给它，也能判断自己到底该不该继续用它。

1.2 MSVC与GCC的生态差异

Visual Studio默认使用的C++编译器是MSVC，也就是cl.exe。它使用的是微软自己的C++标准库实现，通常称为MSVC STL或微软STL。这个实现与GCC的libstdc++是两套独立的代码，各有各的目录结构、头文件命名和扩展集合。微软STL里没有bits这个目录，也没有stdc++.h这个文件，所以当预处理器看到#include <bits/stdc++.h>时，会在所有配置的包含目录里找bits/stdc++.h，找不到就直接报C1083。这不是VS的bug，也不是安装不完整，而是两条工具链在设计取舍上的不同。

有人会问：那我在VS里装个Clang行不行？可以，但要看Clang后端接的是哪套标准库。Windows上的Clang默认往往接MSVC STL，因为这样能直接使用Windows SDK和MSVC ABI，此时依然没有bits/stdc++.h。只有当Clang配上libstdc++时，才可能自带这个头文件，但Windows上给Clang配libstdc++并不是常规操作，成本高、兼容性问题多，普通学习和项目开发没必要走这条路。所以最稳的思路不是换编译器，而是自己把缺失的那一块补上。

1.3 你看到的各种报错到底在说什么

同样是红字，来源可能完全不同。我把最常见的几类列出来。第一类是编译错误，例如fatal error C1083: 无法打开包括文件: “bits/stdc++.h”: No such file or directory，这是预处理器真的找不到文件，代码无法继续编译。第二类是IntelliSense报错，例如编辑器里出现红波浪线，提示“检测到 #include 错误。请更新您的 includePath”，但命令行编译可能通过，或者编译时才报错。IntelliSense是编辑器层面的代码分析，它依赖自己的配置数据库，和实际编译器使用的包含路径未必完全一致。第三类是VS Code的C/C++扩展提示，比如“在找到包含的文件之前，不会报告”，这通常意味着扩展的includePath没配好，或者编译器路径没选对。

要排查问题，先分清是“编译不过”还是“编辑器看着不舒服”。编译不过必须解决路径问题，编辑器红波浪线则可以通过重新配置IntelliSense、重启VS、删除解决方案目录下的.vs隐藏文件夹来刷新。很多人把两者混在一起，结果改了半天编辑器配置，编译错误依旧。我的习惯是先在“输出”窗口看“生成”结果，确认错误号；再看“错误列表”里的来源列，判断是MSVC还是IntelliSense。这个区分动作能省下大量无效折腾。

2. 方案选型：三种解决思路的取舍

2.1 自制bits/stdc++.h并挂到包含目录

这是我最推荐的方案，尤其适合教学、竞赛、个人练习和中小型项目。思路很简单：既然MSVC没有这个文件，那就在项目能看到的目录里自己建一个bits/stdc++.h，把需要的标准库头文件写进去，然后把该目录加入“附加包含目录”。这样#include <bits/stdc++.h>就能被解析到，代码习惯完全不用改，跨平台分享时也只需要把include目录一起带走。它的优势是改动集中、可版本控制、不污染系统目录。缺点是你要维护这份头文件的内容，编译器升级到新标准时可能需要补充新头文件；另外它依然会拉长编译时间，这一点后面会用预编译头来缓解。

具体放哪儿？我通常不会放到系统include目录，因为那样容易在升级VS或被其他项目引用时产生混乱，也不方便随项目提交。推荐放在项目根目录下的include/bits/stdc++.h，然后在项目属性里添加$(ProjectDir)include。这样每个项目独立管理，互不干扰。如果是整个解决方案共用，可以放到解决方案目录下的shared/include/bits/stdc++.h，再用相对路径引用。注意路径里尽量别有中文和空格，虽然现代VS能处理，但某些命令行工具和第三方库在带空格路径下容易出幺蛾子，能避免就避免。

2.2 改用预编译头或强制包含

如果你不是非要保留#include <bits/stdc++.h>这个写法，VS官方其实提供了更工程化的方案：预编译头。你可以建一个pch.h，里面写上你常用的标准库头文件，甚至写上#include <bits/stdc++.h>也行，然后让每个cpp文件第一行包含pch.h，项目属性里开启“使用预编译头”。这样头文件只解析一次，后续编译速度会大幅提升。它的缺点是规则更严格：所有cpp必须在第一行包含pch.h，否则报C1010；而且预编译头文件本身需要先生成，清理重编时要确保生成顺序正确。对于大型项目，这是比万能头更靠谱的做法。

另一种轻量方案是“强制包含文件”。在项目属性 -> C/C++ -> 高级 -> 强制包含文件里填入某个头文件，编译器会在每个源文件开头自动包含它，不需要你手动写include。这个方案适合你想全局注入一些宏或常用头文件，但同样会让编译时间变长，而且可读性差，别人看代码时不知道某个符号从哪来。我的建议是：临时救急可以用，长期项目还是显式包含或者走预编译头。

2.3 换编译器或换IDE的适用边界

如果你的目标只是“在Windows上写C++算法题，能用万能头”，那装一套MinGW-w64或者MSYS2，在VS Code里把编译器配成g++.exe，是最省心的路径。因为MinGW-w64自带libstdc++，通常也自带bits/stdc++.h，不需要你手工造。VS Code本身只是编辑器，它调用外部编译器，配置好tasks.json和c_cpp_properties.json就能跑。这个方案适合学习、刷题、小型跨平台代码，但不适合依赖MSVC特性、Windows SDK、MFC、ATL、C++/CLI或者大型Windows桌面项目的场景。工具链换来换去，最后往往是项目构建系统先崩。

还有一种情况是生产项目里有人写了万能头，迁移到MSVC时编译不过。这时候不要急着换编译器，正确做法是评估这个头文件到底带来了多少便利。如果只是为了图省事，直接替换成具体头文件是长期收益最高的；如果代码量巨大、短期无法整改，再考虑自制头文件过渡。我的经验是：刷题代码随便用，工程代码尽早戒。

3. 手把手实操：在VS里造一个可用的万能头

3.1 创建头文件与内容模板

第一步，在项目根目录新建文件夹include，在里面再建bits文件夹，然后新建文件stdc++.h。注意文件名全小写，和代码里的bits/stdc++.h保持一致。Windows文件系统不区分大小写，但跨平台时需要统一小写，避免在Linux上出问题。文件内容我建议按C++标准分档，用条件编译控制，这样在C++14、C++17、C++20项目里都能用，不会因为包含了当前标准不存在的头文件而报错。

先给出一份我打磨过多次的模板，你可以直接复制：

#pragma once // C standard library #include <cassert> #include <cctype> #include <cerrno> #include <cfenv> #include <cfloat> #include <cinttypes> #include <climits> #include <clocale> #include <cmath> #include <csetjmp> #include <csignal> #include <cstdarg> #include <cstddef> #include <cstdint> #include <cstdio> #include <cstdlib> #include <cstring> #include <ctime> #include <cwchar> #include <cwctype> // C++ standard library (C++11/14) #include <algorithm> #include <array> #include <atomic> #include <bitset> #include <chrono> #include <complex> #include <condition_variable> #include <deque> #include <exception> #include <fstream> #include <functional> #include <future> #include <initializer_list> #include <iomanip> #include <ios> #include <iosfwd> #include <iostream> #include <istream> #include <iterator> #include <limits> #include <list> #include <locale> #include <map> #include <memory> #include <mutex> #include <new> #include <numeric> #include <ostream> #include <queue> #include <random> #include <ratio> #include <regex> #include <scoped_allocator> #include <set> #include <sstream> #include <stack> #include <stdexcept> #include <streambuf> #include <string> #include <system_error> #include <thread> #include <tuple> #include <typeindex> #include <typeinfo> #include <type_traits> #include <unordered_map> #include <unordered_set> #include <utility> #include <valarray> #include <vector> #if defined(_MSVC_LANG) && _MSVC_LANG >= 201703L #include <any> #include <charconv> #include <execution> #include <filesystem> #include <memory_resource> #include <optional> #include <shared_mutex> #include <string_view> #include <variant> #endif #if defined(_MSVC_LANG) && _MSVC_LANG >= 202002L #include <barrier> #include <bit> #include <compare> #include <concepts> #include <coroutine> #include <format> #include <latch> #include <numbers> #include <ranges> #include <semaphore> #include <source_location> #include <span> #include <stop_token> #include <syncstream> #include <version> #endif

这里有个关键点必须解释：为什么用_MSVC_LANG而不是__cplusplus？因为MSVC默认把__cplusplus宏定义为199711L，除非你显式添加/Zc:__cplusplus编译选项。这是MSVC为了兼容旧代码而做的历史选择，但会让很多依赖__cplusplus判断标准版本的代码失效。_MSVC_LANG是微软提供的宏，能正确反映当前语言标准，比如C++17下它等于201703L。所以在这份头文件里用_MSVC_LANG做条件判断，比用__cplusplus更稳。如果你在项目属性里加了/Zc:__cplusplus，两者一致，但用_MSVC_LANG依然没问题。

还要注意，这个模板里的<execution>、<filesystem>、<format>等头文件在部分老版本VS里可能不存在，或者需要额外组件。如果你用的是VS2017早期版本，C++17支持不完整，可以删掉对应的#if块。如果你用的是VS2019/2022，基本都能用。我的原则是：宁可少包含，也不要为了“全”而在每个项目里引入编译错误。你完全可以根据自己常用的功能裁剪，比如不写并发就删掉<thread>、<mutex>、<future>、<condition_variable>，能省一点编译时间是一点。

3.2 放置位置与项目附加包含目录配置

文件建好后，下一步是让编译器找到它。这里分几种情况。如果你用的是标准VS项目（有.vcxproj），右键项目 -> 属性 -> 配置属性 -> C/C++ -> 常规 -> 附加包含目录，点击编辑，添加$(ProjectDir)include。注意$(ProjectDir)自带末尾反斜杠，所以写成$(ProjectDir)include即可。如果你把include目录放在了解决方案根目录，可以用$(SolutionDir)include。如果你想用绝对路径，也可以，但不推荐，因为项目换电脑或换目录后会失效。

配置完成后，可以在项目属性 -> C/C++ -> 命令行里查看生成的编译命令，确认/I参数里包含了你的路径。这一步很多人跳过，导致改了属性却没生效，其实是因为改错了配置（Debug/Release）或改错了平台（x86/x64）。VS的属性页左上角有“配置”和“平台”两个下拉框，必须选成你当前要编译的那个组合。我见过不止一个同学在Debug|x64下配置，结果编译的是Release|x86，然后抱怨配置没用。这个坑很小，但很常见。

如果你用的是VS的“打开文件夹”模式，没有.vcxproj，那配置方式不同。你需要让VS生成CMake或者用CMakeLists.txt。更简单的做法是切回“创建新项目”的标准项目模式。如果坚持文件夹模式，可以在文件夹根目录放一个CMakeLists.txt，用target_include_directories指定include目录。VS对CMake的支持很好，配置一次就能长期用。至于VS Code，后面单独说。

3.3 验证与首次编译

配置完路径后，写一个最小测试文件验证。新建main.cpp：

#include <bits/stdc++.h> using namespace std; int main() { vector<int> v{1, 2, 3}; cout << "size = " << v.size() << endl; return 0; }

编译运行，如果输出size = 3，说明路径配置成功。如果还是报C1083，按以下顺序检查：第一，确认include/bits/stdc++.h文件真实存在，文件名没有拼错，没有隐藏的.txt后缀；第二，确认附加包含目录加的是include的上级路径，而不是bits的路径；第三，确认当前编译的配置和平台与你修改属性时选的一致；第四，清理解决方案并重新生成，排除旧缓存干扰；第五，检查路径里是否有中文、空格或特殊字符，尝试换成纯英文路径测试。

有时编译通过了，IntelliSense还在报红。这不是编译问题，而是编辑器数据库没刷新。可以尝试关闭VS再打开，或者删除项目目录下的.vs隐藏文件夹，还可以在“工具”->“选项”->“文本编辑器”->“C/C++”->“高级”里调整IntelliSense的浏览数据库回退路径。如果用的是VS Code，按Ctrl+Shift+P执行“C/C++: 编辑配置(UI)”，在包含路径里加上${workspaceFolder}/include，并确保编译器路径指向正确的cl.exe或g++.exe读取。记住：IntelliSense红波浪线不影响编译，但看着烦，还是修掉为好。

3.4 VS Code用户的对应配置

既然热词里反复出现VS Code，这里也把它的配置讲明白。VS Code不是编译器，它只是编辑器，真正干活的是g++.exe或cl.exe。如果你在VS Code里用MinGW-w64的GCC，通常不需要自己造万能头，因为MinGW自带。但如果你发现报错，先检查MinGW安装目录下有没有include/c++/版本号/bits/stdc++.h，没有的话说明MinGW安装不完整，换一个完整的发行版，比如MSYS2的pacman -S mingw-w64-x86_64-gcc。如果你在VS Code里用MSVC编译器，那就和VS一样，需要自制头文件并配置includePath。

一个可用的c_cpp_properties.json示例：

{ "configurations": [ { "name": "Win32", "includePath": [ "${workspaceFolder}/**", "${workspaceFolder}/include" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE" ], "compilerPath": "C:/mingw64/bin/g++.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "windows-gcc-x64" } ], "version": 4 }

如果你用MSVC，compilerPath可以指向cl.exe的完整路径，或者留空让扩展自动探测，但includePath必须加上你的include目录。tasks.json里配置编译命令时，也要确保/I或-I参数指向正确位置。很多人只配了c_cpp_properties.json，解决了红波浪线，但编译时用tasks.json里的老命令，依然报错。两个文件都要看。VS Code的配置分散在.vscode目录下，建议把这三个文件一起纳入版本控制：c_cpp_properties.json、tasks.json、launch.json。

4. 避坑与常见问题速查

4.1 编译慢、预编译头冲突、路径空格

万能头最大的副作用是编译变慢。我实测过，一个只有几十行的算法文件，包含bits/stdc++.h后首次编译可能需要两三秒甚至更久，而只包含<iostream>和<vector>时不到一秒。项目里cpp文件一多，这个差距会被放大到几十秒。解决办法就是预编译头：建一个pch.h，内容写#include <bits/stdc++.h>（或者你裁剪后的版本），建一个pch.cpp，内容写#include "pch.h"，然后在项目属性 -> C/C++ -> 预编译头里选择“使用(/Yu)”，预编译头文件填pch.h。对pch.cpp单独设置“创建(/Yc)”。之后每个cpp第一行写#include "pch.h"。这样编译时间能明显下降。

但预编译头有个硬性规则：所有参与编译的cpp文件必须在第一行包含指定的pch头文件，否则报C1010“在查找预编译头时遇到意外的文件结尾”。如果某个第三方cpp不能改，可以在那个文件上单独设置“不使用预编译头”。另一个常见问题是路径里有空格，比如C:\Users\My Name\project，这时候附加包含目录如果没加引号，命令行可能被截断。用$(ProjectDir)include通常没问题，因为MSBuild会处理，但手工写绝对路径时要注意。如果是CMake或Makefile，带空格路径需要显式加引号或用短路径。我的建议始终是：开发路径尽量纯英文、无空格。

还有一个细节：bits/stdc++.h里包含的头文件越多，和项目里已有头文件的宏冲突概率越大。比如某些Windows头文件定义了min和max宏，而<algorithm>里的std::min、std::max会被影响。MSVC默认在<windows.h>里定义这些宏，如果你在包含bits/stdc++.h之后再包含windows.h，可能触发一堆模板错误。解决办法是定义NOMINMAX宏，或者调整包含顺序。这个问题在纯算法代码里少见，一碰Windows桌面开发就容易冒出来。

4.2 报错对照表与排查顺序

我把常见现象、原因和处理方式整理成一张表，方便快速对照：

排查顺序我习惯按这个来：先看错误号，区分编译错误和IntelliSense错误；再看错误列表的来源列，确认是MSVC还是编辑器；然后检查附加包含目录是否生效，用“命令行”属性页看实际/I参数；接着检查文件是否存在、路径大小写、语言标准；最后清理重编，排除缓存。这个顺序能覆盖九成以上的情况。

4.3 多项目、跨平台分享时的注意事项

如果你写的代码要发给同学、同事，或者上传到在线评测平台，自制bits/stdc++.h会带来一个尴尬：对方的环境里没有你的include目录。在线评测平台通常用GCC，自带万能头，问题不大；但如果对方用VS打开你的项目，没有include目录就编译不过。这时候有几种处理方式。第一，把include目录连同项目一起打包，并在README里写明“本项目使用自制的万能头，位于include/bits/stdc++.h，请在项目属性中添加该目录”。第二，在代码里做条件编译，但注意这不能解决文件不存在的问题，只是让代码在不同平台上选择不同的包含方式：

#if defined(_MSC_VER) #include "bits/stdc++.h" // 指向项目自带的版本 #else #include <bits/stdc++.h> #endif

注意，用双引号包含时，编译器会先在当前源文件所在目录查找，然后才去附加包含目录。如果你的include目录结构正确，双引号和尖括号都能找到，但双引号更依赖相对位置，跨目录时容易出错。我更推荐统一用尖括号，把include目录加到附加包含目录里，这样不管源文件在哪个子目录，都能稳定找到。

跨平台项目还有一个坑：Linux下GCC的bits/stdc++.h可能包含一些非标准扩展，比如<ext/numeric>或<bits/...>下的私有头文件，而你自己写的MSVC版本只包含标准头。如果你的代码依赖了某个扩展头里的类型或函数，在MSVC下就会报找不到符号。解决办法是显式包含需要的扩展功能对应的标准头，或者干脆避免使用非标准扩展。对于要长期维护的代码，我的建议是尽早把万能头替换成具体头文件，虽然一开始麻烦，但后期可移植性和编译速度都会好很多。

5. 进阶：让万能头真正“好用”的工程化技巧

5.1 用预编译头把编译时间压下来

前面提了预编译头的基本用法，这里给一个可落地的完整流程。第一步，在项目根目录创建pch.h，内容可以是：

#pragma once #include <bits/stdc++.h>

也可以把bits/stdc++.h的内容直接拷进来，省去一次文件查找。第二步，创建pch.cpp，内容为#include "pch.h"。第三步，右键pch.cpp-> 属性 -> C/C++ -> 预编译头 -> 预编译头 -> 选择“创建(/Yc)”，预编译头文件填pch.h。第四步，选中项目里其他所有cpp，在同样的位置选择“使用(/Yu)”，预编译头文件同样填pch.h。第五步，确保每个cpp第一行是#include "pch.h"。第六步，生成项目，VS会先编译pch.cpp生成.pch文件，然后其他cpp复用它。

实测下来，一个包含二三十个cpp的中小型项目，开启预编译头后全量编译时间可以从四五十秒降到十几秒，增量编译几乎瞬间完成。注意，预编译头对宏变化敏感：如果你在包含pch.h之前定义了某个宏，而pch.h里也依赖这个宏，可能导致预编译头失效。所以最好把宏定义放在pch.h内部，或者统一在项目属性里定义，不要在单个cpp里临时改。另外，预编译头文件本身不要频繁修改，改一次就要全量重编，把它当成项目的基础设施来维护。

5.2 用条件编译控制“万能”范围

自制万能头最大的好处是可控。你完全可以按项目类型裁剪，而不是照搬GCC的全量版本。比如算法练习项目，常用的是<iostream>、<vector>、<string>、<algorithm>、<map>、<set>、<queue>、<stack>、<cmath>、<cstdio>、<cstring>这些，像<thread>、<future>、<filesystem>、<regex>完全不需要。把不需要的删掉，编译时间会下降很多，而且减少了宏冲突的风险。可以给头文件加一个开关宏：

#pragma once #define MY_WAN_NENG_HEADER_LITE 0 #if MY_WAN_NENG_HEADER_LITE // 精简版：只包含最常用的 #include <iostream> #include <vector> #include <string> #include <algorithm> #include <map> #include <set> #include <queue> #include <stack> #include <cmath> #include <cstdio> #include <cstring> #else // 完整版：按标准分档包含 // ... 这里放前面的完整列表 #endif

这样在不同项目里只需要改一个宏，就能切换包含范围。对于要分发给别人的代码，还可以把bits/stdc++.h做成一个可配置的模板，在README里说明如何选择。另一个技巧是用#pragma message在编译时输出提示，比如#pragma message("使用自制万能头，完整版")，这样一看编译日志就知道当前用的是哪个版本，排查问题时很有用。

5.3 团队协作中的规范建议

如果团队决定继续使用万能头，最好把它变成团队资产，而不是每个人各自复制一份。推荐做法是在代码仓库根目录建third_party/universal_include/bits/stdc++.h，然后通过项目的包含目录统一引用。如果是CMake项目，可以这样写：

add_library(universal_header INTERFACE) target_include_directories(universal_header INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/third_party/universal_include ) target_link_libraries(your_target PRIVATE universal_header)

这样所有目标都能用，而且路径统一、方便升级。如果是传统.vcxproj项目，可以在解决方案级别用属性管理器（“视图”->“其他窗口”->“属性管理器”）添加一个公共属性表，把附加包含目录写进去，所有项目继承。这样做的好处是改一处全解决方案生效，不用每个项目单独配置。坏处是属性表本身也需要纳入版本控制，并且要注意不同VS版本的兼容性。我的经验是，小团队用属性表，大团队用CMake，个人项目随便放本地include目录就行。

代码审查时，如果看到#include <bits/stdc++.h>，可以问一句：这个文件是否需要长期维护？如果只是刷题脚本，无所谓；如果是产品代码，建议逐步替换。替换策略不是一次性全改，而是每次修改某个源文件时，顺手把它的万能头换成具体头文件，编译验证，提交。这样风险小、可回滚，几个月后就能自然清理干净。同时可以在项目README里注明：“新代码请勿引入万能头，历史文件逐步迁移。”这种渐进式规范比一刀切更容易落地。

最后再分享一个我自己的小习惯：我在每台开发机的D盘放一个D:\dev\includes\bits\stdc++.h，里面维护一份最全的模板，然后新项目直接把这个目录加入附加包含目录。这样不用每个项目复制一份头文件，升级模板时所有项目都能受益。但要注意，如果项目要分享给别人，这个绝对路径就不成立了，所以我会在项目README里写清楚依赖，或者干脆在发布前把include目录复制进项目。这个习惯跟了我好几年，从VS2015到VS2022都能用，唯一需要定期做的是：升级VS大版本后，检查新标准增加了哪些头文件，把模板补一补。如果你只是偶尔刷题，装个MinGW配合VS Code确实更省事；但如果要在Windows上长期做C++开发，学会自己掌控头文件路径和预编译头，比依赖一个非标准头文件踏实得多。