程序崩溃时无法靠 std::ofstream 自动刷盘，因其析构函数不执行，缓冲区数据丢失；应禁用缓冲、用低级I/O加fsync()、或采用WAL+原子提交方案。
程序崩溃时无法靠 std::ofstream 自动刷盘
标准 C++ 流（如 std::ofstream）在对象析构时才调用 flush()，而进程异常终止（SIGSEGV、abort()、未捕获异常等）会跳过栈展开，析构函数根本不会执行。这意味着你写入缓冲区的数据大概率留在用户态缓冲区里，根本没进内核页缓存，更别说落盘了。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 禁用流的缓冲：构造时传
std::ios::unitbuf，或调用stream.setf(std::ios::unitbuf)—— 但注意这仅对每次后自动 <code>flush()有效，且严重拖慢性能，不适用于高频写入 - 改用低级 I/O：直接用
open()/write()/fsync()组合，绕过 libc 缓冲层；每次关键写入后必须显式调用fsync()（Linux/macOS）或_commit()（Windows） - 避免依赖 RAII 清理：把“刷盘”逻辑从析构函数中剥离，改为主动控制的 checkpoint 函数，在关键路径上定期调用
signal() 捕获后调用 fsync() 是不可靠的
注册 SIGSEGV、SIGABRT 等信号处理器看似可行，但存在硬伤：fsync() 不是 async-signal-safe 函数，POSIX 明确禁止在信号处理上下文中调用它。实际中可能触发二次崩溃、死锁，或静默失败。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 只在信号处理函数中做最简操作：例如写一个标志位（
volatile sig_atomic_t g_should_flush = 0;），然后立即返回 - 主循环中轮询该标志，一旦置位，立刻执行
fsync()+_exit()（不是exit()，后者会再次触发析构） - 对致命信号，可考虑用
sigaltstack()配合备用栈，但仍不能在 handler 内调用fsync()—— 它只是让“退出前刷盘”的窗口更可控，而非万能
真正可靠的方案：预写日志（WAL）+ 双文件原子提交
指望崩溃瞬间“抢救”内存数据是反模式。工业级做法是放弃“崩溃时刷盘”，转为“崩溃后可恢复”。核心思路是：所有脏数据变更先顺序写入一个追加日志（WAL），再更新主数据文件；恢复时重放日志。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- WAL 文件必须每次写入后调用
fsync()（或O_SYNC打开），这是唯一必须强刷的地方 - 主数据文件更新用原子替换：写新文件 →
fsync()新文件 →rename()覆盖旧文件。Linux 下rename()是原子的，且fsync()在rename()前保证元数据落盘 - 避免使用
std::fstream做 WAL：改用open(O_WRONLY | O_APPEND | O_SYNC)，并用write()直接写原始字节，规避流缓冲和编码转换干扰
Windows 下特别注意 _O_U16TEXT 和 _commit()
Windows 的 CRT 对 Unicode 文件流有特殊行为：std::wofstream 默认启用 UTF-16 BOM 和缓冲，即使设 unitbuf 也无法保证 fsync() 级别持久性。且 fsync() 在 MinGW/MSVC 中不可用。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 关键数据文件务必用
_open()+_write()+_commit()，不要用fopen()/std::ofstream - 若必须用宽字符，打开时加
_O_U16TEXT标志，并手动处理 BOM 和字节序，否则_write()会写乱码 -
_commit()等价于 POSIX 的fsync()，但它只对_open()返回的 fd 有效；对FILE*必须用_flushall()+_commit(_get_osfhandle(_fileno(fp)))，步骤繁琐易错
最常被忽略的一点：即使做了 fsync()，SSD 或磁盘固件仍可能缓存写入。若需绝对可靠，得配合 hdparm --yes-i-know-what-i-am-doing --set-sector --I /dev/sdX 关闭设备写缓存（仅限可信环境），或使用带电容保护的企业级 SSD。普通应用做到 WAL + fsync() 已覆盖 99% 场景，过度追求“绝对不丢”反而引入更大不确定性。
