pimpl 的核心价值是切断编译依赖链：头文件仅前向声明 impl 并持 std::unique_ptr，私有成员全移至 .cpp 中定义；析构函数等特殊成员必须在 .cpp 中定义，否则因 impl 不完整导致编译失败。
Pimpl 不是“多加一层封装”，而是彻底切断头文件的编译依赖链；普通 private 成员做不到这点。
头文件里暴露了什么，直接决定谁要重编译
普通私有成员（比如 std::vector<int> data_</int>、std::string name_、MyConfig config_）一旦写在头文件中，所有包含该头文件的 .cpp 文件就隐式依赖 <vector></vector>、<string></string>、MyConfig.h ——哪怕只改了 data_ 的类型为 std::list，或只是更新了 MyConfig 的某个字段，整个项目都得重新编译。
Pimpl 把这些全挪到 .cpp 里：class Impl 只在实现文件中定义，头文件里只有前向声明 class Impl; 和一个 std::unique_ptr<impl></impl>。这意味着：
- 头文件不再
#include任何实现所需的头（<vector></vector>、第三方库、自定义结构体等） - 修改
Impl内部任意内容（增减字段、换容器、改依赖）都不触发其他模块重编译 - 用户看到的头文件体积更小，IDE 补全更快，预处理更轻量
析构函数必须在 .cpp 中定义，否则会编译失败
这是最容易踩的坑：如果把 ~MyClass() 声明在头文件里又不定义（即用 = default），编译器会在每个包含该头文件的翻译单元里尝试生成析构逻辑——但此时 Impl 是不完整类型，std::unique_ptr<impl></impl> 无法析构，报错类似：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
error: invalid application of 'sizeof' to incomplete type 'MyClass::Impl'
正确做法是：
- 头文件中只声明
~MyClass(); - 在
.cpp中定义MyClass::~MyClass() = default;（或显式delete pimpl;） - 同理，
std::unique_ptr的移动构造/赋值也需在.cpp中定义，若用到移动语义
内存布局和二进制兼容性完全不同
普通类的 sizeof 和内存布局由所有成员（包括 private）共同决定。只要增删一个 int 或改个字段顺序，ABI 就可能破坏——动态库升级后，老程序调用新库会崩溃。
Pimpl 类在头文件中只有一个指针成员（通常是 8 字节），sizeof 固定，内存布局稳定：
- 接口类的 ABI 不随
Impl内部变化而变 - 适合做 DLL / SO 接口，或长期维护的 SDK
- 代价是每次访问都要一次指针解引用（通常可忽略，但高频小对象场景需实测）
真正关键的分水岭不在“能不能隐藏实现”，而在“改实现时，是否强迫别人重编译”。Pimpl 的价值不是让代码看起来更‘干净’，而是让大型项目里改一行私有逻辑，不用等五分钟编译。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
