std::filesystem::rename在Windows和Linux上行为不一致：Windows允许同卷覆盖，Linux默认拒绝并抛file_exists错误；安全跨平台覆盖需先检查目标存在性再删除，最后重命名，但非原子操作。
std::filesystem::rename 在 Windows 和 Linux 上的行为差异
直接调用 std::filesystem::rename 本身是跨平台的，但实际能否成功重命名，取决于底层 OS 的语义和权限模型。Windows 允许在同卷内覆盖目标文件（只要目标可写），而 POSIX 系统（Linux/macOS）默认不允许覆盖 —— 如果 to 已存在，会抛出 std::filesystem::filesystem_error，错误码为 std::errc::file_exists。
如何安全地跨平台覆盖重命名
标准库不提供“原子覆盖重命名”接口，必须手动处理目标文件是否存在。常见做法是先删除目标再重命名，但要注意：删除 + 重命名不是原子操作，中间可能被其他进程写入；且删除失败（如权限不足、正在被占用）会导致整个操作中断。
- 检查
std::filesystem::exists(to)，若存在则调用std::filesystem::remove(to)，再执行rename(from, to) - 捕获
std::filesystem::filesystem_error，根据.code().value()判断是否为std::errc::permission_denied或std::errc::device_or_resource_busy，决定是否重试或报错 - Linux 下也可用
std::filesystem::copy_file(from, to, std::filesystem::copy_options::overwrite_existing)+remove(from)替代，但不保证原子性，且 copy 可能比 rename 慢得多（尤其大文件）
路径编码与 Unicode 支持要点
Windows API 原生使用 UTF-16，std::filesystem::path 在 MSVC 和较新 GCC/Clang 中默认支持宽字符构造（std::filesystem::path(L"中文.txt")），但 Linux 仅按字节处理路径 —— 只要传入的 std::string 是合法 UTF-8 编码，就能正确操作中文路径。问题常出在源头：如果从控制台读取路径却没做 locale 转换，或 Qt/WxWidgets 等 GUI 框架返回的字符串编码未统一，就会导致 rename 找不到文件。
- 避免用
char*直接拼接路径，优先用std::filesystem::path的/重载拼接 - 从用户输入获取路径后，确认其编码：Windows 控制台默认 GBK，需用
std::wstring_convert（C++17 已弃用）或MultiByteToWideChar转 UTF-16；Linux 终端一般为 UTF-8，可直接构造std::filesystem::path - 编译时确保启用了 Unicode 支持：MSVC 加
/utf-8，GCC/Clang 加-finput-charset=utf-8
替代方案：为什么有时不该用 std::filesystem::rename
当需要真正原子性的“替换文件内容”（比如更新配置文件、数据库快照），rename 不是最终答案。POSIX 有 renameat2(AT_FDCWD, from, AT_FDCWD, to, RENAME_EXCHANGE) 或 RENAME_NOREPLACE，Windows 有 MoveFileEx(..., MOVEFILE_REPLACE_EXISTING)，但这些都不是标准 C++ 接口。
立即学习“C++免费学习笔记（深入）”；
- 若项目已依赖 Boost，
boost::filesystem::rename内部做了更多平台适配，对覆盖场景封装稍好 - 对关键数据文件，更稳妥的做法是：写入临时文件（
to + ".tmp"），fsync后rename，避免崩溃导致损坏 -
std::filesystem::rename不能跨文件系统移动（即不同挂载点），此时会失败并抛出std::errc::cross_device_link，必须回退到 copy + remove
跨平台重命名真正的难点不在函数调用本身，而在错误分类处理、路径生命周期管理、以及对“覆盖”语义的显式建模 —— 标准库只提供原语，不替你做业务决策。
