ofstream写入失败需检查路径合法性、打开模式匹配及流状态；Windows路径用正斜杠或双反斜杠；追加写需注意ios::app特性；二进制写必须加ios::binary；write()后须检查gcount()；析构自动刷新但崩溃时失效。
ofstream 写入文件失败，检查这三件事
写不进文件，大概率不是 ofstream 本身有问题，而是路径、打开模式或流状态没对上。
-
ofstream默认以ios::out | ios::trunc模式打开，如果路径含中文或上级目录不存在，会静默失败（is_open()返回false） - Windows 下用反斜杠
要写成\或用正斜杠/，否则编译器当转义符处理（比如"C:dataout.txt"中的d报错） - 写完不调
close()或不析构对象，缓冲区内容可能没刷到磁盘；更隐蔽的是，忘记检查failbit—— 比如磁盘满、权限不足时，operator<<看似执行了，实际没写入
想追加写入而不是覆盖，别只改 open() 参数
仅用 ofstream("log.txt", ios::app) 是不够的。追加模式下，seekp() 无效，但更重要的是：如果文件不存在，ios::app 会自动创建；如果存在，所有写入都强制在末尾，哪怕你之前调过 seekp(0) 也白搭。
- 真正需要“先清空再追加”？不存在这种模式——得手动
ofstream("file.txt", ios::trunc)清空，再用ios::app打开 - 多线程写同一文件？
ios::app不保证原子性，两个线程同时写可能交错；必须外加互斥锁 -
ios::app自动设置ios::out，不用重复写；但不能和ios::in共存（fstream才支持读写）
写入字符串 vs 写入二进制，open() 模式必须匹配
文本模式（默认）会把 '
' 自动转成 "
"（Windows），而二进制模式原样输出。如果用文本模式写结构体或图片数据，结果肯定损坏。
- 写二进制：必须显式加
ios::binary，例如ofstream f("data.bin", ios::binary) - 写入
std::string用<<是安全的，但写char*或结构体要用write()：f.write(buf, len) - 用
write()后不检查gcount()，无法知道实际写了几个字节；尤其网络文件系统或 USB 设备可能部分写入
ofstream 析构时自动 flush，但别依赖它做关键日志
局部 ofstream 对象离开作用域会自动析构、关闭、刷新缓冲区——听起来很省心，但有坑。
立即学习“C++免费学习笔记（深入）”；
- 程序崩溃（如
abort()、段错误）时，析构函数不执行，未刷出的日志永远丢失 - 频繁小量写入（比如每条日志都 new 一个
ofstream）性能差：每次打开/关闭文件系统开销大，且缓冲区太小导致频繁 syscall - 长期运行服务中，建议用单例或静态
ofstream+ 手动flush()控制时机；若需确保落盘，写完后调sync()（等价于fflush()）
最常被忽略的一点：ofstream 的缓冲区大小不可调，也不提供回调机制；真要精细控制 IO，得换 std::filebuf 或直接用 POSIX write()。
