std::allocator的核心接口必须重写allocate()、deallocate()、construct_at()、destroy_at()四个函数；其中allocate()和deallocate()不可省略，construct_at()/destroy_at()用于正确初始化/销毁非平凡类型对象。
std::allocator 的核心接口必须重写哪些
标准容器（如 std::vector、std::map）依赖分配器提供内存和对象生命周期管理，但真正强制要求实现的只有 4 个成员函数：
allocate()、deallocate()、construct()、destroy()。C++11 起 construct() 和 destroy() 已被弃用，取而代之的是 construct_at() 和 destroy_at()（C++17），但为兼容老代码或自定义行为，仍常需显式提供。
关键点在于：不实现 allocate() 和 deallocate()，容器根本无法申请/释放内存；漏掉 construct_at() 可能导致 POD 类型正常、但含非平凡构造函数的对象未被正确初始化。
为什么 operator new/delete 不够用
直接在 allocate() 里调 ::operator new、在 deallocate() 里调 ::operator delete 看似可行，但会踩两个坑：
-
allocate()必须支持n == 0—— 标准明确要求返回非空指针（如static_cast<t>(nullptr)</t>是非法的），应返回合法占位指针（常见做法是返回static_cast<t>(std::malloc(1))</t>或抛异常前兜底） - 分配器需满足「可交换性」：同一类型的不同实例必须能互换使用
deallocate()，即a.deallocate(p, n)可由b.deallocate(p, n)安全调用。若内部混用malloc/free和new/delete，或引入线程局部缓存但未同步状态，就会破坏该契约
如何让自定义分配器适配 std::vector 的增长策略
std::vector 在 push_back() 触发扩容时，会调用分配器的 allocate() 请求新内存，并用移动构造逐个迁移旧元素，最后调 deallocate() 释放旧块。这意味着：
- 你的
allocate()返回的内存必须支持按T对齐 —— 用alignof(T)校验，不能只靠malloc默认对齐（对alignas(32) struct X就可能失败） - 如果分配器带状态（比如绑定了某个内存池地址），必须定义
operator==和operator!=，否则vector在移动或交换时可能误判分配器是否相等，导致deallocate()被错误分配器调用 - 别试图在分配器里缓存
sizeof(T)—— 同一模板实例化中T固定，但分配器类型本身是MyAlloc<t></t>，编译期已知，无需运行时查
std::pmr::polymorphic_allocator 是更简单的替代方案吗
如果你只是想切换内存来源（如栈、池、GPU 显存），std::pmr::polymorphic_allocator 常比手写 std::allocator 衍生类更稳妥：
- 它只依赖
std::pmr::memory_resource*接口，你只需实现do_allocate()/do_deallocate()两个虚函数，不用处理模板偏特化、rebind、比较运算符等琐碎契约 - 所有 STL 容器都原生支持
std::pmr::vector这类别名，且std::pmr::string等类型自动传播资源，避免手动传参 - 但注意：虚函数调用有间接开销，高频小对象分配场景下，纯静态分配器（如
std::allocator特化版）仍更快；另外std::pmr是 C++17 起才有，老项目需权衡
最易被忽略的一点：分配器的「状态性」不是可选项——哪怕只存一个 size_t 计数器，也必须显式声明 is_always_equal = false，否则容器可能跳过分配器比较，导致跨实例释放崩溃。这个值默认是 false，但很多教程没提，结果调试时卡在 undefined behavior 上半天。
