实现声明的cpp文件中包含对应头文件是否有保留必要？

架构老林

2026-8-23

为什么C++源文件要包含自身对应的头文件？

场景示例

假设有如下foo.cpp文件：

#include "foo.hpp"
int foo() {
    return 7;
}

对应的头文件foo.hpp：

#pragma once
int foo();

头文件的作用是让下面的main函数能识别foo的存在：

#include <iostream>
#include "foo.hpp" // 使名称`foo`可用

int main() {
    std::cout << foo() << std::endl;
}

这里foo.cpp中的#include "foo.hpp"看起来冗余，是否有保留的必要？

这种写法在工作代码库和开源项目中很常见，比如fish-shell代码库中的src/builtin_builtin.h和src/builtin_builtin.cpp：前者除了包含保护外，仅包含：

有人会提出替代方案：把类声明放到前置声明头文件（fwd header）中，在cpp文件里同时包含该fwd header和原头文件的依赖内容，这样就不用包含自身对应的头文件了。

答案是非常有必要，核心原因如下：

强制检测声明与定义的一致性
头文件里是函数、类的对外声明，cpp里是具体实现。如果cpp包含对应头文件，编译器会自动校验两者的签名是否匹配——比如你把foo的返回值改成double但头文件还是int，编译器会直接报错。要是不包含头文件，这种不一致要等到链接阶段才暴露，排查成本高得多。
避免冗余重复的声明
如果cpp不包含头文件，你得在cpp里手动重复写一遍函数/类的声明，这属于冗余代码。一旦头文件的声明修改，cpp里的重复内容很容易遗漏更新，引发潜在问题。
保证依赖完整性
头文件里可能包含了cpp实现所需的类型定义、宏或其他依赖。比如后续foo的实现用到了头文件引入的某个类，不包含头文件会直接编译失败。就算现在没用到，后续维护添加依赖时，也不用回头补加#include。
统一代码规范
绝大多数成熟C++项目都会要求源文件包含对应头文件，这是约定俗成的规范。团队统一写法后，代码风格一致，新人接手也更容易理解。

至于用前置声明头文件替代的方案，技术上可行但完全没必要——它没解决核心问题，反而增加了文件数量和维护成本。除非头文件依赖极其复杂导致编译速度严重变慢，否则这种优化属于过度设计。

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