Workerman4Http实现大文件分片上传需手动解析请求体，用application/octet-stream传输二进制分片，Redis管理元数据，按序合并并自动清理过期分片。
Workerman4Http 实现大文件分片上传，核心在于：前端按固定大小切片、携带分片序号和唯一标识（如 file_id 或 upload_id），后端接收后暂存分片、校验完整性、合并为完整文件。关键不是“能不能传”，而是“如何可靠地收、存、合、清”。
分片上传的后端接收逻辑
Workerman4Http 是基于 WorkerMan 的轻量 HTTP 服务，不依赖 PHP-FPM，因此不能用 $_FILES 原生处理（无 CGI 环境）。需手动解析 multipart/form-data 请求体：
- 使用
Workerman\Http\Request::post()获取普通字段（如file_id、chunk_index、total_chunks、filename） - 通过
$request->rawBody()获取原始请求体，配合strtok()或第三方库（如symfony/mime）提取文件字段中的二进制数据 - 更推荐方式：前端改用
application/octet-stream+ URL 参数传元信息，例如：POST /upload?file_id=abc123&chunk_index=0&total_chunks=12
此时$request->rawBody()就是纯分片二进制流，直接写入临时目录（如runtime/chunks/abc123_0）
分片存储与去重校验
避免同一文件重复上传或分片错乱，需建立轻量元数据管理：
- 每个
file_id对应一个上传会话，记录：filename、total_chunks、received_chunks（数组或 Redis Set）、chunk_size（可选） - 使用 Redis 存储元数据（速度快、支持原子操作），例如：
hset upload:abc123 filename "report.pdf" total_chunks 12sadd upload:abc123:chunks 0 1 2 - 每次接收分片前，先查
upload:abc123是否存在且未完成；已存在的分片直接跳过（幂等），防止重复写入
合并分片与清理机制
当收到最后一个分片（chunk_index == total_chunks - 1）时触发合并：
- 按序读取所有已接收分片文件（
runtime/chunks/abc123_0→abc123_11），用fopen(..., 'wb')创建目标文件，逐个fread + fwrite拼接 - 合并成功后：删除所有分片文件、清除 Redis 中的
upload:abc123*键、返回最终文件路径或访问 URL - 增加超时自动清理：Redis 设置
EXPIRE upload:abc123 7200（2小时），后台定时任务扫描过期 key 并清理残留分片
错误处理与前端协同建议
分片上传失败率高，后端必须提供可探测的恢复能力：
- 提供
GET /upload/status?file_id=abc123接口，返回当前已上传分片列表和总数量，供前端断点续传 - 对非法请求（缺失参数、越界索引、MD5 不匹配）统一返回 JSON 错误，如：
{"code":400,"msg":"chunk_index out of range"} - 生产环境务必限制单个分片大小（如 5MB）、总文件上限（如 2GB）、并发上传数（通过 Redis 计数器限流），防内存/磁盘打满
Workerman4Http 分片上传不复杂但容易忽略细节——重点不在“一次传多大”，而在“每一片都收得稳、记得清、合得准、删得净”。
