多个线程并发写同一文件必然导致内容错乱、覆盖或崩溃，因std::ofstream非线程安全且lseek+write非原子；须用std::mutex全程保护打开、写入、flush操作，推荐std::lock_guard自动管理。
多个线程同时写文件会出什么问题
直接写同一个 std::ofstream 对象，或者多个线程各自打开同一路径的文件并写入，大概率导致内容错乱、覆盖、截断甚至崩溃。这不是“偶尔出错”，而是标准 I/O 缓冲、系统调用原子性、文件偏移量竞争共同作用下的确定性行为。
典型现象包括：write() interrupted 错误（尤其在 Linux 上）、文件末尾出现乱码、某次写入完全消失、std::ios_base::failure 异常抛出。
根本原因：C++ 标准库流对象（如 std::ofstream）本身不是线程安全的；底层系统调用（如 write()）对同一文件描述符并发写入时，lseek + write 组合不是原子操作，偏移量会互相踩踏。
用 std::mutex 保护写操作的正确姿势
最常用也最可控的方式是把「打开文件 → 写入 → 刷新」整个流程锁住，而不是只锁 operator<< 或 write() 调用本身。
立即学习“C++免费学习笔记（深入）”；
- 必须在写入前加锁，写完后立刻解锁 —— 不要跨函数或跨作用域持有锁
- 推荐使用
std::lock_guard<std::mutex>自动管理，避免异常导致死锁 - 不要把
std::ofstream对象作为全局变量共享；要么每个线程自己打开（需加锁控制打开时机），要么统一由主线程打开后传引用 + 外部锁 - 如果写入频率高、单次内容小，频繁锁/解锁会影响性能，可考虑缓冲聚合写入（见下一条）
示例：
std::mutex file_mutex;
std::ofstream log_file("app.log", std::ios::out | std::ios::app);
void safe_log(const std::string& msg) {
std::lock_guard<std::mutex> lock(file_mutex);
log_file << "[" << std::this_thread::get_id() << "] " << msg << "\n";
log_file.flush(); // 关键：确保立即落盘，否则缓冲区可能延迟
}
为什么不能只锁 operator<< 而不锁 flush()
因为 std::ofstream 的 flush() 才真正触发系统调用。如果只锁
更隐蔽的问题：flush() 本身不是原子的 —— 它内部可能多次调用 write()，而每次 write() 都依赖当前文件偏移量。没有锁保护，两次 flush 就可能交叉写。
- 必须把
- 如果用
std::ios::out | std::ios::app模式打开，系统级 append 模式能保证每次write()原子追加，但仅限于单次write()调用；C++ 流的 - Linux 下可用
O_APPEND标志（通过open()系统调用）获得内核级追加保障，但 C++ 标准流不暴露该控制权
高频写场景下怎么减少锁开销
每条日志都锁一次，在千级 QPS 下会明显拖慢吞吐。这时应聚合写入，而非逐条锁。
- 用无锁队列（如
moodycamel::ConcurrentQueue）暂存日志字符串，由单独的 writer 线程批量消费 - 每个工作线程本地缓冲（
std::string或std::vector<char>），定期（如每 10ms 或满 4KB）提交到共享队列 - writer 线程持有一个独占
std::mutex，每次取一批日志，一次性写入文件并flush() - 避免用
std::stringstream在锁内拼接 —— 构造开销大，且可能触发内存分配（非 lock-free）
这种模式下，互斥锁只在 writer 线程中短时间持有，工作线程几乎不阻塞。
实际落地时最容易被忽略的是：**flush 的必要性与位置**。很多人以为
