不能直接用std::ofstream覆盖写入，因为默认trunc模式会清空原文件，进程崩溃或断电将导致数据全丢；必须用临时文件+原子重命名，并调用fsync/FlushFileBuffers确保落盘。
直接说结论：C++标准库直到 C++20 才提供 std::filesystem::rename 的原子性保证（仅当目标不存在时），而真正跨平台、可预测的“原子写入”必须靠临时文件 + 重命名组合实现，且需手动处理失败回滚和权限继承。
为什么不能直接用 std::ofstream 覆盖写入
看似简单的一句 std::ofstream("data.txt") 在多数系统上不是原子操作：写入中途崩溃或被 kill，会导致文件内容截断或损坏。Windows 上还可能因文件被占用而静默失败；Linux/macOS 虽支持覆盖，但不保证“旧内容完全保留直到新内容就绪”——尤其在 NFS 或某些挂载选项下。
- Windows：
std::ofstream默认以trunc模式打开，会先清空原文件，再写入，中间无回退点 - Linux/macOS：虽然
rename(2)是原子的，但ofstream写入本身不是，必须把“写入临时文件”和“重命名替换”拆成两步并确保顺序 - 所有平台：没做
fsync或FlushFileBuffers时，数据可能只停留在页缓存/内核缓冲区，掉电即丢
核心步骤：临时文件名生成与安全写入
临时文件名必须唯一、不可预测（防竞态）、且与目标同目录（否则跨设备 rename 会失败）。不要用 std::tmpnam（已弃用且不安全），也不要用固定后缀如 .tmp（易被清理工具误删）。
- 推荐方式：用目标路径 +
std::filesystem::temp_directory_path()拼接随机后缀，例如data.txt.5a3f8b2e.tmp - 写入时务必使用
std::ios::out | std::ios::binary模式，避免文本模式换行符干扰二进制内容 - 写完立即调用
fflush（C 风格）或os.flush()，再调用fsync（Linux/macOS）或FlushFileBuffers（Windows）——否则重命名成功但数据未落盘 - 示例关键片段：
std::ofstream tmp{"data.txt.abc123.tmp", std::ios::out | std::ios::binary}; tmp << content; tmp.flush(); #ifdef _WIN32 HANDLE h = CreateFileA("data.txt.abc123.tmp", GENERIC_WRITE, 0, nullptr, OPEN_EXISTING, 0, nullptr); FlushFileBuffers(h); CloseHandle(h); #else int fd = open("data.txt.abc123.tmp", O_WRONLY); fsync(fd); close(fd); #endif
重命名替换与错误恢复
std::filesystem::rename 是跨平台原子替换的唯一可靠手段，但它只在目标不存在时才等价于“原子移动”。如果目标正被其他进程读取（Windows 常见），rename 会失败——此时不能直接抛异常，得考虑降级策略。
立即学习“C++免费学习笔记（深入）”；
- 先尝试
rename(tmp_path, target_path)；失败时检查错误码：std::errc::permission_denied（Windows 文件占用）、std::errc::device_or_resource_busy（Linux 可能为只读挂载） - 若失败且允许覆盖，可尝试先
remove(target_path)再rename，但要注意：两次操作非原子，中间若崩溃，目标文件丢失 - 更稳妥的做法是写入前备份原文件（如
data.txt~），并在重命名失败后自动恢复——但需额外磁盘空间和清理逻辑 - 务必在
rename后再次std::filesystem::status(target_path)确认文件存在且大小匹配，防止某些 FUSE 文件系统假成功
权限与时间戳继承容易被忽略
临时文件默认继承进程 umask，很可能比原文件权限更宽松（如原为 0600，临时文件变成 0644）；Windows 上更无对应机制。修改时间（mtime）也通常不会自动同步。
- Linux/macOS：用
chmod和utimensat复制原文件权限与 mtime，需先stat原文件 - Windows：用
GetFileAttributesEx读取原属性，再用SetFileAttributes设置；注意只设FILE_ATTRIBUTE_READONLY等有限属性，ACL 需另用SetNamedSecurityInfo - 最简方案：若业务不敏感，可在构造类时接受一个
mode_t或DWORD参数显式指定目标权限，绕过继承逻辑
真正难的不是写几行代码，而是想清楚“失败发生在哪一步”：临时文件写了一半？重命名时磁盘满？权限复制时原文件已被删？每个环节都得有对应的清理和状态检查，否则一次异常就留下脏状态。
