delete 不能禁止堆分配，仅禁用特定函数调用；禁止堆分配需私有化 operator new 并配合友元工厂等组合策略。
delete 不能禁止堆分配，但能禁止 new 表达式调用特定构造函数
很多人误以为 delete 构造函数能阻止对象在堆上创建，其实不是——delete 的作用是让某个函数（构造/赋值/析构等）在编译期不可用，而堆分配是否可行，取决于你是否能成功调用 new 所需的构造函数。
比如你想禁止用户用 new MyClass()，就得把对应构造函数（如默认构造函数）声明为 = delete；但如果用户绕过它，比如用 placement-new 或自定义分配器，delete 就拦不住了。
-
MyClass* p = new MyClass;是否报错，取决于MyClass()是否被= delete -
MyClass obj;同样受同一规则约束，和内存位置无关 - 真正控制“只能栈分配”或“只能堆分配”，得靠访问控制 + 友元 + 自定义 new/delete 操作符配合，单靠
= delete不够
禁止拷贝构造和拷贝赋值必须同时 delete 两个函数
只删 MyClass(const MyClass&) 而不删 operator=(const MyClass&)，会导致对象可构造但不可赋值；反之亦然。更常见的是：忘记删移动函数，导致看似“禁止拷贝”的类仍能被 std::vector 等容器移动——这常引发逻辑错误。
正确写法是成对删除，并显式禁用移动操作（除非你明确需要）：
立即学习“C++免费学习笔记（深入）”；
class NonCopyable {
public:
NonCopyable() = default;
NonCopyable(const NonCopyable&) = delete;
NonCopyable& operator=(const NonCopyable&) = delete;
NonCopyable(NonCopyable&&) = delete;
NonCopyable& operator=(NonCopyable&&) = delete;
};- 即使你不写移动函数，C++11 后编译器也可能隐式生成（当没有用户定义的移动/拷贝函数时），所以显式
= delete更安全 - 继承体系中，基类
= delete不会自动传导到派生类，子类仍可能意外提供拷贝接口
delete 析构函数会导致 new + delete 失败，但 new[]/delete[] 不一定报错
如果把析构函数 = delete，那么任何通过 new 创建的对象在 delete 时都会编译失败——因为 delete 表达式必须能访问析构函数。但注意：new[] 分配的数组，其 delete[] 调用的是同一个析构函数，所以也会失败。
不过有个陷阱：如果你只重载了全局 operator delete 而没重载 operator delete[]，且析构函数被 = delete，某些编译器（如 GCC）可能在 delete[] 时漏掉析构调用检查，导致静默通过（但行为未定义）。
- 禁止销毁，就等于禁止所有标准方式的资源释放，包括智能指针管理
-
std::unique_ptr<myclass></myclass>无法编译，因为其默认删除器要调用~MyClass() - 想实现“仅构造不析构”，应考虑 RAII 外的生命周期管理策略，而非单纯
= delete ~MyClass()
delete 重载的 new/delete 操作符要小心匹配签名
如果你想禁止堆分配，最接近目标的做法是把类作用域内的 operator new 和 operator delete 声明为 = delete。但必须严格匹配标准签名，否则编译器不会调用你的版本，而是回退到全局版本。
例如以下写法无效：
class StackOnly {
void* operator new(size_t) = delete; // ✅ 正确
void operator delete(void*) = delete; // ✅ 匹配 new
// ❌ 错误：下面这个 delete 不会被调用，因为 new 返回 void*，delete 必须接受 void*
// void operator delete(StackOnly*) = delete;
};- 要禁用数组形式，还得额外声明
operator new[](size_t) = delete和operator delete[](void*) = delete - 全局
operator new依然可用，所以用户仍可写::new StackOnly——若需彻底封死，得结合链接期隐藏或静态断言 - 被
= delete的 operator new 在模板实例化中可能引发 SFINAE 失败，影响泛型代码兼容性
真正可靠的“禁止堆分配”不是靠 = delete 单点拦截，而是组合策略：私有化 operator new、用友元工厂函数控制创建、配合 static_assert 检查 std::is_trivially_destructible 等特性。很多看似“删掉就能禁用”的地方，实际运行时边界条件比想象中多。
