PHP上传卡在100%主因是upload_max_filesize与post_max_size配置不当：前者设为256M（非256MB），后者至少272M且需≥前者；二者及Nginx的client_max_body_size须匹配，改后必须重启php-fpm和重载Nginx。
PHP上传卡在100%但实际没完成？检查 upload_max_filesize 和 post_max_size
宝塔装完默认值太保守，upload_max_filesize 是单文件上限，post_max_size 是整个 POST 请求体总大小——后者必须 ≥ 前者，否则大文件上传直接被 PHP 截断，浏览器可能卡在 100%，但服务端根本没收到完整数据。
-
upload_max_filesize建议设为256M或更高（根据业务定），不能写成256MB，单位只认M、G（注意大小写） -
post_max_size至少比upload_max_filesize大 16M，比如设272M，留出表单字段等额外开销 - 改完必须重启
php-fpm，光重载不生效；宝塔里点“重载配置”或执行bt 18 - 别只改
php.ini主配置——如果站点启用了「PHP 扩展配置」或「用户自定义 php.ini」，优先级更高，得同步改那里
上传慢还卡顿？调低 max_execution_time 反而更稳
很多人以为上传大文件就得把 max_execution_time 拉到 300 秒甚至 600 秒，结果反而更容易超时失败。PHP 默认是 30 秒，但上传过程本身不计入执行时间（由底层 SAPI 控制），真正卡住的是上传完成后脚本处理阶段。过长的 timeout 容易让 Nginx 或浏览器误判连接异常。
- 建议设为
120（秒），够用且不易触发中间件超时 - 同时检查 Nginx 的
client_max_body_size，它必须 ≥post_max_size，否则请求在进入 PHP 前就被 Nginx 拒绝，错误日志里会看到413 Request Entity Too Large - 宝塔里修改 Nginx 配置后，记得点「重载 Web 服务」，不是「重载配置」
并发上传变慢？调整 pm.max_children 和 pm.start_servers
PHP-FPM 进程不够，多个上传请求排队等 worker，表现就是上传速度忽快忽慢、响应延迟高。宝塔默认用 dynamic 模式，但初始值偏低，尤其在低配机器上容易成为瓶颈。
- 先看当前负载：
sudo -u www /www/server/php/80/bin/php-fpm -t然后查pm.status_path对应的 FPM 状态页，观察active processes和max active processes - 若活跃进程常接近
max_children，就把pm.max_children提到50（2G 内存机器起步），pm.start_servers设为10，避免冷启动抖动 - 别盲目拉高
pm.max_requests（比如设成 10000）——内存泄漏风险会放大，建议保持默认1000或略调高到2000 - 改完务必执行
systemctl reload php-fpm-80（版本号按你实际用的填），service php-fpm reload在宝塔环境可能不生效
上传中途断连？确认 request_terminate_timeout 没被宝塔隐藏覆盖
这个参数不在标准 php.ini 里，而是 PHP-FPM pool 配置项（如 /www/server/php/80/etc/php-fpm.d/www.conf），宝塔界面不暴露它，但某些版本的宝塔模板会默认写死为 0s（即禁用），导致上传中网络抖动时连接被意外终止。
立即学习“PHP免费学习笔记（深入）”；
- 打开对应版本的
www.conf，搜request_terminate_timeout，如果值是0，改成300s - 该参数和
max_execution_time不同：它控制整个请求生命周期（含上传阶段）的硬性超时，对不稳定网络更关键 - 改完一定要
systemctl restart php-fpm-80，reload 不会重读这个 timeout 值 - 注意：如果用了宝塔的「PHP 插件 > 防跨站攻击」，它会注入额外限制，上传异常时先临时关闭它测试是否冲突
curl -F "file=@test.zip" http://yoursite.com/upload.php 实测，别只靠浏览器上传界面判断。 
