大文件断点续传HTML实现方法详解

本文深入解析了HTML中实现大文件断点续传的核心原理与实战难点，强调其本质并非依赖HTTP协议的原生支持，而是通过前端精准切片（正确使用File.slice()处理边界与末尾）、文件唯一指纹（MD5校验）识别上传任务、前后端协同维护切片状态（服务端原子性确认+前端跳过已传索引），以及谨慎应对localStorage在隐私模式、多标签、容量超限等场景下的隐蔽风险；真正挑战在于中断恢复的可靠性——无论页面崩溃、断电还是网络中断，系统都必须确保切片索引严格对齐、状态不丢失、不重复写入，否则断点续传将沦为脆弱的乐观假设。

断点续传在前端不能靠 HTTP 协议原生支持（HTTP/1.1 的 Range 仅用于下载），必须由前后端协同设计实现。核心不是“恢复连接”，而是“跳过已传切片”——靠文件指纹 + 切片状态记录 + 分片上传完成确认。

怎么用 File.slice() 正确切片而不丢数据

切片不是简单按固定字节数等分，关键要对齐边界、处理末尾不整除情况：

• slice(start, end) 的 end 是「不包含」的，所以 file.slice(0, 1024 * 1024) 是前 1MB，file.slice(1024 * 1024, 2 * 1024 * 1024) 是第 2MB，以此类推
• 最后一片的 end 必须设为 file.size，否则会漏掉末尾字节；错误写法：file.slice(lastStart, lastStart + shardSize)（可能越界）
• 不要用 Math.floor(file.size / shardSize) 算片数，要用 Math.ceil(file.size / shardSize)，否则少算一片
• 切片顺序必须严格从 0 开始递增，服务端合并时依赖这个索引

为什么必须计算文件 MD5，只靠文件名+大小不行

文件名和大小极易重复，比如用户反复修改后保存同名文件、不同设备导出同尺寸截图。服务端仅凭这两项无法区分是否为同一上传任务：

• 浏览器端用 spark-md5 计算整个文件的 hash（非逐片拼接），作为唯一 fileId
• 上传前先调接口查 fileId 对应的已传切片列表，返回 uploadedChunks: [0, 1, 3] 就跳过这些索引
• 如果服务端没存该 fileId，说明是全新上传，从 0 开始
• localStorage 存的键也必须是 fileId，而不是 fileName + size

XMLHttpRequest 上传切片时怎么避免 413 或超时

切片本身是小 Blob，但若携带冗余字段或未设请求头，仍可能被 Nginx/Apache 拦截或触发网关超时：

• FormData 中只 append 必需字段：chunk（Blob）、chunkIndex、totalChunks、fileId，去掉注释、时间戳等无关字段
• 服务端接收接口必须显式允许大请求体：Nginx 要配 client_max_body_size 10M（按单片大小设，不是总文件大小）
• 禁用 XMLHttpRequest 的默认 Content-Type（会带 boundary），让浏览器自动设置；手动设 multipart/form-data 反而易出错
• 上传前检查 onerror 和 onabort，网络中断时不要立即重试，先等几秒再查服务端状态

localStorage 存进度有哪些隐藏风险

看似简单的本地存储，实际在多标签、隐私模式、存储满时行为差异极大：

• 隐私模式下 localStorage 是临时的，关窗口即清空 —— 必须在上传开始前弹提示：“请勿使用无痕窗口”
• 多个标签页同时上传同一文件时，localStorage 不同步，可能互相覆盖进度；需加锁机制（如用 localStorage.setItem('uploading', 'true') 做简易互斥）
• 超过 5MB 容量限制会抛 QuotaExceededError，应捕获并 fallback 到 sessionStorage 或内存缓存（但刷新即失）
• 上传成功后必须调 localStorage.removeItem(fileId)，否则下次选同文件仍读到旧状态

真正难的不是切片或发请求，而是让服务端能原子性地确认“某片已存且不可重复写入”，以及前端能在任意中断点（页面崩溃、断电、关机）后精准恢复索引。这两处没对齐，断点续传就只是个有漏洞的乐观假设。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~