使用 std::ofstream 以 std::ios::out | std::ios::app 模式打开日志文件可安全追加写入，文件不存在时自动创建，存在时定位至末尾；需检查 is_open() 和写入状态，多线程下应避免共享流或加锁。
ofstream 用 std::ios::app 追加写入日志文件
直接用 std::ofstream 打开文件时指定 std::ios::app 模式，就能确保每次写入都追加到文件末尾，不会覆盖已有内容。这是最常用、也最安全的日志写入方式。
- 必须显式传入
std::ios::app，仅靠std::ios::out不会自动追加 - 文件不存在时会自动创建；存在时指针自动定位到末尾，无需手动
seekp - 多线程下不保证线程安全，若多个线程共用同一个
ofstream对象，需加锁；更推荐每个线程独占流或用日志库（如 spdlog） - 示例：
std::ofstream log_file("app.log", std::ios::out | std::ios::app); log_file << "[INFO] Startup completed.\n"; log_file.close();
为什么不能只用 std::ios::out？
默认只用 std::ios::out 打开已存在的文件，会清空全部内容再写入——这在日志场景下等于“每天一删”，极易丢失现场信息。
- 等价于 shell 中的
>（覆盖重定向），不是>>（追加重定向） - 即使文件原本是只读的，
std::ios::out仍会尝试截断，可能触发权限错误或静默失败 - 某些平台（如 Windows）下，未指定模式时行为可能因编译器或 CRT 版本略有差异，不可依赖
日志写入前建议检查 is_open() 和 fail()
磁盘满、路径无权限、父目录不存在等情况都会导致打开失败，但 ofstream 构造函数不抛异常（默认关闭异常位），必须主动检查。
- 不要只靠构造成功就认为可写：
std::ofstream f("log.txt", std::ios::app)可能已失败 - 写入后也建议检查：
if (!log_file) { /* handle error */ } - 典型健壮写法：
std::ofstream log_file("log.txt", std::ios::out | std::ios::app); if (!log_file.is_open()) { // 记录到 stderr 或尝试 fallback 路径 return; } log_file << "[DEBUG] Something happened.\n"; if (log_file.fail()) { // 写入失败：磁盘满、权限不足、设备断开等 }
频繁打开/关闭文件 vs 复用 ofstream 对象
工程中常见两种策略：每次写日志都 open/close，或全局/单例复用一个 ofstream。前者简单但开销大；后者高效但需注意生命周期和异常安全。
立即学习“C++免费学习笔记（深入）”；
- 高频写入（如每毫秒一条）务必复用对象，避免系统调用和磁盘寻址开销
- 复用时，若程序异常退出而未
close()，缓冲区内容可能丢失——建议设置log_file 强制行缓冲（但影响性能）或定期flush() - 跨 DLL 边界或动态库加载时，
ofstream的静态析构顺序不可控，可能导致 close 时崩溃；此时更适合用 C 风格FILE*或成熟日志库
日志文件路径权限、编码（尤其 Windows 下中文路径）、以及长时间运行时的文件轮转（按大小/时间切分），这些才是工程落地时真正卡住人的地方。
