为什么std::deque不具备constexpr友好性？

首先先纠正一个常见认知偏差：从C++20开始，constexpr求值上下文已经允许使用编译期临时堆内存——只要编译阶段结束前所有申请的内存都被正确释放、没有泄漏到运行时，new/delete在编译期是完全合法的，这也是std::vector能支持constexpr的规则基础。std::deque迟迟没有落地constexpr支持，核心原因和“是否使用堆内存”无关，主要是以下两点：

内存模型的实现复杂度差距极大 #

• std::vector的内部逻辑极其简单：本质只需要维护三个指针/偏移量，分别指向单块连续堆内存的起始位置、已使用元素的末尾位置、预留容量的末尾位置。所有内存操作都围绕这单块连续内存展开：扩容时一次性申请更大的连续块、搬运元素、一次性释放旧块，没有多余的分支状态和多层内存结构。给它加constexpr支持只需要把内存分配、元素构造/析构、释放的相关逻辑都标记为constexpr，几乎没有额外的逻辑验证成本，所以C++20就顺利落地了。
• std::deque是分段连续的双端队列，主流实现的结构是一层中控数组（map）挂多块固定大小的存储块（chunk），元素分散存储在不同chunk中，内存操作的复杂度比std::vector高一个量级：
  • 首尾插入元素时，如果对应端的chunk已满，需要单独申请新chunk挂到中控数组两端；如果中控数组本身存不下所有chunk指针，还要重新申请更大的中控数组、搬运所有chunk指针、释放旧中控数组
  • 中间位置插入删除时，需要移动多个chunk里的元素，极端场景下还要调整多个chunk的挂载位置、释放空置的chunk
  • 不同标准库的std::deque实现差异很大：部分实现会缓存首块的起始偏移、尾块的已用长度，还有的实现会给迭代器加额外的辅助校验状态，要把所有分支路径的内存操作都做到编译期无泄漏、无未定义行为，还要适配编译期的悬垂指针检测、常量求值合法性校验，验证和实现成本比std::vector高好几倍。

标准落地的优先级和进度问题 #

STL容器的constexpr支持一直按照「使用频率从高到低、实现难度从易到难」的顺序排期：

• std::array是栈上连续存储，和原生C数组的内存模型完全一致，C++17阶段就完成了constexpr支持
• std::vector是日常使用频率最高的动态容器，实现逻辑简单，C++20阶段完成支持
• 你提到的2019年《Making std::deque constexpr》只是初始提案，后续需要经过多轮标准委员会评审、语义修订，还要验证所有主流STL实现（libstdc++、libc++、MSVC STL）都能无歧义实现，不会碰到常量求值的规则盲区，整个流程周期很长。目前std::deque的constexpr支持已经进入C++26标准的落地排期，不存在原理上的不可实现性，只是因为实现成本高、优先级相对靠后，才暂时没有全量上线。

另外补充一点：并不是非连续存储容器天生不支持constexpr，后续std::list、std::set这类节点式容器的constexpr支持也在推进中，只是因为它们的内存结构更零散、指针关联更复杂，落地进度会比连续存储容器慢很多。

内容的提问来源于stack exchange，提问作者Richard H. Nguyen