直接将 operator new 设为 private 无法拦截 placement new 和 nothrow new，且编译器优化（如 RVO）可能绕过重载；可靠方案是删除所有 operator new/delete 变体并保持构造函数公有、析构函数公有。
为什么不能直接把 new 操作符设为 private
很多人第一反应是把 operator new 声明为 private，但这样只能阻止显式调用 new，无法拦截 new (std::nothrow) MyClass() 或 placement new —— 后者在栈上分配内存时也可能被误用。更关键的是，C++ 标准允许编译器在某些优化场景下绕过重载的 operator new（比如返回值优化 RVO），导致限制失效。
真正可靠的方案：禁用堆分配 + 控制构造方式
核心思路是让类对象无法通过任何方式获得堆地址，同时保留栈上构造的合法性。这需要两步配合：
- 将所有
operator new和operator delete（包括数组版本和nothrow版本）声明为delete，彻底切断堆分配入口 - 确保构造函数不是
explicit且可被栈上直接调用（即不依赖外部工厂或友元控制） - 注意：析构函数必须保持
public，否则栈对象离开作用域时无法自动析构
示例：
class StackOnly {
public:
StackOnly() = default;
~StackOnly() = default;
<pre class="brush:php;toolbar:false;">// 禁用所有堆分配可能
void* operator new(std::size_t) = delete;
void* operator new[](std::size_t) = delete;
void* operator new(std::size_t, const std::nothrow_t&) noexcept = delete;
void* operator new[](std::size_t, const std::nothrow_t&) noexcept = delete;private: // 不需要 private 构造——栈上构造不经过 friend 或 static 工厂 };
容易踩的坑：友元工厂 + placement new 的绕过风险
如果类内部定义了 friend 工厂函数，或暴露了 operator new 的 placement 形式，就可能被滥用。例如：
- 声明
void* operator new(std::size_t, void*) = delete;是无效的——placement new 必须可调用，否则连std::vector内部都可能崩溃 - 若提供
static StackOnly create()工厂，它仍可能在内部用malloc+ placement new 绕过限制 - 继承该类的子类，若未同步删除其
operator new，就会重新开放堆分配
替代思路：用静态断言 + 构造时检测地址范围
纯编译期限制总有漏洞，运行时加固更稳妥。可在构造函数中检查 this 地址是否落在栈范围内（需平台支持）：
- Linux 下可用
pthread_getattr_np获取当前线程栈边界 - Windows 可用
GetCurrentThreadStackLimits - 但要注意：栈地址检测不能用于 constexpr 构造，且增加启动开销
- 更现实的做法是结合编译期限制 + 单元测试断言：对每个实例做
assert(reinterpret_cast<uintptr_t>(this) > stack_low && reinterpret_cast<uintptr_t>(this) </uintptr_t></uintptr_t>
强制栈分配不是银弹——它会让调试、动态生命周期管理、多态容器使用变得别扭，真正需要时，优先考虑 RAII 容器（如 std::array、std::optional）或明确所有权语义的设计，而不是堵死所有堆路径。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
