rename() 可原子性移动并重命名文件，支持跨目录但不跨文件系统；需确保权限、路径正确及目标目录存在，失败时应校验读写权限并排查SELinux或路径问题。
用 rename() 一次性完成移动和重命名
rename() 是 PHP 原生函数，它本质就是「原子性地移动文件」，如果目标路径包含不同文件名，就等效于移动 + 重命名。不需要先 copy() 再 unlink()，更不推荐用 system("mv ...") 这类外壳调用。
常见错误是误以为 rename() 只能改名不能跨目录——其实只要目标路径是完整路径（含目录和新文件名），且 PHP 进程对源目录有读权限、目标目录有写权限，就能跨分区/目录移动（Linux 下跨文件系统会失败，但绝大多数 Web 场景都在同一挂载点）。
- 源路径和目标路径都必须是绝对路径或相对于当前工作目录的有效路径；用
__DIR__ . '/uploads/old.jpg'比'uploads/old.jpg'更可靠 - 目标目录必须已存在，
rename()不会自动创建父级目录；可提前用mkdir($target_dir, 0755, true) - 若目标文件已存在，
rename()会直接覆盖（Windows 下可能失败，Linux 下默认成功） - 返回
true表示成功，false表示失败；建议配合error_get_last()查具体原因
移动失败的典型报错和排查点
最常遇到的是 Warning: rename(): Permission denied 或 No such file or directory。前者多因权限不足：PHP 进程用户（如 www-data 或 nginx）对源文件无读权，或对目标目录无写权；后者往往因为路径拼错、目录不存在、或用了相对路径但脚本执行位置（getcwd()）与预期不符。
- 用
is_readable($source)和is_writable($target_dir)提前校验，比直接rename()更易定位问题 - 检查 SELinux（CentOS/RHEL）是否启用并限制了 httpd 进程的文件操作，临时用
setenforce 0测试可排除干扰 - Windows 下注意路径分隔符，统一用
/或DIRECTORY_SEPARATOR，避免\被转义 - 如果源文件在 NFS 或网络存储上，
rename()跨文件系统时会失败，此时只能copy() + unlink()
需要保留原文件时别用 rename()
如果业务逻辑要求「复制后重命名原位置文件」或「移动后留个硬链接」，rename() 就不合适了。这时候得手动组合操作：
立即学习“PHP免费学习笔记（深入）”；
- 先
copy($source, $target)，再unlink($source)—— 注意两次操作非原子，中途失败会导致数据不一致 - 用
exec("cp '$source' '$target' && rm '$source'", $output, $return_code)风险更高，容易被路径中的空格或特殊字符注入 - 真正需要强一致性（比如支付凭证归档），应加锁（
flock()）或事务日志，而不是依赖单次文件操作
大文件移动时的性能和超时风险
rename() 本身极快（底层是 mv 系统调用），但若目标路径跨文件系统（例如从 /var/www 移到 /mnt/backup），实际会退化为拷贝+删除，耗时随文件大小线性增长，还可能触发 PHP 的 max_execution_time 限制。
- 用
disk_free_space($target_dir)提前检查空间，避免移动到一半失败 - 大文件场景下，考虑用
set_time_limit(0)临时取消超时，但要确保有合理退出机制 - Web 请求中处理 GB 级文件移动极易阻塞整个请求，更适合扔进队列（如 Redis + Worker）异步执行
跨文件系统移动不是“能不能”的问题，而是“要不要在当前上下文做”的问题——多数时候该换思路，而不是硬扛 rename() 的局限。
