std::rename跨盘符必然失败，因c++标准限定其仅支持同文件系统操作；遇exdev错误须改用copy_file+remove手动实现跨盘移动，并注意路径编码、权限继承及并发安全。
std::rename 跨盘符失败是常态，不是你写错了
它根本不能跨磁盘移动文件，C++ 标准明确要求 std::rename 必须在同文件系统内操作。Windows 上跨盘（比如从 C: 到 D:）会直接返回 -1 并把 errno 设为 EXDEV；Linux/macOS 同理，errno == EXDEV 就是标准信号。
常见错误现象：std::rename("C:\a.txt", "D:\b.txt") 返回 -1，但很多人没检查返回值或忽略 errno，以为“重命名成功”，结果源文件被删、目标没出现——实际是静默失败后又手动删了源，造成数据丢失。
- 务必检查返回值：
if (std::rename(old_path.c_str(), new_path.c_str()) != 0) - 立刻查
errno：Windows 用_doserrno或GetLastError()更可靠；POSIX 系统直接读errno - 遇到
EXDEV，必须切到「复制 + 删除」逻辑，不能硬 retry
跨盘移动得自己实现 copy + unlink，别信封装库的“自动处理”
没有跨平台标准函数能原子化完成跨盘移动。所谓“自动 fallback”得你自己写，而且要注意顺序和异常安全。
典型场景：用户拖拽文件到另一分区、配置目录迁移到新硬盘、打包工具整理输出路径。
- 先
std::filesystem::copy_file（C++17），设std::filesystem::copy_options::overwrite_existing - 复制成功后，再
std::filesystem::remove源文件 —— 顺序不能反，否则断电就丢数据 - 若需原子性，Windows 可考虑
MoveFileEx配MOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH；Linux 可用renameat2（需 glibc 2.28+）加RENAME_EXCHANGE模拟，但依然不跨 fs - 注意权限继承：
copy_file默认不保留所有权，Windows 上可能丢 ACL，Linux 上可能丢 setuid
std::rename 的参数路径格式和编码陷阱
路径字符串本身就能让 std::rename 失败，尤其在 Windows 上混用正斜杠/反斜杠、相对/绝对路径、宽字符窄字符。
使用场景：构建脚本生成路径、用户输入路径、跨平台项目里硬编码路径分隔符。
- Windows 下传入含中文的窄字符路径（
const char*），若编译器默认 ANSI 编码（如 MSVC 的 CP1252），会乱码导致No such file - 推荐统一用
std::filesystem::path构造，它自动处理分隔符归一化（"a/b"→"a\b"） - 避免拼接：
path1 / path2比path1.string() + "\" + path2.string()安全得多 - 不要对路径做裸
.c_str()后直接传给std::rename，先确认path.native()是否有效（特别是含 Unicode 时）
性能和并发下 std::rename 的真实行为
它快，是因为多数时候只是更新 inode/dentry，但这个“快”有前提：同卷、无锁竞争、无杀毒软件 hook。
容易被忽略的地方：
- 杀毒软件或备份工具可能对文件加共享锁，导致
rename阻塞甚至失败（EACCES），不是权限问题，是句柄占用 - Windows 上 NTFS 卷快照（VSS）启用时，重命名大文件可能触发写时拷贝，延迟飙升
- 多线程同时 rename 同一目录下的不同文件一般安全；但 rename 同一文件（如 A→B，A→C）未定义行为，别这么干
- 不要假设 rename 是原子的跨目录操作：源目录 unlink 和目标目录 link 是两个步骤，崩溃可能留下中间态（源删了、目标没链上）
EXDEV、手写 copy+unlink、小心路径编码、留意后台进程干扰——这四点漏掉任何一条，都可能在某个客户机器上突然出问题。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
