WordPress安装提示超过upload_max_filesize限制怎么办

引言

在后台点”上传插件”或”上传主题”，选中一个稍大一点的压缩包，进度条刚出现就弹出一行红字：上传的文件超过 upload_max_filesize 指令的限制。也可能提示”超出服务器上传大小限制”或”The uploaded file exceeds the upload_max_filesize directive in php.ini”。这个问题的意思很直白：PHP 给单次上传设定的最大文件体积太小了，而你传的包比它还大。默认情况下，很多环境的单文件上限只有 2M 甚至更小，而如今一个带示例数据的主题、一个功能丰富的插件，动辄十几兆、几十兆，分分钟就顶破限制。看着是个”服务器硬限制”，其实绝大多数情况下有办法调大，只要同时照顾到 PHP 和 Web 服务器两层配置，就能顺利把大文件传上去。

故障原因分析

1. upload_max_filesize 设置太小。 这是”单文件”允许的最大体积，是最直接的瓶颈。

2. post_max_size 没跟着调。 整个 POST 请求的体积上限由它控制，如果它比单文件上限还小，实际上以更小的那个为准，两者必须一起调，单独改一个通常看不到效果。

3. memory_limit 偏低。 处理大文件时 PHP 需要在内存里操作，内存不够同样会失败，解压大包时尤其吃内存。

4. Nginx 的 client_max_body_size 拦截。 Nginx 默认只允许约 1M 的请求体，很多时候 PHP 那边放宽了，却栽在 Nginx 这一层，表现为 413 错误。

5. 主机商在更底层做了硬性限制。 部分虚拟主机的环境无法由用户修改，属于套餐天花板，这种情况下无论怎么改配置都无济于事，只能靠手动上传或换套餐、换服务器来解决。

分步解决方案

方法一：宝塔面板图形化设置

进入宝塔【软件商店】→ 对应 PHP 版本【设置】→【配置修改】，把下面三项都调大，然后保存并重启 PHP：

; php.ini
upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 300

注意 post_max_size 要大于或等于 upload_max_filesize，同时 memory_limit 最好不低于前两者中的较大值。

方法二：用 .user.ini 覆盖（PHP-FPM 环境）

宝塔等 PHP-FPM 环境中，可以在网站根目录创建或修改 .user.ini：

; .user.ini —— 放在网站根目录
upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M

一般等几分钟由 PHP 自动重载，或重启 PHP-FPM 生效，注意 .user.ini 只对所在目录及其子目录生效，放在网站根目录最稳妥。

方法三：调整 Nginx 的请求体上限

在站点配置的 server 段中加入：

# nginx 站点配置
client_max_body_size 64m;

宝塔用户也可在【网站】→ 站点【设置】→【配置文件】中修改，保存后重载 Nginx，改错位置会导致整站无法访问，动配置文件之前先备份一份。

方法四：提高 WordPress 可用内存

在 wp-config.php 中加一行，让 WordPress 自己申请更多内存：

// wp-config.php
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

这两个常量只作用于 WordPress 自身，不会改变 PHP 的实际上限，通常与上面几项配合使用。

方法五：绕过限制，直接上传

如果空间实在改不动，就用 FTP 把解压后的主题/插件文件夹直接传到 wp-content/themes/ 或 wp-content/plugins/，一样能在后台启用，完全绕开上传环节；传之前记得先把压缩包在本地解压好，服务器上只需要一个完整的文件夹。

常见踩坑点

1. 只改了 upload_max_filesize。 别忘了 post_max_size 要一起调大，否则改了也白改。
2. 忽略 Nginx 层。 PHP 都调好了却依然报 413，多半是 client_max_body_size 没动。
3. 在 .htaccess 里写 php_value。 Nginx + PHP-FPM 环境不认这套写法，得用 .user.ini 或面板设置。
4. 改完没重载服务。 无论改 php.ini 还是 nginx.conf，都要重启对应服务才生效。
5. 盲目调到极大。 一次性设成几个 G 反而可能带来内存风险，按需设到 64M、128M 通常就够用。
6. 只改一处、让别的站点跟着变。 在面板全局改 PHP 配置会影响到同版本下的所有站点，只想给单个站点放宽时，优先用 .user.ini 或站点级配置。

总结

上传超大文件被拦，本质是”服务器给上传留的口子太小”，而不是 WordPress 的错。处理它的关键思路是分层看：先确认 PHP 里的 upload_max_filesize 与 post_max_size 都调大了，再看 Nginx 的 client_max_body_size 是否放行，最后确认内存和执行时间足够。宝塔面板用户改起来最省事，一条条在配置里调好重启即可；参数之间也讲究配合，上传上限、POST 上限、内存上限和 Nginx 请求体限制要成套调整，不能顾此失彼。实在受限的环境，则用 FTP 直接上传解压后的文件夹来绕开限制。只要按需把这几处限制对齐，之后再装大体积主题和插件就不会再被这句话挡住了。如果空间坚决不肯放手，FTP 手动上传永远是最后的可靠退路，麻烦一点但一定管用。必要时也可以考虑把 WordPress 迁移到能自主配置 PHP 的服务器上，长期看更省心。