提高 WordPress 的最大上传文件大小限制

三个设置共同决定 WordPress 的上传限制，而且它们必须彼此一致。真正生效的限制取 upload_max_filesize、post_max_size 以及 Web 服务器请求上限三者中的最小值。你只调高其中一个、另外两个还是很低，那什么都不会变——这也正是大多数人得出「我改了但没用」这种结论的原因。先用 WordPress 最大上传文件大小检测工具 查一下当前的数值；它读取的正是 WordPress 报告的那些值，并告诉你到底是哪一个在拖后腿。

这个限制为什么存在，又在哪里生效

WordPress 并不设置上传限制，它只是把限制报告出来。当你看到「The uploaded file exceeds the upload_max_filesize directive in php.ini」时，这条消息是 PHP 直接抛出的。

有三个独立的值在控制一次上传，真正的上限就是其中最低的那个：

• upload_max_filesize（PHP）——PHP 能接受的单个文件的最大体积。
• post_max_size（PHP）——整个 POST 请求体的最大体积。你的文件是和其他表单字段一起打包在 POST 请求里发送的，所以这个值必须大于 upload_max_filesize。
• Web 服务器的请求体限制——Nginx 上的 client_max_body_size，或者 Apache 上的 LimitRequestBody。这个值完全在 PHP 之外，这也是为什么在 Nginx 后面只改 PHP 的做法会悄无声息地失败。

还有第四个值 max_execution_time，它不限制体积，但在网络较差时会让一个缓慢的大文件上传在传输途中被中止。这是另一个层面的症状，并不属于体积上限的一部分。

坑就在这里：你把 upload_max_filesize 设成了 256M，重载后还是传不了一个 100 MB 的文件——因为 post_max_size 还是 8M。PHP 在检查文件之前，就已经因为请求体总大小超标而拒绝了这个请求。不是你设的那个限制没起作用，而是另一个限制先把它拦下了。

按顺序修复它

从「最可能一次搞定」的做法排到「最后的手段」。

1. 编辑 php.ini（正确的地方）。 找到你的站点实际加载的那个文件——运行一个包含 <?php phpinfo(); 的页面，看「Loaded Configuration File」一项，或者直接问你的主机商。把两个 PHP 值都设好，并保持 post_max_size 大于 upload_max_filesize：

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

重启 PHP-FPM（sudo systemctl restart php8.2-fpm）或 Apache。在 PHP 进程重启之前，改动不会生效。

2. 没有 php.ini 的访问权限？用 .htaccess（仅限 Apache + mod_php）。 在你 WordPress 根目录的 .htaccess 里添加：

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

这只有在 PHP 作为 Apache 模块运行时才有效。在 PHP-FPM、CGI 或 FastCGI 下，php_value 会抛出 500 错误——那个报错说明你走错了路，而不是数值填错了。这时改用 .user.ini：

upload_max_filesize = 256M
post_max_size = 260M

3. 调高 Web 服务器的限制——所有人都会忘掉的一步。 在 Nginx 上，PHP 甚至根本看不到一个超大的请求；Nginx 会先返回 413 Request Entity Too Large。在你的 server 块里加上：

client_max_body_size 256M;

用 sudo nginx -t && sudo systemctl reload nginx 重载。如果你用的是 Nginx，而改了 PHP 却「毫无变化」，那几乎肯定就是这个原因。

任何改动之后，都要重新检查报告出来的数值。最大上传文件大小检测工具 会告诉你新的实际上限，并根据你的环境生成确切的配置片段，这样你就不用去猜三个值里到底还是哪一个偏低了。

不该做的事

别去改 wp-config.php 还指望它能提高限制。 那条被到处复制的代码根本不是博客文章里说的那回事：

@ini_set( 'upload_max_filesize' , '256M' );

upload_max_filesize 属于 PHP_INI_PERDIR。它无法在运行时通过 ini_set() 从 PHP 里修改。它只接受来自 php.ini、.htaccess 或 .user.ini 的新值——绝不接受来自应用代码的值。这行代码运行时不报错，也什么都不做，这使它成为 WordPress 里最被信心满满地反复传播的错误建议之一。

也别去贴 @ini_set('post_max_size', ...)——同样的限制，同样的悄无声息的无效操作。

别把 WP_MEMORY_LIMIT 当成上传限制来设。 那控制的是 PHP 运行代码时的内存上限，跟服务器能接受多大的文件毫无关系。

别只改一个文件就收手。 最常见的失败就是只改了 upload_max_filesize 一个，然后就断言这个方法不管用。三个都要改，并保持 post_max_size 高于 upload_max_filesize。

别「为了保险」把限制设得高得离谱。 一个 2 GB 的限制会招来资源耗尽的问题，而且也帮不上忙——如果你真的需要传好几个 GB 的文件，那就绕开浏览器上传（用 SFTP，或者一个分块上传插件），而不是硬把它塞进一个单独的 PHP POST 请求里。

还是搞不定？

如果三个值都调高了、你却依然撞墙，那说明请求是在你服务器上游的某个地方被卡住了：可能是 CDN 或代理（Cloudflare 的控制台会单独限制上传请求体的大小），可能是托管主机自己的平台级限制无视了你的 php.ini，也可能是一个还没刷新的 .user.ini——它遵循 PHP 的 user_ini.cache_ttl，所以在你保存之后可能会滞后几分钟。要以服务器实际报告的数值为准，而不是你在某个文件里写下的值，然后去修那个仍然偏低的环节。当报告出来的数字终于和你的目标一致时，上传就成了。