将析构函数设为私有不能真正限制对象只在堆上创建，因为它会阻止智能指针析构、使移动语义失效，且无法解决堆对象安全销毁问题；正确做法是删除所有栈相关函数、保持析构函数public并提供返回智能指针的静态工厂方法。
为什么把析构函数设为私有不能真正限制对象只在堆上创建
把 ~ClassName() 设为 private 确实会让栈上对象编译失败（因为栈对象生命周期结束时，编译器需调用析构函数，而无法访问私有析构），但这个方案有严重漏洞：它同时阻止了所有自动资源管理行为，包括 std::unique_ptr、std::shared_ptr 的正常析构，也导致 move 语义失效。更关键的是，它没解决“如何安全销毁堆对象”的问题——用户只能靠裸指针 new + delete，极易内存泄漏。
正确做法：禁用栈分配 + 提供受控的堆创建接口
核心是两步：一是让编译器无法生成栈对象（通过删除默认构造函数和禁止拷贝/移动），二是只暴露静态工厂方法返回智能指针。析构函数必须是 public，否则 std::unique_ptr 析构时会报错 error: 'ClassName::~ClassName()' is private。
常见错误现象：
- 声明 static std::unique_ptr 但析构函数私有 → 编译失败
- 只禁用构造函数却不删除拷贝/移动 → 对象仍可能被复制到栈上
- 工厂函数返回裸指针 → 用户忘记 delete 或重复 delete
- 将默认构造函数、拷贝构造函数、移动构造函数、拷贝赋值、移动赋值全部声明为
delete - 析构函数保持
public，且通常应为virtual（若类可能被继承） - 提供
static std::unique_ptr工厂函数，内部用create(...) new或std::make_unique - 若需自定义删除器（如对象需特殊释放逻辑），可重载
operator delete，但非必需
class HeapOnly {
public:
static std::unique_ptr create(int x) {
return std::make_unique(x);
}
~HeapOnly() = default; // 必须 public！
private:
explicit HeapOnly(int x) : value(x) {}
// 禁止所有栈相关操作
HeapOnly() = delete;
HeapOnly(const HeapOnly&) = delete;
HeapOnly(HeapOnly&&) = delete;
HeapOnly& operator=(const HeapOnly&) = delete;
HeapOnly& operator=(HeapOnly&&) = delete;
int value;
};
替代方案：使用 placement new + 自定义内存池（高级场景）
当需要更精细控制（如对象必须分配在特定内存区域、避免全局堆碎片），可结合 private 构造函数 + static 内存池 + placement new。此时析构函数仍需 public，且必须显式调用（因不走默认 delete）。典型错误是忘记手动调用析构函数，或调用后未归还内存。
立即学习“C++免费学习笔记（深入）”；
- 内存池需线程安全（如用
std::mutex 保护分配/释放）
- 工厂函数返回对象指针时，必须配套提供
destroy() 静态方法
- 禁止用户直接调用
operator delete，否则破坏内存池一致性
- 该方案复杂度高，仅适用于嵌入式、实时系统等有明确内存布局要求的场景
最容易被忽略的点：友元与继承的影响
如果类有友元函数或友元类，它们仍能访问私有构造函数和析构函数，可能绕过限制；若类被继承，子类的析构函数若未显式声明为 virtual，会导致基类析构不被调用。更隐蔽的问题是：C++17 后，某些编译器对 std::make_unique 的实现依赖于构造函数的可访问性，若构造函数是 private 且无恰当友元声明，std::make_unique 会编译失败。
解决方案：
- 若需支持 std::make_unique，将构造函数设为 private 并声明 friend std::unique_ptr std::make_unique(int&&); （不推荐，过于耦合）
- 更稳妥的是在工厂函数中直接用 new，避开 make_unique 的访问检查
- 所有继承体系中，基类析构函数必须为 virtual 且 public
