有什么理由不写一个#includes所有其他头文件的头文件，只在每个c文件中#include那个头文件？
设置每个头文件#ifndef ... #define ... #endif
澄清重复；我问的是用户编写的代码而不是系统标头，而其他可能的重复项没有说明为什么这不是一个好主意的答案。
感谢您的回答，我没有仔细考虑其中的一些问题。我将考虑采用一些较小的标头的混合方法来组合在一起的模块。 这是我接管的一个代码库，这是一个我正在慢慢尝试解开的网络。
【问题讨论】：
标签： c header-files
我们首先将头文件和实现文件分成单独的文件（除了代码可读性）的原因是为了让编译器能够进行增量构建。也就是说，如果我们在HeadearA.h 中进行更改，只有ImplA.c 和ImplB.c 需要，则无需重新编译ImplC.c 到ImplZ.c。但是，如果您按照自己的方式进行操作，编译器将无法知道这一点，并且您将在每次重建时重新编译所有 .c 文件，无论是否必要。对于构建时间较短的小型项目，这是可以的。对于构建时间接近 30 分钟的大型项目，这变得令人望而却步。
【讨论】：
对于一个不平凡的项目，经常使用两种策略的组合：一个标头包括常用的系统标头，如stdbool.h、stdint.h、stdatomic.h 等。由于这些永远不会改变，因此请注意与重建相关。
您还可能包含大多数/所有模块所需的一些项目设置，因此您不必在编写新模块时关心它们（或在重构它们时更改每个模块）。
然后你有代表你的模块依赖树的特定标题。这些根据需要包括在内。这不仅加快了构建（而不是编译）项目的速度，而且还可以被doxygen 之类的文档工具用来自动为文档创建依赖关系树，因此您不必手动跟踪每个更改。 IDE 可以使用类似的方法来快速访问依赖的头文件/模块。
特别适用于 C 的一个缺点称为命名空间污染。由于 C 不允许自定义命名空间，因此每个包含的标头都会将其符号添加到当前编译单元的命名空间中。对于宏，这可能更糟，因为它们是纯文本替换，对上下文的了解非常有限（为此，还请检查 inline 与
函数宏）。
【讨论】：
主要问题是你最终得到一大碗意大利面条代码，而且一切都知道......最终。你所做的任何改变都会产生影响，你最终不得不重构以重新模块化...... 你没有一点点提醒你实际上包含一些标题来做出 x 应该知道 y 的决定。
但除了符号可见性和宏扩展的正常问题（应该是边缘情况）之外，它并没有任何本质上的错误。
【讨论】：
您的建议是可能的：许多项目都使用这种约定。
一些优点：
一些缺点：
【讨论】：