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 层覆盖。最可靠方式是直接查运行时配置：
<?php
var_dump(ini_get('upload_max_filesize'));
var_dump(ini_get('post_max_size'));
var_dump(ini_get('max_execution_time'));
?>注意：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免费学习笔记（深入）”；
后台主要功能如下：1） 系统管理：管理员管理，网站配置，上传文件管理,QQ-MSN 在线客服设置。2） 企业信息：后台自由添加修改企业的各类信息及介绍。3） 产品管理：产品类别新增修改管理，产品添加修改以及产品的审核。4） 调查管理：发布修改新调查。5） 会员管理：查看修改删除会员资料，及锁定解锁功能。可在线给会员发信！6） 新闻管理：能分大类和小类新闻，不再受新闻栏目的限制。7） 留言管理：管理
- 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（如 nginxclient_header_timeout/client_body_timeout）和 PHPmax_input_time共同控制
真正难调的从来不是改几个数字，而是确认哪一层（nginx → PHP-FPM → php.ini → .htaccess → Docker → 宿主机）实际生效，以及谁在静默丢弃请求。
