queue 默认底层容器是 deque 而非 list，因 deque 头尾操作 O(1) 且缓存友好；emplace 优于 push，pop 不返回值，需先 front() 再 pop()；无迭代器，不支持遍历查找；非线程安全，多线程需外加锁或专用无锁队列。
queue 默认用 deque 作底层容器，不是 list
很多人以为 queue 是基于 list 实现的，其实标准库默认用的是 deque。这是因为 deque 在头尾插入/删除都是 O(1)，而 list 虽然也支持，但缓存局部性差、内存开销大。除非你显式指定，否则 queue<int></int> 等价于 queue<int deque>></int>。
实操建议：
- 不要手动换底层容器，除非你明确需要
list的迭代器稳定性（比如频繁在中间插入）——但这时你大概率不该用queue - 若真要换，写成
queue<int list>></int>，注意第二个模板参数是容器类型，不是元素类型 -
deque对小对象友好，但对大对象（如含动态分配成员的类），拷贝构造开销可能明显，考虑用unique_ptr存指针
push/emplace/pop 三者行为差异必须分清
push 总是拷贝或移动入队；emplace 在队列内部直接构造对象，省一次构造+移动；pop 只删不返值——这是新手最常踩的坑：调 front() 后立刻 pop() 是安全的，但反过来先 pop() 再取 front() 就是未定义行为。
常见错误现象：queue 看似“空了”，但调 front() 没报错却返回垃圾值——其实是没检查 empty() 就访问。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 入队优先用
emplace()，尤其对象构造成本高时（如含字符串、vector 的结构体） - 出队固定套路：
if (!q.empty()) { auto x = q.front(); q.pop(); /* use x */ } - 别写
q.pop(); auto x = q.front();——pop()不返回值，且之后front()可能越界
queue 没有迭代器，不能遍历也不能查找
queue 是容器适配器，接口被严格限制为 FIFO：只有 front()、back()、push()、pop()、size()、empty()。它故意不提供 begin()/end()，也不支持下标访问或查找。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
使用场景：当你需要 BFS、任务调度、缓冲区等纯顺序消费逻辑时，queue 刚好够用；但一旦你需要“看一眼队列里有没有某个值”“跳过前 N 个”“按条件过滤”，它就不是合适工具。
实操建议：
- 需要遍历？改用
deque或vector，自己维护头尾索引 - 需要查找？要么额外维护一个
unordered_set同步增删，要么换priority_queue（如果关心优先级）或自定义结构 - 调试时想看内容？只能靠循环
pop+push临时导出，或改用deque临时替代
多线程环境下 queue 不是线程安全的
标准 queue 所有成员函数都不带同步机制。两个线程同时 push 可能破坏内部状态，一个线程 push 另一个 pop 也可能导致 front() 返回无效引用。
性能影响：加锁本身不重，但锁粒度决定吞吐。粗粒度锁（整个 queue 一把锁）会成为瓶颈；细粒度（如只锁 pop 操作）需配合条件变量防忙等。
实操建议：
- 别自己封装“线程安全 queue”，容易漏边界（如 empty() 和 front() 之间被 pop）
- 用现成方案：
std::queue+ 外层std::mutex+std::condition_variable组合，或直接上boost::lockfree::queue（无锁，但要求元素 trivially copyable） - 若只是生产者-消费者模型，考虑用
std::concurrent_queue（C++20 TS 中的std::experimental::erased类型已废弃，实际项目中仍推荐自己封装或用第三方）
真正麻烦的从来不是“怎么把元素塞进去”，而是“怎么确保 pop 时不崩溃”“怎么让多个线程不踩同一块内存”“怎么在不出队的情况下知道队列状态”。这些点不写进代码注释，运行时也不会报错，只会某天凌晨三点在生产环境悄悄崩掉。
