std::filesystem::rename 是 C++17 起唯一推荐的文件重命名方案，它抛异常、校验路径、自动处理跨文件系统等细节；需包含头文件、链接库（GCC 旧版）、确保源存在且目标目录可写。
std::filesystem::rename 是唯一推荐的方案
别碰 std::rename（C 标准库函数），它不抛异常、不检查路径合法性、跨文件系统可能静默失败。C++17 起，std::filesystem::rename 是标准且健壮的选择，底层会自动处理权限、符号链接、跨分区等细节。
使用前必须确保：
-
#include <filesystem>，并链接-lstdc++fs（GCC 旧版本）或启用 C++17（Clang/MSVC 通常默认支持） - 源路径
from必须存在，目标路径to若存在且非空目录，操作会失败（除非覆盖逻辑显式处理） - 目标路径所在目录必须有写权限；若
to已存在且是文件，会被直接替换（类似 Unix 的 mv 行为）
示例：
try {
std::filesystem::rename("old.txt", "new.txt");
} catch (const std::filesystem::filesystem_error& e) {
// 比如：no such file or directory, permission denied, cross-device link
std::cerr << e.what() << '\n';
}
重命名失败时最常见的几个错误信息
遇到报错别急着改代码，先看 what() 返回的具体字符串，它比错误码更直白：
立即学习“C++免费学习笔记（深入）”；
-
No such file or directory：源路径不存在，或父目录不可访问（注意不是“目标不存在”） -
Permission denied：源文件被其他进程占用（Windows 常见），或目标目录无写权限，或源文件只读（Linux 下不影响 rename，Windows 下可能阻塞） -
Invalid argument：路径含非法字符（如 Windows 的< > : " / \ | ? *），或to是from的子路径（比如把a/b改成a/b/c） -
Cross-device link：源和目标在不同挂载点（Linux/Unix），std::filesystem::rename不支持硬链接跨设备，此时需 copy + remove
需要覆盖已有文件？不能依赖 rename 自动覆盖
std::filesystem::rename 对已存在的目标文件是“原子替换”，但仅限于同类型（文件→文件、目录→目录）。如果目标是目录而源是文件，会直接抛 filesystem_error；反之亦然。没有“强制覆盖”开关。
安全覆盖的常见做法：
- 先用
std::filesystem::exists(to)和std::filesystem::is_regular_file(to)判断目标是否为可覆盖的文件 - 若存在且是文件，调用
std::filesystem::remove(to)显式删除（注意：remove 对目录会递归删，别传错） - 再执行
rename—— 这两步不是原子的，但比裸 rename 更可控
示例逻辑片段：
if (std::filesystem::exists("new.txt") &&
std::filesystem::is_regular_file("new.txt")) {
std::filesystem::remove("new.txt");
}
std::filesystem::rename("old.txt", "new.txt");
Windows 下要注意长路径和权限继承
Windows 默认限制路径长度为 260 字符，std::filesystem::rename 同样受此限制。若路径超长，需在编译时启用长路径支持（Windows 10 1607+）并确保程序 manifest 中声明 longPathAware=true，否则会直接报 Path not found。
另一个隐性坑：rename 不改变目标文件的 ACL（访问控制列表）。如果源文件有特殊权限（比如只允许管理员读），重命名后新文件仍保留原 ACL；但若目标路径位于 NTFS 卷且父目录启用了“继承权限”，则新文件可能被父目录策略覆盖——这取决于 Windows 当前策略，不是 C++ 标准能控制的。
真正难搞的是：某些杀毒软件或 OneDrive/Google Drive 客户端会 hook 文件操作，导致 rename 随机失败且错误信息模糊。这种时候，加 retry 逻辑比深究原因更实用。
