PHP高并发上传优化方法与实战技巧

本篇文章向大家介绍《PHP高并发上传优化技巧与操作指南》，主要包括，具有一定的参考价值，需要的朋友可以参考一下。

$_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) 合并，注意加锁防竞态
• 合并成功后立即删分片，否则磁盘会快速占满

示例关键逻辑：

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 是空的。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~