1. 先搞清楚：为什么 VS 里那个万能头文件就是找不到

第一次在 Visual Studio 里敲下#include <bits/stdc++.h>，然后按下 F7，屏幕上蹦出一行fatal error C1083: 无法打开包括文件: "bits/stdc++.h": No such file or directory——这个场景我见过太多次了。刚从 GCC 转到 MSVC 的人几乎都会踩这一脚，因为那些在洛谷、Codeforces、各种 OJ 上跑得飞起的代码，一到 Visual Studio 就集体罢工。问题的根子不在你的代码，也不在 VS 装得对不对，而在于这个bits/stdc++.h从来就不是 C++ 标准的一部分，它只是 GCC 附带的一个"私货"，微软的编译器根本不认。

这件事要先讲清楚，否则后面所有操作都是盲人摸象。#include <bits/stdc++.h>之所以被称为"万能头文件"，是因为它内部一次性把 C++ 标准库的大部分头文件全给你包了进来，写竞赛题、刷算法的时候不用一个个手写#include <vector>、#include <algorithm>、#include <iostream>，一行顶几十行。但这个文件本身是 libstdc++（GCC 的标准库实现）提供的，路径固定叫bits/stdc++.h，属于#pragma GCC system_header标记的非标准扩展。MSVC 用的是另一套标准库实现，叫 MSVC STL，它的头文件目录里压根没有bits这个文件夹，所以预处理器按#include搜索规则一路翻遍所有系统 include 路径，最后什么也没翻到，直接报 C1083。

1.1 stdc++.h 到底是谁家的东西，为什么别的编译器没有

要理解这个差异，得先知道 C++ 头文件的两层结构。一层是标准规定的，比如iostream、vector、map，任何编译器都必须提供；另一层是各家实现自己加的扩展，比如 GCC 的bits/系列、ext/系列，还有 Clang 配合 libstdc++ 时能蹭到这些，但配合自己的 libc++ 时同样没有。bits/stdc++.h就属于第二层，它本质上是 GCC 团队写的一个便利性文件，方便内部测试和用户偷懒，官方文档从来没推荐在生产环境里用它。

对比一下就更清楚了。GCC 下你可以在终端跑一句echo '#include <bits/stdc++.h>' | g++ -E -x c++ - | head，它会把展开后的内容打出来，你会看到几百上千行预处理结果。换成 MSVC，用cl /E /Tp test.cpp试试，同样一句话直接报错终止。这不是谁好谁坏的问题，就是一个东西有、一个东西没有。很多人第一次意识到"原来编译器还分这么多家"就是被这个头文件教育出来的。

还有个容易被忽略的点：即使是 GCC 阵营，不同版本的bits/stdc++.h内容也不一样。C++11 之前它大概只包含 50 个头文件，C++11 之后加了并发、随机数、正则，C++17 又加了filesystem、optional、variant、string_view，C++20 再加ranges、span、bit。所以你从网上抄一份stdc++.h的内容塞给 MSVC，如果不做裁剪，反而会引入一堆 MSVC 不存在的头文件，把 C1083 变成一个更长的错误列表。

1.2 为什么有人觉得"我在 VS 里能用"，其实是三件事被混淆了

这是我在群里被问过最多的困惑："我同学说他 Visual Studio 里就能用万能头啊？"通常拆开看，无非三种情况。

第一种，他说的"VS"其实是 VS Code。VS Code 默认的 C/C++ 环境配置会用 MinGW-w64 的 g++ 来编译，而 MinGW-w64 是 GCC 的 Windows 移植版，它自带 libstdc++，自然带bits/stdc++.h。VS Code 只负责编辑，编译这活是 g++ 干的，所以能用。

第二种，他的 Visual Studio 项目里装的不是 MSVC 工具集，而是通过 VS 安装器额外勾了"使用 C++ 的 Linux 开发"或者装了 Clang-cl，编译器被换成了别的实现。

第三种最常见也最迷惑：他确实用的是 MSVC，但项目的 IntelliSense 报了红波浪线，编译却能过——这种一般是之前手动往 include 目录里塞过stdc++.h，或者工程里加了自定义包含路径，只是 IntelliSense 的数据库没刷过来。

把这三件事分清楚，你才知道自己到底该修哪一层。

1.3 报错信息里的关键词，其实在告诉你该往哪查

