upload_max_filesize=128m但上传50m文件报upload_err_ini_size，根本原因是post_max_size未同步调大或配置错误；php在解析请求前先校验post_max_size，超限则静默截断整个post体，$_files为空且固定返回错误码1，此时upload_max_filesize根本未被校验。
upload_max_filesize = 128M 但上传 50M 文件仍报 UPLOAD_ERR_INI_SIZE
这几乎可以确定是 post_max_size 没同步调大，或改错了配置文件。PHP 在解析 POST 请求体前就检查 post_max_size，一旦超限，整个请求被静默截断——此时 $_FILES 为空，$_POST 也为空，错误码固定为 UPLOAD_ERR_INI_SIZE（值为 1），根本不会走到 upload_max_filesize 的校验环节。
必须同时满足：
-
upload_max_filesize设为你需要的单文件上限（如128M） -
post_max_size≥upload_max_filesize+ 表单其他字段开销（建议至少加 2–5M，例如设为132M） -
memory_limit≥post_max_size（推荐 ≥256M，尤其做图像处理或内容校验时）
明明改了 php.ini，phpinfo() 却显示旧值
你很可能改错了文件。PHP 可能加载多个配置文件：Loaded Configuration File（主 ini）、Additional .ini files parsed（额外 ini）、甚至 .htaccess 或用户级 ini。别猜路径，直接写个 test.php 输出 phpinfo()，搜索 “Loaded Configuration File” 看它指向哪——那个才是你该编辑的文件。
常见陷阱：
- CLI 和 Web 环境用的不是同一个
php.ini（php --ini查 CLI，phpinfo()查 Web） - Ubuntu/Debian 下 PHP-FPM 配置常在
/etc/php/8.2/fpm/php.ini，Apache 模块则在/etc/php/8.2/apache2/php.ini - 改完不重启服务：Apache 用
sudo systemctl restart apache2，PHP-FPM 必须sudo systemctl restart php8.2-fpm（reload不生效）
用了 Nginx，上传还是被拦在 1MB
PHP 层配置全放开也没用，Nginx 默认 client_max_body_size 是 1M。它在请求到达 PHP 前就拒绝了整个请求体，根本不会把数据传给后端。
在 Nginx 配置里（通常是 server 或 location 块中）加一行：
client_max_body_size 128M;
然后执行 sudo nginx -t && sudo systemctl reload nginx。注意：这个值必须 ≥ post_max_size，否则 PHP 还没机会读取请求，Nginx 就已返回 413 Request Entity Too Large。
ini_set('upload_max_filesize', '128M') 完全没反应
upload_max_filesize 是 PHP_INI_SYSTEM 级指令，在绝大多数生产环境（PHP-FPM、FastCGI、Nginx+PHP）下，ini_set() 对它无效。它只在极少数 Apache 模块模式下可能临时起效，且不会改变 phpinfo() 显示值，仅作用于当前请求上下文——而上传限制是在请求解析阶段硬拦截的，此时脚本甚至还没开始执行。
所以别依赖运行时设置。真要临时覆盖，优先用 .htaccess（仅 Apache，且需 AllowOverride Options）：
php_value upload_max_filesize 128M<br>php_value post_max_size 132M
但最稳的方式永远是改对 php.ini 并重启服务。
最容易被忽略的是：upload_max_filesize 和 post_max_size 的单位必须带字母（M 或 G），不能写 "128M"（引号导致解析失败），也不能写 128MB（B 被忽略，变成 128 字节）。PHP 8.2 支持 G，但某些旧扩展或容器镜像可能不兼容，用 2048M 比 2G 更稳妥。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
