为什么PHP上传文件超过2M就失败_修改upload_max_filesize与post_max

php上传超2m文件失败的根本原因是upload_max_filesize和post_max_size未同步调优，且web服务器（nginx/apache）的client_max_body_size或limitrequestbody未同步放宽，三者缺一不可。

为什么php上传文件超过2m就失败_修改upload_max_filesize与post_max_size

PHP上传文件超过2M失败，根本原因不是“默认限制太小”，而是upload_max_filesize和post_max_size两个配置中至少有一个没调到位，或改了但没生效。

upload_max_filesize 和 post_max_size 必须同时改

这两个值不是可选其一的开关，而是串联生效的硬性关卡：

upload_max_filesize 控制单个文件最大允许大小（比如你设成 64M）
post_max_size 控制整个 POST 请求体上限，包括所有文件 + 表单字段 + 文件头等开销
哪怕 upload_max_filesize = 64M，只要 post_max_size = 8M（PHP 默认值），上传一个 5M 文件也会失败——因为 POST 总体积已超限
建议 post_max_size 比 upload_max_filesize 至少大 5–10%，例如：设 upload_max_filesize = 64M，则 post_max_size = 72M 或 128M

改完 php.ini 后不生效的常见原因

很多人改了配置却还是报错，问题往往出在「改错了文件」或「没重启服务」：

PHP

编写健壮的PHP代码，规避类型转换陷阱、数组怪癖及常见安全漏洞。

下载

用 phpinfo() 页面确认 “Loaded Configuration File” 路径，只编辑这个文件；别碰 php.ini-development 或其他副本
修改后必须重启 PHP-FPM（Nginx 环境）或 Apache（Apache 环境），不是刷新网页就能生效
宝塔用户注意：点「保存」后还要点「重载配置」，否则 PHP 进程仍用旧配置
命令行 PHP（如 php -S）和 Web 服务器用的可能是不同 php.ini，需分别检查

Nginx 或 Apache 本身也在拦截大请求体

PHP 层放开后，Web 服务器若没同步调整，照样会直接拒绝请求，错误通常不提示具体原因，只显示 413 Request Entity Too Large 或空白页：

Nginx：必须在配置中加 client_max_body_size，推荐放在 http 或 server 块里，例如：client_max_body_size 64M;，然后 nginx -s reload
Apache：检查是否有 LimitRequestBody 限制，例如：LimitRequestBody 67108864（64MB），该指令需放在虚拟主机或 <directory></directory> 段内
注意：.htaccess 中的 php_value upload_max_filesize 在多数生产环境已被禁用，不要依赖它

上传失败时最该先看的错误信息

别猜，直接查日志或响应头：

PHP 错误日志里出现 POST Content-Length of XXX bytes exceeds the limit of YYY bytes → post_max_size 不够
浏览器开发者工具 Network 标签中看到 413 错误 → Nginx/Apache 的 client_max_body_size 或 LimitRequestBody 拦截了
上传后页面空白、无报错、$_FILES 为空 → 很可能是 upload_max_filesize 或 post_max_size 其中一个被忽略，或 ini 文件语法写错（比如多加了引号：upload_max_filesize = "64M" 是非法的）
上传中途断掉、提示超时 → 还得调 max_execution_time 和 max_input_time，尤其对 100MB+ 文件，30 秒远远不够

真正卡住人的地方，往往不是不知道要改哪几个参数，而是改了其中一个就以为搞定了，或者改了却没确认是否作用在当前运行的 PHP 实例上。每次调完，务必用 phpinfo() 刷新验证三者：upload_max_filesize、post_max_size、client_max_body_size（Nginx）或 LimitRequestBody（Apache）——缺一不可。