deque内存分段连续、vector连续，故vector随机访问更快且缓存友好；deque仅双端插入/删除稳定O(1)，适合滑动窗口等场景。
deque 和 vector 的内存布局差异直接决定性能表现
vector 是连续内存块，所有元素在物理地址上挨着；deque 是分段连续结构，底层通常由多个固定大小的数组（chunk）组成，通过指针数组索引。这意味着 vector 支持 O(1) 随机访问且缓存友好，而 deque 的随机访问虽标称 O(1)，但实际因跨 chunk 跳转，缓存命中率低，访问延迟更高。
常见误判是认为 deque「和 vector 一样快地支持下标」——实测中，对百万级元素做遍历或频繁 operator[]，vector 通常快 2–5 倍。
- 插入/删除首尾：deque 是真 O(1)（不触发内存重分配），vector 在头部插入是 O(n)
- 中间插入/删除：两者都是 O(n)，但 vector 需要移动后续所有元素，deque 只需调整局部 chunk 指针+少量元素搬移，略优但差距不大
- 扩容成本：vector 扩容可能触发整块内存拷贝（
realloc或新分配+复制），deque 扩容只需新增一个 chunk，无数据搬迁
什么情况下必须用 deque 而不是 vector
核心判断依据是「是否需要高频、稳定、无惧容量变化的双端插入/删除」。vector 无法高效支持 push_front() 或 pop_front() ——每次调用都得整体平移元素。
典型刚需场景包括：
立即学习“C++免费学习笔记（深入）”；
- 实现滑动窗口算法（如最大值队列），需在头尾动态增删，且窗口长度波动大 → 用
deque避免反复erase(begin()) - 任务调度队列，既要从队尾追加新任务（
push_back()），又要从队首取最高优先级任务（front()+pop_front()） - 解析器中的 token 缓冲区，预读若干 token 后可能回退（
push_front()多次再pop_front()） - 不能接受偶发长停顿的实时系统：vector 扩容时若触发大块内存拷贝，可能卡住几十微秒；deque 扩容无此风险
deque 的迭代器失效规则比 vector 更复杂
vector 迭代器只在扩容或 erase() 影响位置时失效；deque 的失效规则更隐蔽：
-
push_front()/push_back()：不导致已有迭代器失效（这是 deque 关键优势） -
insert()在中间位置：可能导致部分迭代器失效（尤其跨 chunk 边界操作时） -
erase()单个元素：仅该位置迭代器失效，其余有效 -
clear()或销毁 deque：所有迭代器当然失效
特别注意：deque 的 begin() 和 end() 返回的迭代器不是原生指针，而是封装类，其比较或算术运算开销略高于 vector。若代码大量做 it += 1000 类操作，vector 更合适。
别在 deque 上调用 capacity() 或 reserve()
deque 没有 capacity() 成员函数，也不支持 reserve() ——因为它的“容量”是分散管理的，无法像 vector 那样预分配一块连续空间。试图写 d.reserve(10000) 会编译失败。
如果你需要预估内存占用或减少 chunk 分配次数，只能靠经验设置构造时的初始大小（部分标准库支持 deque(size_t n) 构造），但效果有限。真正需要可预测内存行为的场景（如嵌入式、内存受限环境），vector + 手动管理 ring buffer 逻辑反而更可控。
另外，deque 的 size() 是 O(1)，但 max_size() 返回值往往远大于实际可用内存，不可信；而 vector 的 max_size() 更贴近真实限制。
