std::pmr的核心用途是实现运行时可切换的内存分配策略，避免模板重实例化；必须使用场景包括动态切换内存行为、嵌入式模拟、请求级内存池、跨模块容器传递；其allocator通过绑定memory_resource实现转发，需注意资源生命周期、线程安全、移动语义及自定义类型适配。
std::pmr 的核心用途是：让同一套容器代码（比如 std::pmr::vector）能在运行时切换底层内存分配策略，而无需模板重实例化 —— 本质是把原本编译期绑定的 Allocator 变成运行期可插拔的资源。
什么时候必须用 std::pmr 而不是普通 allocator？
当你需要在不改代码、不重新编译的前提下，动态切换内存行为时。典型场景包括：
- 单元测试中用
std::pmr::monotonic_buffer_resource模拟“只分配不释放”的嵌入式环境 - 服务端请求处理中，为每个请求预分配一块大内存池（
std::pmr::synchronized_pool_resource），避免频繁系统调用 - 跨 DLL / SO 边界传递容器时，确保双方使用同一内存资源（否则
new分配、另一模块delete会崩溃）
std::pmr::polymorphic_allocator 怎么和资源绑定？
它本身不分配内存，只是个“转发器”，所有分配/释放操作都委托给构造时传入的 std::pmr::memory_resource*。关键点：
- 默认构造的
std::pmr::polymorphic_allocator绑定的是全局默认资源（std::pmr::new_delete_resource()） - 显式传入指针才真正切换策略：
std::pmr::monotonic_buffer_resource pool{buffer, sizeof(buffer)}; std::pmr::polymorphic_allocatoralloc{&pool}; - 容器如
std::pmr::vector的构造函数接受该 allocator，但注意：它只影响该容器自身及其元素的内存，不递归控制嵌套容器（比如vector<:string>中的string需要单独指定 allocator）
常见踩坑：为什么用了 std::pmr 还在用 malloc 或崩溃？
根本原因在于资源生命周期和所有权没理清：
立即学习“C++免费学习笔记（深入）”；
-
std::pmr::monotonic_buffer_resource析构时不会自动回收内存，但若 buffer 是栈变量，而 vector 还在用它，就会访问已销毁内存 - 多个线程共用同一个
std::pmr::synchronized_pool_resource没问题，但若用std::pmr::unsynchronized_pool_resource就必须加锁，否则 UB - 从
std::pmr::vector移动构造出新对象时，allocator 是被拷贝的，但如果原 allocator 指向一个局部memory_resource，新 vector 就会持有悬空指针 - 不能混用资源：用 A 资源分配的内存，必须用 A 资源释放；
std::pmr::polymorphic_allocator不检查这个，出错时通常表现为 double-free 或 heap corruption
最易被忽略的一点：所有自定义类型如果内部有动态内存（比如含 std::string 成员），又想完全走 pmr 路径，必须显式提供 using allocator_type = std::pmr::polymorphic_allocator<...> 并重载带 allocator 的构造函数——否则成员仍走默认 new/delete。