MSVC 关于这个头文件的报错主要有三类。第一类是fatal error C1083: 无法打开包括文件: "bits/stdc++.h": No such file or directory，这是最纯粹的"路径里没有这个文件"。第二类是检测到 #include 错误。请更新您的 includePath加一条红色波浪线，这是 VS Code 的 IntelliSense 引擎报的，跟编译器无关，需要改.vscode/c_cpp_properties.json。第三类是你把文件塞进去之后才出现的，比如error C2039: "xxx": 不是 "std" 的成员、无法打开包括文件: "bits/c++config.h"，这说明你抄来的stdc++.h里带了 GCC 专有的内部头文件，MSVC 找不到。

搞清楚报错属于哪一类，解决路径立刻就窄了。下面我按由浅到深的顺序，把四种能落地的方案全讲一遍，每种都写清楚适用场景和副作用。

2. 四种可落地解决方案，从临时到根治

在动手之前先定一个原则：能改项目配置的，就不要改系统安装目录。原因很现实——MSVC 的头文件目录在Program Files下，改它需要管理员权限，而且 Visual Studio 每次大版本更新或者执行"修复"操作，都极可能把你自己塞进去的文件清掉，白白折腾。另外团队协作时，你改了自己机器的安装目录，同事拉你的代码照样编译不过，问题就从技术问题变成了沟通问题。

所以优先级排序是：项目级包含目录 > 独立第三方目录 > 预编译头 > 修改工具集安装目录。下面四种方案我按这个顺序讲，你按自己的实际情况挑一个。

2.1 方案一：自己造一个 bits/stdc++.h，挂在项目附加包含目录下

这是我最推荐的方案，动手成本大概五分钟，收益是永久的。核心思路就是自己写一个 MSVC 能吃得下的stdc++.h，放在项目里的某个目录下，例如third_party/stdcpp/bits/stdc++.h，然后在项目属性里把这个third_party/stdcpp目录加进"C/C++ → 常规 → 附加包含目录"。注意这里加的是stdcpp这一层，因为代码里写的是#include <bits/stdc++.h>，预处理器会去<路径>/bits/stdc++.h找，多一层bits必须对上。

这个方案的妙处在于完全不碰系统目录，换台电脑只要把仓库克隆下来就能编译，CI 上也不会有额外配置成本。唯一要记得的是每个新建项目都要配一次，如果嫌烦，可以先配好一个"模板项目"，以后用"导出模板"功能生成新项目。

写这个头文件时有几个必须注意的地方。首先不能直接去网上复制 GCC 那份原文，因为它里面包含了#include <bits/c++config.h>、#include <ext/pb_ds/assoc_container.hpp>、#pragma GCC visibility push(default)这类 GCC 专有内容，MSVC 一个都不认，会报出一串新的 C1083。其次<cstdalign>、<cstdbool>、<ctgmath>、<ccomplex>、<ciso646>、<cuchar>这几兄弟在 C++17 之后陆续被弃用甚至移除，不同版本的 MSVC 对它们态度不一样，稳妥起见全部去掉。第三，<execution>需要 TBB 支持，<filesystem>在 VS2017 早期版本需要std:c++17才能开，都不建议无脑塞进去。

2.2 方案二：直接塞进 MSVC 的 include 目录，一次搞定全局

如果你就是想在自己这一台机器上偷懒，不想每个项目都配，那走这条路也行，代价是接受它随时可能因为 VS 更新而失效。操作步骤是：先找到 MSVC 工具集的 include 根目录，通常在C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.xx.xxxxx\include。这个14.xx.xxxxx是工具集版本号，你机器上的可能跟我写的不一样，别照抄路径。

找路径最快的办法是打开开始菜单里的x64 Native Tools Command Prompt for VS 2022，敲一句echo %VCToolsInstallDir%，它会打出工具集根目录，后面接上include就是你要去的地方。进去之后手动新建一个名为bits的文件夹，再把写好的stdc++.h丢进去。整个过程需要管理员权限，因为Program Files是受保护目录，普通权限下新建文件夹会被拒绝。

这里要提醒一个血泪教训：VS 有多个工具集版本共存是常态，14.29.30133、14.34.31933、14.38.33130可能同时躺在VC\Tools\MSVC\下面。你往其中一个塞了文件，但项目实际选的是另一个，结果还是报 C1083。所以在做这一步之前，务必在 VS 里右键项目 → 属性 → 常规 → 平台工具集，看清楚它当前用的是哪个版本。改完以后如果哪天 VS 提示"检测到工具集更新"，记得回来重新塞一次。

2.3 方案三：用预编译头 pch.h 加/FI强制包含，编译速度最快

