是否允许在头文件中引入precompiled header（pch）？存在哪些弊端？

核心结论 #

在头文件中引入pch（即precompiled headers，预编译头）技术层面不存在强制禁止规则，你测试能正常运行是符合编译器预期的行为，但这是行业内普遍不推荐的实践。

主要弊端 #

• 可移植性严重受损：预编译头是编译器专属特性，不同工具链（MSVC、GCC、Clang）的预编译头生成规则、使用逻辑、文件格式完全不兼容。如果头文件中硬编码引入pch，代码切换编译工具、跨平台编译、或者被没有使用pch习惯的开发者引用时，都会直接出现编译错误。
• 破坏头文件自包含性：C/C++开发的通用规范要求头文件具备自包含性，即单个头文件本身已经包含所有依赖的声明、定义，可以独立被其他源文件引用。如果头文件必须依赖pch内的内容才能正常编译，脱离当前项目的pch配置后，该头文件完全无法复用。
• 反而提升编译开销：预编译头的设计初衷是把全局稳定、极少修改的头文件预先编译完成，所有.cpp源文件统一引入以降低重复编译的成本。如果每个头文件都单独引入一次pch，编译器处理每个头文件时都需要额外校验pch的版本、编译参数匹配状态，反而会增加整体编译耗时，完全违背使用pch的初衷。
• 提升问题排查成本：pch相当于隐式为所有引入它的代码注入了一堆依赖，当出现符号冲突、定义缺失、宏污染等问题时，很难快速定位问题根源是来自pch的隐式引入，还是头文件本身的显式依赖，大幅提高调试成本。

推荐实践 #

正常使用pch的规范是只在.cpp源文件的第一行引入pch，不要在任何.h头文件中引入pch，同时保证所有头文件都满足自包含要求。

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