必须同步修改 upload_max_filesize、post_max_size 和 client_max_body_size 三处配置并重启服务，否则大文件上传会失败；upload_max_filesize 控制单文件上限，post_max_size 需大于其值加其他字段开销，client_max_body_size 是 Nginx 层第一道限制，三者缺一不可。
PHP 的 upload_max_filesize 和 post_max_size 必须同时改
宝塔里点开网站的 PHP 设置，光调 upload_max_filesize 没用——表单提交本身有上限，post_max_size 得同步放大，否则上传直接 404 或 500，连错误日志都不报清楚。
常见错误现象：$_FILES 为空、$_POST 也空、Nginx 日志里只有 client intended to send too large body 这类模糊提示。
-
upload_max_filesize控制单个文件最大值，比如设为128M -
post_max_size要 ≥upload_max_filesize+ 其他 POST 字段开销，建议设为132M或直接150M - 改完必须重启 PHP-FPM，不是重载，宝塔界面点「重启」按钮就行，别只点「保存」
Nginx 的 client_max_body_size 是第一道关卡
这个参数在 Nginx 层就拦上传请求，比 PHP 更早。宝塔默认是 50M，哪怕 PHP 全放开，超了照样返回 413 Request Entity Too Large。
使用场景：大附件上传、后台批量导入 Excel、用户头像裁剪上传等需要突破默认限制的操作。
立即学习“PHP免费学习笔记（深入）”；
- 在宝塔网站设置 → 配置文件里，找到
server块，在location ~ \.php$外面加一行：client_max_body_size 150M; - 不要写在
location里，否则只对 PHP 路径生效，而上传表单可能走的是根路径或静态路由 - 改完必须重启 Nginx，不是重载；重载有时不生效，尤其是配置语法没报错但值没更新时
宝塔面板的「网站 > 上传限制」只是障眼法
那个滑块只改了 PHP 的 upload_max_filesize，且不碰 post_max_size，也不动 Nginx 配置。你拖到 500M，实际还是卡在 Nginx 的 50M 或 PHP 的 8M 上。
容易踩的坑：
– 以为拖完就完了，结果上传失败还去查代码逻辑
– 在「PHP 版本 > 设置 > 配置修改」里改了全局值，但网站绑定了独立 PHP 配置，实际没生效
– 改了配置却忘了清浏览器缓存或换无痕窗口测试，旧的 413 错误被缓存了
- 优先在网站单独配置页修改，比全局改更安全
- 验证是否生效：上传一个略大于原限制（如 55M）的文件，看返回的是 413 还是 PHP 的
UPLOAD_ERR_INI_SIZE - 查真实生效值：在网站根目录放
phpinfo.php，访问它看upload_max_filesize和post_max_size行
超大文件上传还要防超时和断连
调大尺寸只是第一步。上传耗时变长后，max_execution_time、max_input_time、Nginx 的 fastcgi_read_timeout 都可能中途掐断连接。
性能影响：这些超时值设太高，会占用 PHP-FPM worker 更久，高并发下容易打满进程，得配合 pm.max_children 一起评估。
-
max_execution_time建议设为600（10 分钟），别用0（无限），生产环境不安全 -
max_input_time至少和max_execution_time一致，否则还没读完 POST 数据就被杀 - Nginx 配置里加：
fastcgi_read_timeout 600;，放在location ~ \.php$块内
真正麻烦的是分片上传或断点续传这种需求，那得换前端方案，PHP 和 Nginx 的配置只是基础门槛。
