fiber 实现大文件分片上传需流式解析 multipart、三重校验分片（序号/哈希/幂等）、透出明确状态码（400/409/410/460）、合并前强制 sha256 全量校验。
Fiber 本身不内置文件上传逻辑，更不直接支持分片校验——它只提供轻量 HTTP 路由与中间件机制。真正实现大文件分片上传 + 实时校验，关键不在「用哪个框架」，而在于「如何组织中间件职责」和「校验点放在哪一层」。
下面直奔实操要点，按真实开发中你最可能卡住的地方来拆解：
中间件里不能直接读 MultipartFile，因为 Fiber 没这概念
Fiber 的请求体是 *fasthttp.RequestCtx，没有 Spring Boot 那套 MultipartFile 封装。你要处理分片上传，得自己解析 multipart/form-data，而且必须流式读取，否则大文件一进来就 OOM。
- 别用
c.Body()全量加载，它会把整个请求体塞进内存 - 用
c.MultipartForm()前先检查Content-Length是否超限（比如 >100MB），超了直接c.Status(413).SendString("file too large") - 每个分片建议限制单次上传 ≤50MB，靠 Nginx 或 Cloudflare 做前置大小拦截更稳妥
uploadChunk 接口必须做三重校验，缺一不可
一个分片上传接口（比如 POST /api/upload/chunk）不是简单存文件，而是要立刻验证：是否重复、是否损坏、是否越界。中间件可以包一层通用校验，但核心逻辑必须在 handler 里写死：
-
分片序号合法性：检查
chunkIndex是否 ≥0 且，这个 <code>totalChunks应该来自初始化接口返回的元数据，不能靠客户端传 -
分片哈希匹配：客户端传的
chunkMd5必须和你用md5.Sum(chunkData)算出来的一致；注意：不要等全部上传完再校验，每个分片上传完立刻算 -
服务端幂等控制：用 Redis 记录
fileMd5:chunkIndex的状态，避免同个分片被重复提交（尤其网络重试场景）
校验失败时，中间件不能吞掉错误，必须透出明确状态码
常见错误如 "chunk hash mismatch"、"chunk out of range"、"upload session expired"，这些不能统一返回 500 或藏在 JSON body 里。前端靠状态码驱动重试逻辑：
-
400 Bad Request：参数缺失或格式错（如chunkIndex不是数字） -
409 Conflict：分片已存在且内容不一致（说明客户端缓存脏了） -
410 Gone：上传会话过期（比如初始化后 24 小时未完成） -
460（自定义）：秒传命中，直接跳过该分片（需配合 Redis 中fileMd5 → complete标记）
状态码比 message 字段更可靠——前端 fetch 的 response.status 不会受网络丢包影响，而 JSON 解析可能失败。
合并阶段不是中间件的事，但中间件得拦住非法合并请求
最后一步 POST /api/upload/merge 是高危操作，中间件必须强制校验：
- 检查 Redis 中该
fileMd5对应的uploaded列表长度是否等于totalChunks - 拒绝任何未经过
/init初始化就直连/merge的请求（可用 JWT claim 或短期 token 控制） - 合并过程必须走异步队列（如 Redis Stream 或 BullMQ），不能阻塞 HTTP 请求；中间件只负责准入，不负责执行
最容易被忽略的是：合并前没做最终文件级 SHA256 校验。哪怕所有分片都通过了校验，拼接顺序错一位也会导致整体失效——所以 /merge handler 开头就得重新计算完整文件哈希，和初始化时传来的 fileMd5 对不上，就直接失败并清空临时分片。
