pimpl惯用法核心是头文件仅声明不透明指针和接口，实现细节全移至.cpp中；需显式声明析构/拷贝/移动函数并在.cpp定义，因unique_ptr需impl完整定义才能生成正确代码。
Pimpl 惯用法不是“加个指针就完事”，核心在于：它只在头文件里暴露接口声明和一个不透明指针（std::unique_ptr<impl></impl> 或裸指针），所有实现细节、私有成员、第三方头文件依赖，全部挪进 .cpp 文件里 —— 这才是编译防火墙生效的前提。
为什么 class Widget { private: struct Impl; std::unique_ptr<impl> pImpl; };</impl> 不能直接编译
因为 std::unique_ptr<impl></impl> 在构造/析构/拷贝时需要知道 Impl 的完整定义（否则无法调用其析构函数）。但头文件里只前向声明了 struct Impl;，没定义它。
- 错误现象：
error: invalid use of incomplete type 'struct Widget::Impl'（尤其在类析构函数隐式生成时爆发） - 必须显式提供
Widget的析构函数声明，并在.cpp中定义（哪怕只写{}） - 如果类支持拷贝/移动，
copy constructor、copy assignment operator、move constructor等也需显式声明并在.cpp中定义（或= default，但前提是Impl已定义） - 别忘了
#include <memory></memory>，且pImpl初始化必须在构造函数初始化列表中完成（如: pImpl{std::make_unique<impl>()}</impl>）
如何正确组织 .h 和 .cpp 文件
头文件只保留契约；实现文件才“知情”。任何对 Impl 成员的访问（包括构造、析构、函数调用），都必须发生在 .cpp 中。
-
widget.h：只含前向声明 + 公共接口 +std::unique_ptr<impl></impl>成员 + 显式析构/赋值声明 -
widget.cpp：先#include "widget.h"，再struct Widget::Impl { ... };完整定义，最后实现所有成员函数（包括委托给pImpl->xxx()的逻辑） - 第三方头（如
<boost></boost>、<opencv2></opencv2>）只能出现在.cpp，绝不能泄露到.h - 如果
Impl需要访问Widget的私有成员，可将Impl声明为friend class Impl;（但慎用，优先考虑接口委托）
使用 std::unique_ptr 还是裸指针 + new/delete？
现代 C++ 应无条件选 std::unique_ptr，但要注意它带来的约束：
立即学习“C++免费学习笔记（深入）”；
-
std::unique_ptr默认禁止拷贝（符合 Pimpl 设计本意），移动是安全的 - 若类需拷贝语义，不能直接拷贝
pImpl，而应实现深拷贝逻辑（在.cpp中 new 一个新的Impl并复制内容） - 裸指针虽省去
<memory></memory>依赖，但必须手动管理生命周期，极易泄漏或 double-delete；且无法自动支持移动语义 - 性能上无实质差异：
std::unique_ptr是零开销抽象，pImpl.get()和裸指针访问成本相同
/* widget.h */
#pragma once
#include <memory>
<p>class Widget {
public:
Widget();
~Widget(); // 必须声明
Widget(const Widget&); // 若需拷贝，必须声明并定义在 .cpp 中
Widget& operator=(const Widget&);
Widget(Widget&&) noexcept;
Widget& operator=(Widget&&) noexcept;</p><pre class='brush:php;toolbar:false;'>void doSomething();
int getValue() const;private:
struct Impl;
std::unique_ptr
/* widget.cpp */
#include "widget.h"
#include <string>
#include <vector>
// 所有实现依赖（如 #include <boost/regex.hpp>）都在这里，绝不进 .h
<p>struct Widget::Impl {
std::string data;
std::vector<int> cache;
// 可以自由包含任意重型头文件、定义复杂类型、链接第三方库
};</p><p>Widget::Widget() : pImpl{std::make_unique<Impl>()} {}
Widget::~Widget() = default; // 此处 Impl 已定义，可 default</p><p>Widget::Widget(const Widget& other)
: pImpl{std::make_unique<Impl>(*other.pImpl)} {}</p><p>Widget& Widget::operator=(const Widget& other) {
if (this != &other) <em>pImpl = </em>other.pImpl;
return *this;
}</p><p>void Widget::doSomething() { pImpl->data += "done"; }
int Widget::getValue() const { return static_cast<int>(pImpl->data.size()); }最容易被忽略的一点：Pimpl 的代价是间接访问（一次指针解引用）、堆分配（除非用 placement new + 内存池优化）、以及强制用户写更多样板代码（析构/移动/拷贝的显式控制）。它解决的是编译依赖爆炸问题，不是运行时性能问题 —— 别为了“看起来更封装”而滥用。
