std::deque 底层采用分段连续缓冲区（map+chunk）实现，非单块循环数组；支持O(1)均摊头尾操作，迭代器仅在对应chunk销毁时失效，随机访问需通过map计算索引与偏移。
deque 的底层不是循环数组，别按 vector 想
很多人一看到 deque 就默认它是“带两端插入的 vector”，结果手写时死磕一块连续内存 + 头尾指针 + 模运算，最后发现 push_front 性能崩了、迭代器失效逻辑对不上——根本原因在于：标准 std::deque 通常用**分段连续缓冲区（map + chunk）**实现，不是单块内存。它牺牲一点缓存局部性，换来了 O(1) 均摊的头尾插入/删除，且迭代器只在对应 chunk 满/空时才失效。
实操建议：
- 不要试图用
std::vector+memmove模拟 ——push_front会触发整段搬移，退化成 O(n) - 若真要手写简化版，优先考虑固定大小的 chunk（如 512 字节），用
std::vector<:unique_ptr>> </:unique_ptr>管理 chunk 列表，再配一个map（即std::vector<t></t>）存各 chunk 首地址 - 注意：
operator[]必须通过 map 算出 chunk 索引和 chunk 内偏移，不能直接算地址 —— 这是和vector最关键的差异点
迭代器失效规则比 vector 复杂得多
std::deque 迭代器只在对应 chunk 被销毁时才失效（比如 pop_front 刚好清空第一个 chunk），而 vector 是“只要 realloc 就全废”。但新手常误判这点，以为“没重新分配内存就安全”，结果在多线程或嵌套操作中踩坑。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 循环中用
for (auto it = dq.begin(); it != dq.end(); ++it)同时调dq.pop_front()—— 表面看没越界，但某次 pop 可能释放了 it 所在 chunk，后续 ++it 访问野指针 - 把
deque::iterator存进容器（如std::set）后长期持有，期间 deque 发生多次头尾操作 —— 迭代器可能已悬空，但编译器不报错
使用场景提醒：适合频繁头尾增删、且迭代范围明确（如 BFS 队列）；不适合需要长期持有迭代器或随机访问频率远高于增删的场景。
reserve() 和 shrink_to_fit() 在 deque 上基本没用
std::deque::reserve() 标准里压根没定义，所有主流实现（libstdc++、libc++）都直接忽略它；shrink_to_fit() 也仅在 C++11 后可选支持，且多数实现不收缩 map 或空闲 chunk，只是清掉末尾空 chunk。
参数差异与影响：
- 传给
deque构造函数的 size 参数（如deque<int>(100)</int>）只预分配前几个 chunk，不会像vector(100)那样占满 100 个元素空间 - 想控制内存布局？只能靠调整编译器宏（如 libstdc++ 的
_GLIBCXX_DEQUE_BUF_SIZE），运行时不可改 - 性能提示：频繁小对象 push_back/push_front 时，chunk 切分反而比 vector 更省内存碎片；但遍历速度通常慢 10%~30%，因 cache miss 多
手写 deque 时最容易漏掉的边界：迭代器的 operator-
标准 deque 迭代器必须支持 it1 - it2 返回 difference_type，这要求你得把“跨 chunk 距离”算清楚。很多手写版本只实现了 ++/-- 和 *，一到 std::distance 或 std::sort 就崩溃。
实操要点：
- 每个迭代器实例需携带三个字段：
chunk_idx（在 map 中下标）、offset（chunk 内偏移）、指向 map 的原始指针（用于计算总跨度） -
operator-必须遍历 [it2, it1) 跨过的 chunk 数，再加首尾 offset 差 —— 不能只靠指针减法 - 测试用例一定要覆盖：跨 0 个 chunk、跨 1 个、跨多个，以及 it1
真正难的不是结构，是让所有 STL 算法（尤其是 std::lower_bound 这类依赖随机访问的）不崩 —— 这意味着 operator+、operator-、
