真正卡住上传的是php和web服务器配置，thinkphp仅做二次校验；需同步调大upload_max_filesize、post_max_size、client_max_body_size（nginx）或limitrequestbody（apache），并重启服务。
PHP.ini 中 upload_max_filesize 和 post_max_size 必须同时调大
ThinkPHP 本身不控制上传大小上限，它只是接收 PHP 已解包的 $_FILES 数据。真正卡住上传的，是 PHP 解析请求体前的两道关：upload_max_filesize（单文件）和 post_max_size（整个 POST 请求体）。后者必须 ≥ 前者，否则哪怕只传一个文件，也会因总 POST 体积超限被截断，报错 PHP Warning: POST Content-Length of XXX bytes exceeds the limit。
实操建议：
-
upload_max_filesize = 20M（按需设，别盲目写 100M） -
post_max_size = 25M（留 5M 余量给其他表单字段） - 改完后必须重启 PHP-FPM 或 Apache/Nginx，仅 reload 不生效
- 用
phpinfo()页面确认值已更新，别只信配置文件
Nginx 需显式配置 client_max_body_size
即使 PHP 层放开，Nginx 默认只允许 1MB 的请求体，超过直接返回 413 Request Entity Too Large，连 PHP 都没机会执行。这个限制独立于 PHP 设置，必须在 server 或 location 块里配。
实操建议：
- 在 ThinkPHP 对应的
server块中加：client_max_body_size 25M; - 不要写在 http 全局块——可能影响其他站点
- 若用 FastCGI，确保
fastcgi_buffers和fastcgi_buffer_size足够（默认通常够用，但上传超大文件时可能需调） - 改完必须
nginx -t && nginx -s reload，语法错误会导致 reload 失败
Apache 下 LimitRequestBody 是关键开关
Apache 用户容易漏掉这个指令。它和 Nginx 的 client_max_body_size 功能一致，但默认不限制；一旦你在虚拟主机或 .htaccess 里设过该值（比如为防 DOS 攻击），就可能意外挡住上传。
实操建议：
- 检查
VirtualHost配置和项目根目录下的.htaccess，搜索LimitRequestBody - 若存在且值太小（如
LimitRequestBody 1048576），改为LimitRequestBody 26214400（25M）或直接注释掉 - 注意：.htaccess 生效需
AllowOverride All，否则配置被忽略 - 修改后需
apachectl configtest && systemctl reload apache2（或 httpd）
ThinkPHP 自身 upload 配置只是校验层，不突破底层限制
很多人以为在 config/filesystem.php 或控制器里设 'maxSize' => 20 * 1024 * 1024 就能上传 20M 文件——这是错的。这个配置只在 PHP 成功接收到文件后做二次校验，如果 PHP 或 Web 服务器已在解析阶段拒绝请求，ThinkPHP 根本收不到数据，$request->file() 返回 null，日志里也看不到任何上传逻辑执行痕迹。
实操建议：
- 把 ThinkPHP 的
maxSize设得略小于 PHP 的upload_max_filesize（比如 PHP 设 20M，TP 设 19M），避免用户传到一半才报错 - 上传失败时优先查 PHP 错误日志（
error_log）、Web 服务器错误日志（Nginx 的error.log或 Apache 的error_log），而不是只看 TP 日志 - 用
curl -F "file=@large.zip" http://your.site/upload手动测试，比浏览器更干净，排除前端 JS 限制干扰
真正卡住上传的永远是 PHP 和 Web 服务器那几行配置，ThinkPHP 只是最后一道门卫。调的时候漏掉任意一层，都会让上传在半路静默失败——尤其 post_max_size 和 client_max_body_size 这两个最容易被忽略。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
