必须用 std::ios::app 标志打开文件才能可靠追加；否则覆盖原内容或定位失效；需注意多进程安全、编码/换行、错误检查及平台差异。
用 std::ofstream 以追加模式打开文件，内容自动写到末尾
直接结论：必须用 std::ios::app 标志打开文件，否则即使调用 seekp(0, std::ios::end) 也大概率失败——因为默认是覆盖模式，open() 会清空文件或重定位不可靠。
常见错误现象：ofstream 构造后没指定模式，写入内容覆盖了原文件开头；或者用了 ios::ate 却误以为它等价于追加；又或者先 seekp() 再写，但中间有缓冲未刷新、或文件被其他进程锁住，导致写入位置错乱。
- 正确做法：构造时显式传入
std::ios::app，例如std::ofstream f("log.txt", std::ios::app); -
ios::app会强制所有写入都发生在当前文件末尾，无论是否调用seekp() - 不能和
ios::in同时使用（C++ 标准规定，app模式只支持输出） - 如果需要读+追加，得用
std::fstream并手动控制定位，但需谨慎处理缓冲与同步
ofstream 追加时中文乱码或换行异常？检查流的 locale 和换行符
Windows 下用 "\n" 写入，文件可能显示为单行（记事本不识别 LF），而 Linux/macOS 下若写入 "\r\n" 又会多出空行。这不是追加逻辑的问题，而是文本模式换行转换与 locale 设置共同作用的结果。
- 默认情况下，
ofstream在文本模式下会做平台相关换行转换（Windows →\r\n，其他 →\n） - 若写入 UTF-8 中文，确保程序启动时未意外更改全局 locale，例如避免调用
std::setlocale(LC_ALL, "")后又没配好环境 - 更稳妥的做法：显式设置流的 locale，如
f.imbue(std::locale::classic());（禁用本地化格式化） - 二进制模式可绕过换行转换，但需自己处理
\n→\r\n（仅当兼容旧工具时才考虑）
多个线程/进程同时追加？ios::app 不保证原子性
ios::app 确保每次 operator 或 write() 都从末尾开始，但它不等价于“系统级原子追加”。在多进程场景下（比如多个程序同时写同一个日志文件），仍可能出现内容交错。
立即学习“C++免费学习笔记（深入）”；
- Linux/macOS：内核对
open(..., O_APPEND)的单次write()是原子的，但 C++ 流的多次小写入（如先写字符串再写换行）会被拆成多个系统调用，不安全 - Windows：没有
O_APPEND对应语义，ios::app完全依赖运行库模拟，多进程下极易覆盖 - 真正安全的方案：用单个日志进程 + 命名管道 / socket 接收消息；或用文件锁（
flock()/LockFileEx()）包裹写入段 - 临时缓解：把每条日志拼成一行再一次性写入，减少系统调用次数
追加失败却没报错？记得检查 failbit 和磁盘空间
ofstream 默认不抛异常，写入失败（如磁盘满、权限不足、路径不存在）时，is_open() 仍返回 true，但后续操作会置位 failbit 或 badbit。
- 务必在每次关键写入后检查：
if (!f && f.fail()) { /* 处理错误 */ } -
fail()在格式化失败或写入被拒绝时触发；bad()表示底层流缓冲严重错误（如磁盘 I/O 故障） - 尤其注意：追加模式下若目录不存在，
ofstream构造会静默失败（is_open() == false），但不会报路径错误细节 - 建议初始化后立即验证：
if (!f.is_open()) { perror("ofstream open failed"); }
追加本身很简单，难的是跨平台行为差异、多实例并发、错误传播链路长——这些地方一旦忽略，问题往往延迟暴露，且难以复现。
