std::filesystem::rename 是 C++17 起最可靠的文件移动方式，同文件系统下原子重命名，跨分区自动退化为复制+删除；失败时需手动处理：检查空间、用 copy_file 覆盖复制、成功后再 remove。
用 std::filesystem::rename 移动文件最可靠
标准库从 C++17 开始提供 std::filesystem::rename，它本质是原子性重命名操作，在同一文件系统内就是真正的“移动”，跨分区则会退化为复制 + 删除（但行为对调用者透明）。这是目前最推荐的方式，不用自己拼路径、不依赖平台 API。
常见错误现象：std::filesystem::rename 抛出 std::filesystem::filesystem_error，比如目标路径已存在、权限不足、源路径不存在，或跨文件系统时磁盘空间不足（因需先复制）。
- 确保包含头文件：
#include <filesystem></filesystem>，编译时加-lstdc++fs（GCC 旧版本）或启用 C++17（Clang/MSVC 通常默认支持） - 目标路径不能是已存在的非空目录；若目标是空目录，
rename会失败，需先清空或用std::filesystem::remove_all - 路径参数用
std::filesystem::path构造，避免手拼字符串斜杠问题；Windows 下用正斜杠/或双反斜杠\都可，std::filesystem::path会自动标准化
示例：
try {
std::filesystem::rename("old.txt", "subdir/new.txt");
} catch (const std::filesystem::filesystem_error& e) {
// e.code().message() 包含具体原因，比如 "No such file or directory"
}
跨文件系统移动失败时得手动复制 + 删除
std::filesystem::rename 在跨挂载点（如从 /home 移到 /mnt/usb）时会失败并抛出 std::errc::cross_device_link 错误。这时必须自己实现：先完整复制，再删除原文件，且要处理中间失败的回滚。
关键点不是“怎么写复制循环”，而是“怎么保证原子性和安全性”：
立即学习“C++免费学习笔记（深入）”；
- 复制前先检查目标磁盘剩余空间（
std::filesystem::space），避免复制一半失败 - 用
std::filesystem::copy_file并指定std::filesystem::copy_options::overwrite_existing，它比手动读写更安全（支持 sparse 文件、保留权限等） - 仅当复制成功后，才调用
std::filesystem::remove；若删除失败，至少原文件还在，不会丢数据 - 不要用
std::filesystem::copy（递归复制整个目录），除非你明确需要目录结构
Windows 上用 MoveFileEx 的坑比想象中多
如果项目必须兼容旧 C++ 标准（MoveFileEx。但它容易踩几个硬坑：
- 路径必须是绝对路径，相对路径行为未定义；
MoveFileEx不做路径标准化，"./a.txt"可能失败 - 目标路径的父目录必须已存在，
MoveFileEx不会自动创建中间目录（而std::filesystem::rename会报错提示） - 若设置
MOVEFILE_DELAY_UNTIL_REBOOT，移动实际发生在重启后，程序无法感知结果 - 返回
TRUE也不代表完成——只是提交成功；若目标被占用，可能静默失败（需检查GetLastError()）
别忽略权限和符号链接的语义差异
移动操作在不同场景下语义不同，尤其涉及权限和符号链接时，容易导致行为不符合预期：
-
std::filesystem::rename移动符号链接本身（而非它指向的目标），这点和 shell 的mv一致；若想移动目标内容，得先read_symlink解析再操作 - Linux 下，移动文件不会改变其所有权和权限；但若目标目录设置了 setgid 位，新文件的组会被继承——这不是移动函数的问题，而是 VFS 层行为
- 移动后原路径的硬链接仍指向同一 inode，但软链接失效（因为路径变了）；这点常被忽略，尤其在构建工具链中
真正麻烦的是：没有一种方法能同时满足“跨平台 + 原子性 + 自动处理符号链接 + 权限继承控制”。得根据场景选——日常开发优先用 std::filesystem::rename，失败后再降级处理；底层工具才值得深挖平台 API 细节。
