std::pmr::vector 可通过绑定栈上 monotonic_buffer_resource 实现栈分配，但资源生命周期必须长于容器；两者与 std::vector 类型不兼容因分配器模板参数不同；自定义 resource 需正确实现 do_is_equal 等虚函数，核心风险是资源析构早于容器使用。
直接用 std::pmr::polymorphic_allocator 配合具体 memory_resource 实例，就能在不改容器类型的前提下切换分配策略——关键不是“能不能”，而是“资源生命周期必须比使用它的容器长”，否则会崩溃。
怎么让 std::pmr::vector 用上栈缓冲区
核心是把 std::pmr::monotonic_buffer_resource 和一块栈内存绑定，再传给容器构造函数。它不回收内存，但极快，适合临时批量数据。
- 先在栈上分配足够大的缓冲区（比如
alignas(std::max_align_t) std::byte buffer[4096];） - 用该缓冲区初始化
std::pmr::monotonic_buffer_resource pool{buffer, sizeof(buffer)}; - 构造容器时显式传入资源指针：
std::pmr::vectorv{&pool}; - 注意：不能把
pool声明为局部变量后返回容器——pool析构后，v的内存就悬空了
为什么 std::pmr::vector 和 std::vector 不能混用
它们类型完全不同，但原因不是 PMR 本身，而是模板参数差异：std::pmr::vector 等价于 std::vector，而后者和默认分配器的 std::vector 不兼容。
- 函数参数想通用？只能统一用
std::pmr::vector并接受std::pmr::memory_resource*作为额外参数 - 想存进同个容器？不行，类型擦除只发生在分配器内部，容器类型仍是硬编码的
- 接口设计时若需灵活性，建议暴露
std::pmr::memory_resource*而非具体容器类型
synchronized_pool_resource 和 unsynchronized_pool_resource 怎么选
前者线程安全，后者更快；但“线程安全”仅指资源自身的 allocate/deallocate 操作互斥，不保证容器操作线程安全。
- 多线程频繁创建/销毁小对象（如节点、消息体）→ 优先
synchronized_pool_resource - 单线程或已由外部加锁保护 → 用
unsynchronized_pool_resource，性能提升明显 - 两者都支持设置上游资源（
upstream），例如 fallback 到new_delete_resource()，避免池耗尽时直接崩溃 - 池大小参数影响实际表现：过小导致频繁向上游申请；过大浪费内存且增加首次分配延迟
自定义 memory_resource 最容易漏掉什么
do_is_equal 必须正确实现，否则跨资源释放内存会出错——这是最常被忽略的点。
- 如果资源不共享内存（比如每个实例独占一块 buffer），
do_is_equal应该只比较地址：return this == &other; - 如果资源可共享（如全局池），则需判断是否指向同一底层管理结构
-
do_deallocate可以什么都不做（如monotonic_buffer_resource），但必须能接受之前do_allocate返回的指针 - 所有虚函数必须标记
override，否则编译可能不报错但运行时调用错误基类实现
PMR 的复杂性不在语法，而在资源生命周期和所有权边界。写完代码后多问一句：“这个 memory_resource 实例，到底谁负责析构？析构时还有没有容器在用它？”——多数崩溃都源于这个问题没想清楚。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
