本文约 3,666 字，预计阅读 10 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：主题包 30MB，后台上传直接失败
从 ThemeForest 或国内主题站下载的商业主题，压缩包动辄二三十兆，有的带演示内容的完整包能到上百兆。后台「外观 → 主题 → 添加新主题 → 上传主题」选中文件，进度条走一半就没了，页面提示「上传的文件超出 upload_max_filesize 指令限制」或干脆只留一句「安装失败」。换浏览器、换网络都没用，因为限制不在客户端，而在服务器。
这类限制其实由三个互不相干的参数共同决定，只改其中一个往往不生效。更麻烦的是虚拟主机环境下你可能改不了 php.ini，需要换用 .htaccess 或主机面板的方式。本文先讲清三个参数的关系，再给出四种按权限从高到低的修改方式，最后说明「完全不碰限制」的 FTP 上传方案——这也是生产环境最稳的做法。
原理分析：三个参数，谁卡住了你
上传一个文件时，PHP 与 Web 服务器会依次做检查：
| 参数 | 作用 | 谁设置 | 必须满足 |
|---|---|---|---|
upload_max_filesize |
单个上传文件上限 | php.ini | 大于主题包体积 |
post_max_size |
整个 POST 请求上限 | php.ini | 大于 upload_max_filesize |
memory_limit |
PHP 内存上限 | php.ini | 解压时够用 |
client_max_body_size |
Nginx 请求体上限 | nginx.conf | 大于主题包体积 |
max_execution_time |
脚本最长执行时间 | php.ini | 解压不超时 |
三条硬规则：post_max_size 必须大于 upload_max_filesize，否则文件还没到 PHP 就被拒；memory_limit 必须大于 post_max_size；Nginx 上的 client_max_body_size 独立于 PHP，改了 PHP 不管用，仍会在 413 Request Entity Too Large 处失败。
Apache 环境（开了 mod_php 或 PHP-FPM + .htaccess 生效）可以用 .htaccess 的 php_value 覆盖；Nginx 环境 .htaccess 完全无效，必须改 php.ini 或 PHP-FPM 的 pool 配置。主机面板（cPanel 的 MultiPHP INI Editor、宝塔的 PHP 设置）本质上也是在改 php.ini，只是给了可视化入口。
WordPress 自身还有一个 upload_size_limit 过滤器，它只影响后台显示的「最大上传文件大小」文案与实际校验值，无法突破 PHP 层面的硬限制——把过滤器设成 1GB 而 PHP 只给 2MB，上传依然失败。这一点常被误解。
保姆级实操
- 先看当前值：后台「工具 → 站点健康 → 信息 → 服务器」里能看到
upload_max_filesize、post_max_size等实际生效值，这是判断依据。 - 改
php.ini（推荐）：找到php.ini路径（站点健康信息里有「PHP 配置文件路径」），把三个参数一起调大，改完重启 PHP-FPM。 - 改不了
php.ini时用.htaccess：仅 Apache 有效，写两行php_value即可，无需重启。 - 虚拟主机用
wp-config.php：@ini_set()可以尝试覆盖，但部分主机禁止运行时修改，属于保底方案。 - Nginx 单独改：在
server块里加client_max_body_size，改完nginx -t && nginx -s reload。 - 绕开限制：FTP 上传：把主题包在本地解压，用 FTP 把整个主题文件夹传到
wp-content/themes/，再到后台启用。或者在服务器上传 zip 后用命令行解压。
; php.ini：三个参数一起调，改完需重启 PHP-FPM
upload_max_filesize = 64M
post_max_size = 80M
memory_limit = 256M
max_execution_time = 300
max_input_time = 300
# nginx.conf 的 server 块：Nginx 有自己的请求体限制
server {
listen 80;
server_name example.com;
client_max_body_size 64m;
location / {
try_files $uri $uri/ /index.php?$args;
}
}
# .htaccess：仅 Apache + PHP 模块模式有效，Nginx 忽略此文件
php_value upload_max_filesize 64M
php_value post_max_size 80M
php_value memory_limit 256M
php_value max_execution_time 300
<?php
// wp-config.php 保底：部分主机允许运行时覆盖
@ini_set( 'upload_max_filesize', '64M' );
@ini_set( 'post_max_size', '80M' );
@ini_set( 'memory_limit', '256M' );
@ini_set( 'max_execution_time', '300' );
// 只调整后台显示的上传上限提示（不能超过 PHP 实际限制）
add_filter( 'upload_size_limit', function( $size ) {
return 64 * 1024 * 1024; // 64MB
} );
# FTP / SSH 方案：服务器本地解压，完全不走 PHP 上传
cd wp-content/themes/
unzip -q ~/mytheme.zip
ls -1 mytheme | head
# 确认 style.css 与 index.php 在 mytheme/ 根目录下
test -f mytheme/style.css && echo "结构正确"
chown -R www-data:www-data mytheme # 按实际运行用户调整
find mytheme -type d -exec chmod 755 {} \;
常见踩坑
- 只改
upload_max_filesize：post_max_size仍是 8M，报错变成「POST 内容超出限制」，看起来像新问题，其实是没改全。 - 改了
php.ini没重启：PHP-FPM 需要 reload 才读取新配置，Apache mod_php 需要重启 Apache。 - 改错
php.ini文件：CLI 和 FPM 用的是两个不同的php.ini。命令行php -i看到的值不代表网站生效值，以站点健康信息为准。 - Nginx 环境写
.htaccess：完全无效，必须改client_max_body_size，否则报 413。 - FTP 上传后权限不对：目录 755、文件 644 是常见配置，属主不对会导致 WordPress 无法读取主题，表现为主题列表里看不到。
- 案例：客户买了带演示数据的主题包（78MB），后台上传始终失败，运维把
upload_max_filesize调到了 128M 依然失败，错误信息变成413 Request Entity Too Large。排查发现站点跑在 Nginx 上，client_max_body_size默认 1m 从未改过。改了这一项后 PHP 层又报post_max_size不足——三个参数挨个补完才成功。后来该项目统一改用 SSH 上传解压，再没遇到类似问题。 - 上传成功但安装失败：那是另一类问题，通常是压缩包结构不对，请参考
主题样式表缺失的成因。
总结
处理上传超限记住三条链路：PHP 层（upload_max_filesize / post_max_size / memory_limit）→ Web 服务器层（Nginx 的 client_max_body_size）→ WordPress 层（仅影响提示值）。改之前先用「工具 → 站点健康 → 信息」确认当前生效值，改之后必须重启 PHP 服务。生产环境更推荐 FTP/SSH 上传解压，既不受限制又便于核对目录结构，是长期最省事的做法。若主题启用后出现异常，可继续看 主题启用后致命错误的应急恢复。
