$_FILES为空或move_uploaded_file()返回false，根本原因不是PHP 8.5.5引入的新问题，而是上传链路中断：需依次排查form enctype、input name一致性、AJAX的FormData使用、upload_max_filesize限制、目标目录存在性与权限、Web服务器body大小限制及upload_tmp_dir绝对路径可写性。
$_FILES 为空或 move_uploaded_file() 返回 false，不是 PHP 8.5.5 的新问题，而是上传链路上某个环节断了。这个版本本身不改变上传机制，排查逻辑和以前完全一致——但你得按顺序卡住几个关键点。
检查 $_FILES 是否为空，先别碰代码逻辑
这是 90% 失败的第一现场。如果 var_dump($_FILES) 输出 array(0) { } 或直接报 Undefined index，说明文件压根没进 PHP。
- 确认 HTML
<form>有enctype="multipart/form-data"，缺这个浏览器根本不会发二进制数据 -
<input type="file">的name属性必须和 PHP 中读取的键名（如$_FILES['avatar']）**完全一致**，包括大小写 - 如果是 AJAX 提交，确保用了
FormData.append('avatar', fileInput.files[0])，且**没手动设置Content-Type头**（会破坏 multipart 边界） - PHP 8.5.5 默认禁用
register_globals，别指望靠全局变量自动映射
$_FILES['xxx']['error'] 是 1、2、3 还是 4？看码说话
错误码比任何日志都准。别只盯着 move_uploaded_file() 返回 false，先查 error 值：
-
UPLOAD_ERR_INI_SIZE（值为 1）：超了upload_max_filesize，改php.ini后必须重启 php-fpm 或 Apache/Nginx -
UPLOAD_ERR_FORM_SIZE（值为 2）：表单里写了<input type="hidden" name="MAX_FILE_SIZE" value="1048576">，但这个值可被绕过，仅作前端提示，不建议依赖 -
UPLOAD_ERR_PARTIAL（值为 3）：网络中断或客户端取消，tmp_name可能存在但内容不全 -
UPLOAD_ERR_NO_FILE（值为 4）：用户根本没选文件，或input被 JS 清空过
move_uploaded_file() 失败但 error === 0？目标路径在“装死”
临时文件已存好（tmp_name 有效），但搬不到你要的位置——这时候问题不在上传，而在落地。
- 目标目录必须**提前存在**：
move_uploaded_file()不会自动创建父级目录，得先mkdir(dirname($target), 0755, true) - Web 服务器进程用户（如
www-data、nginx或www）必须对目标目录有**写权限**；用ps aux | grep php-fpm确认实际用户，再chown -R www-data:www-data /path/to/uploads - Linux 下别用
chmod -R 777，生产环境极不安全；推荐chmod -R 755（目录） +644（文件） - 容器或 SELinux 环境下，挂载卷可能默认不可写，或策略阻止写入，需额外配置
别漏掉 Web 服务器层的 body size 限制
PHP 配置调大了，但 Nginx/Apache 拦在前面，$_FILES 依然为空。
立即学习“PHP免费学习笔记（深入）”；
- Nginx：检查
client_max_body_size，必须 ≥post_max_size，改完 reload（sudo nginx -s reload） - Apache：检查
LimitRequestBody或mod_security规则是否拦截了大 POST - Cloudflare 等 CDN 也会截断大请求，上传失败时顺手查下 CF 日志
upload_tmp_dir 的路径解析更严格，如果设了相对路径或含符号链接，且权限/上下文不对，tmp_name 可能生成失败却无明确报错。务必用绝对路径，并确保该目录对 PHP 进程可写——哪怕你没显式配置它，也要确认系统默认 /tmp 是否被清理工具误删或挂载为 noexec。 
