rename()不是绝对安全的迁移方案，需检查目标路径存在性、权限、符号链接歧义及跨文件系统风险；跨设备时会退化为非原子的复制+删除，易致数据丢失。
PHP 本身没有“安全迁移文件夹”的内置函数，rename() 是最常用、最轻量的方案，但它是否“安全”完全取决于上下文——比如目标路径是否存在、权限是否匹配、是否跨文件系统，以及你是否需要原子性或失败回滚。
用 rename() 迁移前必须检查的 4 件事
它快、原子（同文件系统下）、不占内存，但一错就静默失败。常见错误是直接调用却忽略返回值，结果文件“消失”了也没报错。
-
rename()跨分区（如从/tmp到/home）会退化为“复制+删除”，失败时可能只删源、不写目标，造成数据丢失 - 目标目录必须已存在且有写权限；
rename()不会自动创建父级路径，要用mkdir(..., 0755, true)预处理 - 源路径和目标路径不能有符号链接歧义（比如目标是软链指向自身），否则行为未定义
- Windows 下对正在被其他进程打开的文件会失败，Linux 下通常可重命名，但后续读写可能出错
跨文件系统迁移时，为什么不能只靠 rename()
当 rename() 检测到跨设备（errno === EXDEV），它会内部 fallback 到 copy + unlink，但这个过程不是原子的：若复制中途失败，源文件已被删，目标只有部分数据。
- 手动实现健壮迁移：先
copy()到目标位置 →md5_file()校验一致性 → 确认无误再unlink()源目录（注意：copy()不支持目录，得递归处理） - 更稳妥的做法是用
exec('rsync -a --remove-source-files ...')（需服务器启用 shell 执行且信任输入），它支持断点续传和校验 - 绝对避免在 Web 请求中执行大目录迁移——超时、内存溢出、请求中断都会留下脏状态
如何防止迁移过程中被并发修改？
PHP 没有文件系统级的“迁移锁”，靠应用层控制。典型场景是用户上传后触发归档，但同时又有人在改源文件夹内容。
立即学习“PHP免费学习笔记（深入）”；
- 用
flock()锁一个临时标记文件（如/tmp/move_lock_mydir.lock），而非锁目录本身（目录不能被 flock） - 迁移前生成唯一 token 写入元数据文件（如
.migrating），脚本开头检查该文件是否存在并校验时效（避免死锁残留） - 如果业务允许，把源目录先
chmod 000（需 root 或相同 UID），迁移完再恢复——简单粗暴但有效
真正难的不是“怎么搬”，而是“搬的时候别人能不能动”“搬一半断电了怎么办”“目标磁盘满了报什么错”。这些细节不会出现在函数文档里，但决定了迁移到底安不安全。
