加了std::mutex仍乱序，是因为只锁operator<<而未包裹格式化、write()和flush()全过程；正确做法是将完整日志字符串拼接后，在同一lock_guard内完成写入与flush。
直接用 std::ofstream 多线程并发写同一个文件，必然乱序、丢数据、甚至崩溃——这不是 bug，是标准库设计使然。
为什么加了 std::mutex 还是乱序
锁没包住完整语义：常见错误是只锁 log ，但没锁住换行、时间戳拼接或 <code>flush()。比如两行写法：
loglog
中间没锁，其他线程的日志会插进来。正确做法是把整条逻辑行拼好再写，或整个表达式（含格式化+换行+flush）包进 std::lock_guard 作用域。
另一个坑是：多个线程各自 open() 同一个文件（哪怕都用 std::ios::app），在 Windows 上可能因文件被占用而失败；在 Linux 虽能打开，但内核不保证 write(2) 的原子性，仍可能截断或覆盖。
立即学习“C++免费学习笔记（深入）”；
单写线程 + 无锁队列（推荐默认方案）
所有工作线程把日志内容 push 到一个无锁队列（如 moodycamel::ConcurrentQueue），由唯一后台线程 pop 并批量写入文件。优势明显：
- 完全避免锁争用，吞吐高
- 写入顺序严格等于入队顺序
- 可控制 flush 频率（如每 10 条或每 10ms 一次），平衡延迟与性能
- 天然支持异步落盘，不阻塞业务线程
注意：队列元素应是已格式化好的 std::string 或 std::vector<char>，别把耗时操作（如 JSON 序列化）放进队列 push 前的临界区。
用 std::atomic_flag 自旋锁做轻量追加（仅限简单场景）
如果只是多线程往文件末尾追加固定格式短文本（如“[INFO] xxx\n”），且不强求绝对顺序，可用 std::atomic_flag 替代互斥锁：
std::atomic_flag file_lock = ATOMIC_FLAG_INIT;
// 写入前：
while(file_lock.test_and_set(std::memory_order_acquire)) {
std::this_thread::yield();
}
// 打开文件（O_APPEND）、write、close
file_lock.clear(std::memory_order_release);
关键点：
- 必须用
O_APPEND标志打开文件（std::ofstream不支持，得用 POSIXopen()） -
write(2)在O_APPEND下是原子的（内核保证 seek+write 一体） - 不能用于大块数据或需要格式化/缓冲的场景，否则自旋开销反超互斥锁
真正容易被忽略的点
不是“能不能写进去”，而是“谁在什么时候以什么顺序写进去”。std::ofstream 本身不提供跨线程同步语义，任何依赖它内部状态（如缓冲区位置、seekp）的并发访问都是未定义行为。即使加锁，若没统一管理文件句柄生命周期（比如多个线程反复 open/close 同一路径），仍可能触发系统级冲突。最稳的路径，永远是让写入变成单线程任务——要么靠锁串行化，要么靠队列解耦。
