必须用 deque 而不是 vector 的场景是需要频繁在头部执行 push_front() 或 pop_front() 且无法接受 o(n) 开销时，因其分段连续结构可保证首尾操作均为 o(1)，而 vector 不支持 push_front()，insert(begin(), x) 会引发整体位移。
vector 适合随机访问和尾部增删；deque 支持高效首尾操作但不保证内存连续；list 仅在频繁中间插入/删除且无需随机访问时才值得选——多数场景下 vector 是默认起点，别过早优化。
什么时候必须用 deque 而不是 vector？
当你的逻辑需要在容器头部频繁执行 push_front() 或 pop_front()，且不能接受 vector 的 O(n) 时间开销时，deque 是合理选择。它内部由分段连续缓冲区组成，首尾操作均为 O(1)。
-
vector的push_front()不存在，强行模拟（如insert(begin(), x)）会触发所有已有元素位移，实测在 10⁵ 元素量级下耗时可达毫秒级 -
deque不支持[ ]随机访问的常数性能保障（虽然平均是 O(1)，但有常数因子开销），若代码中存在大量d[i]循环，实际可能比vector慢 2–3 倍 - 迭代器失效规则不同：
deque在首尾增删时不使其他迭代器失效，但vector在push_back()引发扩容时会使全部迭代器失效
list 真的比 vector 插入快吗？
仅当满足「在已知位置反复做 insert() / erase()，且不依赖下标、不遍历查找」时，list 的 O(1) 才成立。现实中多数“中间插入”其实隐含了 std::find 或循环定位，这部分 O(n) 开销远盖过插入本身的差异。
-
list每个节点额外占用指针空间（通常 16 字节/节点），小对象（如int）存储密度极低，cache miss 频繁，遍历速度常比vector慢 5–10 倍 -
list::splice()是少有的真正优势场景：把一个list的一段直接“切”到另一个list中，零拷贝、O(1)，vector无法等价实现 - C++11 后
vector支持emplace()和移动语义，构造开销大幅降低，进一步削弱list的“避免拷贝”理由
内存布局对性能的实际影响有多大？
是否连续直接影响 CPU cache 行利用率。现代 CPU 从内存取数据以 64 字节为单位加载进 cache line，vector 的紧凑布局让一次加载可覆盖多个元素；list 节点分散在堆上，每次访问都可能触发新内存页加载。
立即学习“C++免费学习笔记（深入）”；
- 测试对比：遍历 10⁶ 个
int，vector耗时约 2 ms，list常超 15 ms，差距主要来自 cache miss -
deque居中：单个缓冲区内连续，跨缓冲区跳转时有轻微 gap，但整体仍显著优于list - 若容器生命周期短、只构造一次并顺序读完（如函数内临时结果），内存连续性收益被放大；若长期驻留且随机访问稀疏，则差异缩小
std::vector<int> v;
v.reserve(1000); // 避免多次扩容，比 list 更易控制内存行为
for (int i = 0; i < 1000; ++i) {
v.emplace_back(i * 2);
}
// 连续内存 + 预分配 + emplace → 高效组合真正难判断的不是“哪个容器更快”，而是“你的访问模式是否被误判”。比如用 list 存日志事件，以为要频繁删除旧条目，结果发现 90% 操作是尾部追加+整批遍历——这时 vector 加上 erase(std::remove_if(...), end()) 反而更稳。