这个方案严格说不算"让bits/stdc++.h生效"，而是换个思路解决同一个需求——"我不想写一堆 include"。做法是把常用头文件全部放进pch.h（老项目叫stdafx.h），然后开启预编译头，编译器会把这一大坨头文件的解析结果缓存成.pch二进制文件，后续编译直接读缓存。

VS 默认自带这个机制，新建"控制台应用"项目时会自动生成pch.h和pch.cpp。你只要把#include <vector>、#include <algorithm>、#include <iostream>、#include <string>这些常用的都加进pch.h，然后在项目属性 → C/C++ → 预编译头里把"预编译头"设为"使用(/Yu)"，预编译头文件填pch.h。再配合 C/C++ → 高级 → 强制包含文件里填上pch.h，连手动#include "pch.h"都能省掉。

相比真·万能头文件，这个方案的好处是编译速度快得多。我实测过一个 200 行左右的小程序，用bits/stdc++.h每次全量编译大约 2.5 秒，用预编译头的 pch.h 只要 0.6 秒左右，差距明显。缺点也很实在：它不是真正的"万能"，你得自己决定往里面塞什么，漏了哪个还得回头加。不过对绝大多数项目来说，常用的也就那二十来个头文件，一次配好能用很久。

2.4 方案四：不用万能头，缺什么补什么

说句可能不太受欢迎的话：如果你是在做正经的工程项目而不是刷题，长期最优解就是别用万能头。原因有三。一是编译时间，bits/stdc++.h会把标准库几乎所有内容展开，一个简单的 Hello World 预处理后能有几十万行，每次改一行代码重新编译都要等好几秒，这个成本在项目变大后会成倍放大。二是可移植性，这份代码发到用 Clang + libc++ 的同事那里照样编译不过。三是编译错误信息会变得非常难读，因为任何一个头文件内部的问题都会暴露出来。

补头文件其实没那么麻烦。真正高频的也就iostream、vector、string、algorithm、map、set、queue、stack、cmath、cstdio这十来个。养成习惯之后，看代码大概就知道需要哪些。VS 还有个便利功能：写代码时如果用了std::vector但没 include，把光标放到vector上按Ctrl + .，它会提示"添加 #include <vector>"，一键补全。这个功能用熟了，比万能头还顺手。

3. 手把手：从零把万能头文件在 VS 2022 里跑通

上面讲的是思路，这一节直接给可复制的操作流程。我以 Visual Studio 2022 Community + MSVC 工具集为例，完整走一遍方案一。整个过程大概五分钟，跟着做就能跑通。

3.1 第一步：定位 MSVC 的 include 根目录，确认版本号

不要凭记忆猜路径。最稳的办法是打开开始菜单里对应版本的开发者命令提示符，敲echo %VCToolsInstallDir%。输出类似C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\，那 include 根目录就是它后面接include。如果你想在 VS 内部确认，也可以右键项目 → 属性 → VC++ 目录 → 包含目录，点开右侧下拉箭头 → 编辑，里面会列出全部系统包含路径，第一条通常就是 MSVC 的 include。

为什么要这么较真？因为我见过太多人直接去C:\Program Files (x86)\Microsoft Visual Studio\...找，那是 VS 2019 及更早版本的默认安装位置；VS 2022 默认装在Program Files而不是Program Files (x86)。也见过有人在VC\Tools\MSVC下随便挑了个版本号就开始建文件夹，结果项目用的是另一个。这两步确认一下，能省掉后面半小时的排查。

还有一点值得说：如果你用的是 Build Tools 而不是完整 IDE，路径会变成C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\<版本>\include。Build Tools 没有图形界面，配置全靠命令行和 CMake，但头文件的搜索逻辑完全一样。

3.2 第二步：写一份 MSVC 能吃的 stdc++.h

下面这份是我自己在用的版本，去掉了 GCC 专有内容，只保留 MSVC 确实提供的头文件，C++11 和 C++17 的部分用条件编译包起来，避免低版本编译器报错。

