deque适合频繁头部插入和尾部操作，但随机访问性能弱于vector；中间插入删除为O(n)且常数更大，不宜替代vector仅因push_front需求。
别用 deque 替代 vector 只为图它能 push_front；真要频繁头部插入+偶尔随机访问，deque 才值得上——否则 vector 的缓存局部性优势会被白白牺牲。
什么时候该用 push_front 而不是手写循环搬数据
当你确实需要在已有数据前“追加”新元素，且这个操作频次 ≥ 10³ 次/秒（比如滑动窗口左边界收缩、日志缓冲区前置写入），push_front 的 O(1) 才有意义。如果只是初始化时插几个头元素，直接用列表初始化 deque<int> dq = {x, y, z, ...}</int> 更干净。
-
push_front不触发内存拷贝，只更新中控器指针或分配新缓冲区（典型大小 512 元素/段） - 若头部缓冲区有空位，插入是纯指针偏移，比
vector.insert(begin(), x)移动全部元素快一个数量级 - 但若你误以为
push_front后还能高效erase(begin() + n)（n 非 0 或 size()-1），实际会退化成 O(n)，且常数比vector更大——因为要跨缓冲区计算地址
operator[] 真的和 vector 一样快吗
逻辑上是 O(1)，但硬件层面不如 vector：每次 operator[] 都要先查中控器找缓冲区地址，再算段内偏移。在密集遍历场景下，vector 的连续内存让 CPU 预取器工作更高效。
- 单次访问差异可忽略（纳秒级），但循环里反复
dq[i]时，deque的缓存未命中率明显上升 - 若你主要做随机读（比如按索引查配置项），且写操作极少，
vector+reserve仍是首选 -
at()带边界检查，开销略高于[]，调试期用它，发布版换[]
中间插入/删除为什么比 vector 还慢
因为 deque 的“分段连续”结构让中间操作更复杂：不仅要移动元素，还要处理缓冲区边界跨越。例如 insert(begin() + k)，k 刚好卡在缓冲区末尾时，得拆分、复制、重连指针。
立即学习“C++免费学习笔记（深入）”；
-
insert(iterator, x)和erase(iterator)在中间位置一律视为 O(n)，且实测常数因子比vector高 1.5–2 倍 - 没有
capacity()或reserve()，所以无法预分配“避免扩容”的技巧——它扩容不拷贝旧数据，但中间操作本身就不该是它的主战场 - 真要频繁改中间，要么换
list（放弃随机访问），要么用vector+ 标记删除（空间换时间）
最易被忽略的一点：deque 的内存布局导致它对 ASLR（地址空间布局随机化）更敏感，小对象大量 push_front 后，缓冲区可能散落在不同内存页，影响 TLB 命中率——这不是理论，是在真实服务压测中观测到的延迟毛刺来源。
