std::queue默认底层容器是std::deque，因其是适配器而非容器，故不支持随机访问或遍历；需FIFO时用它，需遍历时选vector/deque。
std::queue 默认底层容器为什么不能直接访问元素
因为 std::queue 是适配器（adapter），不是容器本身，它默认用 std::deque 封装，但屏蔽了迭代器和随机访问接口——这是设计使然，不是 bug。
常见错误现象：q[0] 报错 no operator []，或试图用 begin()/end() 遍历，结果编译失败。
使用场景：当你只需要 FIFO（先进先出）语义，比如 BFS 层序遍历、任务调度缓冲区，就该用 std::queue；如果需要遍历、查找、随机读取，请换用 std::vector 或 std::deque。
- 想看队首？用
q.front()，但必须确保!q.empty() - 想看队尾？用
q.back()，同样要判空 - 想“偷看”中间某个元素？不行——这不是
std::queue的职责，别硬改
push/emplace/pop 的关键区别在哪
push 总是拷贝或移动入队，emplace 则在队列内部原地构造对象，避免临时对象开销。但前提是你的类型支持就地构造（比如有对应参数的构造函数）。
立即学习“C++免费学习笔记（深入）”；
性能影响明显：对大对象（如 std::string、自定义类）或频繁入队场景，emplace 更高效；对 int、double 这类 trivial 类型，差别可忽略。
容易踩的坑：q.emplace(1, "hello") 要求队列元素类型有 T(int, const char*) 构造函数，否则编译失败，而 q.push(T(1, "hello")) 可能悄悄触发隐式转换或临时对象构造，掩盖问题。
- 安全写法：优先用
emplace，但确认构造参数匹配 - 调试时怀疑构造异常？加个
std::cout 到类构造函数里验证 -
pop()不返回值，只移除队首——别写成auto x = q.pop();，这会编译报错
如何安全地清空一个 std::queue
没有 clear() 成员函数——这是标准故意留的缺口，因为适配器不控制底层容器的清除逻辑，也不希望用户误以为清空是 O(1) 操作。
常见错误现象：循环 while (!q.empty()) q.pop(); 看似合理，但对某些底层容器（如基于链表的实现）可能有额外分配/释放开销；更糟的是，有人试图赋值 q = std::queue<int>{};</int>，虽可行但可读性差。
推荐做法：用交换技巧，利用移动语义做到真正高效：
std::queue<int>().swap(q);
这行代码创建一个空临时队列，和 q 交换内容，之后临时对象析构，q 归零。它在所有标准库实现上都是 O(1)，且不依赖底层容器类型。
- 别用
q = {}，C++11 起虽合法，但语义不如swap明确 - 多线程环境下清空前必须加锁，
swap本身不保证线程安全 - 如果队列元素含裸指针或需手动资源释放，清空前得自己处理，
swap不改变析构行为
queue 和 deque / priority_queue 混用时要注意什么
三者接口相似但语义完全不同：std::queue 是 FIFO，std::priority_queue 是最大堆（默认），std::deque 是双端队列，支持两端增删。
最容易被忽略的地方：std::priority_queue 的 top() 返回最大元素，不是最早插入的；而 std::queue::front() 才是“第一个进来”的那个。拿 BFS 代码误用 priority_queue，结果遍历顺序全乱。
兼容性陷阱：虽然 std::queue 和 std::priority_queue 都能指定底层容器（如都可用 std::vector），但它们的模板参数顺序不同，不能靠 typedef 简单互换。
- 别把
std::queue<t std::vector>></t>当作“更快的 queue”——std::vector不支持pop_front()，所以这个声明根本编译不过 -
std::deque是std::queue默认底层，也是唯一同时支持push_back和pop_front的标准容器，别强行换 - 调试时发现顺序不对？先检查你用的是
queue还是priority_queue，光看变量名容易看漏
