C++23为何要新增std::allocator<T>::allocate_at_least接口？

std::allocator<T>::allocate_at_least
该函数会分配count * sizeof(T)字节的未初始化存储空间，其中count是不小于n的未指定整数值；存储空间通过调用::operator new分配（可能会额外传入std::align_val_t参数），但该函数的调用时机和方式未作明确规定。
随后该函数会在分配的存储空间中创建类型为T[count]的数组并启动其生命周期，但不会启动数组内任何元素的生命周期。

新增allocate_at_least接口的核心原因是原有allocate的语义限制无法利用底层内存分配的天然特性，主要优化点如下： #

• 释放底层分配器的超额分配能力
  主流用户态内存分配器（jemalloc、tcmalloc、ptmalloc等）出于对齐、内存池块大小规整的设计，本身就存在超额分配行为：比如申请100字节内存，实际可能返回128字节的块。但原有的std::allocator<T>::allocate语义要求精确分配n个T元素的空间，就算底层实际分配了更多空间，上层也无法获取超额容量信息，这部分空间会被白白浪费。allocate_at_least会把实际分配的元素个数count返回给调用方，上层可以直接使用额外空间，无额外开销即可提升内存利用率。
• 优化动态容器的扩容逻辑
  对于std::vector这类需要动态扩容的容器，原有实现需要自己计算扩容系数（通常为1.5倍或2倍），再调用allocate申请对应大小的空间。使用allocate_at_least后，容器可以直接申请当前需要的最小容量，拿到实际分配的更大容量后直接复用，减少了扩容次数和内存拷贝开销，也让容器扩容逻辑更贴合系统的内存分配特性。
• 规避自定义实现的未定义行为
  如果要手动利用超额分配特性，需要直接调用::operator new接口，还要手动处理T[]数组的生命周期启动逻辑，稍有不慎就会触发未定义行为。allocate_at_least已经按照C++对象模型要求完成了数组生命周期的启动，开发者只需要负责初始化元素即可，无需承担UB风险。
• 明确区分分配语义
  原有allocate的语义是精确分配，适合对分配大小有严格要求的场景；allocate_at_least的语义是至少分配n个，适合可以接受更多空间的通用场景。两个接口各司其职，给标准库实现和开发者提供了更灵活的选择。

内容的提问来源于stack exchange，提问作者xmllmx