std::deque采用分段连续内存布局，由多个固定大小的连续chunk组成，chunk间不相邻；其迭代器为随机访问但非裸指针，不支持跨chunk指针算术与c数组兼容操作，适用于高频头尾操作场景。
std::deque 的内存不是连续的，但也不是完全离散的
它用的是分段连续（segmented contiguous）机制：内部由多个固定大小的缓冲区（chunks）组成，每个 chunk 内存是连续的，但 chunk 之间在堆上随机分配，彼此不保证地址相邻。
这意味着 &dq[0] 和 &dq[1] 可能地址差 4 字节（正常），但 &dq[n-1] 和 &dq[n] 却可能跳转几百字节——不是因为“越界”，而是换 chunk 了。
- 不能对
std::deque进行指针算术跨元素取址（比如&dq[0] + 5不等价于&dq[5]，虽结果常碰巧对，但标准不保证） - 无法把
deque::data()当作 C 风格数组用——std::deque根本没有data()成员函数（C++20 之前） -
std::deque::iterator是随机访问迭代器，但底层靠跳 chunk + 偏移计算，不是简单指针加减
为什么 deque 不用单块连续内存？
连续分配（如 std::vector）在头插/头删时要整体搬移，O(n) 开销；而 std::deque 把两端操作压到 O(1) 平摊，代价就是放弃全局连续性。
它的典型实现（如 libstdc++、libc++）用中控数组（map array）记录各 chunk 地址，类似二级索引：下标 i 先算出 chunk 编号和 chunk 内偏移，再查中控数组得 chunk 起始地址，最后加偏移取值。
立即学习“C++免费学习笔记（深入）”；
- chunk 大小通常是编译期常量（如 512 字节或 64 个元素），与元素类型大小有关，不可配置
- 中控数组本身也会动态扩容，但频率远低于 vector 的 realloc
- 所以 deque 的内存占用略高（中控数组 + 每个 chunk 的 malloc header + 可能的内部 padding）
哪些操作会暴露“非连续”特性？
最典型的坑是误用指针转换或依赖地址连续性的场景：
- 传
&dq[0]给期望T*且要求连续 N 个元素的 C 函数（如memcpy、glBufferData）——行为未定义，可能只拷前半段或崩溃 - 用
std::memcmp(&dq[0], &other[0], n * sizeof(T))比较两个 deque —— 若 n 跨 chunk 边界，结果不可靠 - 对 deque 迭代器做
static_cast<char>(reinterpret_cast<void>(it))</void></char>算地址差——别这么干，迭代器不是裸指针 - 用
std::span<t>(dq.begin(), dq.end())</t>（C++20）——编译失败，因为deque::iterator不满足 contiguous_iterator 概念
什么时候该选 deque 而不是 vector？
只有当你明确需要频繁在头部插入/删除，且无法接受 vector 的移动开销时，deque 才值得引入。
多数场景下，哪怕头插多几次，vector 配合 reserve() + 尾插 + 反转，或者改用 std::list（若真要高频中间插入），都比盲目用 deque 更可控。
- deque 的 cache 局部性比 vector 差：跨 chunk 访问容易触发多次 cache miss
- 调试时观察内存布局（如 gdb 的
x/100xb &dq[0]）会看到明显断层，不是 bug，是设计如此 - 如果只需要尾部高效，vector 更快更省；如果需要任意位置插入且不关心顺序，考虑
std::unordered_set或std::list
分段连续不是缺陷，是权衡。但这个权衡带来的限制，很容易被当成“差不多能用”而埋进生产代码里。
