upload_max_filesize 和 post_max_size 必须同时修改且后者≥前者，否则上传直接失败；需确认并修改正确的php.ini路径，同步调整nginx的client_max_body_size，并通过实测验证生效。
upload_max_filesize 和 post_max_size 必须同时改，且后者必须 ≥ 前者，否则上传直接失败——光调 upload_max_filesize 没用。
确认当前生效的 php.ini 路径
别凭感觉去改错文件。PHP-FPM 多版本共存时，不同站点可能用不同 PHP 版本，对应不同的 php.ini。执行以下命令查准路径：
php --ini
或在 PHP 脚本里写 phpinfo()，看 “Loaded Configuration File” 行。常见路径如：
-
/www/server/php/83/etc/php.ini（宝塔面板） -
/etc/php/8.3/fpm/php.ini（Ubuntu + PHP-FPM） -
C:\php\php.ini（Windows 手动安装）
改错文件是上传限制无效的最常见原因。
修改 upload_max_filesize 和 post_max_size
这两个值不是独立生效的：PHP 在解析 POST 请求体时，先检查 post_max_size；若整个请求体超限，连 $_FILES 都不会生成，错误码为 0 或空白页面，而不是明确的上传失败提示。
修改建议（以 128MB 为例）：
-
upload_max_filesize = 128M（单文件上限） -
post_max_size = 150M（留出空间给其他表单字段） -
memory_limit = 256M（至少 >post_max_size，避免 move_uploaded_file() 时内存不足） -
max_execution_time = 300（大文件上传耗时长，防止超时中断） -
max_input_time = 300（同上，控制接收输入阶段时限）
单位统一用 M（兆字节），不要混用 MB 或小写 m，PHP 8.3 不识别后者。
同步调整 Nginx 的 client_max_body_size
即使 PHP 层全调大了，Nginx 仍会在请求进入 PHP 前拦截。报 413 Request Entity Too Large 就是它干的。
在宝塔或 Nginx 站点配置的 server 块内加一行：
client_max_body_size 128m;
注意：m 是小写，单位是 MB（不是字节），且必须重载 Nginx（宝塔点「重载配置」，命令行用 nginx -s reload）。
Apache 用户则需在虚拟主机或 .htaccess 中设 LimitRequestBody 134217728（128MB = 134217728 字节），但注意 .htaccess 对 post_max_size 无效，仅能调 upload_max_filesize（且仅限 mod_php，不适用于 PHP-FPM）。
验证是否真正生效
别只信 phpinfo() 页面显示的值——它只告诉你配置“读进来了”，不代表“起作用了”。实测才可靠：
- 上传一个略大于设定值的文件（比如设了 128M，就传 135MB 的 zip）
- 观察错误类型：
413→ Nginx 拦截；error=1或空白 → PHP 层upload_max_filesize或post_max_size触发；error=7→ 权限或磁盘满；error=0但$_FILES为空 → 表单缺enctype="multipart/form-data" - 用
var_dump($_FILES)和error_get_last()查真实状态
PHP 8.3 对 ini_set() 更严格：post_max_size 属于 PHP_INI_PERDIR 类型，运行时无法修改；upload_max_filesize 即使能设，也受 php.ini 中硬上限约束。所以动态设置只适合调试，不能替代配置文件修改。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
