rename() 默认直接覆盖目标同名文件，不报错不提示；需手动检查file_exists()或改用move_uploaded_file()避免覆盖。
php rename() 移动文件时会覆盖目标位置的同名文件
直接说结论：rename() 在 PHP 中执行「移动」或「重命名」操作时，如果目标路径（$newname）已存在同名文件，**默认直接覆盖，不报错、不提示、不询问**。这不是“移动失败”，而是设计如此——它本质是原子性的系统级 rename(2) 系统调用，linux/macos 下覆盖即成功，windows 下也遵循类似语义。
常见错误现象：rename('a.txt', 'b.txt') 后发现 b.txt 原内容消失，但没报错，开发者误以为“移动失败”而漏掉日志或回滚逻辑。
- 使用场景：批量处理上传文件、日志归档、临时文件落盘时最易踩坑
- 参数差异：
rename($oldname, $newname)的$newname必须是完整路径（含文件名），不能只传目录 - 性能影响：覆盖是原子操作，比先
unlink()再copy()快得多，也更安全（避免中间态残留） - 兼容性注意：Windows 下若目标文件被其他进程打开（如记事本正在编辑），
rename()会失败并返回false，Linux 下通常仍可覆盖（取决于文件锁类型）
想避免意外覆盖？得自己加判断和防护
rename() 没有内置开关控制是否覆盖，必须手动检查目标是否存在。别依赖 is_writable() 或 file_exists() 后再调用——这之间存在竞态窗口（其他进程可能抢先创建同名文件）。
稳妥做法是用 rename() 自身的返回值 + 异常兜底：
立即学习“PHP免费学习笔记（深入）”；
- 始终检查返回值：
if (rename($src, $dst) === false) { /* 处理失败 */ } - 若需严格禁止覆盖，先用
file_exists($dst)判断，但仅适用于低并发场景 - 高并发下建议用唯一后缀（如
uniqid()）生成目标名，或改用copy()+unlink()组合（牺牲原子性换可控性） - 注意：PHP 8.1+ 对
rename()跨文件系统移动支持更稳，但跨分区仍可能退化为 copy+delete，此时覆盖行为不变
Windows 下重命名失败的典型错误信息
Windows 对文件句柄更敏感，常见失败时 rename() 返回 false，且 error_get_last() 可能返回：
-
"Warning: rename(): Cannot rename file: Permission denied"—— 目标文件正被占用 -
"Warning: rename(): No such file or Directory"—— 源路径不存在，或目标目录不可写/不存在 -
"Warning: rename(): Argument #2 ($newname) is not a valid path"——$newname路径含非法字符或过长（尤其 UNC 路径）
解决方法：确保目标目录存在且可写（mkdir(..., 0755, true)），关闭所有可能占用目标文件的程序，避免使用中文全角符号或 混用（统一用 / 或 DIRECTORY_SEPARATOR）。
替代方案：move_uploaded_file() 的覆盖规则不同
上传文件专用函数 move_uploaded_file() 行为更保守：**如果目标文件已存在，它会直接失败并返回 false，不会覆盖**。这是它和 rename() 最关键的区别。
- 适用场景：处理用户上传时，天然具备防覆盖保护，无需额外判断
- 限制：只能用于
$_FILES临时文件，不能用于普通文件移动 - 注意：
move_uploaded_file()仍要求目标目录存在且可写，否则报错 - 别混用：
move_uploaded_file($tmp, $dest)和rename($tmp, $dest)效果看似一样，但覆盖策略不同，切勿想当然替换
真正麻烦的不是覆盖本身，而是开发者默认它“应该安全”，结果在生产环境静默覆盖了配置文件或用户数据。留个心眼，检查返回值，比事后恢复快得多。