PHP上传大文件失败首要检查upload_max_filesize和post_max_size配置是否同步调大，二者必须同时修改且post_max_size≥upload_max_filesize，否则上传会静默失败或$_FILES为空；还需同步调整Nginx的client_max_body_size、Apache的LimitRequestBody及max_execution_time、memory_limit等参数。
PHP上传大文件失败，先看错误日志里有没有 upload_max_filesize 或 post_max_size 相关提示
大多数“上传失败但没报错”或“上传后 $_FILES 为空”的情况，根源就在这两个配置。它们不是 PHP 的默认值问题，而是被 php.ini 显式限制了——而且这两个值必须同时调大，否则改一个等于白改。
常见错误现象包括：
-
$_FILES数组完全为空，$_POST也收不到数据 - 浏览器上传进度条走到 100% 后卡住，服务端无响应（其实是 Nginx/Apache 在读取请求体时被截断）
- PHP 错误日志中出现
PHP Warning: POST Content-Length of XXX bytes exceeds the limit
修改 upload_max_filesize 和 post_max_size 的实际操作步骤
这两个配置必须在生效的 php.ini 文件中修改，不能靠 ini_set() 动态设置（它们是 PHP_INI_PERDIR 级别，仅在启动时读取）。
- 先用
php --ini（命令行）或phpinfo()（Web 环境）确认你改的是**正在加载的 php.ini 路径** -
upload_max_filesize控制单个文件上限，比如设为128M；post_max_size必须 ≥upload_max_filesize+ 预估表单其他字段开销（一般多加 8–16M 就够），例如设为144M - 改完后必须重启 Web 服务：
sudo systemctl restart php-fpm（PHP-FPM 模式）或sudo systemctl restart apache2/sudo systemctl restart nginx（注意：Nginx 本身不解析 PHP，但需 reload 让它把请求继续转发给更新后的 PHP 进程）
别忘了 Web 服务器层的限制：Nginx 和 Apache 都会拦你
即使 PHP 层全放开，Nginx 或 Apache 仍可能在请求体到达 PHP 前就直接拒绝。这是最常被跳过的环节。
立即学习“PHP免费学习笔记（深入）”；
- Nginx：检查
client_max_body_size，它必须 ≥post_max_size（推荐设为相同值，如144M），位置在http、server或location块中，改完执行sudo nginx -t && sudo nginx -s reload - Apache：如果用
mod_php，主要看LimitRequestBody（单位是字节，默认 0 表示不限，但某些发行版会预设为 512MB 或更小）；如果用 PHP-FPM，则 Apache 本身限制较宽松，重点仍在 Nginx 或 FPM 的request_terminate_timeout等超时设置 - Cloudflare 或其他 CDN/反代层也会拦截大 POST 请求，若启用，需确认其上传限制（如 Cloudflare 默认限 100MB）
上传超时和内存限制也得同步调：不然文件刚传完就崩
大文件上传耗时长，PHP 默认的 max_execution_time 和 memory_limit 很容易触发超时或内存溢出，尤其在用 move_uploaded_file() 前做校验、压缩、转码等操作时。
-
max_execution_time建议设为300（5 分钟）或更高；若用set_time_limit(0)，仅对当前脚本有效，且不能绕过 Web 服务器超时（如 Nginx 的fastcgi_read_timeout） -
memory_limit至少留出 2–3 倍于文件大小的余量（PHP 处理文件流、临时复制、GD/ImageMagick 加载图片等都会吃内存） - 额外建议：在上传逻辑开头加
ignore_user_abort(true)并用set_time_limit(0)防止用户关闭页面中断处理，但这只适用于后台异步处理场景，不是上传本身
真正麻烦的不是改哪几个值，而是每层限制都得对齐：php.ini → Web 服务器 → 反代/CDN → 客户端 JS 的 XMLHttpRequest timeout 设置。漏一层，上传就停在那不动，还查不出原因。
