使用 std::ios::app 模式打开文件即可自动追加，无需 seekp()；而 std::ios::ate 仅初始定位到末尾，后续写入仍从当前位置开始，可能覆盖内容。
直接用 std::ofstream 以 std::ios::app 模式打开文件就能追加，无需手动定位或清空缓冲区
这是最常见也最容易出错的点：很多人以为“追加”得先 seekp() 到末尾，其实 std::ios::app 模式会自动强制所有写入都发生在文件末尾，哪怕你中途调用了 seekp()，下一次 operator 或 <code>write() 仍会跳回末尾。它不是“从末尾开始写”，而是“每次写都重定位到末尾再写”。
-
std::ofstream file("log.txt", std::ios::out | std::ios::app);—— 这是标准写法；单独用std::ios::app会隐式包含std::ios::out，但显式写出更清晰 - 如果文件不存在，
app模式会自动创建；如果存在，原有内容完全保留，新内容总在末尾 - 不能用
app模式读取（file >> x会失败），它只支持写入；需要读+追加请改用std::fstream并谨慎控制模式组合
std::ios::app 和 std::ios::ate 容易混淆，但行为完全不同
ate（at end）只是打开时把写位置定位到末尾，之后所有写操作仍从当前位置顺序进行——也就是说，它不阻止你在中间覆盖写；而 app 是每次写前都强制跳转到末尾，彻底杜绝覆盖风险。
std::ofstream f1("a.txt", std::ios::out | std::ios::ate); f1 → 写在末尾（因为刚打开时就在末尾）f1.seekp(0); f1 → <code>"Y"覆盖开头，ate不再干预std::ofstream f2("a.txt", std::ios::out | std::ios::app); f2 → 总在末尾f2.seekp(0); f2 → 依然写在末尾，“<code>seekp失效”是app的设计特性，不是 bug
追加中文或特殊字符时，必须注意文件编码与流缓冲一致性
Windows 下默认 ANSI 编码（如 GBK），Linux/macOS 默认 UTF-8；若用 std::ofstream 直接写宽字符串（std::wstring）或含 BOM 的 UTF-8 文本，可能乱码或截断。推荐统一用 UTF-8 字节串 + 显式设置 locale（仅限 C++11 及以上）。
- 写 UTF-8 字符串：确保源文件保存为 UTF-8 无 BOM，且字符串字面量本身是 UTF-8 编码（如
"你好\n"） - 避免
std::wofstream：它依赖 facet 实现，跨平台行为不稳定；优先用std::string+ UTF-8 - 必要时可调用
file.imbue(std::locale(""));让流跟随系统 locale，但 Windows 控制台 locale 常不匹配文件实际编码，慎用
多线程同时追加同一文件？std::ofstream 本身不保证线程安全
C++ 标准库的文件流对象不是线程安全的——多个线程共用同一个 std::ofstream 实例写入，会导致数据交错、丢失甚至崩溃。即使每个线程各自构造独立的 ofstream 并用 app 模式打开同一文件，在 POSIX 系统上通常能正确追加（内核级原子追加），但在 Windows 上可能因缓存/句柄竞争出现异常。
立即学习“C++免费学习笔记（深入）”；
- 安全做法：用互斥锁（
std::mutex）保护写操作段，或让每个线程写独立临时文件，最后合并 - 不推荐依赖“操作系统保证追加原子性”：C++ 标准不承诺，且
ofstream自身缓冲区（rdbuf()->sputn()）可能拆分写入，破坏原子性 - 若需高性能并发日志，考虑用成熟的日志库（如 spdlog），它们内部已处理好文件追加的同步与缓冲策略
#include <fstream>
#include <string>
int main() {
// 正确：每次写都追加到末尾
std::ofstream log("app.log", std::ios::out | std::ios::app);
if (log.is_open()) {
log << "[INFO] Startup completed.\n";
log << "[DEBUG] Value = " << 42 << "\n";
log.close(); // 或让析构自动关闭
}
return 0;
}
追加看似简单，但 app 模式的“每次写都重定位”特性、编码隐式依赖、以及多线程下的真实行为边界，才是实际项目里最常翻车的地方。 
