ofstream追加写入必须用std::ios::app标志，其他方式如ate或seekp均不可靠；多线程需手动加锁；写入前须检查is_open()；避免endl频繁刷盘，推荐' '和缓冲优化。
ofstream 构造时必须指定 std::ios::app 标志
不加标志默认覆盖写入，哪怕文件已存在。追加模式不是靠“打开后 seek 到末尾”实现的，而是由操作系统在每次 write 前自动定位到文件末尾——这个行为只在 std::ios::app 下保证可靠。
常见错误是误用 std::ios::ate（打开即定位到末尾），但它不改变后续写入位置：后续 write 仍从当前位置开始，可能覆盖原有内容。
-
std::ofstream log("app.log", std::ios::app);✅ 正确 -
std::ofstream log("app.log", std::ios::out | std::ios::ate);❌ 错误，不是追加 -
std::ofstream log("app.log", std::ios::out); log.seekp(0, std::ios::end);❌ 不可靠，多线程/多进程下极易出错
多线程写日志必须自己加锁，ofstream 本身不线程安全
ofstream 的 operator<< 和 write() 都不是原子操作。即使只用一个全局 ofstream 对象，多个线程同时调用也会导致日志行混杂、截断甚至崩溃。
典型现象：一行日志被拆成两段，中间插进另一条日志；或某次写入完全丢失。
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用
std::mutex包裹每次写入操作（推荐） - 避免在构造
ofstream时传入std::ios::ate或手动seekp，那会干扰app模式的行为 - 不要复用已关闭的
ofstream对象再以app模式 reopen：需先close()，再用新构造函数重新打开
追加模式下 open() 失败通常是因为权限或路径问题
std::ios::app 要求文件可写，且父目录存在。如果路径中某级目录不存在，open() 会静默失败（is_open() 返回 false），不会自动创建目录。
错误示例：std::ofstream log("/var/log/myapp/app.log", std::ios::app); —— 若 /var/log/myapp/ 不存在，写入失败且无提示。
- 写入前务必检查
log.is_open()，否则所有<<操作都静默丢弃 - 目录创建需单独处理，例如用
std::filesystem::create_directories()（C++17） - Windows 下注意路径分隔符，
"C:\logs\app.log"或R"(C:logspp.log)"
频繁小写入性能差，建议配合 std::ostream::rdbuf()->pubsetbuf() 或缓冲写入
每次 << 都触发一次系统调用，在高频率日志场景下开销显著。虽然 ofstream 默认带缓冲，但小量写入仍易频繁刷盘。
更实用的做法是：攒几条日志再一次性写入，或手动设置更大缓冲区。
- 启用全缓冲：
log.rdbuf()->pubsetbuf(buffer, sizeof(buffer));（需在open()后、首次写入前调用） - 避免在循环内反复构造/析构
ofstream：打开一次，长期持有（注意线程安全） -
log << "msg" << std::endl;中的std::endl会强制刷新，改用' '减少刷盘次数
std::ios::app 模式下，seekp 调用会被忽略，且任何对写位置的显式控制都会破坏追加语义——它就该老老实实只做一件事：往末尾添。 
