PHP怎样调整上传文件限制_PHP调整上传文件限制改动【限制】

upload_max_filesize 控制单个文件大小，post_max_size 限制整个 POST 请求体且必须 ≥ 前者，否则 $_FILES 和 $_POST 均为空；还需同步调整 nginx 的 client_max_body_size。

php.ini 中 upload_max_filesize 和 post_max_size 的关系

PHP 文件上传限制由两个配置项共同决定：upload_max_filesize 控制单个文件最大体积，post_max_size 控制整个 POST 请求体（含所有字段、文件、边界符）的上限。后者必须 ≥ 前者，否则即使单文件没超限，上传也会失败并静默卡在 $_FILES 为空或 UPLOAD_ERR_NO_FILE。

常见错误现象：表单提交后 $_FILES 为空，$_POST 也为空，且无明确报错——大概率是 post_max_size 被触发，导致整个请求体被截断。

• upload_max_filesize 只影响 $_FILES 中的文件项，不控制其他 POST 字段
• post_max_size 是硬性闸门：一旦超过，PHP 直接丢弃全部 POST 数据，$_POST 和 $_FILES 都为空
• 修改后必须重启 Web 服务器（如 Apache 或 PHP-FPM），仅 reload 不生效

如何确认当前生效的限制值

不能只看 php.ini 文件内容，因为运行时可能被 .htaccess、ini_set()、Docker 环境变量或 SAPI 层覆盖。最可靠方式是直接查运行时配置：

注意：ini_get() 返回的是字符串（如 "2M"），不是 字节 数；若需做数值比较，可用 ini_parse_quantity()（PHP 8.1+）或手动转换（如 return (int)ini_get('upload_max_filesize') * 1024 ** ($unit === 'M' ? 2 : ($unit === 'G' ? 3 : 1))）。

立即学习“PHP 免费学习笔记（深入）”；

• CLI 模式下 php -i | grep -E 'upload_max_filesize|post_max_size' 查看 CLI 配置，与 Web 模式无关
• 使用 phpinfo() 页面时，重点看“Loaded Configuration File”路径，并核对“Master Value”和“Local Value”是否一致
• 某些共享主机禁用 ini_set() 修改这些选项，强行调用会静默失败

nginx + PHP-FPM 场景下额外要改 client_max_body_size

当 PHP 运行在 nginx 后端 时，nginx 本身也会拦截大请求。即使 PHP 层允许 100MB，若 nginx 的 client_max_body_size 仍为默认 1MB，则请求根本到不了 PHP，返回 413 Request Entity Too Large。

需在 nginx 配置中显式设置（通常在 http、server 或 location 块内）：

client_max_body_size 100M;

修改后执行 nginx -t && nginx -s reload 生效。该值应 ≥ post_max_size，否则 前端 就被拦下了。

• 如果用 FastCGI，还需检查 fastcgi_buffers 和 fastcgi_buffer_size，极端大文件上传可能触发缓冲区溢出（但一般 100MB 内无需调整）
• Docker 环境中，若通过环境变量传入 PHP 配置（如 -e PHP_UPLOAD_MAX_FILESIZE=100M），需确认基础镜像是否支持该机制（如 official php:apache 默认不处理）

临时绕过限制的替代方案（不推荐长期使用）

有些场景无法修改服务器配置（如第三方托管、CI 环境测试），可考虑分片上传或前端压缩。但要注意：

• JavaScript 的 File.slice() 或 stream().pipe() 可切片，但服务端必须自己拼接，PHP 原生不支持“续传”或“分片合并”
• 前端 ZIP 压缩（如 JSZip）能减小体积，但用户需安装额外库，且压缩 / 解压消耗 CPU，移动端易卡顿
• set_time_limit(0) 不能解决上传超时，它只影响脚本执行时间；上传超时由 web server（如 nginx client_header_timeout / client_body_timeout）和 PHP max_input_time 共同控制

真正难调的从来不是改几个数字，而是确认哪一层（nginx → PHP-FPM → php.ini → .htaccess → Docker → 宿主机）实际生效，以及谁在静默丢弃请求。