将构造函数设为private可禁止栈上创建对象，仅允许通过public静态工厂函数（如create()）在堆上创建，配合禁用拷贝/移动、使用智能指针及protected virtual析构函数（若需继承），实现可靠的堆限定类。
为什么要把构造函数设为 private？
因为 C++ 中对象在栈上创建时，编译器会直接调用构造函数（包括默认、拷贝等），而堆上创建（new）时，构造函数仍需可访问——但我们可以把构造函数设为 private，再提供一个 public 的静态工厂函数来控制创建入口。这样栈上声明 A a; 就会编译失败，而 A* p = A::create(); 可以通过。
- 构造函数和析构函数都必须是
private（否则用户可能用new A()+delete之后再栈上定义引用或临时对象，绕过限制） - 必须提供
public static成员函数（如create()）返回堆上对象指针 - 如果类有继承需求，析构函数还得是
protected virtual，但此时“仅堆上”约束已不严格——子类可能被栈上实例化，慎用
怎么写一个可靠的堆限定类？
核心是封死所有栈上创建路径：禁止隐式拷贝、禁止直接构造、禁止移动（除非你显式支持），同时让 new 只能通过你的接口发生。
class HeapOnly {
private:
HeapOnly() = default;
~HeapOnly() = default;
<p>public:
static std::unique_ptr<HeapOnly> create() {
return std::make_unique<HeapOnly>();
}</p><pre class="brush:php;toolbar:false;">// 禁用拷贝和移动（防止 move 构造出栈对象）
HeapOnly(const HeapOnly&) = delete;
HeapOnly& operator=(const HeapOnly&) = delete;
HeapOnly(HeapOnly&&) = delete;
HeapOnly& operator=(HeapOnly&&) = delete;};
- 使用
std::unique_ptr而非裸指针，避免用户忘记delete - 不提供
public析构函数，否则std::shared_ptr或自定义 deleter 可能绕过封装 - 如果必须返回裸指针，至少把
delete也收进类里（如destroy(HeapOnly*)），否则用户delete p;会因析构函数不可访问而编译失败
容易被忽略的绕过方式有哪些？
即使做了上述限制，C++ 的灵活语法仍留有缝隙：
立即学习“C++免费学习笔记（深入）”；
-
std::optional<heaponly></heaponly>或std::variant可能在内部栈上构造该类型（触发私有构造），导致编译失败——这不是绕过，而是你设计没兼容标准容器；若需配合容器，得加friend或改用std::unique_ptr存储 - 模板元编程中，
std::is_constructible_v<heaponly></heaponly>会返回false，影响 SFINAE 判断；如果库代码依赖此 trait，可能意外失效 - 继承该类的子类，若子类析构函数是
public，且父类析构是protected，那么子类对象仍可栈上创建（父类约束不传递）
最麻烦的是：一旦用了 friend 放开某个函数或类，就等于开了后门——比如为了支持 std::make_unique，你得 friend class std::default_delete<heaponly>;</heaponly>，但 C++ 标准不保证其实现细节，不同 STL 版本行为可能不一致。
要不要用 placement new 绕过？
有人试过在栈内存上调用 new (buf) HeapOnly，但这只是“伪栈对象”：它绕过了构造函数访问检查（因为 placement new 不调用构造函数？错），实际仍需要访问 private 构造函数——所以依然编译失败。真正能绕过的，只有友元或反射（C++20 无原生反射，不考虑）。
-
placement new本身不规避访问控制，它只是指定内存位置，构造函数调用权限照旧检查 - 若你把构造函数改成
protected并让某个友元类调用它，那确实可能被滥用——比如友元类暴露了构造能力给不该拥有的人 - 所以“仅堆上”本质是编译期契约，不是运行时强制；它防的是误用，不是恶意破解
真正在意生命周期控制的场景，与其花力气堵所有口子，不如接受“用智能指针表达所有权”，把约束从“只能堆上”降级为“推荐堆上+清晰所有权”，反而更稳健。
