RAII是C++中将资源获取与对象构造绑定、资源释放与析构绑定的核心机制，确保异常安全下的自动资源管理。它依赖构造函数申请资源、析构函数自动释放，适用于内存、文件句柄、锁等，智能指针和std::lock_guard是典型应用。
对象管理器不是标准 C++ 的内置组件，也没有统一接口或强制规范。它通常是项目自定义的封装层，用于集中控制对象生命周期——但它的职责边界很容易越界，导致资源管理混乱或 RAII 原则被破坏。
对象管理器不该接管栈对象的创建和销毁
栈对象（如 MyClass obj;）的生命周期由作用域自动决定，编译器在函数进入/退出时插入构造/析构调用。任何试图用“管理器”介入这个过程的行为（比如包装成 create_on_stack() 或延迟析构）都会破坏确定性，且毫无必要。
- 栈对象地址、布局、析构时机全由编译器静态控制，无法也不应被运行时管理器干预
- 若管理器返回栈对象的引用或指针，极易产生悬垂引用（dangling reference）
- 所有“栈对象池”“栈对象注册表”类设计，本质上违背了栈语义，应直接放弃
对象管理器只应在堆分配场景中承担有限职责
当且仅当使用 new / malloc 等动态分配时，管理器才可能有意义。但它只应做三件事：内存分配策略封装、构造后初始化委托、析构前清理钩子。不负责调用 delete 本身——那是智能指针或用户代码的事。
- 推荐只封装
operator new和operator delete的重载逻辑（例如对齐控制、特定内存池分配） - 可提供
make_unique_with_pool<T>()这类工厂函数，但内部仍应返回std::unique_ptr<T>，而非裸指针 - 若支持对象复用（如对象池），必须保证每次
acquire()后调用完整构造逻辑（placement new + 成员初始化），release()前显式调用析构函数（obj.~T()），否则虚表、成员状态会残留
析构时机失控是对象管理器最常踩的坑
很多自研管理器在对象销毁时试图“统一回收”或“延后释放”，结果导致析构函数不在预期作用域结束时执行，破坏 RAII。C++ 的栈展开（stack unwinding）机制只响应作用域退出或异常传播，不响应管理器的 destroy_all() 调用。
立即学习“C++免费学习笔记（深入）”；
- 析构函数必须在对象生命周期自然结束点被调用；延迟调用等于跳过析构，资源泄漏几乎必然发生
- 若管理器持有
std::shared_ptr<T>，析构仍由引用计数驱动，管理器只是参与者，不是控制者 - 禁止在析构函数里调用管理器的回调或事件通知——此时对象内存可能已部分失效，虚函数调用不可靠
真正关键的分寸在于：对象管理器只能影响“如何分配”和“何时允许析构”，不能篡改“谁触发析构”和“析构是否发生”。一旦混淆这两层，就从工具变成隐患源。
