upload_max_filesize和post_max_size必须同时调大，且post_max_size应略大于前者；还需同步调整nginx的client_max_body_size、fastcgi_read_timeout及php的upload_tmp_dir等配置，否则上传会静默失败。
PHP的upload_max_filesize和post_max_size必须同时调大
只改upload_max_filesize没用，PHP在解析POST请求时会先检查post_max_size，哪怕你只传一个大文件、没其他字段，也会被拦在门外。这两个值得一起调，而且post_max_size建议略大于upload_max_filesize（比如前者设为128M，后者130M），否则上传可能静默失败。
常见错误现象：$_FILES为空、$_POST也空，但Nginx日志里没有413错误——大概率是PHP自己截断了，没走到Nginx那步。
upload_max_filesize = 128Mpost_max_size = 130M- 别忘了
max_execution_time = 300（至少5分钟），大文件读写+ThinkPHP的验证逻辑耗时容易超 - 修改后必须重启PHP-FPM，不是 reload
Nginx的client_max_body_size要覆盖整个请求体
这个配置管的是“整个HTTP请求体”的上限，包括文件二进制数据 + 表单字段 + boundary分隔符。如果只按文件大小设成128M，实际请求体可能到132M以上，直接触发413 Request Entity Too Large。
使用场景：ThinkPHP上传接口走的是标准multipart/form-data，Nginx必须放行整段原始body，不能只看文件名或Content-Length头。
- 在server或location块里加：
client_max_body_size 135M（比PHP侧再留点余量） - 别只写在default_server里，确认当前站点用的是哪个server块
- 如果用了反向代理（如前端还套了CDN或SLB），CDN侧也可能有独立限制，得同步查
ThinkPHP自身对临时文件的处理会受upload_tmp_dir影响
PHP把上传文件暂存到upload_tmp_dir后，ThinkPHP才开始移动、验证、保存。如果这个目录磁盘满、权限不对、或路径不存在，move_uploaded_file()就会失败，报错可能是Unable to move uploaded file，但$_FILES['xxx']['error']却显示0（UPLOAD_ERR_OK），让人误以为是代码问题。
性能影响：tmp目录如果在机械盘或网络存储上，大文件写入慢，会拖长整个请求时间，甚至触发PHP超时。
- 检查
upload_tmp_dir指向的路径是否存在、可写、空间充足（df -h看看） - 推荐设为本地SSD路径，比如
/var/tmp/php-upload，并确保PHP-FPM worker用户有权限 - ThinkPHP 6.x默认用
think\File类移动文件，它不校验tmp目录状态，出错才抛异常——所以日志里务必开log_level = 'error'捕获底层警告
超时不只是PHPmax_execution_time，还有Nginx的fastcgi_read_timeout
PHP处理大文件时，可能卡在IO或ThinkPHP的validate()规则（比如图片尺寸检测、内容扫描），这时PHP还没返回，但Nginx等不到响应，就主动断连，报504 Gateway Time-out。光调PHP的执行时间没用。
容易踩的坑：很多人只改了fastcgi_connect_timeout和fastcgi_send_timeout，漏掉最关键的fastcgi_read_timeout——它控制Nginx等待PHP-FPM返回响应的最长时间。
-
fastcgi_read_timeout 300（单位秒，和PHP的max_execution_time对齐） - 这个配置必须放在Nginx的location ~ \.php$块里，不能只写在http或server块顶层
- 如果启用了opcache，记得清掉旧脚本缓存，否则新配置可能不生效
真正麻烦的不是参数调多大，而是每层超时和大小限制像齿轮咬合——PHP卡住1秒，Nginx就可能已经断了；tmp目录慢100ms，整条链路就多100ms，累积起来就超限。调参前先用curl -v抓包看哪一层先甩出错误，比盲目加大数字靠谱得多。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
