为何C++中增删<exception><array>等头文件不影响编译？

这种编译正常的现象源于C++标准库头文件的间接包含特性：
C标准仅规定了每个标准库组件对应的官方头文件，没有强制要求各头文件之间完全隔离。不同编译器的标准库实现（比如GCC的libstdc、MSVC的MSVC STL、Clang的libc++）、甚至同编译器的不同版本，都可能在某个头文件内部自动引入它依赖的其他头文件。
比如你给出的示例代码：

#include <exception> // 移除这行没有任何效果
#include <array> // 移除这行也一样
// ...
throw std::invalid_argument( exceptionMsg ); // 代码中的某处
// 这为什么能正常工作？
// ...
std::array<int, 4> buffer { }; // 代码中的某处
// 没有引入<array>的情况下array为什么能正常工作？

大概率是你代码的其他位置（或者预编译头里剩下的其他头文件）引入了比如<string>、<vector>、<iostream>这类常用头，这些头在GCC 11.2的libstdc++实现里，内部已经间接包含了<stdexcept>（std::invalid_argument的定义头）、<array>、<iterator>等组件，所以你移除自己写的#include语句后依然能编译通过。

另外补充个小知识点：std::invalid_argument的标准定义头文件是<stdexcept>，不是<exception>，<exception>里只有std::exception基类的定义，你之前哪怕显式引入<exception>能用std::invalid_argument，本质也是依赖了间接包含。

• 保证可移植性：间接包含是编译器实现的私有细节，不是C++标准强制要求的行为。你现在在GCC 11.2上能编译通过，换个编译器版本、换MSVC/Clang编译，或者后续标准库实现调整了头文件依赖关系，你的代码就会直接编译失败。
• 提升可读性：显式的#include列表能让其他维护者一眼看明白当前代码依赖了哪些标准库组件，不需要逐层排查头文件依赖。
• 降低后续维护成本：如果后续你删掉了那个帮你间接引入依赖的头文件，代码会直接报找不到类型的错误，排查起来耗时很高，显式引入能完全避免这类问题。

绝对不安全。编译不报错不代表代码符合C标准规范，你现在的正常编译完全绑定了当前的编译环境，换环境就会出问题。
正确的做法是：严格按照C标准的要求，用到哪个标准库组件就显式引入它对应的标准头文件，完全不要依赖间接包含的特性。

内容的提问来源于stack exchange，提问作者digito_evo