大文件上传技术全流程分析 ：切片上传 + 断点续传 + 秒传 + 暂停上传

一、大文件上传问题本质（结合场景分析）：前情概括：本文由AI生成，结合个人文档撰写提升阅读体验，是全栈偏前端视角，方便理解学习全流程视角1.1 传统文件上传的致命缺陷网络稳定性问题：单次大文件传输（100MB）在网络波动时极易失败，重传需从头开始服务端瓶颈：HTTP请求超时限制（Nginx默认60s）、内存溢出风险、带宽占用过高用户体验：进度不可控、失败无感知、重复上传相同文件浪费资源1.2 原因：传输可靠性与资源效率问题网络不可靠性（TCP重传机制仅解决底层问题）以及业务层传输完整性要求思路：将"原子操作"从「整个文件」降维到「数据块」，通过状态管理实现可恢复性场景特征：用户侧：弱网环境（移动端/跨国传输）、浏览器可能关闭服务侧：分布式存储、限流策略、成本控制需求PRD 需求描述：用户对进度敏感（5s无反馈即认为失败）1.3 四种情况的底层逻辑切片上传是基础：解决单次请求过大问题（本质是空间换可靠性）断点续传是核心：依赖切片+状态存储（本质是状态机管理）秒传是优化：基于内容寻址(Content-Addressable)思想（本质是去重）暂停上传是交互：客户端状态控制（本质是异步流程中断）A[原始文件] -- B(切片上传) -- C[分块传输] C -- D[断点续传] -- E[状态持久化] C -- F[秒传] -- G[内容指纹比对] E -- H[暂停/恢复] -- I[客户端状态管理]二、技术方案设计：前端主导的全链路架构2.1 前端核心职责（关键设计点）表格功能前端关键任务技术本质切片按固定大小切分文件、生成唯一标识、计算每个切片的哈希值流式处理 + 内容指纹生成断点续传本地持久化上传状态（已传切片列表）、失败时请求服务端校验已有切片状态同步 + 增量传输秒传上传前计算文件整体哈希，服务端比对是否存在完整副本内容寻址(Content-Addressable)暂停/恢复中断XHR/fetch请求、管理并发队列、恢复时重建状态异步流程控制 + 状态机2.2 关键技术决策切片大小：5-10MB（平衡并发数与单次请求稳定性）过小：HTTP头部开销占比高过大：单次失败重传成本高INTJ深度思考：根据网络RTT动态调整（首次上传后记录平均响应时间）哈希算法选择：切片哈希：xxhash-wasm（性能比Web Crypto快5-10倍，适合大文件）文件整体哈希：SubtleCrypto（SHA-256，安全性要求高）关键权衡：速度 vs 安全性（切片仅用于校验完整性，无需强抗碰撞性）状态存储方案：ts编辑// 状态数据结构（必须包含这些关键字段） interface UploadState { fileId: string; // 服务端生成的唯一ID（非文件名） fileName: string; totalSize: number; // 防止文件被篡改 chunkSize: number; uploadedChunks: number[]; // 已成功上传的切片索引 fileHash: string; // 用于秒传校验 last