webman本身不提供分片上传和断点续传功能，必须手动实现；关键在于元数据通过header（如x-file-hash）传递而非$_post/$_files，分片以file_hash为目录加flock锁存储，合并前须三重验证（索引连续、md5校验、文件存在），且必须流式写入并用redis持久化状态。
Webman 本身不提供分片上传和断点续传功能，必须手动实现；关键不是“能不能做”，而是“元数据怎么传、分片怎么存、状态怎么记、合并怎么防崩”。
为什么不能用 $_POST 或 $_FILES 接收分片元数据
分片请求是 multipart/form-data 类型，PHP 的默认解析在 Swoole 常驻进程下极易出错：字段丢失、乱码、$_FILES['chunk']['tmp_name'] 指向不可靠路径（Swoole 不走系统临时目录）。Webman 的 $request->file('chunk') 才是安全入口，它封装了协程安全的临时文件处理逻辑。
- 前端必须通过 HTTP Header 传递关键元数据：
X-File-Hash、X-Chunk-Index、X-Total-Chunks、X-Chunk-MD5 - 后端统一用
$request->header('x-file-hash')获取，不碰$_POST和$_SERVER - 若坚持用 POST body 传 JSON 元数据，需手动读取
php://input，但仅限非 multipart 场景——这会迫使前端改用application/json+ base64 或二进制流，反而增加复杂度
分片存储必须加锁且隔离目录
Webman 多 worker 并发运行，多个请求同时写入同一分片目录时，mkdir() 可能失败，file_put_contents() 可能覆盖。不能依赖“先判断再创建”这种非原子操作。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 以
$fileHash为根目录名（如/runtime/uploads/abc123/），目录内只存纯数字命名的分片文件（如0、1、2），不带扩展名 - 写入前调用
flock($fp, LOCK_EX)对一个固定句柄（如/runtime/uploads/abc123/.lock）加排他锁 - 分片文件写入后立即
fflush($fp)+fclose($fp)，避免缓存延迟导致后续校验失败 - 所有路径必须用绝对路径，禁用
sys_get_temp_dir()—— Swoole 下该值可能指向被清理的系统临时区
怎么判断可以合并？不能只数文件个数
count(glob($dir . '/*')) === $totalChunks 是典型陷阱：文件系统延迟、残留脏文件、NFS 挂载不同步都会让这个判断失效。必须做三重验证。
- 用
scandir($dir)获取全部文件名，array_filter($files, 'is_numeric')筛出纯数字项，array_map('intval', ...)转整型并sort(..., SORT_NUMERIC) - 检查数组是否连续：若
$indices === range(0, $total - 1)，才说明序号无缺漏 - 逐个调用
md5_file($dir . '/' . $i)，比对前端传来的X-Chunk-MD5—— 这步能发现磁盘损坏、传输截断等静默错误 - 只有三项全通过，才进入合并流程；任一失败，返回 400 并附具体错误字段（如
"missing_chunk": 3）
合并必须流式写入，且状态要持久化到 Redis
合并不是把所有分片 file_get_contents() 加载进内存——2GB 文件直接触发 OOM。同时，Webman 无内置会话，服务重启后上传进度就丢了，必须外置状态存储。
- 用
fopen($finalPath, 'wb')打开目标文件，循环遍历已验证的分片索引，对每个分片fopen(..., 'rb')→fseek()→fread($fp, 8192)→fwrite() - 每写入一块调用
fflush()，防止缓冲区堆积；合并完成后fclose()，再array_map('unlink', $chunkFiles)清理 - 所有上传状态（
uploaded_chunks数组、total_chunks、status）必须存 Redis，key 为upload:{$fileHash}，设置合理过期时间（如 7 天） - 前端发起“检查进度”请求时，后端查 Redis 返回已上传索引列表，而不是重新扫描磁盘——这才是断点续传可落地的前提
最易被忽略的是：Redis 状态和磁盘分片文件必须强一致。比如合并成功后删分片失败，得回滚 Redis 状态；或者 worker crash 导致部分分片写入但未更新 Redis，下次检查就会误判为“已完成”。这些边界情况没有银弹，只能靠日志 + 定期扫描脚本兜底。
