Workerman无法使用$_FILES或PHP上传配置，因其不依赖PHP-FPM，$_FILES为空、php://input不可靠、upload_max_filesize等配置无效；必须手动流式解析rawBody中的multipart边界，逐行扫描定位字段、截取payload并MD5校验，否则必OOM或丢数据。
Workerman 无法直接用 $_FILES 或 PHP 上传配置处理大文件分片，必须手动流式解析原始请求体；否则必爆内存、丢数据、或返回空文件。
为什么不能依赖 PHP 原生上传机制？
Workerman 不走 PHP-FPM，$_FILES 根本不生效；php://input 在 multipart 场景下不可重复读、不支持分块；upload_max_filesize 等 ini 配置完全无效。所有分片都得靠自己从 $request->rawBody() 里按 boundary 逐行扫描、定位字段、截取 payload —— 这是硬门槛，跳不过。
- 错误现象：
$_FILES为空、file_get_contents('php://input')返回空、分片写入后文件损坏 - 根本原因：PHP 原生 multipart 解析器未被调用，Workerman 只提供裸 HTTP 流
- 后果：若强行用
move_uploaded_file或绕过流式处理，100MB+ 分片大概率触发 OOM 或超时中断
如何安全提取并保存单个分片？
核心是解析 Content-Type: multipart/form-data; boundary=----WebKitFormBoundary...，找到 filename= 字段和对应二进制块，跳过头尾换行与边界线，再校验完整性。
- 必须提取
boundary字符串，用它分割原始 body（注意 CRLF 和边界前后空行） - 每个 part 要识别出
Content-Disposition中的name（如file）、filename（建议忽略，前端传fileId+chunkIndex更可靠） - payload 起始位置在最后一个
\r\n\r\n之后，结束于下一个--boundary或--boundary--之前 - 写入前建议计算 MD5（流式计算，不全加载进内存），比对前端传来的
Content-MD5头或字段值，不一致则直接丢弃 - 保存路径推荐：
/upload/chunks/{fileId}/{chunkIndex}，用file_put_contents($path, $payload, LOCK_EX)或Files.copy()保证原子写入
断点续传状态怎么存？怎么查？
状态必须可跨请求、跨进程、跨机器访问，Redis 是最轻量且可靠的选择；数据库太重，本地文件易冲突，内存变量一重启就丢。
- 键名格式：
upload:status:{fileId}（Hash 结构），字段为chunkIndex→1（存在即成功） - 每次收到分片请求，先
HGET upload:status:{fileId} {chunkIndex}，命中就直接返回 200，不写磁盘 - 写入成功后执行
HSET upload:status:{fileId} {chunkIndex} 1+EXPIRE upload:status:{fileId} 86400（防堆积） - 合并前用
HLEN upload:status:{fileId}对比totalChunks，少于则返回 409，提示“分片不全” - 不要用
file_exists()判断分片是否存在——NFS/分布式存储下可能有延迟或缓存问题
合并分片时最容易踩的坑
合并不是简单 cat 拼接，顺序错一位、漏一个 chunk、权限不对、磁盘满，都会导致最终文件损坏。
- 必须严格按
chunkIndex升序读取，不能依赖文件系统遍历顺序（尤其 ext4/xfs 下不可靠） - 用
fopen(..., 'wb')创建目标文件，然后循环fopen(chunk, 'rb')→stream_copy_to_stream()，避免全量加载 - 合并完成后立即计算整文件 MD5（同样流式），与前端传的总 MD5 比对，不一致则删掉目标文件并报错
- 合并过程加分布式锁（如 Redis SETNX
merge:lock:{fileId}），防止并发合并导致文件被截断 - 临时分片目录需定期清理：用
scan /upload/chunks/+lastModified判断超 24h 未更新的fileId目录，异步删除
真正的难点不在切片或上传，而在「状态一致性」——前端认为已传完，Redis 里缺一个 chunk，磁盘上多一个脏文件，合并脚本又没校验 MD5。这些缝隙，才是断点续传真正崩坏的地方。
