视频文件分片上传，几乎每个做视频类产品的团队都绕不开。我在公司里接手过一个视频课程平台，老师上传一段录屏课程，动辄就三四百兆，一开始用的是普通文件上传接口，结果隔三差五就有老师反馈"传了三十分钟提示失败"，然后又要从头来。这个问题我印象太深了，后来花了一周时间把整个上传链路改成基于分片上传的方案，才算彻底解决。这篇就把我在Java环境下实现视频文件分片上传的完整思路和示例代码整理出来，适合正在做视频上传、大文件上传，或者刚接触分片上传想抄一份能跑的代码的人。
1. 视频文件为什么不能一把梭：大文件上传的三个坎
先说个反直觉的结论：视频文件分片上传不是"优化手段"，而是"基本要求"。视频文件本身就具备大体积、长传输时间、二进制内容三个特性，这三个特性决定了它和普通图片、文档上传的处理逻辑完全不一样。
1.1 HTTP连接超时与失败成本问题
普通上传接口的做法是客户端把整个文件放入请求体，服务端一次性接收。视频文件动辄几百MB，就算网络状况不错，也得传十几分钟。而几乎所有网关、负载均衡器、Web服务器都有默认的连接超时时间，一般在30秒到5分钟之间。只要传输时间超过这个阈值，连接就会被中间设备强拆。
服务端可能已经收到了一部分数据，但客户端看到的却是连接断开、上传失败。更致命的是，文件越大，单次失败丢弃的数据量越大，客户端只能从头再来。这就陷入了一个循环：文件越大越容易超时，越容易超时就越要重传，越重传就越容易超时。
1.2 服务端内存与临时文件压力
服务端如果直接用内存接收大文件，传统做法是先把整个文件读入内存，再转存磁盘。一个500MB的视频，如果同时有10个老师在传，就是5GB的内存开销，不现实。即使把临时存储切到磁盘上，一次性写入一个500MB的临时文件，磁盘IO的瞬时压力也很大。
分片上传把这个压力拆解了：每个请求最多传输几MB数据，服务端每处理一个请求，内存占用最多也就是这个分片的大小。通过控制并发分片数，可以把瞬时压力限制在可控范围内。
1.3 业务的"一把梭"思维陷阱
还有一点容易忽略：普通上传接口天然不提供"进度续传"能力。一旦失败，用户必须重新选择文件、重新上传。而分片上传方案天然支持断点续传和秒传，后面我会详细说。从产品体验角度看，这两项能力对视频类应用几乎是刚需。
所以你如果现在还在用MultipartFile直接接收整个视频文件，我建议你尽早改造。下面这套方案，可以直接在你的Spring Boot项目里落地。
2. 分片上传的总体架构与关键参数设计
分片上传的思路很简单：客户端把文件切成若干分片，逐个上传到服务端，服务端收到全部分片后合并成一个完整文件。整体链路包含三个角色：浏览器端切片与上传、服务端接收与合并、临时目录与元数据管理。
2.1 完整链路与接口划分
一次分片上传的完整交互如下：
- 前端读取文件，计算唯一标识（通常用MD5），向服务端查询该文件是否已存在。
- 如已存在，直接返回文件访问地址，这就是"秒传"。
- 如不存在，前端按固定大小切片，每个分片带上传凭证（文件唯一标识、分片序号、分片总数）。
- 前端并发放送N个分片请求，服务端逐个落盘到临时目录。
- 所有分片上传完成后，前端调用合并接口。
- 服务端校验分片完整性，按顺序写入完整文件，返回最终文件地址。
对应的后端接口至少要有三个：上传分片接口、查询已上传分片接口、合并分片接口。秒传判断逻辑可以单独做一个查询接口，也可以和查询已上传分片接口合并。
2.2 分片大小的选型逻辑
分片大小是最容易被忽视的调优点，这里直接给结论：常规视频文件建议单片2-5MB，网络环境好的局域网或内网应用可以调到10MB。
为什么不能太小？分片太小意味着请求数量太多，每个请求都有HTTP头、鉴权、日志等额外开销。500MB的文件如果切1MB一片，就是500个请求，调度和失败重试的复杂度都会上升。
为什么不能太大？分片太大就失去了分片的意义。单片10MB以上时，服务端接收耗时变长，一旦某个分片失败，重传代价变大，而且并发传输时的带宽争抢问题会更明显。
以网课录屏文件为例，我建议的默认配置是单片5MB、并发3个。计算一下：500MB文件切出来100片，3个并发串行完成，每片传输时间假设1秒，整体大约33秒完成；如果单片直接传，即使不超时，一旦失败就毁了。这个性价比是划算的。
2.3 文件唯一标识与元数据设计
文件唯一标识是分片上传的核线索，所有分片和合并操作都靠它串起来。实践中我用的方案是MD5值。前端先读取文件内容计算MD5，然后作为标识传给后端。注意大文件不能一次性读入内存计算，要用流式分批读取，Java和前端都有对应的流式MD5方法，下面会给出代码。
后端保存分片时，文件命名规则推荐这样设计：
${uploadId}/${chunkIndex}.part其中uploadId就是MD5，chunkIndex从0开始，代表分片序号。比如：
/tmp/upload/3f9a7b2c1d8e4f5a6b7c8d9e0f1a2b3c/0.part /tmp/upload/3f9a7b2c1d8e4f5a6b7c8d9e0f1a2b3c/1.part所有分片放进一个以MD5命名的目录里，合并时按序号读取即可。这样做的好处是，临时目录里天然就是分片集合，断点续传时服务端只要能数出目录里有多少个.part文件，就能告诉前端还缺哪些分片。
3. 后端示例代码：从接收分片到合并落盘
这一章直接上代码。我用的是Spring Boot环境，JDK 8+，依赖只有spring-boot-starter-web，不需要额外引入任何第三方存储服务。整个后端包含三个核心接口和两个辅助工具类。
3.1 分片上传的Controller实现
先看Controller层，三个接口：上传分片、查询已上传分片、合并分片。我习惯把这几个接口放在一个ChunkUploadController里。
@RestController @RequestMapping("/api/v1/file") public class ChunkUploadController { private static final String UPLOAD_DIR = "/data/tmp/video-upload/"; @PostMapping("/chunk") public Result uploadChunk(@RequestParam("file") MultipartFile file, @RequestParam("md5") String md5, @RequestParam("chunkIndex") Integer chunkIndex, @RequestParam("chunkTotal") Integer chunkTotal) { // 基础参数校验 if (file.isEmpty()) { return Result.fail("分片文件为空"); } if (chunkIndex < 0 || chunkIndex >= chunkTotal) { return Result.fail("分片序号非法"); } try { // 生成当前上传任务的目录 String taskDir = UPLOAD_DIR + md5; File dir = new File(taskDir); if (!dir.exists()) { dir.mkdirs(); } // 分片落盘命名规则：序号 + .part File targetFile = new File(taskDir, chunkIndex + ".part"); file.transferTo(targetFile); return Result.ok("分片上传成功", null); } catch (IOException e) { return Result.fail("分片写入失败"); } } @GetMapping("/chunk/check") public Result checkChunk(@RequestParam("md5") String md5, @RequestParam("chunkTotal") Integer chunkTotal) { String taskDir = UPLOAD_DIR + md5; File dir = new File(taskDir); if (!dir.exists()) { // 没有任何已上传分片，返回所有分片都缺 return Result.ok("未发现已上传分片", buildChunkStatus(null, chunkTotal)); } File[] files = dir.listFiles((d, name) -> name.endsWith(".part")); return Result.ok("查询成功", buildChunkStatus(files, chunkTotal)); } @PostMapping("/merge") public Result mergeChunks(@RequestParam("md5") String md5, @RequestParam("chunkTotal") Integer chunkTotal, @RequestParam("fileName") String fileName) { String taskDir = UPLOAD_DIR + md5; File dir = new File(taskDir); if (!dir.exists()) { return Result.fail("上传任务不存在，请重新上传"); } // 校验分片完整性 File[] files = dir.listFiles((d, name) -> name.endsWith(".part")); if (files == null || files.length != chunkTotal) { return Result.fail("分片不完整，已上传" + (files == null ? 0 : files.length) + "片"); } // 执行合并 String targetPath = UPLOAD_DIR + "merged/" + md5 + "_" + System.currentTimeMillis() + "_" + fileName; boolean merged = ChunkMergeUtil.mergeFiles(dir, targetPath, chunkTotal); if (!merged) { return Result.fail("合并失败"); } return Result.ok("合并成功", targetPath); } }这里有个小细节：分片名直接用数字序号，没有用全角补零。因为合并时先排序再拼接，后面合并工具类里会处理。
3.2 查询接口的返回结构设计
check接口的返回要能把"哪些分片已存在、哪些缺失"一次说清楚。这里给一个简单清晰的DTO结构：
public class ChunkStatusVO { private List<Integer> uploadedIndexes; // 已上传分片序号列表 private List<Integer> missingIndexes; // 缺失分片序号列表 private boolean fileExists; // 是否已完整上传，用于秒传 }对应的buildChunkStatus方法，逻辑就是扫描目录下存在的.part文件，把序号解析出来，再和理论总数比对：
private ChunkStatusVO buildChunkStatus(File[] files, int chunkTotal) { Set<Integer> uploadedSet = new HashSet<>(); if (files != null) { for (File f : files) { String name = f.getName(); String numStr = name.substring(0, name.indexOf(".part")); uploadedSet.add(Integer.parseInt(numStr)); } } List<Integer> uploaded = new ArrayList<>(uploadedSet); Collections.sort(uploaded); List<Integer> missing = new ArrayList<>(); for (int i = 0; i < chunkTotal; i++) { if (!uploadedSet.contains(i)) { missing.add(i); } } ChunkStatusVO vo = new ChunkStatusVO(); vo.setUploadedIndexes(uploaded); vo.setMissingIndexes(missing); vo.setFileExists(uploaded.size() == chunkTotal); return vo; }前端拿到这个结构后，可以直接把missingIndexes里的分片发出去，这就是断点续传的基础。实际项目中还可以把这个查询结果缓存到Redis里，避免每次都扫目录，但如果文件量不大，直接扫目录是最简单可靠的。
3.3 合并分片的工具类与文件流处理
合并的核心逻辑不复杂，但要特别注意两个问题：一是顺序，二是IO效率。这里给出一个可以直接用的合并工具类。
public class ChunkMergeUtil { public static boolean mergeFiles(File taskDir, String targetPath, int chunkTotal) { try (FileOutputStream fos = new FileOutputStream(new File(targetPath))) { for (int i = 0; i < chunkTotal; i++) { File chunk = new File(taskDir, i + ".part"); if (!chunk.exists()) { return false; } try (FileInputStream fis = new FileInputStream(chunk)) { byte[] buffer = new byte[8 * 1024]; int len; while ((len = fis.read(buffer)) != -1) { fos.write(buffer, 0, len); } } } return true; } catch (IOException e) { return false; } } }这里用的是最简单的顺序流式合并。为什么不用RandomAccessFile定位写？因为这个场景下分片是顺序接收、顺序合并的，不需要随机定位写入，用流式合并就可以避免文件随机读写的额外开销。只有在"多个分片同时写入同一个物理文件"的场景下才需要RandomAccessFile，但那是不必要的复杂设计，反而容易引入并发覆盖问题。
合并完成后，最好把任务的临时目录整体删除，释放磁盘空间。可以在合并成功返回前加上一段清理逻辑：
if (merged) { deleteQuietly(dir); }删除时要注意文件流的关闭，Windows环境下如果分片的读流没关干净，删除会失败。Linux相对好一些，但出于习惯我依然会用try-with-resources确保所有流都关闭。
4. 前端配合逻辑：切片、并发、进度与重试
后端接口就位以后，前端是另一条腿。前端要做四件事：切片、上传、进度展示、失败重试。我用原生JavaScript写了一份示例，不依赖任何前端框架，你随便贴到Vue或者React里都能直接适配。
4.1 分片读取与MD5计算
前端读取文件用File.slice()方法，计算MD5用SparkMD5库，它支持增量计算，不会一次性把大文件读入内存。
const CHUNK_SIZE = 5 * 1024 * 1024; // 5MB function blobToMD5(file) { return new Promise((resolve, reject) => { const fileReader = new FileReader(); const spark = new SparkMD5.ArrayBuffer(); const chunkSize = 2 * 1024 * 1024; let currentChunk = 0; const chunks = Math.ceil(file.size / chunkSize); fileReader.onload = e => { spark.append(e.target.result); currentChunk++; if (currentChunk < chunks) { loadNext(); } else { resolve(spark.end()); } }; fileReader.onerror = reject; function loadNext() { const start = currentChunk * chunkSize; const end = Math.min(start + chunkSize, file.size); fileReader.readAsArrayBuffer(file.slice(start, end)); } loadNext(); }); }这里用2MB的小块做MD5计算，是为了避免内存突然冲高。如果你用5MB甚至更大的切片去读，遇到1GB的录像文件，JS引擎内存占用可能飙到几百MB，老机器会卡。
4.2 并发上传与进度管理
切片完成后，每个分片的FormData里要带上后端要求的参数。我自己实践下来的稳妥做法是：维护一个并发池，固定3个并发，每完成一个就从队列里取下一个，同时实时更新上传进度。
async function uploadFile(file) { const md5 = await blobToMD5(file); // 先检查服务端状态，决定是否秒传或续传 const checkResp = await fetch(`/api/v1/file/chunk/check?md5=${md5}&chunkTotal=${chunkTotal}`); const checkData = await checkResp.json(); if (checkData.data.fileExists) { // 秒传逻辑 return; } const missingIndexes = checkData.data.missingIndexes; const chunkTotal = Math.ceil(file.size / CHUNK_SIZE); const uploadedCount = { value: chunkTotal - missingIndexes.length }; // 构造待上传分片队列 const tasks = missingIndexes.map(index => { const start = index * CHUNK_SIZE; const end = Math.min(start + CHUNK_SIZE, file.size); return { index, blob: file.slice(start, end) }; }); // 并发控制：3个并发 const concurrency = 3; const queue = [...tasks]; const workers = Array.from({ length: concurrency }, () => worker(queue, md5, chunkTotal, uploadedCount)); await Promise.all(workers); // 全部完成，调用合并接口 await fetch('/api/v1/file/merge', { method: 'POST', body: buildForm({ md5, chunkTotal, fileName: file.name }) }); } async function worker(queue, md5, chunkTotal, uploadedCount) { while (queue.length > 0) { const task = queue.shift(); const form = new FormData(); form.append('file', task.blob, `${task.index}.part`); form.append('md5', md5); form.append('chunkIndex', task.index); form.append('chunkTotal', chunkTotal); let retry = 0; while (retry < 3) { try { const resp = await fetch('/api/v1/file/chunk', { method: 'POST', body: form }); if (resp.ok) { uploadedCount.value++; // 更新进度条 updateProgress(uploadedCount.value, chunkTotal); break; } } catch (e) { // 网络异常，重试 } retry++; } } }这段代码核心是worker函数里的重试循环。每个分片最多重试3次，单分片失败了不会影响其他分片继续上传，因为并发池里的其他worker还在跑。三个worker各失败三个分片，最后missingIndexes会返回缺失序号，前端再补传就行。
4.3 续传的触发时机
续传逻辑就藏在check接口返回的missingIndexes里。用户刷新页面重新选择同一个文件，MD5没变，服务端还是那些.part文件，前端只需要把缺失的分片补传。不需要额外做任何状态恢复。
这也是为什么我建议用MD5作为任务标识而不是用UUID。UUID每次生成都会变，服务端没法判断哪些分片已经传过，断点续传就无从谈起。
5. 秒传与断点续传：分片方案的进阶玩法
分片上传跑通只是第一步，真正让用户体验质变的是秒传和断点续传。这两件事实现成本不高，但对产品体验的提升非常明显。
5.1 秒传的前提是唯一的文件标识
秒传的实现依赖文件的唯一标识，最常用的是MD5。前端计算出MD5后，先请求一个查询接口，如果服务端判断这个MD5对应的完整文件已经存在，就直接返回已有地址，前端跳转下一步，一秒钟都不需要等。
这里要说明一点：秒传是否可靠，取决于MD5计算的质量和唯一性。理论上MD5有可能碰撞，但实际业务中碰撞概率极低，而且视频内容几乎不可能出现两个不同视频相同MD5的情况。如果你的产品对数据一致性极敏感，可以升级到SHA-1或者MD5加文件大小双重校验。
服务端判断"文件已存在"有两个维度：一是分片是否齐全，二是合并后的完整文件是否已在存储区。前者用于断点续传，后者用于秒传。这两个状态要区分开，不能混用。
5.2 断点续传的状态恢复实例
举一个我实际处理过的场景：老师上传一个800MB的课程视频，传到第47片时断网了。前端此时已经传完46片，剩余54片。
老师重新连接网络后，刷新页面重新选中同一个文件。前端计算MD5，调用check接口。后端扫临时目录发现0.part到45.part都存在，返回uploadedIndexes是0-45，missingIndexes是46-99。前端拿到缺失列表，直接补传46片之后的内容，然后触发合并。整个恢复过程用户没有感知。
这个方案里有一个容易踩的坑：临时目录的碎片清理。如果用户传了一半就彻底放弃，.part文件会残留。我建议加一个定时任务，清理超过24小时未更新的任务目录。
5.3 合并后的文件去向与二次确认
合并完成后，文件还不能直接认为上传成功。业务上通常还要对视频做转码、切片、抽帧等处理，这时候建议把文件移动到业务存储目录，再发消息给后端处理队列。我在项目中用的是同步合并+异步转码的方式：合并接口返回"文件已合并"，同时发送一条队列消息，转码服务拿到文件路径后处理完再把结果写回数据库。
这个设计的意义在于：上传接口的响应时间不会因为视频转码而被拖长，用户能立刻看到"上传成功"，转码进度可以另做轮询或推送。
6. 我踩过的坑与最后的经验总结
分片上传代码写出来不难，真正麻烦的是在真实网络环境里把它调稳。这一章把我实际碰到的几个问题列出来，当作给你的预警。
6.1 分片大小和并发数的配合坑
我第一次做分片上传时，把分片大小设为1MB，并发设为8，想着这样更细粒度。结果实测下来接口响应数量暴增，服务端日志刷屏，数据库连接池差点被占满，而且前端并发请求把带宽全吃掉了，上传总耗时反而比单片上传慢。
后来把分片调到5MB、并发降到3，整体才稳定下来。核心逻辑是：分片上传追求的不是把单次传输做到最小，而是让"失败可恢复、资源可控、整体时间可接受"这三者达到平衡。
6.2 服务端磁盘与临时目录的规划
临时目录一定要放在数据盘上，别放系统盘。视频文件合并前的分片总和和原文件大小一样，一个1GB的视频在合并完成前占用1GB磁盘。如果同时有几个大文件在传，临时目录可能会暴涨。
建议在代码里定期统计任务目录数量，超过阈值就告警或拒绝新上传。另外，合并完成后立即删除临时目录，这个逻辑别漏，否则磁盘满了才发现问题就晚了。
6.3 MultipartFile的transferTo方法的一个细节
file.transferTo(targetFile)在Spring Boot里很常用，但它的实现会受容器的临时目录影响。当分片写入/tmp之类的目录时，如果该目录所在文件系统空间不足，会抛出FileSystemException或者IOException。生产环境务必把spring.servlet.multipart.location单独配置到一个有足够空间的路径下，并且注意清理。
还有一点，如果分片文件和目标文件在同一个文件系统内，transferTo会走原子性的文件移动；如果跨文件系统，则会退化成复制加删除。这个差异会影响性能和失败表现，你可以在配置里明确指定分片写入目录。
6.4 前端并发上传的内存问题
前端如果直接用file.slice()生成分片后再一次性放进数组，大文件会占大量内存。因为每个slice对象实际上引用了原文件的某段数据，并不会马上释放。我上面的代码里是边生成任务边消费，这个思路在高并发场景下仍然有效。如果你使用的是现成的分片上传库，注意检查它的实现是否也做了流式处理。
6.5 关于示例代码的最终使用建议
这份示例代码是入门级的可运行版本，目的是把分片上传的主干逻辑完整呈现。拿到自己项目里用的时候，建议在这个基础上加上三处增强：一是上传凭证校验，给每个上传任务分配token，防止乱传文件；二是合并时对分片做MD5一致性校验，防止传输中被篡改；三是把状态记录从目录扫描升级为数据库或缓存管理，便于做总量统计和异常监控。
我在实际项目里最后用的方案就是这套思路：Spring Boot后端接收分片，前端流式切片并发上传，MD5做断点续传和秒传标识，合并完成后异步转码。稳定跑了很久，老师们再也没来找我说上传失败的问题。你照着这个方案实现一遍，再根据自己的业务场景调整参数和存储方式，基本就能覆盖视频上传的绝大多数需求了。
暴力到O(1)空间解法)
