环形队列中front/rear不能直接++因需模运算绕回，但负数取模可能为负，应使用(x%n+n)%n或条件判断；空满判据不能都用front==rear，须预留冗余位或引入size；new T[n]需手动析构避免泄漏；应使用unique_ptr和construct_at/destroy_at支持移动与异常安全。
为什么环形队列的 front 和 rear 不能直接用 ++i 后自增？
因为环形本质是数组首尾相连，下标必须始终落在 [0, capacity) 范围内。直接自增会越界，必须靠取模运算“绕回”。但取模有陷阱：C++ 中负数取模结果可能为负（如 -1 % 5 == -1），而数组下标不能为负。所以不能写 front = (front - 1) % capacity 这类表达式。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 统一用
(x % n + n) % n做安全取模，确保结果恒为非负 - 更高效的做法是用条件判断替代取模：当
rear == capacity - 1时置 0，否则++rear；但会增加分支，对高频操作有微小性能影响 - 推荐封装成内联辅助函数：
inline int mod(int x, int n) { return (x % n + n) % n; }
isFull() 和 isEmpty() 的判据为什么不能都用 front == rear？
这是环形队列最易错的设计点。单靠 front == rear 无法区分空和满——两者状态完全一致。必须预留一个“冗余槽位”或引入额外字段（如计数器 size）来打破歧义。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 主流做法是牺牲一个元素空间：队列最大有效容量为
capacity - 1，用(rear + 1) % capacity == front判满，用front == rear判空 - 若坚持物理满容（即
capacity个元素），必须加size成员变量，此时isFull()直接返回size == capacity，isEmpty()返回size == 0 - 前者节省内存、逻辑简洁；后者避免容量浪费，但多一次内存访问（读
size）
构造函数里用 new T[capacity] 分配元素，为什么必须配合 std::destroy 或手动析构？
因为 new T[n] 会调用 T 的默认构造函数初始化每个元素，而环形队列实际只在入队时才真正使用某位置的元素。如果用户类型 T 构造开销大（如含 std::string 或动态分配），提前全量构造就是浪费；更严重的是，出队后该位置对象仍处于“已构造未析构”状态，再次入队前若不显式析构，会造成资源泄漏或未定义行为。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 改用
std::allocator<t></t>+allocate()/construct()/destroy()手动控制生命周期 - 或者用
std::vector<:byte></:byte>配合std::construct_at和std::destroy_at（C++20） - 简单起见，也可要求
T必须是 trivially destructible，跳过析构步骤——但需文档明确标注限制
如何让 CircularQueue 支持移动语义和异常安全？
默认生成的拷贝/移动函数对原始指针或未管理内存会失效。若内部用裸指针存数组，移动后原对象仍持有已转移的资源，析构时双重释放。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::unique_ptr<t></t>管理底层数组，移动构造函数自动获得强异常安全保证 - 入队时用
std::construct_at(&data[rear], std::move(value))，避免不必要的拷贝 - 出队时先
std::destroy_at(&data[front])再更新front，确保异常发生时对象状态一致 - 所有修改状态的操作（如
push()）应在完成资源变更后再更新索引，防止中途异常导致索引错位
多数人卡在取模符号和空满判据上，这两个点一旦写错，调试时现象极其隐蔽：队列看似正常工作，但在边界容量下突然丢数据或死锁。动手前先手算三组 capacity=3 的推演（空→push×3→pop×2→push），比看十遍源码更管用。
