std::ios::app 模式打开文件可直接追加写入，无需先读再写；必须在构造或 open() 时指定，该模式强制写入文件末尾并忽略 seekp()；文件不存在时自动创建；需手动添加换行符并注意缓冲区刷新。
用 std::ofstream 以 std::ios::app 模式打开文件
直接追加写入的核心是打开文件时指定追加模式，而不是先读再写再覆盖。C++ 标准库不提供“打开后切换到追加模式”的接口，必须在构造或 open() 时就明确。std::ios::app 会强制所有写操作定位到文件末尾，且忽略任何 seekp() 调用——这点容易被忽略。
-
std::ofstream file("log.txt", std::ios::app);是最简可靠方式；若省略std::ios::app，默认是覆盖模式（std::ios::out） - 不要混用
std::ios::in | std::ios::app：标准规定这种组合行为未定义，某些平台可能失败或静默忽略app - 如果文件不存在，
std::ios::app会自动创建它；无需预先检查或手动创建
追加写入时注意换行和缓冲区刷新
追加内容不会自动换行，如果每次写入都希望独占一行，得自己加 "\n"；另外，程序异常退出时未刷新的缓冲区内容可能丢失。
- 写入后调用
file 或 <code>file.flush();可确保立即落盘（尤其日志场景必需） -
std::endl等价于"\n" + flush，但频繁使用会影响性能；高频率写入建议用"\n"+ 定期flush() - 避免在循环内反复打开/关闭同一文件：开销大，且多进程下易因文件句柄竞争导致写入错位
多线程或多个进程同时追加的安全边界
C++ 标准库本身不保证多线程对同一 std::ofstream 对象的线程安全；更关键的是，多个进程用 std::ios::app 同时写一个文件，是否原子取决于操作系统和文件系统。
- Linux 下，单次
write()小于PIPE_BUF（通常 4096 字节）且用O_APPEND（std::ios::app底层通常映射为此标志）是原子的；超过则可能交错 - Windows 的
CreateFile()配合FILE_APPEND_DATA权限也提供类似保障，但 C++ 标准流封装层不暴露这些细节 - 真正需要并发安全追加（如多进程日志），应改用带文件锁的方案（如
flock()）或专用日志库，而非依赖std::ios::app
常见错误：误以为 seekp(0, std::ios::end) 等价于 app 模式
有人尝试先用 out 模式打开，再 seekp(0, std::ios::end)，然后写入——这在多数情况下看似有效，但有隐患。
立即学习“C++免费学习笔记（深入）”；
- 两次操作之间存在竞态窗口：其他进程可能已向末尾写入，你的
seekp定位就失效了 - 某些文件系统或挂载选项（如 NFS）下，
seekp+write不是原子操作，而O_APPEND是内核级保障 - 如果文件被截断（
truncate()）或重命名，seekp的位置会错乱；app模式始终写入当前逻辑末尾
追加写入的可靠性不在于“找到末尾”，而在于“让内核保证写入末尾”——所以别绕开 std::ios::app。
