新项目优先用 std::pmr::memory_resource 及其派生类，它线程安全、可组合、与标准容器无缝配合；手写裸指针池仅适用于嵌入式无STL或需精确字节控制的极少数场景。
内存池该用 std::pmr::memory_resource 还是手写裸指针？
直接说结论：新项目优先用 std::pmr::memory_resource 及其派生类（比如 std::pmr::synchronized_pool_resource），它已通过 libc++/libstdc++ 实现验证，线程安全、可组合、能和 std::vector 等容器无缝配合。手写裸指针池只在极少数场景必要——比如嵌入式无 STL、或需精确控制每字节布局。
常见错误是把 std::pmr::polymorphic_allocator 当成“开关”乱开：传给一个 std::vector 就以为整条调用链都走池，其实它只影响该容器自身内存申请，内部节点（如 std::map 的红黑树节点）仍走全局 new，除非你显式用同一 std::pmr::polymorphic_allocator 构造所有嵌套容器。
-
std::pmr::synchronized_pool_resource默认线程安全，但锁粒度较粗；高并发下可考虑std::pmr::unsynchronized_pool_resource+ 外层加锁 - 裸指针池若没实现对齐逻辑（比如用
alignas(16)或手动std::align），new T[10]类型分配会崩溃 - 不要试图把
malloc返回的内存直接塞进std::pmr::memory_resource子类——它要求do_allocate必须返回满足对齐要求的地址，且do_deallocate能反向识别块边界
如何让 std::vector 和 std::string 真正走内存池？
关键不是换容器，而是换分配器。默认 std::vector<int></int> 用的是全局 std::allocator，必须显式指定 std::pmr::polymorphic_allocator。
典型错误是只改声明不改构造：写 std::vector<int std::pmr::polymorphic_allocator>> v;</int> 没用，因为默认构造器仍用 std::pmr::get_default_resource()，而它默认是 new_delete_resource()（即普通 new）。必须传入具体资源对象：
立即学习“C++免费学习笔记（深入）”；
std::pmr::synchronized_pool_resource pool;
std::vector<int, std::pmr::polymorphic_allocator<int>> v{std::pmr::polymorphic_allocator<int>{&pool}};
-
std::string同理，需用std::pmr::string（C++17 起），别试图给std::string塞std::pmr::polymorphic_allocator—— 它模板参数不匹配 - 容器内元素类型如果是自定义类，且含动态成员（如
std::vector成员），这些成员也得用同源分配器，否则内存仍在堆上 - 移动语义不传递分配器：从池分配的
v1移动到v2，若v2未指定分配器，它会退化为全局分配
为什么 std::pmr::monotonic_buffer_resource 不能随便复用？
它是一次性向前推进的缓冲区，deallocate 是空操作，只有整个资源析构时才真正释放内存。这导致两个典型问题：
第一，短生命周期对象反复分配后，缓冲区不断增长，即使对象早已销毁；第二，多线程共用同一 monotonic_buffer_resource 实例会因无锁设计引发未定义行为（libc++ 文档明确警告）。
- 适合场景：函数内临时批量构建对象（如解析 JSON 生成中间节点），用完立刻销毁资源对象
- 不适合场景：作为长期存活的“通用池”，尤其不能跨函数传递裸指针给它管理
- 若需复用，必须调用
release()归还全部内存，但注意这会令之前所有分配的指针立即失效——不是延迟失效，是立刻野指针
裸指针内存池最易忽略的对齐与销毁顺序
手写池时，malloc 返回地址不一定满足 alignof(std::max_align_t)，而 C++ 对象构造要求严格对齐。更隐蔽的问题是销毁：如果池内对象有析构函数（比如 std::string 成员），但池只管归还内存块，不逐个调用析构函数，就会泄漏资源甚至崩溃。
- 分配时务必用
std::align手动对齐，或用aligned_alloc（C11）/_aligned_malloc（Windows） - 销毁阶段必须遍历活跃对象列表，显式调用
T::~T()，再归还内存——这意味着池需维护对象元信息（起始地址、大小、类型 ID），复杂度陡增 - 别信“我只放 POD 类型就不用析构”：只要用了
std::vector或std::string，它们内部就有非 trivial 析构函数
真正难的从来不是怎么分内存，而是怎么确保每一块都被正确构造、使用、析构、回收。池越薄，责任越重；池越厚，调试越难。选 std::pmr 不是偷懒，是把经过千锤百炼的边界条件检查接过来用。