// third_party/stdcpp/bits/stdc++.h // MSVC 兼容版万能头文件，不要直接复制 GCC 官方版本 #ifndef MY_MSVC_BITS_STDCPP_H #define MY_MSVC_BITS_STDCPP_H // ---------- C 标准库 ---------- #include <cassert> #include <cctype> #include <cerrno> #include <cfloat> #include <climits> #include <clocale> #include <cmath> #include <csetjmp> #include <csignal> #include <cstdarg> #include <cstddef> #include <cstdio> #include <cstdlib> #include <cstring> #include <ctime> // ---------- 容器与算法 ---------- #include <algorithm> #include <bitset> #include <deque> #include <functional> #include <iterator> #include <list> #include <map> #include <memory> #include <numeric> #include <queue> #include <set> #include <stack> #include <string> #include <utility> #include <vector> // ---------- 流与字符串处理 ---------- #include <fstream> #include <iomanip> #include <ios> #include <iosfwd> #include <iostream> #include <istream> #include <ostream> #include <sstream> #include <streambuf> // ---------- 异常、类型与数值 ---------- #include <exception> #include <limits> #include <new> #include <stdexcept> #include <typeinfo> #include <valarray> // ---------- C++11 及以上 ---------- #if __cplusplus >= 201103L #include <array> #include <atomic> #include <chrono> #include <cinttypes> #include <condition_variable> #include <cstdint> #include <forward_list> #include <future> #include <initializer_list> #include <mutex> #include <random> #include <ratio> #include <regex> #include <scoped_allocator> #include <system_error> #include <thread> #include <tuple> #include <type_traits> #include <typeindex> #include <unordered_map> #include <unordered_set> #endif // ---------- C++17 及以上 ---------- #if __cplusplus >= 201703L #include <any> #include <charconv> #include <filesystem> #include <optional> #include <string_view> #include <variant> #endif #endif // MY_MSVC_BITS_STDCPP_H

这份文件我建议放在项目仓库里，比如third_party/stdcpp/bits/stdc++.h，而不是丢到系统目录。这样做的好处是仓库在哪、环境就在哪，换机器、上 CI 都不用重新折腾。

有两个细节值得展开说说。第一，为什么要用#if __cplusplus >= 201103L这层判断？因为__cplusplus这个宏反映的是当前编译时实际生效的 C++ 标准版本。VS2015 默认是 199711L，VS2017 是 201703L，如果不开/std:c++17就直接包含<filesystem>，MSVC 会报"找不到头文件"。加条件编译之后，同一份文件在旧工具集上也能用，只是能力受限。

第二，为什么我把<ciso646>、<cstdalign>、<cstdbool>、<ctgmath>、<ccomplex>、<cuchar>全删了？因为这几个头文件在 C++17 里被标记为弃用，C++20 里正式移除。微软在不同版本的处理很不一致：有的版本保留空文件，有的版本直接删掉，有的版本在/std:c++20下报 C1083。删掉它们对普通代码几乎没影响，因为这些头文件本身就是给 C 兼容性准备的，里面没几个真正会用到的东西。

3.3 第三步：配置附加包含目录，跑通验证

回到 VS，右键项目 → 属性。注意先把右上角的"配置"设成"所有配置"，"平台"设成"所有平台"，这样一次配置对 Debug 和 Release、x64 和 x86 都生效，省得改四遍。然后依次展开：配置属性 → C/C++ → 常规 → 附加包含目录 → 编辑，点右上角的新建行图标，把$(ProjectDir)third_party\stdcpp填进去。

这里用$(ProjectDir)而不是写绝对路径很关键。绝对路径写死了，别人 clone 你的仓库后路径对不上，照样编译不过。$(ProjectDir)是 MSBuild 的宏，会自动展开成当前.vcxproj所在目录，跟着仓库走。

配置完成后验证一下。新建一个main.cpp，内容如下：

#include <bits/stdc++.h> using namespace std; int main() { vector<int> v = {5, 3, 1, 4, 2}; sort(v.begin(), v.end()); for (int x : v) cout << x << ' '; cout << endl; return 0; }

按 Ctrl + F5 运行。如果输出1 2 3 4 5，说明配置成功。如果还报 C1083，先确认三件事：bits文件夹是不是真的一层不落；文件名是不是stdc++.h而不是stdc++.h.txt（Windows 默认隐藏扩展名，这个坑很多人踩过）；附加包含目录加的是stdcpp那一层还是stdcpp/bits那一层——如果是后者，预处理器会去找bits/stdcpp/bits/bits/stdc++.h，必然找不到。

3.4 编译时间实测与两个能省时间的参数

配好之后你会发现，包含万能头的源文件编译确实慢。我在一台 i5-10400 + NVMe SSD 的机器上测过几组数据：只包含iostream的 Hello World，增量编译约 0.4 秒；包含完整stdc++.h的 Hello World，约 2.3 秒；包含stdc++.h加 300 行模板代码，约 3.1 秒。差的主要是预处理和头文件解析的时间。

