post_max_size必须≥upload_max_filesize，否则php在解析前就拒绝整个post请求，导致$_files为空且无错误提示；还需同步调整memory_limit（≥post_max_size的1.5倍）、nginx的client_max_body_size，并重启php-fpm服务生效。
post_max_size 必须 ≥ upload_max_filesize，否则上传直接失败
PHP 在接收 POST 请求时，先校验整个请求体大小（由 post_max_size 控制），再校验单个文件大小（upload_max_filesize）。如果 post_max_size 小于 upload_max_filesize，哪怕你传的是 1MB 文件，只要它在表单里混了几个文本字段，整个 POST 请求体就可能超限——结果是 $_FILES 和 $_POST 全为空，连错误码都拿不到。
常见表现：$_FILES 是空数组，$_FILES['file']['error'] 为 0（UPLOAD_ERR_OK）但 size 为 0；或 Nginx 日志报 413 Request Entity Too Large（说明根本没进 PHP）。
-
upload_max_filesize = 200M→ 单个文件上限 -
post_max_size = 210M→ 留出至少 10MB 余量给表单字段、边界符等开销 - 二者单位必须一致（
M或m），不能写200MB（PHP 7.3 解析失败） - 数值不能含空格，如
200 M会当作无效值回退到默认 8M
upload_max_filesize 不是唯一瓶颈，memory_limit 必须兜底
PHP 把上传文件先写入临时目录，再交给脚本处理。但如果你在 move_uploaded_file() 前做了 file_get_contents()、GD 图像处理、或 ZIP 解压等操作，内存会瞬间吃满。此时即使 upload_max_filesize 和 post_max_size 都调大了，脚本仍会因 Allowed memory size exhausted 中断。
-
memory_limit至少设为post_max_size的 1.5 倍，例如post_max_size = 210M→memory_limit = 320M - 注意：该值不是“只用于上传”，它影响整个脚本生命周期，别盲目设成
-1（不安全且掩盖真实问题） - 若用
ini_set('memory_limit', '...')运行时修改，PHP 7.3 下仅在 CLI 模式或未启用 OPcache 时可靠，Web SAPI 下常被忽略
改完 php.ini 后，必须重启 PHP-FPM（不是 reload）
PHP 7.3 使用 FPM 模式时，php.ini 是进程启动时加载的静态配置。执行 systemctl reload php7.3-fpm 或 nginx -s reload 不会重读 php.ini，新配置完全不生效。
- 确认当前生效的配置路径：访问
phpinfo()页面，查 “Loaded Configuration File” 行 - 改完后必须执行：
systemctl restart php7.3-fpm（Debian/Ubuntu）或systemctl restart php-fpm（CentOS，注意版本号） - 验证是否生效：
php -r "echo ini_get('upload_max_filesize'), "\n";"（CLI 模式下也需重启服务才同步） - 别信编辑器里搜到的 “已修改”，生产环境一定要用
ini_get()或phpinfo()实际确认
Nginx 层 client_max_body_size 必须同步放开
PHP 配置再大，请求在到达 PHP 前就被 Nginx 拦截了，照样 413。这个参数和 post_max_size 是并列关系，不是替代关系——Nginx 卡在外层，PHP 卡在内层。
- 在
http、server或location块中加：client_max_body_size 210M; - 单位必须用
M（小写），210MB会解析失败，回退为默认 1M - 修改后只需
nginx -s reload，无需重启 Nginx 进程 - 如果用了 CDN 或反向代理（如 Cloudflare、Traefik），它们也有各自请求体限制，得一并检查
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
