在C++中进行文件操作时，追加写入是一个常见需求，尤其是日志记录、数据采集合并等场景。如果直接用默认的写方式打开文件，原有内容往往会被截断清空，导致历史数据丢失。标准库中的fstream系列类通过开放模式标志提供了安全的追加能力，其中app模式是最直接也最容易误用的一种。理解它在底层文件指针行为上的约定，是写出稳定程序的前提。
app模式的基本用法与打开方式
在C++标准库中，std::ofstream和std::fstream都可以通过第二个参数指定打开模式。追加写入需要使用std::ios::app标志，它可以和std::ios::out组合，但即便不显式写out，以app方式打开输出流通常也隐含了输出意图。最关键的一点是，app模式要求每次输出操作前，文件位置指针都被强制移动到文件末尾，这意味着你无法用seekp把写入位置改到中间去覆盖某一段。
下面的代码展示了最基础的追加写入方式。我们先尝试打开一个不存在的文件，写入首行；随后再次以app模式打开同一文件，新内容会接在后面而不是覆盖。注意判断is_open或直接使用流对象作为布尔条件，能避免向未成功打开的流写入而导致静默失败。
#include <fstream>
#include <iostream>
int main() {
// 第一次写入，文件不存在则创建
std::ofstream fout("data.log", std::ios::app);
if (!fout) {
std::cerr << "无法打开文件" << std::endl;
return 1;
}
fout << "初始化日志第一行" << std::endl;
fout.close();
// 第二次以app模式打开，内容追加而非覆盖
std::ofstream fout2("data.log", std::ios::app);
if (fout2.is_open()) {
fout2 << "运行期追加的一条记录" << std::endl;
fout2.close();
}
return 0;
}
很多初学者会混淆std::ios::app与std::ios::ate。ate模式只是在打开时把指针定位到末尾，之后你可以自由seekp移动并覆盖；而app模式则在每次写之前重定位末尾，从语义上杜绝了覆盖。若你需要既能追加又偶尔定点修改，应该用ate并自己管理指针，但这在并发日志中风险较高，不如纯app简单可靠。
多模块与异常下的追加安全性
在实际项目中，文件往往由多个模块甚至多个线程写入。app模式的原子性依赖于操作系统层面的追加语义：在POSIX和Windows中，以O_APPEND或FILE_APPEND_DATA打开的文件，内核保证写操作发生在当前末尾，不受其他进程并发写的影响。因此用C++ fstream封装app模式，比自己先读长度再seek再写要安全得多，后者在多线程下极易出现内容交错或丢失。
当程序异常退出时，正确使用的app流若已析构或显式close，缓冲区会刷盘；但如果用std::endl频繁刷盘会影响性能，可用'n'配合定期flush。下面示例演示了一个简单的日志函数，它每次调用都以app模式打开、写入带时间戳的行并关闭，适合低频工具程序。对于高频服务，则建议长期持有流对象减少开关开销。
#include <fstream>
#include <string>
#include <chrono>
#include <ctime>
void append_log(const std::string& msg) {
std::ofstream out("service.log", std::ios::app);
if (!out) return;
auto now = std::chrono::system_clock::now();
std::time_t t = std::chrono::system_clock::to_time_t(now);
char buf[32];
std::strftime(buf, sizeof(buf), "%Y-%m-%d %H:%M:%S", std::localtime(&t));
out << buf << " " << msg << "n";
// 不强制flush，析构时刷盘
}
如果程序以写权限打开文件但忘记加app，在重复启动时std::ios::out单独使用会截断文件。有些开发者误以为fstream默认是追加，其实默认trunc行为会清空。因此封装一个强制app的辅助类很有必要，可以在构造函数里固定模式，避免团队成员误用。此外，在Windows上若文件被另一进程独占，open会失败，应当有重试或报错提示而不是忽略。
二进制追加与常见陷阱
除了文本日志，二进制数据如序列化包、采集到的原始字节流也常需要追加。此时应组合std::ios::app | std::ios::binary，防止文本模式在Windows下把n转成rn破坏结构。下面的例子把两个内存块依次追加进二进制文件，读取方只需按顺序解析长度前缀即可还原。
#include <fstream>
int main() {
int a = 12345;
double b = 3.14;
std::ofstream bio("pack.bin", std::ios::app | std::ios::binary);
if (bio) {
bio.write(reinterpret_cast<const char*>(&a), sizeof(a));
bio.write(reinterpret_cast<const char*>(&b), sizeof(b));
bio.close();
}
return 0;
}
一个典型陷阱是：用std::fstream同时读写并以app打开时，读操作的位置不受app约束，但一旦写就追尾。如果你先读后写，逻辑上容易以为写在了读的位置，实际却到了末尾。因此混合读写追加需求应拆成两个流，或者明确用ate加手动锁。另一个陷阱是缓冲区未满且程序崩溃，未flush的内容丢失，关键日志应适时flush或采用异步队列。
最后要注意文件路径中的反斜杠在C++字符串里必须转义，例如"C:\logs\app.log"，如果写成单斜杠会被当作转义前缀导致路径错误。在跨平台代码中，建议使用正斜杠或std::filesystem::path来构造路径，避免手动拼接带来的追加失败。掌握这些细节，fstream的app模式就能成为你稳定落盘数据的基石。