std::filesystem::rename是C++17起最稳妥的跨平台文件重命名方案，它抛异常、校验路径、自动处理跨文件系统等细节，比C风格rename更安全可靠。
用 std::filesystem::rename 替代 C 风格的 rename 是当前最稳妥的选择
标准 C++17 起，std::filesystem::rename 已成为跨平台文件重命名的首选。它比 C 的 rename 函数更安全、语义更清晰，且能抛出明确异常（如权限不足、目标已存在、路径不存在等），避免靠返回值和 errno 手动判断的繁琐与易错。
常见错误现象：调用 C 的 rename 后返回 0 就认为成功，但其实目标路径若在不同文件系统（比如从 /tmp 移到 /home），Linux 下可能静默失败（实际执行的是 copy+unlink）；而 std::filesystem::rename 在跨文件系统时直接抛出 std::filesystem::filesystem_error，强制你处理迁移逻辑。
- 必须链接
-lstdc++fs（GCC）或启用 /std:c++17 + 链接 Windows SDK 的 filesystem 库（MSVC） - 路径参数为
std::filesystem::path类型，支持 UTF-8 字符串构造（Windows 上自动转宽字符） - 若目标已存在，默认行为是“覆盖”——但仅限于同类型（文件→文件、目录→目录）；否则抛异常，不会像 C 版本那样静默失败或行为不一致
当 std::filesystem::rename 报 filesystem_error 怎么查原因
异常信息里通常只含简短描述，真正有用的是 .code().value() 和 .path1()/.path2()。别只打印 what() 就完事。
- 检查
e.code().value()：常见值有 13（权限拒绝）、2（文件或目录不存在）、18（跨设备/文件系统）、20（不是目录但当作目录用） - 确认
e.path1()是否可读、e.path2()父目录是否可写（尤其注意目标路径的父目录权限，而非目标本身） - Windows 下注意长路径：如果路径超过
MAX_PATH（260 字符）且未启用长路径支持，会报 3（路径未找到），此时需在 manifest 中启用或使用\?前缀（std::filesystem::path不自动加，需手动拼）
示例片段：
立即学习“C++免费学习笔记（深入）”；
try {
std::filesystem::rename("old.txt", "new.txt");
} catch (const std::filesystem::filesystem_error& e) {
std::cerr << "Fail: " << e.what()
<< ", code=" << e.code().value()
<< ", path1=" << e.path1()
<< ", path2=" << e.path2() << '
';
}
C 的 rename 还能不能用？什么场景下不得不兜底
可以，但仅限极简场景（如嵌入式无 STL 支持、或仅操作本地 ASCII 路径且确定不跨文件系统）。它不抛异常、不检查路径合法性、不处理编码，纯靠返回值和 errno 判断，极易漏错。
-
rename返回 -1 表示失败，此时必须立刻检查errno；返回 0 不代表“完成”，只代表“原子重命名尝试成功”——跨文件系统时可能退化为复制删除，且不保证原子性 - 路径字符串必须是当前 locale 编码（Linux 多为 UTF-8，Windows 默认是 ANSI Code Page），传入含中文的
std::string在 Windows 上大概率乱码或失败 - 无法区分“目标是目录但给了文件名”和“目标被占用”等语义差异，
errno都可能是 13 或 17
所以除非你明确知道运行环境限制，否则不要主动选 rename。
重命名失败后想“移动+覆盖”，std::filesystem::copy_file + remove 不是等价替代
手动模拟 rename 的跨文件系统行为时，很多人直接 copy 再 remove，但这不是原子操作，且容易出竞态：copy 成功但 remove 失败，导致源文件丢失、目标残留旧副本。
- 务必先
copy_file(src, dst, std::filesystem::copy_options::overwrite_existing)，成功后再remove(src) - 但即使这样，中间状态仍可见——其他进程可能在 copy 完成后、remove 前读到不一致的文件
- 更健壮的做法是：先 copy 到临时名（如
dst + ".tmp"），再rename临时名到目标（利用 rename 的原子性），最后 remove 源。这才能逼近原生 rename 的可靠性 - 注意
copy_file不复制所有权和权限位（Linux/macOS 下需额外用permissions设置）
这事没标准封装，得自己写一层容错逻辑——这也是为什么原生 rename 不可用时，问题复杂度陡增。