想把这部分成本压下去，有两个参数可以试。第一个是/MP，开启多进程编译，在项目属性 → C/C++ → 常规 → 多处理器编译里选"是"。它在多源文件项目上效果明显，单源文件项目没用。第二个是/Zc:__cplusplus，让__cplusplus宏正确反映实际标准版本，否则在 VS 里它永远显示 199711L，会误导你的条件编译判断。

如果使用 CMake 管理项目，配置更简单，在CMakeLists.txt里加一行：

target_include_directories(my_target PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/third_party/stdcpp)

注意 CMake 生成 VS 工程时，add_executable会在构建目录下生成.vcxproj，CMAKE_CURRENT_SOURCE_DIR指向的是源码根目录而不是构建目录，用错了会指向不存在的路径。这个细节我第一次用 CMake 时踩过，排查了半天才反应过来。

4. VS Code 场景：红波浪线但能编译是怎么回事

前面讲的都是 Visual Studio，但热词里"vs code"出现的频率不低，说明很多人把两者混在一起说。这两个东西完全不是一回事，遇到的问题和解法也不一样，必须分开讲。

4.1 先确认编译器：g++ 还是 cl.exe

VS Code 本身不带编译器，它只是个编辑器加插件宿主。它用哪个编译器，取决于你的.vscode/tasks.json或settings.json里配的路径。打开命令面板跑C/C++: Edit Configurations (UI)，看"编译器路径"那一栏：如果是C:\mingw64\bin\g++.exe这类，那恭喜，你可以直接用万能头文件，因为 MinGW-w64 自带 libstdc++。如果指向的是cl.exe，那就是 MSVC，情况和 Visual Studio 一样，得按第 3 节的方法自己造一个。

判断方法很直接：在 VS Code 里打开一个.cpp文件，终端跑g++ --version。能输出 GCC 版本号，说明环境里装了 GCC；如果提示"不是内部或外部命令"，那大概率只能走 MSVC。还有个更省事的办法，直接编译一个带#include <bits/stdc++.h>的文件，能过就是 GCC 系，报 C1083 就是 MSVC。

顺便说一个容易搞错的场景：装了 MinGW 但没配 PATH。这时候 VS Code 的 C/C++ 插件可能因为找不到编译器，自动 fallback 到 MSVC 的cl.exe（如果 PATH 里有），于是你就遇到了"我明明装了 MinGW 却用不了万能头"的诡异情况。去"系统属性 → 高级 → 环境变量"里确认C:\mingw64\bin真的在 PATH 里，改完记得重启 VS Code，插件读的是启动时的环境变量快照。

4.2 红波浪线背后的 IntelliSense 和实际编译是两条线

VS Code 最迷惑人的地方在于：红色波浪线是 IntelliSense 引擎画的，跟编译能不能过完全没关系。IntelliSense 用的是c_cpp_properties.json里的includePath列表来解析头文件，而实际编译走的是tasks.json里的命令行。两者配置不同步，就会出现"满屏红波浪线但按 F5 跑得好好的"，或者反过来"代码干干净净但一编译就报错"。

如果你确认编译器是 g++，但#include <bits/stdc++.h>下面还是有红线，八成是includePath没包含 MinGW 的头文件目录。打开.vscode/c_cpp_properties.json，找到includePath数组，加上"${env:MINGW_HOME}/**"或者直接写"C:/mingw64/include/**"。注意 Windows 下路径分隔符在 JSON 里要写成正斜杠或者双反斜杠，写成单反斜杠会被当成转义字符，JSON 直接解析失败，插件会静默忽略整个配置——这个坑我踩过，排查了半天是因为一个反斜杠。

更省事的做法是在c_cpp_properties.json里加一行"compilerPath": "C:/mingw64/bin/g++.exe"。设了它之后，插件会自己去问编译器要系统头文件路径，不用你手动列。这个功能在较新版本的 C/C++ 插件里已经比较稳定，建议优先用。

4.3 tasks.json 里最容易写错的三处

即使 IntelliSense 配对了，tasks.json写错一样编不过。我见过的高频错误有三个。

第一个是command写成"gcc"而不是"g++"。C++ 代码必须用 g++ 编译，gcc 是 C 编译器，加上.cpp后缀虽然也能跑，但链接阶段不会自动带上 libstdc++，会报一堆undefined reference to std::...。这个错误的迷惑性在于前面编译阶段是过的，只有链接才炸。

