我做了几年程序员。
我总是被告知（并告诉其他人），你应该在你的.c文件中只包含你需要的.h文件。没有更多，没有更少。
但让我问问——为什么？
使用今天的编译器，我可以包含项目的整个h文件，而且它不会对编译时间产生巨大影响。
我不是在说包含OS.h文件，它包含许多定义、宏和预处理命令。
只包括一个"MyProjectIncludes.h"。这只会说：
#pragma once
#include "module1.h"
#include "module2.h"
// and so on for all of the modules in the project
你怎么说？
这并不是因为包含了太多的头而导致.c文件的编译时间变长。正如您所说，包含一些额外的头文件可能不会对该文件的编译时间产生太大影响。
真正的问题是，一旦您使所有的.c文件都包含"master"头文件，那么每次更改任何.h文件时，每个.c文件都需要重新编译，因为您使每个.c文件依赖于每个.h文件。因此，即使你做了一些无害的事情，比如添加一个只有一个文件会使用的新#define，你也会强制重新编译整个项目。如果你和一个团队一起工作，并且每个人都频繁地更改头文件，情况会变得更糟。
如果重建整个项目的时间很短，比如不到1分钟，那么就没那么重要了。我承认，为了方便起见，我在小项目中按照你的建议做了。但是，一旦你开始处理一个需要几分钟才能重建所有文件的大型项目，你就会意识到需要重建一个文件与重建所有文件之间的区别。
它将影响您的构建时间。此外，您还面临循环依赖的风险
通常情况下，您不希望重新编译模块，除非它们实际依赖的头被更改。对于较小的项目，这可能并不重要，全局的"include_maything.h"文件可能会使您的项目变得简单。但在大型项目中，编译时间可能非常重要，最好尽可能减少模块间的依赖关系。最小化包含不必要的标头只是一种方法。使用仅由指针或引用引用的类型的前向声明，使用Pimpl模式、接口和工厂等，都是旨在减少模块之间依赖关系的方法。这些步骤不仅可以减少编译时间，还可以使系统更容易测试和修改。
约翰·拉科斯的《大规模软件设计》是一本关于这一主题的优秀著作，尽管有些过时。
当然，正如您所说，包括额外的文件不会对您的编译时间造成太大损害。就像您建议的那样，使用1 include行转储所有内容会方便得多。
但是，如果陌生人确切地知道你在特定的.c文件中使用的是什么.h文件，你难道不觉得他们可以更好地理解你的代码吗？对于初学者来说，如果你的代码有任何错误，并且这些错误在.h文件中，他们就会确切地知道要检查哪些.h文件