根本原因是多个线程同时调用同一 std::ofstream 对象的 operator<<，其内部缓冲区和文件位置指针未加同步，导致写入错位必然发生。
std::ofstream 多线程写入错位的根本原因
错位不是“偶尔乱”，而是必然现象：多个线程同时调用同一个 std::ofstream 对象的 operator，C++ 标准明确定义为未定义行为（UB）。它内部可能分步执行格式化、缓冲区填充、指针移动等操作，线程切换会卡在任意中间状态，导致日志内容被截断、穿插、甚至空行或乱码。
最简可行方案：全局 std::mutex + 完整表达式加锁
别只锁 log_file 前半句，必须把整个逻辑行包死——包括时间戳拼接、级别标记、换行符，且不能拆成多次 <code> 调用。
- 错误写法：
log_file 和 <code>log_file 分两行，中间无锁 → 必然穿插 - 正确写法：
{ std::lock_guard<:mutex> lk(mtx); log_file </:mutex> -
flush()放锁内是安全的，但高频调用伤性能；日常用"\n"即可，不依赖std::endl - 锁对象必须是所有线程共享的同一
std::mutex实例（如static std::mutex g_log_mtx;），不能每个线程自己 new 一个
为什么锁了还错？检查这三点
常见“加了锁却无效”的真实原因，不是锁没起作用，而是同步范围没对齐：
- 日志内容本身含换行符（比如
msg是从用户输入或网络读取的），而你只在末尾加"\n"→ 错位点就在那个内部换行处。解决：预处理msg，用std::replace(msg.begin(), msg.end(), '\n', ' ') - 多个 logger 实例各自持有一个
std::ofstream，但共用一个文件路径 → 操作系统层面文件截断/覆盖，不是线程竞争，是竞态资源。解决：确保全局唯一文件流对象 - 日志函数里做了耗时操作（如
std::to_string(std::this_thread::get_id())或 JSON 序列化）再进锁 → 锁持有时间过长，加剧排队，间接放大错觉。解决：先算好字符串，再进锁写
真正高并发场景该换异步模型
锁方案能止血，但治标不治本。当 QPS 过千、日志量上万条/秒时，std::mutex 会成为瓶颈，且无法规避 flush 延迟和崩溃丢日志问题。
立即学习“C++免费学习笔记（深入）”；
- 主线程只做：格式化日志字符串 → 原子入队（用
moodycamel::ConcurrentQueue或boost::lockfree::queue） - I/O 线程独占
std::ofstream：构造、写入、flush()、关闭全部在线程内完成，绝不跨线程传递流对象 - 必须实现优雅关闭协议：主线程发 stop 信号 → I/O 线程清空队列 → 关闭文件 →
join()，否则进程退出时队列未消费完就丢日志 - 别用
std::async：默认策略不可控，std::future析构可能阻塞，违背非阻塞初衷
错位问题表面是输出顺序，根子在资源归属和控制流边界。锁只是把混乱收敛到单点，而异步才是把生产者和消费者彻底解耦。别在锁粒度上反复调试，该切模型时就切。
