std::queue + std::mutex 不能直接用作背压日志队列，因其无内置阻塞等待或丢弃策略，需手动加锁、检查容量、配合 condition_variable 实现 wait/notify 及 discard_oldest/newest 逻辑，否则易导致日志丢失、竞态或死锁。
为什么 std::queue + std::mutex 不能直接用作背压日志队列
因为裸队列本身不提供阻塞等待或丢弃策略，push() 和 pop() 都是即时操作。你得自己在调用前检查大小、加锁、判断是否满/空，再决定是 wait、throw 还是 return false——这些逻辑一旦漏掉，就变成无背压的“尽力而为”，日志丢失或线程狂旋都可能发生。
典型错误现象：std::queue::size() 在多线程下不可靠（非原子），两次调用之间可能已被其他线程修改；用 if (q.size() 看似安全，实则存在竞态窗口，仍可能 push 失败。
- 必须用
std::condition_variable配合std::unique_lock实现真正的等待/唤醒 - 丢弃策略不能只看当前 size，还要考虑「正在 pop 的消费者是否卡住」——否则高负载下队列永远清不完
-
std::queue底层是std::deque，频繁 push/pop 下内存分配开销明显，生产环境建议换boost::lockfree::queue或自建环形缓冲区
用 std::condition_variable 实现阻塞式背压（带超时）
核心不是“让队列变聪明”，而是让生产者在满时主动 wait，等消费者腾出空间。关键在于：wait 条件必须和 push/pop 在同一把锁下检查，且用 wait_for() 避免无限阻塞。
常见错误：在 wait() 前没加锁，或条件判断写成 while (q.size() >= cap) 却忘了锁保护 size —— 这会导致未定义行为甚至死锁。
立即学习“C++免费学习笔记（深入）”；
- 初始化时用
std::queue<logentry></logentry>+std::mutex+std::condition_variable - push 逻辑：加锁 → while (q.size() >= cap) cv.wait_for(lock, 100ms) → 若超时则返回 false 或丢弃 → 否则 push 并 notify_one
- pop 逻辑：加锁 → if (!q.empty()) { auto x = std::move(q.front()); q.pop(); cv.notify_one(); return x; } → 否则返回 nullopt
- 注意
cv.notify_one()必须在锁内调用，否则可能唤醒后立刻又陷入 wait
丢弃策略选 discard_oldest 还是 discard_newest？
取决于日志用途。调试日志通常要最新上下文，用 discard_newest（即满时不 push，直接 return）；审计日志强调完整性，宁可丢旧的也要保新的，就得用 discard_oldest —— 但这要求队列支持 O(1) 弹出头部（std::queue 满足），且不能用 std::vector 模拟。
容易踩的坑：有人用 std::deque 手动管理，但每次 pop_front() 后又 push_back()，没控制最大 size，结果内存持续上涨；或者用 std::list 导致 cache 不友好，吞吐骤降。
-
discard_newest：最简单，只需在 push 前检查 size，满则跳过 -
discard_oldest：需在 push 前判断 size ≥ cap，若是则先pop()再push()，确保 size 永远 ≤ cap - 别用
std::vector::erase(begin())做 discard_oldest —— O(n) 移动开销太大
boost::lockfree::queue 能替代手写背压吗？
不能直接替代。它天生无阻塞、无等待、无丢弃回调，push() 返回 bool 表示是否成功，但不会告诉你“为什么失败”（满？内存不足？），更不会自动丢旧或等空位。你得在外面包一层策略逻辑，反而比手写 std::mutex + cv 更难控制语义。
性能上它确实快，但前提是：你的丢弃/阻塞策略足够简单，且能容忍“失败即丢弃”这种粗粒度行为。一旦需要超时等待、优先级日志、或按模块限流，它就退化成普通容器，还得加锁兜底。
- 适合场景：高吞吐、低延迟、允许少量丢失（如指标打点）
- 不适合场景：审计日志、错误链路追踪、需严格顺序和背压响应的系统日志
- 若真要用，务必配合
boost::lockfree::queue::is_lock_free()检查是否真的 lock-free，某些平台（如 Windows MSVC）可能 fallback 到 mutex 版本
真正麻烦的从来不是“怎么让日志进队列”，而是消费者线程挂了、磁盘满了、格式化慢了导致消费速度波动——这些都会让背压逻辑从“可控等待”变成“全局阻塞”。所以队列只是第一道阀，后面得配健康检查、异步刷盘、以及明确的失败降级路径。
