PCH失效主因是编译器未将其识别为PCH：MSVC要求源文件首行非空非注释必须为#include "stdafx.h"，Clang/GCC需正确配合-include与-x c++-header参数且禁止前置包含。
为什么你的 stdafx.h 或 pch.h 没生效？
预编译头（PCH）没提速，甚至编译报错，大概率不是配置错了，而是它根本没被识别为“第一个头文件”。C++ 编译器（MSVC / Clang / GCC）要求：**源文件中第一个非注释、非空行必须是预编译头的 #include**。哪怕前面有一行 // comment 或 #pragma once，PCH 就直接失效——编译器会默默忽略它，转而重新编译所有头文件。
实操建议：
- 检查每个
.cpp文件：确保#include "pch.h"（MSVC）或#include "stdc++.h"（GCC 系统级 PCH）是文件最顶部的第 1 个#include，且前面无任何宏、注释、空行 - MSVC 下若用
stdafx.h，需确认项目属性 → C/C++ → 预编译头 → “创建/使用预编译头”已设为“使用预编译头”，且“预编译头文件”填的是stdafx.h - Clang/GCC 不支持自动识别
pch.h，必须显式生成并引用：clang++ -x c++-header pch.h -o pch.h.pch，再在编译时加-include pch.h -Xclang -include-pch -Xclang pch.h.pch
#include <iostream> 能放进 PCH 吗？哪些头该放？
能放，但不该全放。PCH 的核心价值是固化**稳定、高频、难解析**的头文件。把 <iostream> 放进去通常合理（它展开后超 2 万行），但把 "utils.h" 这类常改的头放进去反而拖慢开发：每次改 utils.h，整个 PCH 就要重生成，所有依赖它的 .cpp 全得重新编译。
推荐放入 PCH 的内容：
立即学习“C++免费学习笔记（深入）”；
- 标准库头：
<vector>、<string>、<memory>（注意：不要放<bits/stdc++.h>，它破坏模块化且 GCC 下不兼容） - 第三方稳定库：如
<boost/noncopyable.hpp>（若项目长期固定版本） - 项目全局宏定义：比如
#define NOMINMAX、#define _CRT_SECURE_NO_WARNINGS（这些本身不产符号，但影响后续头行为）
明确排除：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 含
#pragma once或#ifndef守卫但内部有#define可变宏的头（如带版本号的 config.h） - 模板实现头（
*.tpp）或内联函数密集的头——它们可能被不同翻译单元以不同宏状态包含
MSVC 和 CMake 下启用 PCH 的关键参数差异
MSVC 默认用 stdafx.h，CMake 则需手动桥接。两者底层机制一致，但开关位置和命名习惯不同，混用易出错。
MSVC 关键设置：
- 预编译头文件名必须与“预编译头文件”配置项完全一致（大小写敏感），例如设为
pch.h，则所有.cpp必须#include "pch.h"，不能写#include "PCH.H" - “预编译头”选项选“创建”仅对单个
.cpp生效（通常是pch.cpp），其余文件必须选“使用”
CMake 实操（3.16+）：
- 用
target_precompile_headers()，而非老式set_source_files_properties() - 正确写法：
target_precompile_headers(myapp PRIVATE "<vector>" "<string>" "pch.h")
—— 注意顺序：系统头用<>，项目头用""，且pch.h必须在列表末尾 - 若用 Ninja 生成器，确保 CMake 版本 ≥ 3.20，否则可能静默忽略 PCH
为什么加了 PCH 反而编译更慢？
最常见原因是 PCH 文件本身太大或包含低效内容。一个 50MB 的 pch.h.pch 不是优化，是负担。编译器加载 PCH 是 mmap 内存映射操作，体积过大时，I/O 和内存页分配开销会抵消解析收益。
排查和优化点：
- 用
cl /showIncludes main.cpp（MSVC）或g++ -H main.cpp（GCC）看实际包含树，确认哪些头确实被 PCH 覆盖了 - 删掉 PCH 中所有
using namespace std;—— 它强制将整个std符号表注入每个翻译单元，显著增大 PCH 体积且易引发 ODR 冲突 - 避免在 PCH 里
#include带大量模板实例化的头（如<regex>），除非你 90% 的文件真用它 - 定期清理：当项目引入新构建系统（如从 MSVC 切到 Clang-CL），旧 PCH 文件（
vc143.pch等）残留会导致奇怪的 LNK2038 错误，直接删Debug/和Release/下所有.pch文件最干脆
PCH 不是银弹。它只对头文件多、改动少、编译频繁的大项目有效；小工具或头常改的模块，关掉它反而更省心。
