std::priority_queue非线程安全，多线程并发调用push/top/pop会引发未定义行为；必须用std::mutex保护全部入队/出队操作，且消费者需严格按top-pop-write顺序处理以保证优先级语义。
为什么 std::priority_queue 不能直接用于多线程日志写入
因为 std::priority_queue 本身不是线程安全的——任何对它的 push()、top()、pop() 调用，一旦被多个线程并发执行，就会触发未定义行为。你看到的日志乱序、崩溃或静默丢日志，八成是这里出的问题。
常见错误现象：double free、segmentation fault 在 push() 后立刻出现；日志级别高的消息（如 ERROR）反而比 INFO 晚写入磁盘。
- 必须用互斥体（
std::mutex）保护整个队列的入队/出队逻辑，不能只锁一部分 - 别用
std::priority_queue存裸指针——对象生命周期容易失控，优先用, Compare> std::shared_ptr - 如果日志量极大（比如每秒上万条），单纯加锁会成为瓶颈；这时得考虑无锁环形缓冲 + 批量消费，但复杂度陡增
怎么让日志线程真正“按优先级消费”，而不是只靠队列排序
队列排序只是第一步。真正决定写入顺序的，是消费者线程如何取数据——它必须每次从队列顶部取，且不能跳过、不能缓存、不能批量 pop 后再排序（那会破坏优先级语义）。
使用场景：服务端需要确保 FATAL 日志在进程退出前 100ms 内落盘，而低优日志可延迟。
- 消费者循环里必须用
while (!pq.empty()) { auto top = pq.top(); pq.pop(); write_to_file(top); }，不能改成for (int i = 0; i - 如果用了条件变量唤醒消费者，注意
wait()的谓词要检查!pq.empty()，否则可能虚假唤醒后调用top()崩溃 -
Compare函数对象必须严格满足严格弱序：比如按level（数值越小优先级越高）为主键，timestamp为次键，避免同级日志因比较不稳定导致std::priority_queue行为异常
std::ofstream 在高并发写入时为什么卡住或丢数据
默认情况下，std::ofstream 的 operator 是带缓冲的，但缓冲区属于单个流对象，多线程直接往同一个 std::ofstream 写，会竞争内部缓冲锁，甚至引发 std::ios_base::failure 异常（尤其在磁盘满或权限不足时）。
性能影响：实测在 NVMe 盘上，10 个线程共用一个 ofstream，吞吐比单线程还低 40%；而每个线程独占流对象又会导致文件损坏。
- 唯一安全做法：仅由**单一消费者线程**调用
ofstream::write()或，其他线程只负责生产并入队 - 务必在打开文件时设置
std::ios::app模式，否则多线程写同一文件偏移会冲突；但app模式下每次写都 seek 到末尾，所以别手动调用seekp() - 写入前检查
file.is_open() && file.good()，失败时需记录错误到备用路径（如/tmp/fallback.log），否则高优日志可能彻底消失
日志结构体设计不当会直接废掉优先级语义
如果 LogEntry 里只存 level 枚举和 message 字符串，看起来没问题，但实际运行中你会发现 WARNING 总比 ERROR 先写入——问题往往出在时间戳或内存布局上。
容易踩的坑：构造 LogEntry 时没把 std::chrono::steady_clock::now() 记录下来，而是等入队后才取时间，导致同一批日志时间戳一样，Compare 无法稳定排序。
-
LogEntry必须在创建瞬间（即调用LOG_ERROR("...")宏那一刻）就捕获完整上下文：精确时间戳、线程 ID、文件名/行号、格式化后的字符串（避免延迟格式化引入锁） - 别在
Compare里调用std::string::compare()或任何可能抛异常的函数——std::priority_queue不保证异常安全 - 如果日志要支持动态级别调整（如运行时降级
DEBUG），优先级判断必须在入队前完成，不能依赖消费者读取时再判断，否则队列里已堆积的低优日志无法被跳过
最麻烦的点其实是时间精度和跨线程可见性：用 std::chrono::system_clock 可能因系统时间跳变导致优先级反转，而 steady_clock 的 time_since_epoch().count() 又得小心溢出。这些细节不显眼，但一出问题就难定位。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
