pimpl 模式需严格隔离实现：头文件仅前向声明 class impl;，定义及析构函数等必须置于 .cpp 中，禁用头文件包含任何实现依赖头文件，否则破坏编译防火墙。
能彻底隐藏私有实现、切断头文件重编译链，但前提是每个环节都守规矩——漏掉一个析构函数定义或偷偷在头文件里 #include <string></string>，整个防火墙就失效。
为什么头文件里只能写 class Impl; 而不能定义它
头文件是接口契约，一旦定义了 Impl，哪怕只有一行 std::string data;，所有包含该头文件的翻译单元就得看到 std::string 的完整定义。这意味着：第三方库升级、STL 实现变更、甚至你改了个私有成员类型，都会触发下游全量重编。
- 前向声明
class Impl;让编译器知道“有这么个类型”，但不关心它多大、有哪些成员、怎么析构 -
std::unique_ptr<impl></impl>只需要知道Impl是个类型，不需要它的布局——这是它能工作的前提 - 如果把
Impl定义放进头文件，Pimpl 就退化成普通类，编译隔离完全失效
析构函数必须在 .cpp 文件里定义，不能 = default 在头文件中
这是最常踩的坑：编译通过，链接失败，报错类似 invalid application of 'sizeof' to incomplete type 'Impl'。因为 std::unique_ptr<impl></impl> 析构时要调用 Impl 的析构函数，而头文件里 Impl 是不完整类型，编译器根本不知道怎么销毁它。
- 头文件中只写声明：
~Widget(); -
.cpp文件中，在Widget::Impl定义之后，再写：Widget::~Widget() = default; - 不能把
Impl定义提前到析构函数之前——顺序错了照样链接失败 - 同理，拷贝构造、拷贝赋值若涉及
*pImpl深拷贝，也必须在.cpp里实现
哪些头文件绝对不能出现在 .h 文件里
任何和实现细节沾边的头文件，都得被挡在 .h 外面。不是“我没用到就没事”，而是“只要它被 #include 进来，依赖就泄露了”。
- 禁止：
#include <string></string>、#include <vector></vector>、#include "third_party.h" - 允许：
#include <memory></memory>（因为std::unique_ptr需要）、#include <iosfwd></iosfwd>（如需前向声明std::ostream） - 所有 STL 类型、第三方类型、自定义辅助类，全部挪到
.cpp中#include - 连
std::size_t这种基础类型，如果只是用于私有成员，也别在头文件里暴露——用int或long做转发参数更安全
移动语义和内存布局的隐含约束
std::unique_ptr<impl></impl> 确实帮你绕过了不完整类型问题，但它不是免费的。几个容易被忽略的物理层细节会直接影响行为正确性：
-
pImpl应该是类中最后一个非静态数据成员——否则移动构造/赋值时，若前面成员抛异常，pImpl可能已部分移动，导致资源泄漏或双重释放 - 不要手动写移动操作符，除非你真需要定制逻辑；默认生成的对
std::unique_ptr是安全的 - 禁用拷贝（
Widget(const Widget&) = delete;）比实现深拷贝更常见——多数 Pimpl 类本就不打算被拷贝 - 调试时看不到
Impl成员内容？这是代价：GDB 需要加载.cpp符号才能展开，IDE 内联提示也会变弱
真正难的不是写对那几行 class Impl; 和 pImpl，而是每次加一个私有变量、换一个容器、引入一个新依赖时，都下意识问一句：“这个东西，能不能被用户看到？”——答案永远是否定的，否则你就没在用 Pimpl，只是在用指针。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
