最核心约束是析构函数、移动构造函数和移动赋值运算符必须在.cpp中定义，因impl前向声明导致不完整类型，unique_ptr析构器需impl完整定义才能生成；头文件仅前向声明，.cpp中包含impl定义并实现特殊成员函数。
用 std::unique_ptr 实现 Pimpl 时，最核心的约束是：析构函数、移动构造函数和移动赋值运算符必须在 .cpp 文件中定义（不能 = default 在头文件里），否则编译失败——因为 Impl 是前向声明的不完整类型，unique_ptr 的析构器会在实例化时尝试 sizeof(Impl)，而此时它不可知。
为什么析构函数不能写在头文件里
头文件中只能看到 class Impl;，编译器不知道 Impl 的大小、成员、析构逻辑。但 std::unique_ptr<impl></impl> 的默认析构器需要调用 Impl 的析构函数并释放内存，这要求 Impl 是完整类型。
-
~Widget() = default;放在头文件 → 编译器在实例化unique_ptr时找不到Impl定义 → 报错invalid application of 'sizeof' to incomplete type - 必须在
widget.cpp中显式定义：Widget::~Widget() = default;，此时#include "widget_impl.h"已提供完整定义 - 同理，
Widget(Widget&&)和Widget& operator=(Widget&&)也需在 .cpp 中定义（哪怕只是= default）
如何组织头文件和实现文件
目标是让头文件只依赖最少的类型（最好是标准库前向声明或无依赖），所有具体实现细节藏在 .cpp 里。
- 头文件
widget.h：只做class Impl;前向声明，声明std::unique_ptr<impl> pImpl;</impl>，声明公有接口和特殊成员函数（不定义） - 实现文件
widget.cpp：先#include "widget.h"，再#include <string></string>、<vector></vector>等实际用到的头，然后定义class Widget::Impl { ... };，再定义构造/析构/移动函数 - 避免在头文件中
#include任何与Impl实现相关的头（比如gadget.h、config.h），否则“编译防火墙”就失效了
用 make_unique 初始化时要注意什么
std::make_unique<impl>(...)</impl> 必须在 Impl 是完整类型的上下文中调用，也就是只能在 .cpp 文件里。
- 构造函数初始化列表里不能直接写
pImpl(std::make_unique<impl>(...))</impl>—— 因为初始化列表仍属于类定义的一部分，头文件中Impl不完整 - 正确做法：在构造函数体内部（即 .cpp 中）调用
make_unique，或使用委托构造（仍需确保发生在完整类型可见处） - 示例（widget.cpp）：
Widget::Widget(int n) : pImpl(std::make_unique<impl>(n)) {}</impl>—— 这行代码在 .cpp 中，Impl已定义，合法
容易被忽略的 ABI 和性能点
Pimpl 虽然解耦了编译依赖，但引入了间接访问开销和堆分配成本，这些在接口设计初期就该权衡。
- 每次访问
pImpl->member都是一次指针解引用，对高频调用函数可能有可观影响；不要把get_x()这类 trivial getter 也塞进 Pimpl -
std::unique_ptr默认使用operator delete，如果Impl需要自定义内存管理（如对象池），必须传入自定义删除器：std::unique_ptr<impl mydeleter></impl> - ABI 稳定性：只要
Widget的公有接口不变，哪怕重写整个Impl，二进制兼容性不受影响——这是库作者最看重的一点，但前提是别在头文件里暴露任何Impl相关符号（包括友元声明、模板特化等）
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
