必须同时修改 upload_max_filesize 和 post_max_size，且 post_max_size ≥ upload_max_filesize（如 64M 和 72M），单位用大写 M；还需检查 .user.ini 覆盖、Nginx 的 client_max_body_size 及 Apache 的 LimitRequestBody，并重启 PHP 和 Web 服务。
upload_max_filesize 和 post_max_size 必须一起改
宝塔里改上传大小，只调 upload_max_filesize 是没用的——PHP 会直接拒绝整个 POST 请求，报错 UPLOAD_ERR_INI_SIZE。根本原因是 post_max_size 控制的是“整段 HTTP 请求体”的上限，而文件只是其中一部分（还有表单字段、边界符等），它必须 ≥ upload_max_filesize，否则哪怕文件本身没超，也会被拦在门外。
-
upload_max_filesize = 64M→ 允许单个文件最大 64MB -
post_max_size = 72M→ 留出约 8MB 余量给其他 POST 数据（推荐比 upload 大 5–10M） - 单位必须用大写
M（64M可行，64m或64MB会被 PHP 忽略） - 改完必须点击对应 PHP 版本的「重启」按钮——不重启，配置完全不生效
.user.ini 文件会偷偷覆盖你的设置
宝塔默认在网站根目录（如 /www/wwwroot/your-site/）生成 .user.ini，它的优先级高于 php.ini，且每 5 分钟自动重载一次。很多人明明在面板里改了，phpinfo() 却显示旧值，就是它在作怪。
- 进网站根目录，用宝塔「文件管理器」查看是否存在
.user.ini - 如果里面有
upload_max_filesize=2M或post_max_size=8M这类行，直接删掉或改成和php.ini一致 - 改完
.user.ini不用重启 PHP，但建议手动点一下站点右侧的「重载配置」，避免等待 5 分钟
Nginx 的 client_max_body_size 是第二道关卡
就算 PHP 层全放开，Nginx 默认只允许客户端发来最多 1MB 的请求体，超过就直接返回 413 Request Entity Too Large 错误，压根不会把请求交给 PHP 处理。
- 进宝塔「网站」→ 点击目标站点 → 「配置文件」
- 在
server { }块内（不要放在location / { }里面）、靠前位置添加：client_max_body_size 64M; - 保存后务必点「重启 Nginx」——只点「重载配置」有时不生效
- Apache 用户则需在站点配置中加：
LimitRequestBody 67108864（64MB = 67108864 字节）
验证时别只信 phpinfo()，要真传一个文件
phpinfo() 显示值正确，不代表上传一定能成功。浏览器缓存、CDN 中间层、WordPress 插件、甚至某些安全模块都可能二次拦截。
- 新建
info.php放根目录，内容为<?php phpinfo(); ?>，访问后搜索确认upload_max_filesize、post_max_size、memory_limit（建议 ≥ upload 值）三项已更新 - 再建一个最小化上传页（含
<input type="file">表单），上传一个略小于设定值的文件（比如设了 64M，就传 60MB 的 ZIP） - 若仍失败，检查是否用了多 PHP 版本——宝塔里「网站」→「设置」→「PHP 版本」选错了；或者开了防篡改/防火墙插件，临时关闭测试
最容易被忽略的是 .user.ini 和 Nginx 限制这两层，很多人查了半天 php.ini，却忘了它们正在静默生效。
