std::ofstream多线程直接写会丢日志，因其write()和<<非原子操作，涉及缓冲区、文件指针、系统调用等多步，必然引发竞态导致截断、乱序、错位；用mutex串行保护虽可行但性能差，高并发下I/O成瓶颈且flush阻塞会拖垮整个系统。
为什么std::ofstream直接多线程写会丢日志
因为std::ofstream::write()和operator<<本身不是原子操作：内部涉及缓冲区管理、文件指针移动、系统调用等多步，线程A写到一半被抢占，线程B覆盖了文件偏移或冲垮了缓冲区，最终出现日志截断、乱序、甚至内容错位（比如“[INFO] user”和“login”被拆成两行，中间插进另一条日志）。这不是概率问题，是必然发生的竞态。
用std::mutex锁住整个write()调用够不够
够用，但不推荐在高并发场景下直接这么干——所有线程串行写磁盘，吞吐量卡死在单磁盘I/O上，CPU再强也白搭。更糟的是，如果某次flush()阻塞（比如磁盘临时忙），所有日志线程全被拖住，可能连业务逻辑都卡顿。
- 只适合QPS
- 务必把
std::mutex声明为static或全局唯一，别每个日志对象搞一个互斥量 - 避免在锁内做格式化（如
std::to_string()、std::chrono::system_clock::now()），防止锁持有时间不可控
推荐方案：无锁环形缓冲 + 单消费者线程刷盘
核心思路是把“日志生成”和“日志落盘”解耦：业务线程只往内存环形缓冲（如boost::lockfree::spsc_queue或自研atomic索引环）里快速投递日志字符串（或结构化数据），由单独一个I/O线程负责批量读取、合并、写文件。这样既规避了锁竞争，又控制了系统调用频次。
- 环形缓冲大小建议 ≥ 64KB，避免频繁满载自旋等待
- 投递前对日志字符串做栈上预分配（如
std::array<char, 512>），杜绝堆分配带来的malloc锁争用 - I/O线程用
writev()或std::ofstream::write()批量写，每次至少凑够4KB再刷盘 - 务必处理缓冲满时的策略：丢弃（加告警）、阻塞（影响业务）、或降级为同步写（需标记并记录）
别忽略std::endl和\n的区别
std::endl会强制触发flush()，在多线程+锁或环形缓冲场景下，它会让本该合并的多次写变成多次系统调用，性能雪崩。而\n只是换行符，是否刷新完全由缓冲策略控制。
立即学习“C++免费学习笔记（深入）”；
- 所有日志宏/函数里禁用
std::endl，统一用"\n" - 若需强制刷盘（如进程退出前），显式调用
log_queue.flush_to_disk()这类接口，而不是依赖std::endl - 检查第三方日志库（如
glog、spdlog）的默认行为——spdlog::daily_logger_mt默认就禁用自动flush，但glog的LOG(INFO)在某些版本里会隐式flush
/dev/shm临时文件），否则再好的原子性设计也会在运维现场崩掉。 
