这种不兼容性源于 std::uses_allocator 类型特性，对于 std::string 和 std::pmr::polymorphic_allocator 的组合评估为 false。 std::string 将其 allocator_type 硬编码为 std::allocator<char>，而 std::pmr::vector 提供 std::pmr::polymorphic_allocator<char>；这些是不同的、无关的类类型，没有隐式转换或继承关系。当容器构造元素时，它查询 std::uses_allocator_v<T, Alloc> 以确定是否将分配器作为构造函数参数传递；因为这一检查失败，向量将 std::string 视为不感知分配器，并调用其默认构造函数，该构造函数内部使用全局的 new 和 delete，而不管向量的内存资源。
static_assert(!std::uses_allocator_v<std::string, std::pmr::polymorphic_allocator<char>>); // std::pmr::vector 不会将其分配器传递给 std::string
在优化金融风险计算引擎时，我们重构了一条热点路径，使用 std::pmr::monotonic_buffer_resource 以堆栈内存为后盾，以消除堆争用。我们声明了 std::pmr::vectorstd::string temp_symbols，希望所有临时符号名称都从单调缓冲区中获取，但性能分析显示 std::string 构造函数内出现了意外的 malloc 调用，表明内存资源完全被绕过。
我们考虑手动构造每个 std::string，将显式的 std::pmr::polymorphic_allocator 传递给其构造函数，但这要求将分配细节暴露给更高层的业务逻辑，并阻止使用方便的修饰符，如 emplace_back。另一种方法是创建一个继承自 std::string 的自定义字符串包装器，并接受一个多态分配器，但这违反了里氏替换原则，并在容器重新分配时引入了对象切片风险。最终，我们用 std::pmr::string（std::basic_string<char, std::char_traits<char>, std::pmr::polymorphic_allocator<char> 的别名）替换了 std::string，它本质上将 allocator_type 声明为多态变体。这使得向量能够通过 uses_allocator 协议自动传播其分配器，从而消除了热点路径中的所有堆分配，并将延迟从微秒减少到几百纳秒。
如果一个自定义类执行内部动态分配，如何使其与 std::pmr::polymorphic_allocator 兼容，单纯在其构造函数中接受一个分配器参数是不够的？
一个类必须明确宣传其对分配器的感知，方法是公开一个可从当前使用的分配器转换的公共 allocator_type 类型别名，或者提供一个构造函数，其第一个参数为 std::allocator_arg_t，第二个参数为分配器类型，并结合专门化 std::uses_allocator<ClassName, Alloc> 以派生自 std::true_type。没有这种明确的宣传， std::pmr::vector 会假定该类不感知分配器，并通过默认初始化构造它，导致任何内部分配绕过多态内存资源。
为什么 std::allocator_traits<std::pmr::polymorphic_allocator<T>>::rebind_alloc<U> 无法解决 std::pmr::vector 和 std::string 之间的不兼容性？
重新绑定产生了一个 std::pmr::polymorphic_allocator<U>，它仍与 std::allocator<U> 不兼容，因为它们是不同的具体类型，没有转换关系。 std::uses_allocator 机制要求元素的 allocator_type 必须与容器的分配器类型相同或可从中转换，而不仅仅是可重新绑定为不同的值类型；由于 std::string 硬编码为 std::allocator，重新绑定容器的分配器并不会改变元素的预期分配器类型。
使用 std::pmr::monotonic_buffer_resource 与 std::pmr::string 时出现的具体生命周期风险是什么，为什么检测比标准分配器更困难？
因为 std::pmr::polymorphic_allocator 是类型擦除的，并存储指向基类 std::pmr::memory_resource 的指针，编译器无法在编译时强制执行生命周期约束。当一个引用栈基 monotonic_buffer_resource 的 std::pmr::string 被移动或复制到一个生命周期更长的作用域时，指向内存资源的指针变得悬挂；与通常使用全局堆的 std::allocator 不同（总是有效），在缓冲区销毁后访问字符串将导致使用后释放。静态分析仪难以检测到这一点，因为虚拟的 do_allocate/do_deallocate 接口将底层资源的生命周期隐藏在类型系统之外。