一、大文件上传问题本质（结合场景分析）：
前情概括：本文由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
