大文件断点续传后端需协同前端完成状态管理、校验与合并：通过文件指纹和元数据校验分片合法性，提供毫秒级已传分片查询接口，规范分片存储命名并由前端触发安全合并，同时实施超时清理、并发限流与事务日志等异常防护机制。

大文件断点续传的后端协同处理，本质是为前端分片上传提供状态支撑、校验能力与合并服务。它不是被动收文件，而是主动参与上传生命周期管理——从识别、记录、验证到组装，每一步都需前后端严格约定并协同执行。

文件唯一标识与分片元信息校验

前端上传每个分片时，必须携带不可变的文件指纹（如全文件 MD5 或 SHA256）和结构化元数据。后端收到请求后，不直接写入，而是先做三项校验：

• 检查 fileHash 是否为空或非法格式，拒绝无标识上传
• 比对 index 是否在 totalChunks 合理范围内（0 ≤ index ＜ totalChunks）
• 验证该分片是否已存在（通过读取临时目录或查询 Redis/DB），避免重复写入

只有全部通过才保存分片，否则返回明确错误码（如 400 Bad Request 或 409 Conflict），让前端决定跳过或重试。

已上传分片状态查询接口

断点续传的前提是“知道哪些已传”。后端需提供轻量、高响应的查询接口（如 GET /upload/status?fileHash=xxx），其逻辑为：

• 接收 fileHash 参数，定位对应临时目录（如 uploads/chunks/{fileHash}/）
• 扫描目录下所有 part_* 文件，提取 index 数字并去重排序
• 返回 JSON 格式数组，例如 {"uploaded":[0,1,3,4],"total":8}

该接口应支持缓存（如加 ETag 或短时效 CDN 缓存），且不依赖数据库，优先用文件系统扫描或 Redis 的 SET 成员查询，确保毫秒级响应。

分片安全存储与合并触发机制

分片落地不是简单丢进目录，而要兼顾可追溯性与可靠性：

• 分片文件命名统一为 {fileHash}_part_{index}，避免命名冲突和遍历歧义
• 使用 move_uploaded_file() 替代 file_put_contents()，防止临时文件被意外覆盖或注入
• 合并操作必须由前端显式触发（如 POST /upload/merge），携带 fileHash 和原始文件名，后端校验所有分片齐备后再执行拼接
• 合并成功后立即清理临时分片目录，并记录最终文件路径与元信息（大小、时间、hash）

异常防护与资源清理策略

真实环境中网络波动、用户关闭页面、服务重启频繁发生，后端需主动兜底：

• 启用 ignore_user_abort(true)，确保合并过程不因客户端断开而中断
• 设置定时任务（如每小时 cron 脚本），清理超过 24 小时未完成的临时目录
• 对高频上传 IP 或单个 fileHash 的并发请求做限流（如 Redis + token bucket），防恶意刷片
• 所有分片写入前开启事务式日志（如追加写入 upload_log.json），便于故障回溯