C语言为何要使用分离源文件？能否将所有代码放在头文件中？

你提到的「仅保留1个.c文件，其余所有代码都放在头文件中」的方案仅能在极小的单开发者玩具项目中勉强运行，在绝大多数场景下完全不可行，核心原因和C语言的编译模型、工程开发的实际需求直接相关：

先纠正一个核心前提误解 #

你认为「把代码都放在头文件里就能做到内容仅定义一次，构建时只会被引入一次」的认知仅在整个项目只有1个.c文件的前提下成立。
只要项目中存在第二个.c文件，且两个.c都包含了同一个带函数/全局变量定义的头文件，哪怕加了#ifndef头文件守卫，链接阶段也一定会报重定义错误。
头文件守卫的作用范围仅限单个编译单元（即单个.c和它所有递归引入的头文件展开后的完整内容），多个.c是完全独立的编译单元，各自展开头文件后都会生成一份函数定义的副本，链接时多个同名全局符号冲突就会报错。
如果硬要在头文件中定义函数，只能给函数加static限定，但这样每个编译单元都会生成独立的函数副本，不仅会导致二进制体积无意义膨胀，一旦函数内部使用了静态变量，各个副本的静态变量彼此独立，会出现非常隐蔽的逻辑错误。

全头文件写法的致命缺陷 #

• 构建效率极低：C语言采用分离编译模型，正常拆分源文件的前提下，修改单个文件仅需要重编译对应的编译单元，再执行链接即可，中大型项目可以把构建耗时压缩到秒级。如果所有代码都放在头文件中，哪怕只修改一行代码，都要触发全量重编译，万行级别的项目单次编译就可能要等待几十分钟，完全不具备可开发性。
• 完全不支持协作和模块化：所有代码耦合在头文件中，根本没法按模块拆分权责，多人协作时版本冲突会多到无法处理，代码可读性、可维护性基本为0，出问题根本没法排查。
• 无法实现闭源分发：如果你需要对外提供功能库，全头文件的写法等于直接交付全部源码，没法实现仅对外暴露头文件声明、交付静态/动态链接库的闭源分发模式。
• 存在大量语法陷阱：除了前面提到的static函数的静态变量问题，全局变量重定义、inline函数的规则冲突、跨编译单元的常量同步问题都会频繁出现，非常容易写出看似能运行实际隐含大量bug的代码。

关于你提到的「声明定义分离修改麻烦」的问题 #

这个问题在实际开发中已经有非常成熟的解决方案：主流IDE都支持函数声明和定义的自动同步，也可以通过代码生成工具根据接口定义自动生成头文件声明，并不会带来太多额外的工作量。
如果你只是开发极小的个人玩具项目，完全可以把所有代码都写在单个.c文件中，不需要拆分头文件和源文件，分离编译的规则本身就是为中大型项目的工程化需求设计的。

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