std::filesystem::rename 默认不覆盖文件，需先检查目标存在性并手动删除或备份；原子覆盖应采用“写临时文件+rename替换”方案，且需注意跨平台行为差异及Windows文件锁问题。
用 std::filesystem::rename 覆盖文件前必须先检查目标是否存在
直接调用 std::filesystem::rename 覆盖已有文件在大多数平台上会失败（抛出 std::filesystem::filesystem_error），错误信息类似 File exists。这不是 bug，而是标准行为：C++20 的 rename 默认不覆盖，它对标 POSIX 的 rename(2)，而后者在目标存在时是否覆盖取决于平台（Linux 允许，Windows 不允许）。
所以不能假设“同名就自动覆盖”。实操建议：
- 先用
std::filesystem::exists检查目标路径，若存在，显式删除（std::filesystem::remove）或重命名旧文件备份 - 再调用
std::filesystem::rename移动新文件过去 - 注意：两次操作（删 + 重命名）不是原子的，中间可能被中断，导致目标文件丢失
想真正原子覆盖？得靠临时文件 + rename 替换
真正的原子覆盖只能靠“写入临时文件 → 原子替换”两步。因为 std::filesystem::rename 在同一文件系统内是原子的（Linux/macOS/NTFS 均保证），但前提是源和目标在同一个挂载点。跨分区会退化为复制+删除，失去原子性。
关键步骤：
立即学习“C++免费学习笔记（深入）”；
- 生成临时路径：用
std::filesystem::temp_directory_path()+ 随机后缀（如std::tmpnam不安全，推荐std::filesystem::unique_path） - 把内容写入该临时路径（确保
close()或flush()完成） - 用
std::filesystem::rename将临时文件重命名为目标路径 —— 这一步才是原子的 - 务必检查
rename返回值或捕获异常；失败时临时文件需手动清理，否则磁盘泄漏
Windows 下 rename 失败的三个高频原因
即使按上述流程做，Windows 上仍常报错 Access is denied 或 The process cannot access the file。根本原因是 Windows 文件锁比 Unix 严格得多。
- 目标文件正被其他进程（包括 Explorer、杀毒软件、日志监控）以共享模式打开 ——
rename会失败 - 当前进程自己没关闭对目标文件的句柄（比如之前用
fopen打开过但忘了fclose） - 目标是只读文件（
std::filesystem::permissions中含owner_read但无owner_write）—— 必须先用std::filesystem::permissions清除只读位
临时缓解方式：加 retry 循环（带短延时），但治标不治本；长期应避免让其他程序长期 hold 目标文件句柄。
std::filesystem::rename 的跨平台兼容性陷阱
看似统一的接口，背后行为差异不小：
- Linux：源和目标在同一文件系统时原子；跨文件系统则复制+删除，且目标目录需有写权限，源文件可能被部分复制后中断
- macOS：HFS+/APFS 同 Linux；但若目标在 iCloud Drive 或网络卷上，
rename可能静默降级为非原子复制 - Windows：仅当目标不存在或为空目录时才允许
rename；若目标是目录且非空，直接失败（不会像 Linux 那样覆盖）
所以别依赖“一次 rename 解决所有问题”。真实项目里，覆盖逻辑必须区分场景：配置文件更新可接受短暂不可用，数据库快照则必须保证原子性 + 失败回滚能力。
