fstream断电易损坏因默认缓冲且未强制落盘；应采用“写临时文件+fsync+原子rename”方案，并辅以崩溃标记机制确保恢复一致性。
为什么 fstream 直接写入断电后文件大概率损坏
fstream 默认使用缓冲（buffered I/O），write() 或 操作只是把数据塞进内存缓冲区，不立即落盘。断电时缓冲区里没 flush 的数据就丢了，文件可能截断、内容错位，甚至元数据（如 size）和实际内容不一致——这不是 fstream 的 bug，是 POSIX 文件语义和硬件层的天然限制。
- 即使调用
flush()，也只保证数据到达内核 page cache，不保证写到磁盘物理扇区 -
close()会触发 flush + sync，但断电发生在 close 返回前，依然可能失败 - ext4/xfs 等默认挂载参数（如
data=ordered）不保护文件内容完整性，只保 journal 一致性
用 fsync() 强制落盘，但要注意调用时机和错误检查
真正让数据写入磁盘物理介质，得靠 fsync()（Linux/macOS）或 FlushFileBuffers()（Windows）。C++ 标准库不封装它，必须通过 fileno() 拿到底层 fd：
#include <fstream>
#include <unistd.h> // Linux
#include <fcntl.h>
std::ofstream ofs("data.bin", std::ios::binary);
ofs.write(buf, len);
ofs.flush(); // 先清 C++ 缓冲区
if (fsync(fileno(ofs.rdbuf()->pubseekoff(0, std::ios_base::cur))) == -1) {
// 处理 fsync 失败：errno 可能是 EIO、ENOSPC 等
}
ofs.close();
- 别对
ofstream对象直接调fileno()，要通过rdbuf()->pubseekoff()获取关联的 fd（某些 libstdc++ 实现中，fileno(&ofs)不可靠） -
fsync()失败 ≠ 写失败，但意味着数据未落盘，此时应记录错误并拒绝认为写入成功 - 频繁
fsync()会显著拖慢性能（尤其机械盘），别每写 1 字节都 sync
更安全的方案：先写临时文件 + 原子 rename
POSIX 的 rename() 是原子操作（只要在同文件系统内），利用这点可规避“写一半断电”问题：
- 打开临时文件（如
"data.bin.tmp"），写入全部内容，fsync()完毕 - 调用
rename("data.bin.tmp", "data.bin")替换原文件 - 断电发生在 rename 前 → 临时文件残留，原文件完好；发生在 rename 后 → 新文件完整，旧文件被删
注意：std::filesystem::rename() 在 C++17 中可用，但需确认底层是否映射到原子 syscall（GCC/libstdc++ 通常可以，MSVC 需查文档）；更稳妥是直接用 ::rename()。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
崩溃恢复逻辑不能省：写前留标记，写后擦标记
即便用了临时文件+rename，如果程序在写完但还没 rename 前崩溃，下次启动时得知道“上次写了一半”。常见做法是在文件头或独立 marker 文件里存校验标记：
- 写入前，先写一个
"writing_in_progress"标记文件（或在目标文件开头写 magic + status 字段） - 全部写完 + fsync + rename 后，再删掉标记（或更新 status 为
"complete"） - 启动时检查标记：存在 → 视为脏状态，丢弃临时文件或回退到上一版
这个逻辑没法靠 fstream 自动完成，必须由业务代码显式控制。漏掉这步，前面所有 fsync 和 rename 就白做了。
真正的难点不在怎么写，而在怎么定义“写入成功”的语义，以及如何让恢复逻辑和写入逻辑严格对称——这里出一个条件分支不匹配，断电后就可能误删有效数据。
