placement new不能直接配普通delete，因其不分配内存而仅调用构造函数，delete会错误释放内存并调用析构函数，导致双重释放或崩溃；必须先显式调用析构函数再按原方式释放缓冲区。
placement new 为什么不能直接配普通 delete
因为 placement new 不分配内存，只调用构造函数；而 delete 会尝试释放内存并调用析构函数，导致双重释放或崩溃。必须手动调用析构函数，再按原始方式释放缓冲区。
- 常见错误现象：
double free or corruption或程序在析构时 SIGSEGV - 正确顺序永远是：先
obj->~T()，再free(buf)（若用malloc分配）或operator delete(buf)（若用new分配） - 别依赖 RAII 自动管理——
placement new构造的对象不会被智能指针自动析构，除非你自定义删除器
如何安全地复用同一块缓冲区多次构造不同对象
核心是确保每次构造前旧对象已析构，且缓冲区足够大、对齐正确。C++17 起推荐用 std::aligned_storage_t，但要注意它不保证生命周期管理。
- 使用场景：对象池、序列化反序列化、嵌入式固定内存分配
- 关键参数：
sizeof(T)和alignof(T)必须同时满足，否则placement new行为未定义 - 示例：
alignas(alignof(MyClass)) char buf[sizeof(MyClass)]; MyClass* p = new (buf) MyClass(42); // OK p->~MyClass(); // 必须显式析构 new (buf) MyClass(99); // 可复用
- 容易踩的坑：用
std::vector<char></char>当缓冲区时，data()返回指针可能未按alignof(T)对齐——得用std::aligned_alloc或包装一层
std::allocator::construct 与 placement new 的实际差异
std::allocator 的 construct 是对 placement new 的封装，但多了类型擦除和异常安全处理；它本身不解决延迟构造的本质问题，只是让模板代码更统一。
- 性能影响：几乎无差别，现代编译器基本内联掉
- 兼容性注意：C++20 起
construct被弃用，推荐直接用std::construct_at - 实操建议：
char buf[1024]; auto p = std::construct_at(reinterpret_cast<MyClass*>(buf), 123); std::destroy_at(p); // 替代手动写 p->~MyClass()
- 为什么推荐
std::construct_at：它自动处理对齐检查（debug 模式下），且语义更明确，避免裸placement new的隐式转换风险
对象析构后访问缓冲区内容是否安全
只要没重用缓冲区、也没释放底层内存，读取原内存字节是安全的——但读出来的不是有效对象，只是原始字节。任何通过指针调用成员函数或访问非静态成员都属于未定义行为。
立即学习“C++免费学习笔记（深入）”；
- 常见错误现象：调试时发现“对象还在”，于是误以为还能用，结果优化开启后行为突变
- 使用场景：仅限调试打印、内存快照比对、或为后续复用做准备
- 关键提醒：
std::launder不适用于已析构对象——它只在对象生命周期内、且指针被编译器误判为“失效”时才需要 - 真正安全的做法：把缓冲区视为 raw memory，对象生命周期严格由构造/析构边界界定
事情说清了就结束。最常出问题的地方不是怎么构造，而是忘了析构，或者析构后还当成对象用。对齐和缓冲区大小这两个硬约束，一旦漏掉，连编译都不报错，运行时才崩。
