改一行头文件需重编译多个.cpp，因#include是文本复制而非引用，预处理后所有包含该头文件的编译单元内容均改变，触发全量重建；而改.cpp仅影响自身编译单元。
改一行代码就要重新编译，不是编译器故意为难你，而是 C++ 的编译模型决定了：只要某个 .cpp 文件的内容（包括它通过 #include 拉进来的所有头文件内容）变了，它对应的目标文件（.o）就必须重做。
为什么改了头文件，一堆 .cpp 都得重编译？
因为 #include 不是“引用”，是文本复制。预处理器会把 #include "widget.h" 整段替换成 widget.h 里的全部内容——哪怕你只用了里面一个类名，整个头文件的定义、它包含的 <vector></vector>、<string></string>、甚至它再 #include 的其他头文件，全被塞进当前翻译单元。
所以一旦 widget.h 被修改，所有 #include "widget.h" 的 .cpp 文件，其预处理输出（.i 文件）就不同了，后续编译、汇编、链接都得重来。
- 常见错误现象：
error: redefinition of 'class Manager'或者莫名其妙的 ODR（One Definition Rule）违规，往往就是头文件被多份拷贝进来，又没加#pragma once或#ifndef守卫 - 使用场景：改了公共头文件（比如
common.h）后，发现 20 个模块全在重编译——这不是 bug，是机制使然 - 性能影响：一个被 50 个源文件包含的头文件，每改一次，就触发 50 个翻译单元重建；如果它又拉了
<boost></boost>这种重型头，单个编译单元可能膨胀到几十 MB
为什么改了 .cpp 文件，只编译它自己就够了？
每个 .cpp 是独立的编译单元。编译器不关心别的 .cpp 长什么样，只认当前文件 + 所有 #include 展开后的完整文本。所以改 A.cpp，只要 A.h 和它依赖的头都没变，就只重生成 A.o，然后链接阶段拿旧的 B.o、C.o 拼一起就行。
- 参数差异：
g++ -c A.cpp -o A.o和g++ -c B.cpp -o B.o是完全解耦的两件事；但如果你用g++ A.cpp B.cpp -o app一把梭，那就真成“一锅炖”了——哪怕只改了A.cpp，也得重跑整个命令 - 容易踩的坑：有人为了图省事，在
main.cpp里直接#include "A.cpp"，这会让main.o里重复出现A的函数定义，链接时报multiple definition
怎么判断某次修改到底要动几个 .o？
最可靠的办法是看预处理输出是否变化。用 g++ -E A.cpp > A.i 生成预处理后文件，再对比修改前后的 A.i 差异。如果 diff 有变化，那 A.o 就必须重编译；如果没变，说明改动没进入这个翻译单元（比如改的是另一个头文件，或只是注释）。
- 常见错误现象：
make告诉你“nothing to be done”，但程序行为却变了——大概率是你改了某个没被#include进来的头文件，或者改的是运行时读取的配置文件 - 兼容性影响：C++26 的
-fexperimental-demand-compilation可以延迟解析未使用的模板和函数，但它不改变头文件文本替换的本质；对普通类定义、全局变量、宏，该重编译还是得重编译
真正卡住编译速度的，从来不是单个文件有多大，而是头文件之间像蜘蛛网一样互相 #include。切断这种隐式依赖，比调高 CPU 频率有用得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
