move_uploaded_file返回false却无报错，主因是open_basedir限制目标路径、临时目录不在允许范围、同名文件被静默覆盖、MIME类型仅依赖$_FILES['type']校验失效、权限设为0600且属组锁定；需检查ini_get('open_basedir')与upload_tmp_dir配置，生成唯一文件名，用finfo_open校验真实MIME，chmod操作须在移动成功后执行。
move_uploaded_file 返回 false 却没报错？先查 open_basedir
这个函数在 PHP 7.4 中对 to 参数路径做严格检查，但不检查 from（即 $_FILES['x']['tmp_name']），所以即使临时文件存在、权限正常，只要目标路径不在 open_basedir 范围内，就静默返回 false，连 warning 都不抛。
- 运行
echo ini_get('open_basedir');确认当前限制范围 - 用
echo ini_get('upload_tmp_dir');查临时目录，并确保它和你的目标上传目录（比如/var/uploads）都列在open_basedir值里，格式如：/var/www:/tmp:/var/uploads - 修改
php.ini后必须重启 php-fpm 或 Apache，仅 reload 不生效
文件被覆盖了还不知道？别直接用原始文件名
move_uploaded_file() 默认覆盖同名目标文件，没有警告、不回滚、不提示——并发上传或用户重试时，前一次内容直接丢弃。
- 永远不要拼接
basename($_FILES['file']['name'])作为最终文件名 - 生成唯一名推荐组合：
date('YmdHis') . '_' . bin2hex(random_bytes(8)) . '.' . pathinfo($original, PATHINFO_EXTENSION) - 如果业务强制要求保留原名，至少加一层存在性检测：
if (file_exists($target_path)) { /* 拒绝 or 重命名 */ }，但注意竞态条件，生产环境建议用flock()或数据库记录锁
chmod(0644) 不是万能解药，得看 Web 进程用户身份
Linux 下 move_uploaded_file() 强制设权限为 0600，属主属组锁定为 Web 进程用户（如 www-data）。你调 chmod(0644, $path) 能改权限位，但改变不了属组——如果归档脚本或 CLI 任务由另一用户（如 backup）执行，仍可能读不到。
- 查 Web 进程用户：
ps aux | grep -E '(apache|nginx|php-fpm)' | head -1，看 UID/GID - 若需跨用户访问，优先用
setgid目录 + 统一属组（如chgrp www-data /var/uploads && chmod g+s /var/uploads），而非放宽 world 权限 -
chmod必须紧跟move_uploaded_file()成功之后，失败时调用会报错
MIME 类型校验不能只信 $_FILES['type']
客户端提交的 $_FILES['file']['type'] 可被任意篡改，move_uploaded_file() 完全不校验这个字段。靠它放行文件，等于给恶意脚本开后门。
立即学习“PHP免费学习笔记（深入）”；
- 必须用
finfo_open(FILEINFO_MIME_TYPE)重新探测真实 MIME：$finfo = finfo_open(); $real_type = finfo_file($finfo, $_FILES['file']['tmp_name']); - 白名单比黑名单更可靠，例如只允许
image/jpeg、application/pdf，拒绝所有text/*和application/x-php - 扩展名要从
pathinfo()提取，不要从原始$_FILES['file']['name']解析，避免shell.php.jpg这类绕过
最常被忽略的是：临时文件生命周期极短，脚本结束即删；一旦 move_uploaded_file() 失败，再想读 tmp_name 就是空文件或报错。所有校验、重命名、权限调整，必须在单次请求内串行完成，没法“回头补”。
