为什么Pimpl能保住ABI不崩
因为公开头文件里只暴露一个 class 壳子和一个 std::unique_ptr（或裸指针），所有具体成员、函数实现、私有类型全塞进 .cpp 里。只要壳子的内存布局不变（比如没加新 public 成员、没改构造/析构/赋值签名），哪怕内部重写了三遍，链接时老二进制照样能调新库。
关键不是“隐藏实现”，而是“把可变部分彻底移出头文件”。头文件一旦被用户包含，就等于把 ABI 合约钉死了——Pimpl 把这个合约缩到最小：仅指针大小 + 四个默认函数。
怎么写才不踩坑：构造/析构/拷贝/移动必须显式定义
编译器自动生成的默认函数会尝试访问 Impl 类型，但头文件里只有前向声明，Impl 定义在 .cpp 里——这会导致链接失败或 ODR 违规。常见错误现象：undefined reference to `MyClass::~MyClass()' 或编译时报 invalid use of incomplete type。
- 在头文件中声明但不定义：
MyClass()、~MyClass()、MyClass(const MyClass&)、MyClass& operator=(const MyClass&)、MyClass(MyClass&&)、MyClass& operator=(MyClass&&) - 全部实现在 .cpp 里，且必须用
new Impl/delete pImpl_（或更推荐std::make_unique） - 如果类带资源管理（如文件句柄），移动语义不能省；否则默认移动会浅拷贝指针，导致 double-delete
std::unique_ptr vs raw pointer：选哪个？
用 std::unique_ptr 是当前最稳妥的选择，它自动处理析构、禁止拷贝、支持移动，且大小仍是单指针（无额外开销）。裸指针虽然更“轻”，但容易漏掉 delete，且无法靠类型系统阻止误拷贝。
立即学习“C++免费学习笔记（深入）”；
性能上没区别：两者都是一个指针宽度；兼容性上 std::unique_ptr 要求 C++11+，但几乎所有现代项目都满足。唯一要注意的是：别在头文件里写 std::unique_ptr<impl></impl> 的完整定义——仍需前向声明 class Impl;，然后用 std::unique_ptr<impl></impl> 声明成员，否则又引入了对 Impl 完整定义的依赖。
示例头文件片段：
class MyClass {
class Impl;
std::unique_ptr<Impl> pImpl_;
public:
MyClass();
~MyClass();
MyClass(const MyClass&);
MyClass& operator=(const MyClass&);
MyClass(MyClass&&);
MyClass& operator=(MyClass&&);
};
ABI稳定性的真正敌人：虚函数表和内联函数
很多人以为只要用了 Pimpl 就万事大吉，结果加了个 virtual 函数，或者把某个 getter 写成 inline，ABI 就悄悄破了。虚函数会把 vtable 指针塞进对象开头，一旦增删虚函数，偏移全乱；内联函数一旦改动，调用方代码里已经埋好了旧逻辑，根本不会重新编译。
- 所有对外接口函数，必须是非虚、非内联、定义在 .cpp 里
- 如果必须多态，用策略模式或类型擦除替代虚继承，把虚表关在 Pimpl 内部
- 禁止在头文件里写
inline、constexpr（除非确定永不变更）、static const成员变量（C++17 前可能引发 ODR） - 连
sizeof(MyClass)都要小心——它必须始终等于sizeof(std::unique_ptr<impl>)</impl>，也就是指针大小（通常 8 字节）。加任何 public 成员都会破坏这点
复杂点在于：ABI 稳定不是单靠 Pimpl 实现的，它是整个接口设计的纪律——Pimpl 只是帮你守住最外层那堵墙。墙后面怎么建，还得自己盯紧。
