推荐用 size 变量判空满，front/rear 更新为 (front + 1) % capacity 和 (rear + 1) % capacity；若不用 size，则需预留一空位，满条件为 (rear + 1) % capacity == front。
用数组实现循环队列时，front 和 rear 怎么更新才不越界
数组下标不会自动“绕回”，必须手动取模。但直接写 (index + 1) % capacity 仅适用于“空位判别法”——即牺牲一个元素空间来区分满/空。否则 front == rear 既可能表示空，也可能表示满，无法判断。
- 推荐做法：额外维护一个
size变量，而非依赖front/rear关系判断满/空；这样逻辑干净，front和rear始终只做取模移动：front = (front + 1) % capacity、rear = (rear + 1) % capacity - 如果坚持不用
size，必须预留一个空位：容量为n的数组最多存n-1个元素，满条件是(rear + 1) % capacity == front - 注意：
%在 C++ 中对负数结果为负（如-1 % 5 == -1），所以dequeue后更新front时，避免写成front = (front - 1) % capacity；应改用front = (front - 1 + capacity) % capacity
std::vector 能不能直接当循环队列底层数组用
可以，但不推荐——std::vector 的 capacity 不等于你期望的“队列容量”。它会动态扩容，导致 front 和 rear 下标失效；而且每次 push_back 或 erase 都可能触发内存重分配，破坏循环逻辑。
- 真正需要的是固定大小、不移动的连续内存块，
std::array<T, N>或裸T arr[N]更合适 - 若要用容器封装，建议继承或组合
std::array，而不是std::vector - 误用
vector的典型症状：某次enqueue后，之前入队的元素突然“消失”或读到乱值——其实是vector内部指针已变，但你的front/rear还在旧地址上算偏移
为什么 enqueue 失败时不报错，而是静默丢弃数据
因为多数手写循环队列把“满”当作业务逻辑的一部分，不是异常场景。C++ 没有强制要求容器必须抛异常，尤其嵌入式或实时系统中，异常开销不可接受。
- 检查是否满，应在调用方主动判断：
if (!q.is_full()) q.enqueue(x);，而不是依赖函数返回错误码 - 如果一定要反馈，让
enqueue返回bool（成功/失败），不要用void+ 异常 - 容易踩的坑：用
assert(q.size() < q.capacity())调试时没问题，但发布版assert被剔除，就变成静默失败——务必用运行时检查
内存对齐和缓存行对齐对性能的实际影响有多大
在高频入队/出队（比如网络包处理、音频缓冲）场景下，如果 front 和 rear 放在同一个缓存行（通常是 64 字节），会产生“伪共享（false sharing）”，两个线程分别修改它们会导致该缓存行反复在 CPU 核间同步，性能暴跌。
立即学习“C++免费学习笔记（深入）”；
- 解决方法：用填充字段隔离关键变量，例如在
front后加char pad1[64 - sizeof(size_t)]，再放rear - 但别过度优化：单线程场景、低频使用时，加 padding 反而浪费内存，且现代编译器可能自动重排结构体
- 验证是否真有影响？用
perf stat -e cache-misses对比加 padding 前后，看缓存未命中率是否显著下降
实际写的时候，最常被忽略的是：size 字段要不要原子化。多线程读写同一个队列时，哪怕只用 size 判断空满，也得是 std::atomic<size_t>，否则可能读到撕裂值——这不是理论风险，是真实会复现的偶发 crash。
