不能直接用std::deque而要手写，因其底层为分段连续内存、缓存不友好、无法保证物理连续；手写可控制内存布局、避免迭代器失效、适配实时系统，并通过预留head gap、双指针+size判空满、翻倍扩容等实现高效环形缓冲。
为什么不能直接用 std::deque 而要手写？
因为你要控制内存布局、避免迭代器失效、或对接嵌入式/实时系统——std::deque 底层是分段连续（通常为指针数组+固定大小缓冲区），头插/头删虽是 O(1)，但缓存不友好，且无法保证所有元素物理连续。手写动态数组 + 双指针方案，能实现真正连续存储 + 尾部追加高效 + 头部插入可控（通过预留空间或循环偏移）。
push_front 时怎么避免频繁搬移数据？
关键在预留头部空位（head gap）。初始化时分配 capacity 空间，但只把 front 指针设在中间偏右位置（比如 front = capacity / 2），back = front - 1。这样前后都有伸缩余地：
- 每次
push_front：先检查front > 0，若成立则--front并赋值；否则触发扩容 - 扩容逻辑不是简单
realloc，而是申请新数组，将旧数据从front到back（考虑循环 wrap）拷贝到新数组中央，重置front/back - 不要用
memmove直接搬整个旧数组——它不处理逻辑上“首尾相接”的情况；必须按实际有效区间逐段拷贝
如何判断队列为空或满？
用两个指针 front 和 back，配合一个 size 成员最稳妥。别用 “front == back 表示空” 这种经典循环队列 trick——它会让空和满状态无法区分，除非牺牲一个槽位。所以：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 空：
size == 0 - 满：
size == capacity -
front始终指向第一个有效元素（若非空），back指向最后一个有效元素（若非空） - 插入/删除后必须同步更新
size，而不是靠指针差值计算——因为数组是线性分配、非环形索引
扩容时 capacity 翻倍还是加固定值？
翻倍。这是摊还分析下 O(1) 均摊插入的必要条件。加固定值（如 +16）会导致多次插入后频繁 realloc，均摊复杂度退化为 O(n)。但注意两点：
- 首次分配别太小（比如至少 8），否则小对象反复扩容浪费 CPU
- 如果已知最大规模（如游戏帧队列固定 60 帧），可预分配避免运行时扩容——这时
capacity就是硬上限，无需动态增长 - 用
std::allocator<t></t>而非new T[capacity]，方便后续对接自定义内存池
头尾指针管理真正的难点不在增删逻辑，而在于扩容时的数据重排边界：当旧 front > back（即逻辑上跨过数组末尾），拷贝必须拆成两段——从 front 到数组尾，再从数组头到 back。漏掉这个 case，数据就静默错乱了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
