std::filesystem::rename 在 Windows 和 Linux 上行为不一致：Windows 允许跨卷重命名，Linux 遇 EXDEV 错误需降级为复制+删除；目标为非空目录时均失败；不保证原子性；应优先用 status 检查目标类型而非 exists；避免 system 或 Win32 API 以保可移植性。
std::filesystem::rename 在 Windows 和 Linux 上行为不一致？
是的，std::filesystem::rename 本身是跨平台的，但底层语义差异会导致实际行为不同：Windows 允许跨卷重命名（本质是移动+复制+删除），Linux 默认拒绝跨文件系统调用并抛出 std::filesystem::filesystem_error，错误码通常是 EXDEV。
这意味着你不能假设一次 rename 调用在所有平台都成功 —— 它不是“原子移动”，而是“尽力而为”的重命名，失败后需降级处理。
- 跨分区/挂载点移动文件时，Linux 直接报错；Windows 可能静默完成（取决于权限和目标卷格式）
- 目标路径已存在且非空目录时，所有平台都失败，但错误信息略有差异（Linux 多报
ENOTEMPTY，Windows 可能报ERROR_DIR_NOT_EMPTY） -
rename不保证原子性：若中途被中断（如磁盘满、权限突变），可能留下部分副本或残留临时状态
遇到 EXDEV 错误时怎么安全 fallback 到复制+删除？
检测到 EXDEV 后，必须手动实现“复制 → 同步 → 删除源”的逻辑，否则业务就卡死。关键不是写对复制，而是避免中间态污染和资源泄漏。
- 先用
std::filesystem::copy_file+std::filesystem::copy_options::overwrite_existing复制，注意它不复制所有权/ACL，仅内容与基本属性 - 复制后立即调用
std::filesystem::equivalent检查源与目标是否内容一致（可选但推荐，尤其对小文件） - 确认无误后再删源：
std::filesystem::remove；若删除失败，保留目标并抛异常，**绝不能静默忽略** - 整个过程建议封装成函数，并捕获
std::filesystem::filesystem_error，用.code().value()判断是否为EXDEV（值为 18 on Linux, 123 on Windows）
示例片段：
立即学习“C++免费学习笔记（深入）”；
try {
std::filesystem::rename(src, dst);
} catch (const std::filesystem::filesystem_error& e) {
if (e.code().value() == 18) { // EXDEV
std::filesystem::copy_file(src, dst, std::filesystem::copy_options::overwrite_existing);
std::filesystem::remove(src);
} else {
throw;
}
}
rename 前要不要先检查目标是否存在？
要，但方式得对。直接 exists(dst) 不够 —— 如果 dst 是目录，rename 会失败；如果 dst 是文件，标准要求覆盖（C++17 起），但某些旧 libc 实现可能不支持。
- 用
std::filesystem::status(dst)获取精确类型，再比对is_regular_file()或is_directory() - 若
dst是目录且非空，rename必败，提前报错比等系统报ENOTEMPTY更可控 - 若
dst是文件，可放心调用rename（标准保证覆盖），无需先删 —— 多余的remove反而增加竞态风险 - 注意：Windows 下对只读文件调用
rename会失败，Linux 不关心只读位，所以跨平台时最好先permissions(src, perms, std::filesystem::perm_options::add)确保可写
为什么用 rename 而不是 system("mv") 或 CreateMoveFile？
因为 std::filesystem::rename 是唯一标准、无 shell 依赖、不触发病毒扫描钩子、且能统一异常模型的方案。调用 system 或 Win32 API 会破坏可移植性，还引入注入、编码、权限继承等一堆隐性问题。
-
system("mv")在 Windows 上根本不存在；即使加兼容层（如 busybox），路径分隔符、空格转义、编码（GBK vs UTF-8）全得自己兜底 - Win32 的
MoveFileEx支持更多标志（如延迟删除），但 Linux 没对应物，硬封装只会让逻辑分支爆炸 -
std::filesystem::rename的异常类型统一，错误码可映射，配合std::error_code参数还能避免抛异常，适合嵌入式或游戏热更等敏感场景
真正难的不是调用 rename，而是想清楚：哪些情况必须 fallback，哪些情况该提前拒绝，以及失败后日志里能不能还原出当时 src/dst 的绝对路径和 status —— 这些细节比语法更重要。
