rename()是PHP唯一跨平台原生重命名方案，直接修改文件系统inode或目录项，成功返回true、失败false并触发Warning；目标路径需有写权限且同分区，会覆盖同名文件，操作时需防Web服务器读取和OPcache缓存问题。
PHP 中用 rename() 替换文件名最直接
PHP 本身不提供“重命名队列”或原子化批量改名机制，rename() 是唯一跨平台、无需额外扩展的原生方案。它在绝大多数情况下等价于 shell 的 mv，会直接修改文件系统中的 inode 指向（Linux/macOS）或重写目录项（Windows），不是复制+删除。
关键点：rename() 成功返回 true，失败返回 false，且会触发 Warning（除非用 @rename() 抑制，但不推荐）。
- 目标路径必须有写权限，且不能与源文件在不同分区（Linux/macOS 下跨挂载点会失败；Windows 稍宽松，但仍建议同盘操作）
- 如果目标文件已存在，
rename()会直接覆盖（无提示），这是最常被忽略的风险点 - 不要对正在被 Web 服务器（如 Apache/Nginx）读取的 PHP 文件执行
rename()，可能导致 500 或部分请求加载旧字节码（OPcache 未刷新时）
if (rename('/var/www/old_script.php', '/var/www/new_script.php')) {
echo "文件名已更新";
} else {
echo "重命名失败，请检查权限或路径";
}回滚依赖你是否提前记录了原始信息
PHP 不保存历史快照，所谓“恢复旧名”，本质是你自己得留好“旧名 → 新名”的映射关系。没有预存，就无法可靠回滚——文件系统不会记住它曾经叫什么。
常见做法是把原始文件名写进日志、数据库或临时配置文件。如果只是单次手动操作，最简单的是在 rename 前先 copy() 一份备份：
立即学习“PHP免费学习笔记（深入）”；
-
copy('old.php', 'old.php.bak')比rename()更安全，因为备份失败不影响主流程 - 若已 rename 过且没备份，只能靠文件系统级工具（如 ext4 的
debugfs或 macOS 的 Time Machine），但成功率极低，不具实操性 - Web 部署场景下，建议用版本控制（Git）管理文件名变更，
git mv old.php new.php后 commit，回滚只需git checkout HEAD~1 -- old.php new.php
批量重命名要防覆盖和顺序依赖
比如要把 a.php → b.php、b.php → a.php，直接循环 rename() 会导致第二个操作失败（因为 b.php 已被第一个操作删掉）。必须引入中间名或先统一备份。
- 推荐策略：先全部
rename($old, $old . '.tmp')，再统一rename($old . '.tmp', $new) - 或者用数组记录所有变更：
$map = ['a.php' => 'b.php', 'b.php' => 'a.php']，再按拓扑顺序处理（需检测环） - 别用
glob("*.php")+foreach直接 rename，文件列表顺序不确定，容易踩坑
OPcache 和 Web 服务器缓存会让“新名”延迟生效
即使 rename() 成功，用户访问新文件名仍可能看到旧内容，原因有两个：
- PHP OPcache 缓存了旧文件的编译字节码，key 默认是完整绝对路径；rename 后路径变了，但旧缓存可能还在（尤其
opcache.validate_timestamps=0时） - Nginx/Apache 可能缓存了 fastcgi / proxy 的响应头或内容（非 PHP 层面）
回滚时同样要注意：如果只改回文件名，但 OPcache 还记着新路径的字节码，反而会加载错误版本。稳妥做法是改名后调用 opcache_invalidate('/full/path/to/new_script.php', true)，或干脆 opcache_reset()（开发环境可用，生产慎用）。
实际操作中，最难的不是 rename 本身，而是确认「此刻线上到底在跑哪个文件」——路径、符号链接、include 路径、OPcache key、CDN 缓存，每一层都可能偏离你的预期。
