根本原因是VS默认单线程编译、未启用预编译头、未并行化构建；需手动开启/MP多处理器编译、合理配置PCH（仅含稳定大头文件）、必要时选用ccache或C++20模块。
Visual Studio 编译大型 C++ 项目慢，根本原因不是硬件不够，而是默认配置没打开关键加速项、依赖关系没理清、构建流程没并行化。开箱即用的 VS 默认是单线程编译、不预编译头、不缓存中间结果——这些都得手动调。
开启多处理器编译（/MP）
这是最直接有效的一步，VS 默认关闭该选项。不启用时，cl.exe 只会串行编译每个 .cpp 文件；启用后，它会自动把多个源文件分发到 CPU 核心上并发编译。
操作路径：项目属性 → 配置属性 → C/C++ → 常规 → 多处理器编译 → 是 (/MP)
- 仅对当前项目的
.cpp文件生效，不影响第三方库或子项目 - 若项目含大量小文件（如自动生成的 glue code），/MP 提升明显；若只有几个巨无霸源文件，效果有限
- 注意：/MP 与某些旧版预编译头（PCH）配合可能出错，建议同时检查
预编译头设置是否为使用 (/Yu)而非自动使用 (/YX)
合理配置预编译头（PCH）
预编译头能跳过重复解析标准库和稳定头文件的过程，但用错反而拖慢编译——比如把常变的头（config.h、version.h）塞进 stdafx.h，每次改一个宏，整个 PCH 就要重做。
立即学习“C++免费学习笔记（深入）”；
关键原则：PCH 文件里只放几乎不变更的头，且必须被所有源文件统一包含
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 推荐结构：
stdafx.h中只包含<vector>、<string>、<memory>等 STL 头，以及项目级稳定接口头（如core/base.h） - 在每个
.cpp开头第一行写#include "stdafx.h"，且不能有任何前置宏定义或头文件 - 若项目已用
#pragma once或模块（import），PCH 可能冗余，此时应关闭（设为不使用）避免冲突
启用 ccache 并绕过常见陷阱
ccache 对 VS 有效，但必须通过命令行调用 cl.exe 才能生效（GUI 构建不走 ccache）。它靠哈希缓存 .obj，命中时跳过编译阶段，对未改动文件提速极显著。
典型配置（在 Developer Command Prompt 中）：
set CCACHE_SLOPPINESS=file_macro,time_macros set CCACHE_BASEDIR=C:\myproject set CL=/FC /nologo /c /EHsc /MP ccache cl.exe main.cpp
-
/FC必须加，否则 ccache 无法定位输出路径 - 禁用
/MM或/showIncludes类选项，它们会让 ccache 命中率为 0；改用/MMD生成依赖文件 - ccache 和 PCH 冲突：一旦启用 PCH，ccache 会退化为直通模式（文档明确说明），此时应二选一——PCH 适合稳定大项目，ccache 更适合频繁改头文件的开发阶段
模块（C++20 Modules）替代头文件包含
这是面向未来的根本解法。传统 #include 导致每个 .cpp 都重复解析同一份头文件，而 import 让编译器只解析一次模块接口单元（.ixx），再复用 AST。
MSVC 支持从 VS 2019 16.5+ 开始，需显式开启：
- 项目属性 → C/C++ → 语言 → 启用 C++ 模块支持 → 是 (/experimental:module)
- 模块接口文件（如
math.ixx）必须用export module math;声明 - 使用处写
import math;，而非#include "math.h" - 注意：第三方库（如 Boost、Qt）尚未模块化，它们仍走传统头文件路径，模块只能用于你完全控制的代码层
模块真正起效的前提是项目已做好接口隔离——如果所有头还在互相 include、到处用 using namespace，强行模块化只会增加维护负担，编译速度也不一定提升。
