多线程直接调用std::filesystem::rename()不安全，必须串行化或加锁保护；推荐生产者-消费者模型+单移动线程，配合路径校验、父目录预创建及异常捕获。
多线程移动文件本身不安全，必须加锁或串行化
直接用多个 std::thread 调用 std::filesystem::rename() 移动不同文件，看似可行，但实际风险极高：Windows 上可能报 Access is denied 或 The process cannot access the file，Linux 上虽较稳定，但若目标路径存在竞争（比如两个线程同时往同一目录 rename），仍可能覆盖、丢失或抛出 std::filesystem::filesystem_error。根本原因是 rename() 不是原子跨设备操作，且多数文件系统不保证并发 rename 的隔离性。
真正安全的做法是：**移动操作本身必须串行**，或至少对每个目标目录/目标路径加互斥保护。线程只负责“调度”和“准备”，不直接竞写同一资源。
推荐方案：生产者-消费者模型 + 单移动线程
把文件路径对（源、目标）放进线程安全队列，由一个专用线程逐个执行 std::filesystem::rename()。其他线程只做路径计算、权限检查、预创建父目录等无副作用工作。
-
std::queue换成std::concurrent_queue（C++20 起可用）或用std::mutex+std::queue手动保护 - 移动前务必调用
std::filesystem::exists(src)和std::filesystem::status(src).type() == std::filesystem::file_type::regular，避免移动目录或已删文件 - 目标父目录用
std::filesystem::create_directories(dest.parent_path())提前建好，否则rename会失败 - 捕获
std::filesystem::filesystem_error并记录e.code().message()，常见错误码如no_such_file_or_directory、permission_denied
为什么不能用 std::filesystem::copy_file + unlink？
有人想绕过 rename 限制，改用 copy_file 后 remove，但这更危险：
-
copy_file不是原子操作，中途失败会导致源存、目标残缺 -
remove失败（如权限不足）会留下冗余副本，且无法回滚 - 大文件复制耗时长、占磁盘空间，失去“移动”的语义优势
- 跨分区时
rename本就会退化为 copy+remove，但标准库已内部处理——自己手动拆解反而破坏了这个优化
Windows 下 MoveFileEx 的特殊处理
如果必须用 Win32 API（例如需要 MOVEFILE_DELAY_UNTIL_REBOOT 或 MOVEFILE_REPLACE_EXISTING），注意：
-
MoveFileExA/W本身线程安全，但参数中的路径字符串若被多个线程共享修改，需额外同步 - 返回
FALSE时必须调用GetLastError()，常见值如ERROR_ACCESS_DENIED（目标正被占用）、ERROR_SHARING_VIOLATION（源被其他进程打开） - 不要在多线程中反复调用
SetCurrentDirectory来简化路径——它影响整个进程，极易引发竞态 - 使用
std::filesystem::absolute()统一转为绝对路径再传给MoveFileEx，避免相对路径解析歧义
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
