WordPress 上传文件大小限制怎么改？upload_max_filesize 与 post_max_size 排查
WordPress 上传文件大小限制看起来只是一个数字，实际却可能同时受 PHP、WordPress、Web 服务器或代理层影响。后台提示“最大上传文件大小：100 MB”，并不代表把任意小于 100 MB 的主题、插件、图片或备份文件传上去都一定成功。
更稳妥的处理顺序是：先确认失败发生在哪一层，再修改对应配置，最后用同一入口复测。本文用本站当前线上环境的只读结果做基线，把 upload_max_filesize、post_max_size 和 WordPress 最终显示值之间的关系讲清楚。
WordPress 上传文件大小限制不是只看一个参数
WordPress 核心的 wp_max_upload_size() 会先比较 PHP 的 upload_max_filesize 与 post_max_size，取其中较小的值，然后再经过 upload_size_limit 过滤器。也就是说，单独把其中一个参数调大，最终限制可能完全不变。
| 限制层 | 控制什么 | 常见表现 |
|---|---|---|
upload_max_filesize | 单个上传文件的 PHP 上限 | 超过后提示文件大于允许值 |
post_max_size | 整个 POST 请求体的 PHP 上限 | 文件没超过前一项，提交仍失败 |
| WordPress 最终值 | 两项较小值再经过过滤器 | 媒体上传页显示的“最大上传文件大小” |
| Web 服务器、反向代理或安全层 | 请求到达 PHP 之前的体积与规则 | 常见为 413，WordPress 可能来不及记录错误 |
| 临时目录、磁盘与权限 | 上传过程中的临时写入和最终落盘 | 卡住、临时文件错误或无法移动文件 |
PHP 官方文档还明确说明，post_max_size 应大于 upload_max_filesize。因为请求体不只有文件本身，还可能包含表单字段和编码开销。若两者都设置成完全相同的值，接近上限的文件仍可能失败。
本站实测：后台显示的 100 MB 是怎么来的
截至 2026 年 9 月，本站线上环境为 WordPress 7.1、PHP 8.4.10。通过 WP-CLI 只读检查得到：
wp eval 'printf(
"WordPress: %s\nupload_max_filesize: %s\npost_max_size: %s\n",
size_format( wp_max_upload_size() ),
ini_get( "upload_max_filesize" ),
ini_get( "post_max_size" )
);'WordPress: 100 MB
upload_max_filesize: 100M
post_max_size: 100M这个结果说明当前有效上限是 100 MB，但它也暴露出一个小问题：post_max_size 没有给请求体额外余量。本站目前没有靠近上限的大文件上传需求，所以不为了一个“更好看”的数字冒然修改生产配置；真要长期上传接近 100 MB 的文件，再把请求体上限适当调高更合理。
注意：WP-CLI 与网站请求不一定使用同一套 PHP 运行环境。命令行结果只能作为基线，还要到“媒体 → 添加媒体文件”核对页面显示值，必要时再通过“工具 → 站点健康 → 信息 → 服务器”确认 Web 环境。两处结果不一致时，以实际上传入口所用的 PHP-FPM 或主机面板配置为准。
先看报错发生在上传的哪一步
同样是“上传失败”，修复方向可能完全不同。先记录文件大小、上传入口、HTTP 状态和完整错误文字，再对照下面的判断表：
| 现象 | 优先怀疑 | 第一步 |
|---|---|---|
| 选择文件后立即提示超过大小 | WordPress 或 PHP 上限 | 核对媒体上传页与 wp_max_upload_size() |
| 请求返回 413 | Web 服务器、代理或安全网关 | 查响应头和服务器日志，不要只改 PHP |
| 后台显示的上限没变化 | 改错 PHP 配置文件或服务未重载 | 比较 CLI 与 Web 环境，核对生效配置 |
| 上传一段时间后超时 | 执行时间、网络、代理或资源不足 | 查请求耗时、PHP 与服务器错误日志 |
| 提示缺少临时文件或无法移动 | 临时目录、磁盘空间或权限 | 查磁盘、临时目录及 uploads 权限 |
| 只有某种扩展名失败 | 文件类型或安全策略 | 核对允许的 MIME 类型和安全插件日志 |
如果是在特定主机面板里安装插件时失败，还要结合主机自身限制。本站之前记录过一篇阿里云虚拟主机安装 WordPress 插件上传失败排查，那类环境不能照搬 VPS 的配置方式。
怎样只读检查当前有效限制
1. 先看 WordPress 实际显示值
进入“媒体 → 添加媒体文件”，上传区域下方会显示当前最大上传文件大小。这是最接近普通后台上传场景的结果，也是初步沟通时最容易核对的一项。
2. 有 SSH 时再比较 PHP 参数
WP-CLI 可以一次输出 WordPress 计算结果和两个 PHP 参数：
wp eval 'echo "WP=" . size_format( wp_max_upload_size() ) . PHP_EOL;
echo "upload=" . ini_get( "upload_max_filesize" ) . PHP_EOL;
echo "post=" . ini_get( "post_max_size" ) . PHP_EOL;'若命令行输出与后台不同，不要马上下结论。先确认 CLI 和网站分别读取哪个 php.ini，以及网站是否由不同版本的 PHP-FPM 处理。
3. 用一个略超上限的小测试文件复现
测试文件只需略高于当前限制，不需要准备几百 MB 的大文件。先确认它不含真实客户数据，再从与故障相同的入口上传，并记录浏览器网络面板中的状态码。测试完成后删除无用文件，避免媒体库和备份被测试数据占满。
WordPress 上传文件大小限制怎么安全修改
优先使用主机控制面板提供的 PHP 设置，因为它通常知道当前站点实际使用的 PHP 版本和处理方式。面板没有入口时，再根据主机文档选择 php.ini、.user.ini 或站点级 PHP-FPM 配置。不要把网上的一段 .htaccess 代码当成所有服务器都通用的答案。
下面只是一个关系示例，不是建议所有网站都设置成这个数值：
upload_max_filesize = 64M
post_max_size = 72M这里给 post_max_size 留出了请求体余量。修改后还要确认配置是否需要重载 PHP-FPM，并重新检查后台显示值。若前端代理先拒绝请求，还需按主机或代理服务的官方文档调整请求体限制；只改 PHP 不会生效。
也不建议为了偶尔上传一次大型插件，就把生产站上限长期设成几 GB。较大的上传入口会增加超时、磁盘占用和异常请求的处理成本。插件或主题包过大时，可以先检查压缩包是否套了多层目录，或使用 SFTP、主机文件管理器等受控方式部署。
把限制调大后仍失败，继续查这 5 项
- 413 是否在 PHP 之前产生：看响应头、代理和 Web 服务器日志。
- Web 与 CLI 是否读取同一配置：PHP 版本、SAPI 和配置文件路径可能不同。
- 临时目录与磁盘是否可写：上传会先占用临时空间，最终还要写入
wp-content/uploads。 - 处理图片时是否耗尽内存：原图解码需要的内存可能远大于压缩文件体积，可结合WordPress 内存不足排查继续确认。
- 文件类型与安全规则是否拦截：只失败某种扩展名时，不要继续盲目加大体积限制。
修改后的验证清单
- 后台媒体上传页显示的新上限与预期一致。
- 小文件、接近目标上限的测试文件都能正常上传。
- 略超上限的文件会被明确拒绝，而不是长时间卡住。
- 插件、主题或媒体从实际使用入口复测成功。
- PHP、Web 服务器和代理日志没有新增 413、超时或磁盘错误。
- 测试媒体已清理，缓存只做与本次页面相关的定向处理。
总结
处理 WordPress 上传文件大小限制，关键不是把数字尽量调大，而是找出真正生效的最小限制层。先看后台显示值和报错时机，再比较 upload_max_filesize、post_max_size 与 WordPress 计算结果；遇到 413、超时或临时文件错误时，继续查 Web 服务器、代理、磁盘与权限。这样修改范围更小，也更容易验证和回滚。
参考资料：WordPress Developer Resources《wp_max_upload_size()》、WordPress.org《Media Add New Screen》、PHP Manual《Description of core php.ini directives》（访问日期：2026 年 9 月 1 日）。