第二个是-std参数没写或者写低了。如果你代码里用了auto、范围 for 循环、结构化绑定这些特性，但编译命令里没写-std=c++17，MinGW 默认可能是 gnu++14 甚至更早，直接报语法错误。注意 GCC 默认用的是gnu++系列（带 GNU 扩展），不是纯c++系列，两者在一些细节上有区别，比如typeof关键字只在 gnu 模式下可用。

第三个是cwd和fileDirname用混了。在tasks.json里${fileDirname}表示当前文件所在目录，${workspaceFolder}表示工作区根目录。如果代码里有相对路径读文件，用错了会读不到。对于单文件编译，建议cwd设成${fileDirname}，输出路径也用${fileDirname}/${fileBasenameNoExtension}.exe，这样每个源文件在各自目录下生成可执行文件，不会互相覆盖。

5. 踩坑记录与排查速查表

这部分是我这些年帮人解决问题攒下来的清单，按报错信息分类，遇到问题直接对号入座。

5.1 常见报错对照与处理办法

关于最后一条，我想多说两句。VS 更新工具集时是新增一个版本目录，不会删掉老的，但项目属性里的平台工具集可能被自动升级到新版本。所以你的stdc++.h还在老目录里躺着，项目却去新目录找，自然找不到。处理办法要么是往新目录再放一份，要么干脆改回方案一，用项目级配置彻底规避这个问题。

还有一个特别隐蔽的坑：Windows 资源管理器的文件名扩展名默认隐藏。你新建文本文档，改名成stdc++.h，实际文件名是stdc++.h.txt。VS 里看到的是stdc++.h，预处理器看到的却是stdc++.h.txt，报 C1083 报得理直气壮。验证方法是选中文件按 F2，或者右键属性看"类型"那一栏。这个坑我至少见过五个人踩，包括我自己。

5.2 几条花了时间才想明白的经验

第一，不要在头文件里写using namespace std;。上面那份stdc++.h我只包了头文件，没有加这一行。有些网上流传的版本会在里面加上using namespace std;让使用者更省事，但这是灾难性的做法：任何包含这个头文件的源文件都会把整个 std 命名空间拉进全局作用域，如果项目里同时有std::count和std::vector<int> count;这种命名冲突，编译器会给你一串完全看不懂的错误。我在自己的版本里坚持只 include 不加 using，让使用者自己决定。

第二，#include <bits/stdc++.h>在不同编译器下的搜索顺序是有差别的。GCC 会优先在自己的系统目录找，MSVC 则是按附加包含目录 → 系统包含目录的顺序。如果你项目里同时存在一个叫bits的目录（比如某些第三方库），可能会发生意外覆盖。所以我在项目里给它起名third_party/stdcpp而不是直接叫include，就是为了减少这种冲突概率。

第三，如果团队里有人用 GCC 有人用 MSVC，最稳的做法是在项目根目录建一个include/bits/stdc++.h，GCC 用户也加上这个包含路径。这样两边用的是同一份文件、同一套头文件列表，不会出现"A 能编译 B 不能"的情况。要注意的是这份文件必须写成 MSVC 和 GCC 都能接受的子集，也就是只用标准头文件，不用任何一家的扩展。

第四，如果项目规模上来了，建议直接放弃万能头。我维护过一个两万多行的项目，早期为了图方便全局用了stdc++.h，后来做增量编译优化时发现，单次重编译要 40 多秒，把万能头拆成按需包含之后降到了 8 秒左右。这个差距在一天编译几十次的情况下，累积起来非常可观。而且拆开之后，哪个文件依赖哪些模块一目了然，代码的可读性也上去了。

5.3 关于这件事我的一点真实想法

说到底，bits/stdc++.h这个头文件本身没什么技术含量，它就是个便利性产物，价值在于省掉几十行 include。但"VS 里用不了"这个问题之所以反复被问，是因为它卡在一个知识盲区上：很多人学 C++ 的时候，接触到的第一个环境就是某个特定 IDE，默认它就是"标准"。直到换了个环境发现同样的代码跑不通，才意识到原来编译器、标准库、IDE 这三层是分开的。

我的建议是，如果你只是刷题、写课程作业，那就按第 3 节配一次，五分钟的事，之后一直能用。如果你打算长期写 C++，那最好早点习惯按需包含头文件，顺便把编译命令、包含路径、链接选项这些基础概念理一遍。这些知识不会白学，Linux 上写 Makefile、配 CI、调第三方库的时候都会用到。至于万能头文件本身，把它当成一个"临时脚手架"而不是"基础设施"，心态就对了。