直接写文件不安全是因为非原子更新导致崩溃时文件损坏；原子重命名通过rename()保证“全成功或全失败”，但需同文件系统，且须fsync()确保落盘，再配合唯一临时名和校验可应对并发。
为什么直接写文件不安全
直接用 fopen 打开原文件并 fwrite 覆盖，一旦写入中途崩溃、断电或磁盘满，原文件就彻底损坏——既不是旧内容，也不是新内容。这是典型的“非原子更新”问题。
根本原因在于：普通写操作不提供“要么全成功、要么全回滚”的保障。操作系统和文件系统本身不保证单个 write() 调用的原子性（尤其对大文件），更不保证跨多个系统调用（open → write → close）的事务性。
原子重命名为什么能解决问题
POSIX 系统（Linux/macOS）和 Windows（从 Vista 起 via MoveFileEx with MOVEFILE_REPLACE_EXISTING）都保证：同一文件系统内，rename()（或其等价 API）是原子的。这意味着：rename("temp.dat", "config.json") 要么完全成功（旧文件瞬间被替换），要么完全失败（原文件毫发无损），绝不会出现中间态。
关键约束：rename() 的源和目标必须在同一个挂载点（即同个文件系统）。跨分区重命名会失败（EXDEV 错误），此时需 fallback 到拷贝 + 删除，但那就失去原子性了。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 先用
std::filesystem::temp_directory_path()获取临时目录（确保与目标同分区，优先选同目录下"xxx.tmp"） - 写入时打开临时路径（如
"config.json.tmp"），完成fsync()或fflush() + fsync()后再rename() - Windows 上用
std::filesystem::rename()即可（C++17），它内部已处理MoveFileEx语义 - Linux/macOS 下注意：若目标文件已存在且是只读，
rename()仍会成功（权限不影响原子性）；但 Windows 会失败，需提前chmod或SetFileAttributes
完整 C++17 实现示例（含错误防护）
以下代码封装了安全更新逻辑，覆盖常见边界：
bool safe_overwrite(const std::filesystem::path& target, const std::string& content) {
auto temp = target.parent_path() / (target.filename().string() + ".tmp");
// 1. 写临时文件（O_CREAT|O_WRONLY|O_TRUNC）
std::ofstream f(temp, std::ios::binary);
if (!f.is_open()) return false;
f << content;
if (!f.good()) return false;
// 2. 强制刷盘（关键！否则 rename 后可能丢数据）
f.close();
int fd = open(temp.c_str(), O_RDONLY);
if (fd >= 0) {
fsync(fd);
close(fd);
}
// 3. 原子重命名（同文件系统前提下）
try {
std::filesystem::rename(temp, target);
return true;
} catch (const std::filesystem::filesystem_error&) {
std::filesystem::remove(temp); // 清理残留
return false;
}
}
注意点：
- 没调
fsync()就rename()，相当于把缓存里的脏页“假装”已落盘——断电后仍是空文件或截断文件 - 不要用
std::ofstream::flush()代替fsync()：它只刷 C++ 缓冲区，不保证内核页缓存写入磁盘 - Windows 上若
target正被其他进程以SHARE_READ打开，rename()仍会成功；但若被独占打开（如记事本未关闭），则失败
多线程/多进程并发更新怎么办
rename() 本身是原子的，但多个进程同时尝试更新同一文件，仍可能因竞态导致某次写入丢失。例如：A 和 B 都生成自己的 .tmp 文件，然后都试图 rename("x.tmp", "x") —— 后执行者会覆盖先执行者的成果。
解决思路不是加锁（文件锁不可靠），而是让每次更新携带唯一标识：
- 临时文件名加入 PID + 时间戳 + 随机数，如
config.json.tmp.12345.1712345678.abcde - 写入前先检查目标文件的 mtime 或校验和，确认是否已是期望版本（乐观并发控制）
- 真正需要强一致性时，应改用数据库或带事务的日志结构存储，而非纯文件
文件系统的原子重命名只是基础保障，它解决的是“单次更新不损坏”，不解决“多次更新不冲突”。这点容易被忽略，尤其在配置热更新场景里。
