std::ofstream 以 std::ios::app 模式打开文件可确保内容严格追加到末尾，该模式忽略 seekp() 调用，每次写入前自动定位到 eof，是标准库中唯一可靠实现此行为的方式。
用 std::ofstream 以 std::ios::app 模式打开文件最可靠
直接在文件末尾追加内容，核心是让流跳过所有前置写入逻辑、强制定位到 EOF。C++ 标准库里唯一能保证这一点的，就是用 std::ofstream 构造时显式指定 std::ios::app 模式。这个模式会忽略任何 seekp() 调用，每次 operator 或 <code>write() 都自动先 seek 到末尾再写。
常见错误是只用 std::ios::out 加 std::ios::ate ——ate 只是打开时定位到末尾，但后续写入仍从当前位置开始，一旦中间有读或写操作，位置就偏了，根本不是“追加”。
-
std::ofstream file("log.txt", std::ios::app);—— 安全，推荐 -
std::ofstream file("log.txt", std::ios::out | std::ios::ate);—— 不安全，不等于追加 - 如果文件不存在，
std::ios::app会自动创建；如果存在，内容一定加在末尾，不会覆盖
追加字符串时注意换行符和编码一致性
追加内容常用于日志，但容易忽略换行问题：上一次写入没带 \n，下一次追加就粘连在一起；或者 Windows 下用 \r\n、Linux 下用 \n，跨平台读取混乱。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 写入前统一加
\n：file - 避免手动拼接
"\r\n"，除非明确要求 CRLF；依赖系统默认换行更稳妥 - 若文件原为 UTF-8 且含中文，确保程序输出也是 UTF-8（尤其在 Windows 控制台，默认可能是 GBK）；可用
std::locale::global(std::locale(""));尝试同步本地编码
多线程环境下不能直接共享同一个 std::ofstream 对象
多个线程共用一个 ofstream 实例并调用 operator，会导致写入错乱、内容重叠甚至崩溃——因为内部缓冲区和文件指针操作不是原子的。
- 每个线程应独立打开文件（用
std::ios::app），操作系统层面保证追加原子性（对多数现代文件系统，单次write()小于 PIPE_BUF 是原子的） - 若必须复用句柄，需加互斥锁（如
std::mutex），但会显著降低吞吐；不如让各线程自己开、写、关 - 注意频繁打开/关闭小文件的性能损耗；高频率场景建议用无锁环形缓冲 + 单独写线程
追加失败时检查 failbit 和磁盘空间
追加看似简单，但失败原因往往藏在细节里：ofstream 打开失败不抛异常（默认行为），operator 失败也静默，只有主动查状态才知道出错了。
- 写完后务必检查：
if (!file) { /* handle error */ } - 常见失败原因包括：磁盘满、权限不足（如只读文件系统）、路径中父目录不存在（
std::ios::app不会自动创建目录） - 不要依赖
file.is_open()判断写入是否成功——它只表示打开成功，不反映后续写入状态
追加本身逻辑极简，但真正难的是边界：并发、编码、错误恢复、路径有效性。别假设“打开了就能写”，每一步都值得验证。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
