deque头尾插入删除比vector快，因其分段连续存储结构支持O(1)头尾操作；而vector头插或中间操作需O(n)搬移。但deque随机访问稍慢、内存开销大，仅在真需频繁头尾操作时选用。
deque 的插入和删除为什么比 vector 快？
因为 deque 底层是分段连续存储（类似多个小数组 + 中控数组），头尾插入/删除都是 O(1)；而 vector 尾插是 O(1)，但头插或中间删插要整体搬移元素，O(n)。
实际用的时候别默认“deque 一定比 vector 快”——它在随机访问上略慢（中控数组跳转多一次间接寻址），而且内存占用更高（管理开销）。只在真需要频繁头尾操作时才换。
- 头插用
push_front()，头删用pop_front()；尾插删对应push_back()/pop_back() - 不支持
insert(pos, value)在中间高效插入——这会退化成 O(n)，和vector一样慢 -
deque迭代器失效规则比vector宽松：只有对应位置被删时才失效，头尾操作不会让其他迭代器失效
迭代 deque 时修改内容会不会出问题？
可以安全读写已存在的元素，比如 d[i] = x 或 *it = y，只要不触发扩容或收缩（即不调用 push_front/push_back/pop_front/pop_back）。
常见错误是边遍历边增删：
立即学习“C++免费学习笔记（深入）”；
for (auto it = d.begin(); it != d.end(); ++it) {
if (*it % 2 == 0) d.pop_front(); // 危险！it 立刻失效，行为未定义
}
- 想边遍历边删，优先用索引 +
erase()，并注意返回值（erase()返回下一个有效迭代器） -
clear()后所有迭代器、引用、指针全部失效 - 用
at()而不是[]可获得越界检查（抛std::out_of_range），调试期建议打开
deque 和 vector 在内存布局上到底差在哪？
deque 不是一整块内存，而是由固定大小的缓冲区（buffer）组成，每个 buffer 存若干元素，再用中控数组（map）存这些 buffer 的地址。所以 &d[0] 和 &d[1] 地址不连续，甚至可能跨页。
这意味着：
- 不能把
deque当 C 风格数组传给需要T*的 API（比如 OpenGL 的glBufferData、C 库函数qsort）——必须先拷到vector或new T[n] -
data()成员函数在deque上不存在（C++20 也没加），别试图取首地址 - 初始化大容量
deque（如deque<int>(1000000)</int>）比同规模vector更慢，因为要分配+链接多个 buffer
哪些场景下 deque 反而不如 list？
当你要频繁在任意位置插入/删除，且不关心随机访问性能时，list（双向链表）更合适——它的 insert/erase 在任意迭代器位置都是 O(1)，而 deque 只有头尾是 O(1)。
但别为了“看起来更灵活”就滥用 list：它缓存不友好、内存碎片多、遍历慢三倍以上。多数真实场景里，如果操作集中在两端，deque 是更平衡的选择。
- 误判：以为
deque::erase(iterator)是 O(1) —— 实际是 O(min(distance(begin, it), distance(it, end)))，靠近哪端就按哪端算 - 真正需要中间高频修改？先确认是否能重构逻辑（比如延迟删除、用索引标记+批量清理）
- 跨线程共享
deque时，头尾操作仍需加锁——它不是线程安全的容器
最常被忽略的一点：deque 的构造函数对初始容量没意义。写 deque<int> d(1000)</int> 是创建含 1000 个 0 的 deque，不是预留空间——它没有 reserve() 接口。想控制 buffer 数量？基本做不到，也别试。
