std::ofstream本身非线程安全，需用std::mutex保护完整写入操作；锁粒度不足或作用域错误会导致内容错乱，应将整个写入表达式（含格式化与flush）置于lock_guard内。
写文件时内容错乱，std::mutex 锁不住？
不是锁没用，是锁的粒度或作用域错了。常见现象是：多个线程调用同一个 std::ofstream 对象的 operator<<，即使加了 std::mutex，输出仍交织——因为 operator<< 内部可能分多步写入（如格式化、缓冲区刷写），而锁只包住了开头那一下，中间被其他线程插进来。
- 必须把「打开文件 + 写入 + 关闭」或「单次完整写入动作」整个包在
lock_guard里，不能只锁<<前半句 - 不要在类成员函数里只锁
this->file << data;，而应确保file是所有线程共享的同一对象，且锁对象也是共享的（比如mutable std::mutex mtx;） - 避免在锁内做耗时操作（如拼接大字符串、JSON 序列化），否则会拖慢其他线程；先算好内容，再进锁写
std::ofstream 能否跨线程复用？
能，但必须配合外部同步；它本身不是线程安全的。C++ 标准明确说：多个线程同时访问同一 std::ofstream 实例，且至少一个在修改状态（比如写、seekp），是未定义行为。
- 推荐方式：全局单例
std::ofstream+ 全局std::mutex，每次写前lock_guard包住整个<<表达式 - 不推荐方式：每个线程自己
open()同一文件——会导致覆盖、截断或系统级错误（尤其 Windows 上文件可能被拒绝访问） - 注意
std::ofstream的缓冲行为：flush()不等于立即落盘，加std::ios::unitbuf或手动sync_with_stdio(false)没用；真要强一致性，得用fsync()（POSIX）或FlushFileBuffers()（Windows），但这代价大，一般日志场景不需要
为什么用了 std::mutex 还出现“部分写入”或“空行”？
典型原因是写入内容含换行符，但锁没覆盖到完整逻辑行；或者多个 << 调用被拆开，中间穿插了别的线程输出。
- 例如：
log << "[" << now() << "] ";和log << msg << "\n";分两行写，中间没锁 → 其他线程的输出会挤进去 - 正确做法：拼成一整条再写，或用 RAII 锁包裹全部操作：
std::lock_guard<std::mutex> lk(mtx); log << "[" << now() << "] " << msg << "\n"; log.flush(); // 可选，控制缓冲
- 别依赖
std::endl：它等价于<< '\n' << flush，flush 在锁内没问题，但频繁 flush 伤性能；日常用"\n"更稳
比 std::mutex 更轻量的替代方案？
如果只是追加日志，且不关心顺序严格性（只要不乱），可以用 std::atomic_flag 自旋锁，或更现实地：用无锁队列 + 单独日志线程。
立即学习“C++免费学习笔记（深入）”；
-
std::mutex在高并发写场景下会成为瓶颈，尤其短内容高频写；此时建议生产者-消费者模型：各线程往moodycamel::ConcurrentQueue或boost::lockfree::queue推字符串，由一个专用线程批量写文件 - 如果必须用文件锁（如防止多进程冲突），
flock()（Linux）或CreateFile(..., FILE_SHARE_NONE)（Windows）是进程级的，和std::mutex不冲突，但解决的是不同问题 - 别为了“轻量”改用
std::shared_mutex——写文件是纯写操作，读写锁没意义；std::shared_mutex适合读多写少的共享数据结构
真正容易被忽略的点：文件对象生命周期必须长于所有线程的使用时间。常见坑是把 std::ofstream 声明在某个函数里，又在线程里捕获引用——函数返回后文件已关闭，线程再写就崩溃或静默失败。
