17370845950

使用 std::ios::app 模式打开文件即可自动追加，无需 seekp()；而 std::ios::ate 仅初始定位到末尾，后续写入仍从当前位置开始，可能覆盖内容。

直接用 std::ofstream 以 std::ios::app 模式打开文件就能追加，无需手动定位或清空缓冲区

这是最常见也最容易出错的点：很多人以为“追加”得先 seekp() 到末尾，其实 std::ios::app 模式会自动强制所有写入都发生在文件末尾，哪怕你中途调用了 seekp()，下一次 operator 或 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 → "Y" 覆盖开头，ate 不再干预
• std::ofstream f2("a.txt", std::ios::out | std::ios::app); f2 → 总在末尾
• f2.seekp(0); f2 → 依然写在末尾，“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 上可能因缓存/句柄竞争出现异常。

• 安全做法：用互斥锁（std::mutex）保护写操作段，或让每个线程写独立临时文件，最后合并
• 不推荐依赖“操作系统保证追加原子性”：C++ 标准不承诺，且 ofstream 自身缓冲区（rdbuf()->sputn()）可能拆分写入，破坏原子性
• 若需高性能并发日志，考虑用成熟的日志库（如 spdlog），它们内部已处理好文件追加的同步与缓冲策略

#include 
#include 

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 模式的“每次写都重定位”特性、编码隐式依赖、以及多线程下的真实行为边界，才是实际项目里最常翻车的地方。