析构函数必须在.cpp中定义，因为std::unique_ptr析构时需调用impl的析构函数，而头文件中仅含class impl;前向声明，impl为不完整类型，编译器无法获取其大小和布局，若在头文件中= default会导致sizeof错误或链接失败。
为什么析构函数必须在 .cpp 里定义
因为 std::unique_ptr<impl></impl> 在析构时需要调用 Impl 的析构函数，而头文件里只有 class Impl; 前向声明——编译器此时不知道 Impl 有多大、有哪些成员、怎么销毁它。如果把 ~Foo() = default; 放在头文件里，链接阶段会报错，典型错误是：invalid application of 'sizeof' to incomplete type 'Impl'。
常见错误现象：
- 编译通过，但链接失败（尤其在使用
std::unique_ptr且析构函数未显式定义时） - 局部对象离开作用域时崩溃（隐式调用析构却无法正确释放）
正确做法：
- 在头文件中只声明
~Foo();（不实现） - 在
.cpp文件中，Impl 定义之后 写Foo::~Foo() = default;或空实现{} - 不能把
Impl定义放在头文件里，否则就失去 Pimpl 的编译隔离意义
头文件里怎么声明 Impl 才安全
头文件是接口契约，必须严格控制暴露范围。任何对 Impl 类型的直接依赖（比如 std::vector<int></int>、std::string、第三方库类型）都不能出现在头文件的私有区。
关键点：
- 只写
class Impl;前向声明，不包含任何Impl的定义或头文件 -
pimpl_成员必须是std::unique_ptr<impl></impl>，不能是裸指针或std::shared_ptr（除非真需共享所有权） -
pimpl_应该是类中最后一个数据成员（避免移动语义导致未定义行为） - 显式禁用拷贝：
Foo(const Foo&) = delete;、Foo& operator=(const Foo&) = delete;
容易踩的坑：
- 误在头文件里包含
#include <vector></vector>—— 即使没用到，也会把依赖泄漏给所有包含者 - 把
Impl定义成全局命名空间下的独立类（如class WidgetImpl），造成符号污染；应定义为Widget::Impl或匿名命名空间内结构体
实现文件里如何组织 Impl 和转发逻辑
所有具体实现都收拢到 .cpp，这是 Pimpl 的“黑盒”所在。这里决定了编译隔离是否真正生效，也最容易遗漏细节。
实操建议：
-
Impl定义放在.cpp开头，紧挨着#include "foo.h"之后，确保其完整可见 - 每个公有函数只需简单转发：
void Foo::DoWork() { pimpl_->DoWork(); } - 若需支持拷贝，不能直接复制
pimpl_（那是浅拷贝），而应在Impl中实现拷贝构造，并在Foo的拷贝构造函数中调用std::make_unique<impl>(*other.pimpl_)</impl> - 构造函数初始化列表里用
pimpl_(std::make_unique<impl>())</impl>，别在构造函数体内 new
性能影响：
- 每次访问都要一次指针解引用 + 堆分配开销，高频小对象场景慎用
- 但换来的是头文件变更零重编译——大型项目中节省的编译时间远大于这点运行时成本
什么时候不该用 Pimpl
Pimpl 不是万能钥匙。它解决的是编译依赖和 ABI 稳定问题，不是封装本身。
明显不适合的场景：
- 类很小（比如只有几个 int 成员），加一层指针反而增加内存和访问开销
- 性能敏感路径（如数学计算核心、高频循环体内的对象）
- 需要 POD 或 trivially copyable 类型（Pimpl 必然破坏 triviality）
- 类本身就不打算被导出或复用，纯内部工具类
真正值得用 Pimpl 的地方很明确：动态库接口、跨平台模块、频繁迭代的私有实现、或引入了第三方头文件依赖（比如 HttpClient.h）却不想让使用者感知。
最常被忽略的一点是：Pimpl 的价值不在代码“看起来更封装”，而在于你改了 Impl 里的任意一行（哪怕只是换了个容器类型），所有依赖这个头文件的源文件都不用重新编译——这才是它不可替代的地方。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
