$_FILES在高并发多文件上传时失效，因其同步阻塞、易超限、不支持断点续传且无进度回调；应改用php://input分片上传+Redis状态管理+Nginx流式透传配置。
PHP 原生 $_FILES 机制扛不住高并发多文件上传，必须绕开它做分片、异步和状态解耦。
为什么 $_FILES 在大量上传时直接失效
PHP 默认把整个上传文件先写入临时目录，再解析 $_FILES，这个过程是同步阻塞的：单请求卡住整个 FPM 进程，上传未完成前无法响应其他请求；大文件（如 >100MB）还容易触发 upload_max_filesize、post_max_size、max_execution_time 三重超限；更关键的是，Nginx/Apache 对 multipart/form-data 的解析本身不支持流式或分片，一旦网络抖动或中断，整个上传就失败，无法续传。
- 别指望调大
php.ini参数能解决问题——只是把崩溃点往后推，本质仍是单点瓶颈 -
$_FILES没有上传进度回调，前端无法显示实时进度条，用户体验差 - 所有文件元信息（如原始名、类型）都混在一次 POST 里，服务端无法按需校验或预处理
用 php://input + 分片上传替代 $_FILES
核心思路是让前端把文件切块（如每块 5MB），用普通 POST 或 PUT 发送二进制流，后端用 php://input 直接读取原始 body，跳过 PHP 文件上传解析流程。
- 前端需计算每块的唯一标识（如
file_id + chunk_index + total_chunks），避免并发写冲突 - 后端接收时检查
Content-Type: application/octet-stream，用fopen('php://input', 'rb')流式写入临时分片文件，不占内存 - 分片上传完成后，用
file_put_contents($final_path, file_get_contents($chunk_path), FILE_APPEND | LOCK_EX)合并，注意加锁防竞态 - 合并成功后立即删分片，否则磁盘会快速占满
示例关键逻辑：
立即学习“PHP免费学习笔记（深入）”；
if ($_SERVER['REQUEST_METHOD'] === 'POST' && isset($_GET['upload_id'])) {
$uploadId = $_GET['upload_id'];
$chunkIndex = (int)$_GET['chunk'];
$totalChunks = (int)$_GET['chunks'];
$chunkFile = "/tmp/upload_{$uploadId}_{$chunkIndex}";
file_put_contents($chunkFile, file_get_contents('php://input'));
<pre class='brush:php;toolbar:false;'>// 检查是否全部接收完毕
if ($chunkIndex === $totalChunks - 1) {
$finalPath = "/data/uploads/{$uploadId}.bin";
for ($i = 0; $i < $totalChunks; $i++) {
file_put_contents($finalPath, file_get_contents("/tmp/upload_{$uploadId}_{$i}"), FILE_APPEND | LOCK_EX);
unlink("/tmp/upload_{$uploadId}_{$i}");
}
}}
用 Redis 记录上传状态并支持断点续传
单纯靠文件系统判断分片是否收齐不可靠（比如某块上传成功但服务重启了），必须用 Redis 存储每个 upload_id 的当前已接收分片列表和总块数。
- 每次收到分片，执行
LPUSH upload:{$uploadId}:chunks {$chunkIndex}，并用SETNX upload:{$uploadId}:total {$totalChunks}初始化总数 - 合并前用
LLEN upload:{$uploadId}:chunks校验数量，不一致则返回 409，前端可据此发起缺失块重传 - 设置过期时间（如
EXPIRE upload:{$uploadId}:chunks 86400），防止僵尸上传长期占用内存 - 上传成功后用
DEL清理整组 key，不要只删部分
Nginx 层要配合做超大请求透传和超时放宽
即使后端改成流式接收，Nginx 默认也会缓存整个请求体再转发，导致内存暴涨甚至 OOM。必须显式关闭缓冲并延长超时。
- 在 location 块中加：
client_body_buffer_size 128k;（不能设太大）、client_max_body_size 0;（禁用限制）、client_body_timeout 300; - 关键配置：
proxy_buffering off;和proxy_request_buffering off;（后者仅 Nginx ≥ 1.7.11 支持，必须开） - 如果用 HTTPS，还要确认
ssl_buffer_size 4k;，避免 TLS 层缓冲干扰流式读取 - 别用
fastcgi_pass直连 PHP-FPM——它不支持流式，必须走proxy_pass http://php_backend走 HTTP 协议转发
真正难的不是代码怎么写，而是分片策略、状态一致性、Nginx 与 PHP 协作边界这三处细节稍有偏差，上传就会静默失败或产生脏数据。尤其注意 proxy_request_buffering off 这个开关，很多线上环境因为版本低或没配，导致看似接收了但实际 body 是空的。
