正确写法是std::ofstream f("log.txt", std::ios::out | std::ios::app)；仅std::ios::app不隐含输出权限，必须显式添加std::ios::out，否则文件无法打开。
用 std::ofstream 以追加模式打开文件的正确写法
直接上结论：必须同时指定 std::ios::out 和 std::ios::app，只写 ios::app 会失败——因为 ios::app 本身不隐含输出权限。
常见错误是这么写：std::ofstream f("log.txt", std::ios::app);，结果文件打不开、f.is_open() 返回 false，且无明确报错提示。
-
std::ios::app只控制写入位置（总在末尾），不决定能否写入 - 必须显式加上
std::ios::out，否则流对象默认不具备输出能力 - 不需要也不建议加
std::ios::in——追加模式下无法读取
ios::app 和 ios::ate 容易混淆的差别
两者都让文件指针“去结尾”，但行为完全不同，选错会导致数据被覆盖或写不进去。
-
ios::app：每次write()或前自动跳转到当前文件末尾，**线程安全地追加**，适合日志场景 -
ios::ate：只在打开时定位到末尾，之后写入从该位置开始——如果没手动seekp()，新内容会覆盖原有末尾字节 - 如果文件不存在，
ios::app会自动创建；ios::ate在只读模式下可能直接失败
示例：std::ofstream f("data.bin", std::ios::out | std::ios::app); —— 安全追加二进制数据；而 std::ios::out | std::ios::ate 不保证追加。
追加写入时 failbit 和 badbit 的实际触发条件
很多人以为“写不进去”就是权限问题，其实更常因流状态位未清或缓冲区异常导致静默失败。
- 若文件以只读方式打开（如漏了
std::ios::out），f.fail()会立即为true - 磁盘满或路径无写权限时，首次写入操作后
f.bad()可能为true，但f.fail()更常用 - 忘记检查
f.is_open()就直接写入，后续所有操作都无效，且不会抛异常（默认不开启 exception mask） - 建议每次写入后加
if (!f) { /* 处理错误 */ }，而不是只在打开后检查一次
多线程下用 ios::app 追加的安全边界
标准库不保证 ofstream 对象线程安全，但 ios::app 模式本身在操作系统层面有原子性保障——这是它比手动 seekp() + write() 更可靠的关键。
- 多个进程/线程各自用
ios::app打开同一文件，写入不会互相覆盖（内核保证追加原子） - 但同一个
std::ofstream对象不能跨线程共享使用，否则operator 内部缓冲区会冲突 - 如果需高频并发写日志，建议每个线程独占一个
ofstream，或用线程安全封装（如加 mutex + 单个流） - 注意：Windows 下对同一文件的并发追加支持弱于 Linux，某些旧版本 NTFS 会有锁竞争延迟
真正容易被忽略的是：即使用了 ios::app，如果程序崩溃或未调用 close()，最后几 KB 缓冲数据可能丢失——生产环境务必考虑 flush() 频率或用 std::ios::unitbuf。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
