move_uploaded_file失败但不报错，因其仅返回false且错误被静默记录；常见原因包括$_FILES为空、临时文件缺失、目标目录不可写、upload_max_filesize超限等。
为什么 move_uploaded_file 会失败但不报错？
它本身不抛异常，只返回 false，而错误被静默压进 PHP 的错误日志（或被 @ 抑制）。常见原因不是代码写错，而是上传上下文没满足——比如 $_FILES 为空、临时文件已被删、目标目录不可写、或 upload_max_filesize 超限但没在表单里体现。
实操建议：
- 先检查
$_FILES['file']['error'] === UPLOAD_ERR_OK，别跳过这个判断 - 用
is_uploaded_file($_FILES['file']['tmp_name'])确认文件确实来自POST上传，防止路径伪造 - 目标路径必须是绝对路径，相对路径容易因
chdir()或 CLI 工作目录导致失败 - 确保
sys_get_temp_dir()返回的临时目录和$_FILES['file']['tmp_name']实际一致，某些容器环境会挂载不同 tmpfs
move_uploaded_file 和 copy 的本质区别在哪？
它不只是“复制+删除”，而是 PHP 内部调用一个原子性校验流程：先验证源文件是否在 upload_tmp_dir 下且未被修改，再用系统级 rename()（Linux/macOS）或安全复制（Windows）完成移动。这意味着它无法跨文件系统移动，也不能处理符号链接源文件。
关键差异点：
立即学习“PHP免费学习笔记（深入）”；
-
move_uploaded_file会拒绝非上传产生的临时文件（哪怕路径对），copy不管来源 - 目标目录的父级必须存在且可写，
move_uploaded_file不会自动创建中间目录 - 如果目标文件已存在，它直接覆盖，不提示也不报错——这点常被忽略，导致旧文件被静默替换
- Windows 下若目标正在被其他进程打开（如记事本），会失败并返回
false，Linux 下通常成功
上传后重命名文件时怎么避免冲突和安全风险？
别直接拼接原始 $_FILES['file']['name']，它可能含 ../、空字节、控制字符或恶意扩展名。PHP 不做任何过滤，全靠你把关。
安全做法：
- 用
pathinfo($filename, PATHINFO_EXTENSION)提取扩展名，再白名单校验（如in_array(strtolower($ext), ['jpg', 'png', 'pdf'])） - 生成新文件名用
uniqid() . bin2hex(random_bytes(8))，别用时间戳或自增 ID - 目标路径用
dirname($target) . '/' . $safe_filename拼接，再通过realpath()+str_starts_with()校验是否仍在允许的上传根目录内 - 上传完成后立刻
chmod($target, 0644)，防止 web server 进程以外的用户读取（尤其共享主机）
大文件上传时 move_uploaded_file 卡住或超时怎么办？
它本身不耗时，卡住通常是前置环节出问题：Nginx 的 client_max_body_size 拦截了请求、PHP-FPM 的 request_terminate_timeout 杀掉了进程、或浏览器在 POST 阶段就断连。
排查顺序：
- 查 Nginx error log 是否有
client intended to send too large body - 确认
php.ini中post_max_size≥upload_max_filesize，且两者都大于文件体积 - PHP 脚本开头加
set_time_limit(0)，但更关键是检查max_execution_time是否被 SAPI（如 Apache mod_php）强制覆盖 - 用
curl -v -F "file=@large.zip" http://yoursite.com/upload.php绕过浏览器，确认是否前端限制导致
真正的大文件（>500MB）建议改用分片上传或 PUT 接口，别依赖 move_uploaded_file 做主干流程。
