deque 应优先用 push_back()/push_front() 和 pop_back()/pop_front() 进行首尾操作，避免 erase() 删除中间元素；调试时用 at() 替代 operator[] 以启用边界检查；其分段内存布局导致不支持连续访问、无法用于 std::sort 或 C 函数直接传参。
deque 的基本插入和删除操作怎么写才不踩坑
直接用 push_back() 和 push_front() 插入，用 pop_back() 和 pop_front() 删除，这是最安全的起点。但要注意：这些操作都是常数时间复杂度，可前提是不触发内存重分配；一旦内部缓冲区满，deque 会申请新块、复制指针数组，此时性能跳变——这不是 O(1)，而是摊还 O(1)，但单次可能卡顿。
常见错误是误以为 deque 支持像 vector 那样频繁用 operator[] 配合 erase() 删除中间元素：erase() 在 deque 中是线性时间，且会使迭代器大规模失效（不只是被删位置之后的迭代器，前后若干段都可能失效）。
- 避免对非首尾位置调用
erase()；真要删中间，考虑换成list或先标记再批量清理 - 不要保存长期有效的迭代器——哪怕只 push/pop 一次，原有迭代器也可能失效（标准未保证稳定性）
- 初始化时若已知大致规模，可用
deque<t>(n)</t>预留 n 个默认元素，比反复 push 快，但不会真正“预留容量”（deque 没有reserve()）
为什么 deque::at() 比 operator[] 更值得在调试中启用
at() 做边界检查，越界抛 std::out_of_range；而 operator[] 不检查，行为未定义——可能读到脏内存、崩溃，也可能“恰好”跑通，埋下难复现的 bug。
尤其在多线程场景下，一个线程刚 pop 完，另一线程还拿着旧 size 去 operator[] 访问，结果不可控。开发期建议全用 at()，上线前用 profile 确认热点再酌情换回 operator[]。
立即学习“C++免费学习笔记（深入）”；
- 调试构建中，可加宏定义统一替换：
#define deque_at(d, i) ((d).at(i)) -
at()开销极小（一条比较 + 分支），远小于一次 cache miss - 注意：
at()返回的是引用，修改它会直接影响容器内容
deque 和 vector 在内存布局上的根本差异影响了什么
deque 不是连续内存，而是分段缓冲区（通常固定大小的数组块）+ 指针数组管理；vector 是单一连续内存块。这意味着：
-
&a[0]对deque无效——不能取首元素地址来当 C 风格数组用 -
std::sort()不能直接用于 deque 迭代器范围（虽然语法通过，但性能极差，因随机访问实际是两级跳转） - 传递给 C 函数时，必须逐个拷贝，或改用
vector中转 - cache 友好性弱于
vector：跨块访问易造成多次 cache line 加载
什么时候该坚持用 deque，而不是换 vector 或 list
核心判断点只有两个：是否需要高频首尾增删 + 是否接受随机访问稍慢。如果只是偶尔在前面插一个元素，用 vector.insert(begin(), x) 更省心；如果大量中间插入/删除，list 更合适。
- 典型适用场景：滑动窗口算法、撤销栈（undo stack）、BFS 边界节点缓存
- 反例：存储日志行并按索引查第 N 条——用
vector更快更省内存 - 注意：C++20 起
std::span无法绑定 deque，因其不满足 contiguous_iterator 要求
deque 的设计权衡很明确：它不是 vector 的升级版，也不是 list 的替代品，而是为特定模式优化的独立容器。用错地方时，问题往往不是“报错”，而是“慢得不合理”且难以定位。
