多个线程并发写同一文件必然导致内容错乱、覆盖或崩溃，因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 或 <code>write() 调用本身。
- 必须在写入前加锁，写完后立刻解锁 —— 不要跨函数或跨作用域持有锁
- 推荐使用
std::lock_guard<:mutex></: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<:mutex> lock(file_mutex);
log_file
<h3>为什么不能只锁 <code>operator 而不锁 <code>flush()</code></code>
</h3>
<p>因为 <code>std::ofstream</code> 的 flush() 才真正触发系统调用。如果只锁
</p>
<p>更隐蔽的问题：<code>flush()</code> 本身不是原子的 —— 它内部可能多次调用 <code>write()</code>，而每次 <code>write()</code> 都依赖当前文件偏移量。没有锁保护，两次 flush 就可能交叉写。</p>
<ul>
<li>必须把
</li>
<li>如果用 <code>std::ios::out | std::ios::app</code> 模式打开，系统级 append 模式能保证每次 <code>write()</code> 原子追加，但仅限于单次 <code>write()</code> 调用；C++ 流的
</li>
<li>Linux 下可用 <code>O_APPEND</code> 标志（通过 <code>open()</code> 系统调用）获得内核级追加保障，但 C++ 标准流不暴露该控制权</li>
</ul>
<h3>高频写场景下怎么减少锁开销</h3>
<p>每条日志都锁一次，在千级 QPS 下会明显拖慢吞吐。这时应聚合写入，而非逐条锁。</p>
<ul>
<li>用无锁队列（如 <code>moodycamel::ConcurrentQueue</code>）暂存日志字符串，由单独的 writer 线程批量消费</li>
<li>每个工作线程本地缓冲（<code>std::string</code> 或 <code>std::vector<char></char></code>），定期（如每 10ms 或满 4KB）提交到共享队列</li>
<li>writer 线程持有一个独占 <code>std::mutex</code>，每次取一批日志，一次性写入文件并 <code>flush()</code>
</li>
<li>避免用 <code>std::stringstream</code> 在锁内拼接 —— 构造开销大，且可能触发内存分配（非 lock-free）</li>
</ul>
<p>这种模式下，互斥锁只在 writer 线程中短时间持有，工作线程几乎不阻塞。</p>
实际落地时最容易被忽略的是：**flush 的必要性与位置**。很多人以为 </:mutex>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
