一、C++真正的编译单位是什么
首先必须建立一个最重要认知：
C++真正的编译单位不是头文件
而是 cpp 文件
准确说是：
cpp + 所有 include 展开后的代码 = 编译单位
例如：
A.h
#pragma once
int add(int a,int b);
B.h
#pragma once
#include "A.h"
class B
{
public:
int test();
};
B.cpp
#include "B.h"
int B::test()
{
return add(1,2);
}
编译时实际发生的是：
预处理后：
int add(int a,int b);
class B
{
public:
int test();
};
int B::test()
{
return add(1,2);
}
然后：
这个完整代码被编译 → B.obj
不是：
A.h 编译
B.h 编译
而是：
只编译 B.cpp
头文件只是源码的一部分。
二、为什么修改头文件会触发重新编译
因为：
如果你改：
A.h
int add(int a,int b);
改成：
int add(int a,int b,int c);
那么展开后：
B.cpp 实际代码变了：
return add(1,2); // 参数不匹配
所以：
依赖它的 cpp 必须重新编译
否则：
obj文件就和源码不一致
VS就是靠：
文件修改时间
判断：
需不需要重新编译
例如：
A.h 修改时间 > B.obj 时间
则：
重新编译 B.cpp
三、VS增量编译真正的工作方式
VS不会每次重新分析所有依赖。
否则：
大型项目 build 会非常慢
所以它会：
记录上一次编译时的依赖关系
例如记录：
B.cpp 依赖：
B.h
A.h
这些记录在：
.tlog
.obj依赖信息
里面（你不用管具体文件）。
然后下一次：
VS只是检查：
这些文件有没有变化
不会重新扫描整个工程。
这是为了：
速度优化
不是为了绝对准确。
四、为什么有时候修改头文件会出现莫名错误 （核心原因）
关键就在：
VS依赖关系不是实时分析的
是上一次编译时记录的
所以可能出现这种情况：
五、典型出问题的例子
例如：
最开始：
B.h
class B
{
public:
int test();
};
B.cpp
#include "B.h"
int B::test()
{
return 1;
}
VS记录：
B.cpp → B.h
没有：
A.h
因为还没 include。
然后你修改：
B.h
#include "A.h"
class B
{
public:
int test();
};
但此时：
如果：
B.cpp 没重新编译
VS记录还是：
B.cpp → B.h
不会有：
A.h
然后你改：
A.h
例如：
int value;
你点击：
生成解决方案（Build）
VS检查：
B.cpp 依赖：
B.h
发现：
B.h 没改
于是：
不重新编译 B.cpp
但真实依赖已经变成：
B.cpp → B.h → A.h
只是：
VS还不知道
因为：
它还没重新编译过 B.cpp
所以依赖没更新。
这时可能出现：
奇怪错误
链接错误
类型不一致
但代码本身没问题。
六、为什么 Rebuild 又好了
因为：
Rebuild = 删除所有 obj
重新编译所有 cpp
于是：
重新编译 B.cpp 时：
VS重新分析：
include 关系
发现：
B.cpp → B.h → A.h
依赖关系更新。
之后：
再改 A.h：
VS就能正确触发：
重新编译 B.cpp
错误消失。
七、问题总结
问题本质是：
VS的增量编译依赖记录有时不是最新的
导致：
真实依赖 ≠ VS记录依赖
于是：
该编译的没编译
产生错误。
Rebuild本质就是：
强制重新建立依赖关系
八、经验做法
所以实际开发都会有这个习惯：
如果：
修改头文件后出现奇怪错误
直接：
Rebuild
这是标准操作。
不是你代码问题。
是：
增量编译缓存问题
属于：
正常工程现象
九、最终理解
1 只有 cpp 会被编译
2 h 只是被 include 展开
3 修改 h 会触发依赖 cpp 重新编译
4 如果 VS 依赖没更新可能需要 Rebuild
到这里也就说明了 为什么大工程中都会强调减少头文件依赖（例如前向声明、PImpl等），因为这直接影响编译稳定性和速度。
