std::scoped_allocator_adaptor仅在构造时将外层分配器注入支持allocator_arg_t协议的类型（如std::string），需同时满足模板参数为适配器类型且构造时传入其实例，否则退回到默认分配器。
std::scoped_allocator_adaptor 不是万能转发器，只在构造时起作用
它不改变已存在对象的分配器绑定，也不干预运行时的内存操作（比如 push_back 中元素的后续分配），只在容器或其元素被构造那一刻，把外层分配器“注入”到支持 std::allocator_arg_t 构造协议的类型中。
常见错误现象：容器里 std::string 仍走默认堆分配，即使外层用了 std::scoped_allocator_adaptor —— 很可能是因为你没用该适配器实例初始化容器，或者元素类型压根不接受分配器（如 std::pair<int std::string></int> 中的 int 不触发传播，而 std::string 部分又因构造方式不对没接收到）。
- 必须满足两个条件才生效：容器模板参数是
std::scoped_allocator_adaptor<...></...>类型，且构造时传入对应类型的实例（例如std::vector<:string myalloc> v(MyAlloc{});</:string>） -
std::string、std::vector、std::deque等标准容器/字符串类显式支持allocator_arg_t构造；int、std::pair、std::tuple等则不支持，不会自动转发 - 若需让
std::pair<:string std::string></:string>的两个成员都受控，得手动在emplace时传入分配器，或改用支持嵌套分配器的自定义类型
两层嵌套（如 vector）不需要手动写两层 scoped_allocator_adaptor
当你定义 using MyAlloc = std::scoped_allocator_adaptor<:pmr::polymorphic_allocator>>;</:pmr::polymorphic_allocator> 并用于 std::vector<:string myalloc></:string> 时，内层 std::string 自动获得一个由外层分配器 rebind 出来的 std::pmr::polymorphic_allocator<char></char> 实例 —— std::scoped_allocator_adaptor 内部已处理了这层推导。
你不需要、也不应该写成 std::scoped_allocator_adaptor<:scoped_allocator_adaptor>></:scoped_allocator_adaptor>。C++ 标准要求实现自动展开 inner allocator 链，只要外层适配器类型正确，第二层容器（如 std::string）构造时会拿到适配后的分配器视图。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 错误写法：
std::vector<:vector>, std::scoped_allocator_adaptor<:scoped_allocator_adaptor>>></:scoped_allocator_adaptor></:vector> - 正确写法：
std::vector<:vector>, MyAlloc></:vector>，内层std::vector<int></int>的分配器类型自动为MyAlloc::inner_allocator_type::template rebind_alloc<int></int> - C++17 起，
construct成员函数签名变严格：调用者必须显式传入std::allocator_arg和分配器对象，自己实现可分配类型时需注意
std::scoped_allocator_adaptor 构造容器时漏传实例，等于白配
这是最常踩的坑：模板参数对了，但容器是默认构造的，结果所有嵌套层级退回到 std::allocator。
例如：std::vector<:string myalloc> v;</:string> 这行代码完全无视 MyAlloc —— 因为默认构造不触发分配器传播逻辑，内层 std::string 仍用全局 new。
- ✅ 正确：
std::vector<:string myalloc> v(MyAlloc{std::pmr::pool_resource{}});</:string> - ❌ 错误：
std::vector<:string myalloc> v;</:string>（类型匹配但无实例，传播中断） - ❌ 错误：
std::vector<:string std::allocator>> v(MyAlloc{});</:string>（类型不匹配，适配器被忽略） - 若使用
std::pmr::vector或std::pmr::string，它们内部已集成scoped_allocator_adaptor行为，此时直接传std::pmr::polymorphic_allocator即可，无需额外包装
深层嵌套（如 vector>）依赖内层容器是否真正“感知分配器”
三层结构如 std::vector<:vector>, MyAlloc></:vector> 能否全链路受控，取决于中间层 std::vector<:string></:string> 是否在构造其元素（即每个 std::string）时，也通过 allocator_arg_t 转发——标准库实现保证了这一点，但前提是外层分配器适配器完整参与了整个构造链。
容易被忽略的是：一旦某一层容器被 move 构造或 copy 赋值，传播行为是否持续，取决于 propagate_on_container_copy_assignment 等 traits 设置。多数自定义分配器默认不传播，所以 move 后的容器可能丢失原始分配器上下文。
- move 操作后，目标容器的分配器可能仍是原分配器（如果
propagate_on_container_move_assignment::value == true），也可能被重置为默认值 - 拷贝构造/赋值更危险：若
propagate_on_container_copy_assignment::value == false（默认），则新容器继续用旧分配器，但其内层元素构造时仍会尝试从 outer 获取，可能失败或回退 - 调试建议：在自定义分配器中加日志，重载
allocate和construct，观察哪些调用没走预期路径
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
