傳：分片原理與Spring Boot實戰(zhàn))
最近在面試候選人的時候我經(jīng)常問到一個問題“你們項目里實現(xiàn)過大文件上傳嗎斷點續(xù)傳是怎么做的”這個問題看起來基礎(chǔ)但能把大文件上傳從“能用”做到“好用”其實涉及分片、并發(fā)、合并、去重、異?；謴?fù)等一系列細(xì)節(jié)。很多候選人能說出“把文件切成幾塊傳上去再合并”這個思路但一旦追問到分片大小怎么定、斷點續(xù)傳怎么判斷、合并順序怎么保證、秒傳怎么實現(xiàn)就答不上來了。這篇文章就從面試視角出發(fā)把大文件上傳與斷點續(xù)傳的完整知識體系和可落地代碼整理出來。如果你是剛接觸文件上傳的開發(fā)者可以把它當(dāng)成一份系統(tǒng)化的入門教程如果你已經(jīng)做過普通文件上傳但沒深入過大文件場景本文也會幫你彌補方案設(shè)計和異常排查這兩塊短板。1. 背景與核心概念1.1 為什么大文件上傳經(jīng)常出問題普通文件上傳很簡單前端一個input typefile后端用MultipartFile接收幾行代碼就能跑通。但一旦文件體積上升到幾百 MB、甚至幾個 GB問題就會集中出現(xiàn)HTTP 連接超時一次請求傳輸時間過長中間網(wǎng)絡(luò)抖動一下整個文件就要重新傳。內(nèi)存溢出后端通過byte[]一次性讀取整個文件時很容易造成 JVM 堆內(nèi)存溢出OOM。無法續(xù)傳傳輸?shù)?90% 失敗沒有續(xù)傳機制只能從頭再來。帶寬浪費同一個文件在多個用戶之間重復(fù)上傳浪費存儲空間和帶寬。服務(wù)端壓力大大量用戶同時上傳大文件服務(wù)端的線程、內(nèi)存、磁盤 IO 都會被瞬間打滿。大文件上傳的核心思路就是“化整為零再聚零為整”前端把大文件切成多個小分片逐個上傳到服務(wù)端最后服務(wù)端把所有分片按順序合并成完整文件。這個過程中再配合斷點續(xù)傳、秒傳等機制就能解決上面的大部分問題。1.2 分片上傳、斷點續(xù)傳、秒傳的區(qū)別這三個概念經(jīng)常一起出現(xiàn)但含義不同。分片上傳Multipart Upload是基礎(chǔ)手段。前端把文件按照固定大小切開比如每個分片 5MB然后一個個傳上去。它的價值在于單次請求的時間變短了失敗后只需要重傳失敗的分片服務(wù)端也可以并發(fā)處理多個分片。斷點續(xù)傳是建立在分片上傳之上的。它記錄“哪些分片已經(jīng)傳成功”當(dāng)網(wǎng)絡(luò)中斷、頁面刷新、服務(wù)重啟之后已經(jīng)上傳成功的分片不需要重傳只需要從第一個失敗的分片繼續(xù)傳。實現(xiàn)斷點續(xù)傳的關(guān)鍵在于服務(wù)端要能告訴前端“你已經(jīng)有這些分片了跳過它們”。秒傳則是更高一層的優(yōu)化。它本質(zhì)上做了“文件去重”在上傳開始前先計算文件內(nèi)容哈希服務(wù)端發(fā)現(xiàn)這個哈希對應(yīng)的文件已經(jīng)存在就直接返回已有文件地址前端不再真正上傳數(shù)據(jù)。秒傳面對的場景是“同一個文件被多人上傳”而不是“文件真的能秒傳”。用一個表格來總結(jié)概念解決什么問題核心依賴分片上傳大文件傳輸超時、內(nèi)存溢出前端切片、服務(wù)端合并斷點續(xù)傳傳輸失敗后重新上傳已上傳分片記錄秒傳相同文件重復(fù)上傳文件內(nèi)容哈希去重1.3 常見應(yīng)用場景大文件上傳和斷點續(xù)傳在業(yè)務(wù)系統(tǒng)里非常常見視頻類網(wǎng)站的視頻上傳、轉(zhuǎn)碼素材上傳。網(wǎng)盤類的文檔、壓縮包、安裝包上傳。企業(yè)內(nèi)部系統(tǒng)的大數(shù)據(jù)文件導(dǎo)入、日志上傳。在線教育平臺的課件、錄播視頻上傳。對象存儲服務(wù)的前端直傳場景。這些場景往往對成功率、傳輸效率、用戶體驗都有較高要求所以需要一套比普通上傳更完整的方案。2. 整體方案設(shè)計2.1 典型技術(shù)棧與流程一個可落地的大文件上傳方案通常由三部分組成前端負(fù)責(zé)文件分片、并發(fā)控制、進度展示、失敗重試。后端負(fù)責(zé)接收分片、記錄上傳狀態(tài)、合并分片、校驗文件。存儲層保存分片臨時文件、最終文件、上傳元數(shù)據(jù)。本地磁盤、分布式文件系統(tǒng)、對象存儲都可以。整體流程如下前端選擇文件后計算文件 MD5/SHA 值并按照固定大小切成多個分片。前端調(diào)用后端初始化接口攜帶文件名、文件大小、總文件 MD5、總分片數(shù)。后端生成uploadId返回“該文件是否已經(jīng)存在秒傳判斷結(jié)果”以及“已上傳分片編號列表”。如果秒傳命中前端直接結(jié)束。如果秒傳未命中前端遍歷分片跳過已經(jīng)上傳過的分片并發(fā)上傳剩余分片。后端接收每個分片校驗分片編號、分片大小、分片 MD5把分片落盤并記錄“該分片已上傳成功”。所有分片上傳完成后前端調(diào)用合并接口。后端校驗分片是否齊全按分片編號順序合并生成最終文件。后端清理臨時分片和上傳元數(shù)據(jù)返回最終的文件訪問地址。這里的關(guān)鍵設(shè)計是服務(wù)端必須能夠回答“哪些分片已經(jīng)傳過了”這個問題這也是斷點續(xù)傳與普通分片上傳的本質(zhì)區(qū)別。2.2 需要維護哪些元數(shù)據(jù)要讓整個流程可恢復(fù)、可校驗服務(wù)端需要記錄一份上傳會話信息。通常包含以下字段字段含義uploadId上傳會話唯一標(biāo)識fileName原始文件名fileSize文件總大小fileMd5整個文件的 MD5用于秒傳判斷totalChunks總分片數(shù)chunkSize分片大小uploadedChunks已上傳成功分片編號集合status上傳狀態(tài)例如 INIT / UPLOADING / MERGED / FAILEDcreateTime / updateTime創(chuàng)建時間、更新時間在中小項目或單機部署場景下這個信息可以放在內(nèi)存Map里也可以存入數(shù)據(jù)庫。在生產(chǎn)環(huán)境中更推薦存入 Redis因為 Redis 天然支持過期時間可以自動清理長時間未完成的上傳會話而且多實例部署時狀態(tài)是共享的。3. 核心原理拆解3.1 分片大小怎么定分片大小沒有絕對標(biāo)準(zhǔn)需要結(jié)合網(wǎng)絡(luò)環(huán)境、服務(wù)器配置和業(yè)務(wù)類型來選。如果分片太小比如 1MB分片數(shù)量會非常多HTTP 請求數(shù)過多反而增加網(wǎng)絡(luò)開銷和服務(wù)端壓力。如果分片太大比如 100MB等于把大文件上傳問題又繞回來了單次請求時間過長失敗重試代價大。業(yè)界常用的范圍是2MB ~ 20MB。局域網(wǎng)內(nèi)部系統(tǒng)可以用 10MB 或 20MB公網(wǎng)環(huán)境下5MB是比較穩(wěn)妥的選擇。分片數(shù)量可以這樣計算totalChunks Math.ceil(file.size / chunkSize)比如一個 1GB 的文件使用 5MB 分片1024MB / 5MB ≈ 205也就是約 205 個分片這個數(shù)量級對服務(wù)器來說是完全可以接受的。3.2 斷點續(xù)傳的實現(xiàn)方式斷點續(xù)傳有兩種典型的實現(xiàn)思路方案一服務(wù)端記錄已上傳分片編號前端每次開始上傳前先調(diào)用查詢接口服務(wù)端返回已經(jīng)上傳成功的分片編號集合。前端篩選出未上傳的分片只上傳這些分片。這種方案的優(yōu)點是邏輯清晰、實現(xiàn)簡單適合前后端都是自己控制的場景。缺點是需要自己維護分片狀態(tài)。方案二基于對象存儲的 Multipart Upload如果使用 MinIO、阿里云 OSS、AWS S3 這類對象存儲它們本身提供了 Multipart Upload 接口。服務(wù)端先調(diào)用 InitiateMultipartUpload 獲取 uploadId然后逐片調(diào)用 UploadPart 上傳最后調(diào)用 CompleteMultipartUpload 合并。如果中途失敗可以調(diào)用 ListParts 查詢已上傳的分片。這種方案把分片存儲、合并、容災(zāi)都下沉到對象存儲適合云原生場景。但需要理解對象存儲的 API并且上傳憑證、簽名邏輯要處理好。兩種方案并不沖突。實際項目中也經(jīng)?？吹健扒岸朔制? 后端聚合 對象存儲保存最終文件”的混合模式。3.3 秒傳的哈希策略秒傳的核心是內(nèi)容去重最常用的手段是 MD5。但這里有一個坑如果文件非常大對完整文件計算 MD5 會非常耗時前端可能要卡頓幾十秒甚至幾分鐘。所以生產(chǎn)環(huán)境常用折中方案先取文件大小、修改時間做一層快速篩選。再對文件的開頭、中間、結(jié)尾各取一段字節(jié)合并計算 MD5。如果兩個文件這些特征完全一致再決定是否執(zhí)行全量 MD5。這種方案雖然存在理論上的碰撞概率但在絕大多數(shù)業(yè)務(wù)場景下已經(jīng)夠用。如果對準(zhǔn)確性要求極高可以使用 SHA-256或同時結(jié)合文件大小做二次校驗。我這里為了演示方便前端示例中還是使用 SparkMD5 對完整文件計算 MD5。實際項目如果擔(dān)心性能可以參考上面的優(yōu)化思路。3.4 服務(wù)端合并分片合并分片是大文件上傳中最容易出現(xiàn)問題的環(huán)節(jié)核心是保證順序和完整性。合并必須按照chunkIndex升序進行不能依賴文件名排序因為分片文件名可能是隨機生成的。合并過程中要校驗分片數(shù)量是否等于totalChunks每個分片大小是否符合預(yù)期。合并完成后要清理臨時分片文件避免磁盤被占滿。合并時建議使用流式讀寫不要把所有分片一次性讀入內(nèi)存。如果分片數(shù)量很多可以分批合并比如每次合并 100 個分片防止單次 IO 抖動。3.5 并發(fā)控制分片上傳的一大好處是可以并發(fā)上傳多個分片提升傳輸速度。但并發(fā)不能無上限否則服務(wù)端線程、帶寬、磁盤 IO 會被直接打滿。前端并發(fā)建議控制在3 ~ 6個后端在網(wǎng)關(guān)層或服務(wù)層也建議做總并發(fā)限制。分段并發(fā)上傳時需要前端自己實現(xiàn)一個簡單的“任務(wù)隊列”而不是Promise.all一次性把所有分片請求發(fā)出去。4. 實戰(zhàn)Spring Boot 實現(xiàn)大文件分片上傳與斷點續(xù)傳4.1 環(huán)境準(zhǔn)備本文的示例以后端 Spring Boot 前端原生 HTML/JavaScript 為主重點演示完整流程。需要準(zhǔn)備的環(huán)境如下JDK 8 或以上版本。Maven 3.6 或以上版本。Spring Boot 2.x 或 3.x本示例以常見版本為基礎(chǔ)實際請按項目情況調(diào)整。一個前端靜態(tài)目錄Spring Boot 直接放在src/main/resources/static下即可。由于分片上傳的核心邏輯和 Spring Boot 版本關(guān)系不大核心代碼在 2.x 和 3.x 上都可以運行。4.2 項目結(jié)構(gòu)upload-demo ├── pom.xml └── src/main ├── java/com/example/upload │ ├── UploadDemoApplication.java │ ├── controller/UploadController.java │ ├── dto/UploadInitDTO.java │ ├── dto/UploadChunkDTO.java │ ├── dto/UploadMergeDTO.java │ ├── service/UploadService.java │ └── vo/UploadInitVO.java └── resources └── static ├── index.html └── index.js4.3 添加依賴pom.xml只需要 Spring Boot Web 依賴和文件上傳相關(guān)依賴Spring Boot 默認(rèn)已經(jīng)引入了文件上傳能力。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency /dependencies重點說明示例中沒有引入額外工具包合并分片全部使用 JDK 原生 IO 實現(xiàn)依賴少、容易理解。4.4 后端接口設(shè)計后端一共提供 4 個接口接口方法作用/upload/initPOST初始化上傳會話返回 uploadId 和已上傳分片列表/upload/chunkPOST上傳單個分片/upload/check/{uploadId}GET查詢已上傳分片編號/upload/mergePOST合并分片我們先定義 DTO。// 文件路徑src/main/java/com/example/upload/dto/UploadInitDTO.java public class UploadInitDTO { private String fileName; private Long fileSize; private String fileMd5; private Integer totalChunks; private Integer chunkSize; // 省略 getter/setter }// 文件路徑src/main/java/com/example/upload/dto/UploadChunkDTO.java public class UploadChunkDTO { private String uploadId; private Integer chunkIndex; private Integer totalChunks; private String chunkMd5; // 省略 getter/setter }// 文件路徑src/main/java/com/example/upload/dto/UploadMergeDTO.java public class UploadMergeDTO { private String uploadId; // 省略 getter/setter }然后定義上傳會話實體。為了方便演示這里使用ConcurrentHashMap保存上傳元數(shù)據(jù)。生產(chǎn)環(huán)境建議替換為 Redis。// 文件路徑src/main/java/com/example/upload/service/UploadSession.java public class UploadSession { private String uploadId; private String fileName; private Long fileSize; private String fileMd5; private Integer totalChunks; private Integer chunkSize; private SetInteger uploadedChunks ConcurrentHashMap.newKeySet(); private String finalFilePath; }4.5 核心 Service 實現(xiàn)下面逐步實現(xiàn)UploadService。// 文件路徑src/main/java/com/example/upload/service/UploadService.java Service public class UploadService { private static final String UPLOAD_DIR System.getProperty(java.io.tmpdir) /upload-demo/; private static final String MERGE_DIR System.getProperty(java.io.tmpdir) /upload-demo/merge/; private final MapString, UploadSession sessionMap new ConcurrentHashMap(); public UploadSession initUpload(UploadInitDTO dto) { // 先做秒傳判斷如果文件已存在直接返回完整的 session并標(biāo)記為秒傳命中 String existFile findExistByMd5(dto.getFileMd5()); UploadSession session new UploadSession(); session.setUploadId(UUID.randomUUID().toString().replace(-, )); session.setFileName(dto.getFileName()); session.setFileSize(dto.getFileSize()); session.setFileMd5(dto.getFileMd5()); session.setTotalChunks(dto.getTotalChunks()); session.setChunkSize(dto.getChunkSize()); if (existFile ! null) { session.setFinalFilePath(existFile); // 給一個特殊標(biāo)記表示秒傳命中 session.setSkipUpload(true); } sessionMap.put(session.getUploadId(), session); return session; } public void uploadChunk(UploadChunkDTO dto, MultipartFile file) throws IOException { UploadSession session sessionMap.get(dto.getUploadId()); if (session null) { throw new RuntimeException(uploadId 不存在請重新初始化上傳); } // 分片編號不能超出總分片數(shù) if (dto.getChunkIndex() 0 || dto.getChunkIndex() session.getTotalChunks()) { throw new RuntimeException(分片編號不合法); } // 如果該分片已經(jīng)上傳直接返回避免重復(fù)寫盤 if (session.getUploadedChunks().contains(dto.getChunkIndex())) { return; } File chunkDir new File(UPLOAD_DIR dto.getUploadId()); if (!chunkDir.exists()) { chunkDir.mkdirs(); } // 分片文件名使用 uploadId chunkIndex便于合并時按順序讀取 File chunkFile new File(chunkDir, chunk_ dto.getChunkIndex()); try (InputStream in file.getInputStream(); FileOutputStream out new FileOutputStream(chunkFile)) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } } session.getUploadedChunks().add(dto.getChunkIndex()); sessionMap.put(dto.getUploadId(), session); } public SetInteger getUploadedChunks(String uploadId) { UploadSession session sessionMap.get(uploadId); if (session null) { throw new RuntimeException(uploadId 不存在); } return session.getUploadedChunks(); } public String mergeUpload(UploadMergeDTO dto) throws IOException { UploadSession session sessionMap.get(dto.getUploadId()); if (session null) { throw new RuntimeException(uploadId 不存在); } // 檢查分片是否齊全 if (session.getUploadedChunks().size() ! session.getTotalChunks()) { throw new RuntimeException(分片不完整已上傳 session.getUploadedChunks().size() / session.getTotalChunks()); } File mergeDir new File(MERGE_DIR); if (!mergeDir.exists()) { mergeDir.mkdirs(); } String targetFileName session.getFileMd5() _ session.getFileName(); File targetFile new File(mergeDir, targetFileName); // 使用 RandomAccessFile 按順序?qū)懳募?try (RandomAccessFile raf new RandomAccessFile(targetFile, rw)) { for (int i 0; i session.getTotalChunks(); i) { File chunkFile new File(UPLOAD_DIR dto.getUploadId(), chunk_ i); if (!chunkFile.exists()) { throw new RuntimeException(第 i 個分片不存在); } byte[] bytes Files.readAllBytes(chunkFile.toPath()); raf.seek(raf.length()); raf.write(bytes); } } // 合并成功后清理臨時分片 File chunkDir new File(UPLOAD_DIR dto.getUploadId()); if (chunkDir.exists()) { for (File f : chunkDir.listFiles()) { f.delete(); } chunkDir.delete(); } session.setFinalFilePath(targetFile.getAbsolutePath()); sessionMap.put(dto.getUploadId(), session); return targetFile.getAbsolutePath(); } private String findExistByMd5(String fileMd5) { // 簡化邏輯遍歷 sessionMap 中已經(jīng)合并過的文件 // 生產(chǎn)環(huán)境改為查詢數(shù)據(jù)庫或?qū)ο蟠鎯?return null; } }這里需要解釋幾個關(guān)鍵點分片文件名使用的是chunk_0、chunk_1這種命名方式合并時直接按編號遍歷即可不依賴文件修改時間或隨機名。RandomAccessFile寫入時先定位到文件末尾再寫入保證分片按順序追加。合并之后清理臨時目錄避免磁盤空間被不斷占用。findExistByMd5在示例中返回null實際項目中可以查詢數(shù)據(jù)庫中的文件表判斷是否存在同 MD5 的文件。4.6 Controller 實現(xiàn)// 文件路徑src/main/java/com/example/upload/controller/UploadController.java RestController RequestMapping(/upload) public class UploadController { private final UploadService uploadService; public UploadController(UploadService uploadService) { this.uploadService uploadService; } PostMapping(/init) public UploadSession init(RequestBody UploadInitDTO dto) { return uploadService.initUpload(dto); } PostMapping(/chunk) public MapString, Object uploadChunk(UploadChunkDTO dto, RequestParam(file) MultipartFile file) throws IOException { uploadService.uploadChunk(dto, file); MapString, Object result new HashMap(); result.put(uploadId, dto.getUploadId()); result.put(chunkIndex, dto.getChunkIndex()); return result; } GetMapping(/check/{uploadId}) public SetInteger check(PathVariable String uploadId) { return uploadService.getUploadedChunks(uploadId); } PostMapping(/merge) public MapString, String merge(RequestBody UploadMergeDTO dto) throws IOException { String path uploadService.mergeUpload(dto); MapString, String result new HashMap(); result.put(filePath, path); return result; } }注意/upload/chunk接口接收的是MultipartFile所以前端上傳分片時分片文件要放在表單的file字段中其他參數(shù)放在表單字段中。4.7 前端實現(xiàn)前端使用原生 HTML JavaScript Axios 實現(xiàn)。先寫一個簡單的頁面。!-- 文件路徑src/main/resources/static/index.html -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 title大文件分片上傳示例/title /head body input typefile idfileInput / button iduploadBtn開始上傳/button div idprogress等待選擇文件.../div script srchttps://cdn.jsdelivr.net/npm/axios/dist/axios.min.js/script script srchttps://cdn.jsdelivr.net/npm/spark-md53.0.2/spark-md5.min.js/script script srcindex.js/script /body /html然后寫核心的 JavaScript 邏輯。// 文件路徑src/main/resources/static/index.js const CHUNK_SIZE 5 * 1024 * 1024; // 5MB const MAX_CONCURRENT 3; // 同時上傳 3 個分片 document.getElementById(uploadBtn).addEventListener(click, async () { const fileInput document.getElementById(fileInput); const file fileInput.files[0]; if (!file) { alert(請先選擇文件); return; } // 1. 計算文件 MD5用于秒傳判斷 const fileMd5 await calcFileMD5(file); console.log(文件 MD5:, fileMd5); // 2. 計算總分片數(shù) const totalChunks Math.ceil(file.size / CHUNK_SIZE); // 3. 初始化上傳 const initRes await axios.post(/upload/init, { fileName: file.name, fileSize: file.size, fileMd5: fileMd5, totalChunks: totalChunks, chunkSize: CHUNK_SIZE }); const uploadId initRes.data.uploadId; // 如果服務(wù)端判斷命中了秒傳直接結(jié)束 if (initRes.data.skipUpload) { document.getElementById(progress).textContent 秒傳成功文件已存在; return; } // 4. 查詢已上傳的分片編號這里用 set 提升查找效率 const checkRes await axios.get(/upload/check/ uploadId); const uploadedChunks new Set(checkRes.data); // 5. 構(gòu)造待上傳分片隊列 const chunkTasks []; for (let i 0; i totalChunks; i) { if (uploadedChunks.has(i)) { continue; } const start i * CHUNK_SIZE; const end Math.min(start CHUNK_SIZE, file.size); const chunk file.slice(start, end); chunkTasks.push({ index: i, chunk: chunk }); } if (chunkTasks.length 0) { // 所有分片都已上傳過只需要合并 await mergeFile(uploadId); return; } // 6. 并發(fā)控制上傳 await uploadChunksInConcurrency(chunkTasks, uploadId, totalChunks); // 7. 合并分片 await mergeFile(uploadId); }); function uploadChunksInConcurrency(tasks, uploadId, totalChunks) { return new Promise((resolve, reject) { let index 0; let active 0; let completed 0; function next() { if (index tasks.length active 0) { resolve(); return; } while (active MAX_CONCURRENT index tasks.length) { const task tasks[index]; index; active; uploadOneChunk(task, uploadId) .then(() { active--; completed; const percent Math.floor(completed / totalChunks * 100); document.getElementById(progress).textContent 上傳進度 percent %; next(); }) .catch((err) { active--; console.error(上傳失敗, err); reject(err); }); } } next(); }); } function uploadOneChunk(task, uploadId) { const formData new FormData(); formData.append(file, task.chunk); formData.append(uploadId, uploadId); formData.append(chunkIndex, task.index); formData.append(totalChunks, task.totalChunks); return axios.post(/upload/chunk, formData); } function mergeFile(uploadId) { return axios.post(/upload/merge, { uploadId }).then((res) { document.getElementById(progress).textContent 合并完成文件路徑 res.data.filePath; }); } function calcFileMD5(file) { return new Promise((resolve, reject) { const reader new FileReader(); const spark new SparkMD5.ArrayBuffer(); let currentChunk 0; const chunkSize 2 * 1024 * 1024; // 讀取 MD5 時也用分片避免大文件卡死瀏覽器 function readNext() { const start currentChunk * chunkSize; const end Math.min(start chunkSize, file.size); reader.readAsArrayBuffer(file.slice(start, end)); } reader.onload (e) { spark.append(e.target.result); currentChunk; if (currentChunk Math.ceil(file.size / chunkSize)) { readNext(); } else { resolve(spark.end()); } }; reader.onerror (err) { reject(err); }; readNext(); }); }前端代碼中calcFileMD5使用分片讀取的方式計算 MD5而不是一次性readAsArrayBuffer整個文件這樣可以避免大文件導(dǎo)致瀏覽器內(nèi)存暴漲。uploadChunksInConcurrency函數(shù)實現(xiàn)了一個簡單的并發(fā)隊列保證同一時間最多只有 3 個分片在傳輸。這種寫法比Promise.all一次性發(fā)出所有請求更安全。4.8 運行與驗證啟動 Spring Boot 應(yīng)用后瀏覽器訪問http://localhost:8080/index.html選擇一個比較大的文件比如幾百 MB點擊“開始上傳”觀察控制臺輸出。預(yù)期效果前端按 5MB 大小切分文件。后端臨時目錄下出現(xiàn)uploadId/chunk_0、chunk_1等分片文件?？刂婆_顯示上傳進度。所有分片上傳結(jié)束后后端合并文件并清理臨時目錄。如果想驗證斷點續(xù)傳可以在上傳過程中手動關(guān)閉后端服務(wù)然后重新啟動再次選擇同一個文件上傳。前端會通過/upload/check接口拿到已上傳分片跳過它們只補傳失敗的分片。5. 常見問題與排查思路5.1 上傳大文件時 OOM問題現(xiàn)象上傳過程中服務(wù)端拋出OutOfMemoryError: Java heap space。可能原因后端使用byte[]直接接收整個文件文件過大導(dǎo)致堆內(nèi)存溢出。前端使用readAsArrayBuffer讀取整個文件瀏覽器標(biāo)簽頁內(nèi)存飆升。并發(fā)分片太多每個請求都緩存了較大的分片數(shù)據(jù)。解決思路后端接收分片時用MultipartFile.getInputStream()流式讀取不要轉(zhuǎn)成byte[]。前端計算 MD5 時也要分片讀取。控制并發(fā)數(shù)量避免同時多個大請求占用內(nèi)存。5.2 合并后文件損壞問題現(xiàn)象分片上傳全部成功但合并后的文件無法打開或文件大小不一致?？赡茉蚝喜r未按照chunkIndex排序分片順序錯亂。某個分片上傳失敗但被記錄為成功。分片文件被多個請求同時寫入。解決思路合并時嚴(yán)格按下標(biāo)順序遍歷分片文件。服務(wù)端接收分片時校驗分片大小如果分片大小與預(yù)期不符則不標(biāo)記為成功。分片文件采用uploadId chunkIndex唯一命名防止并發(fā)覆蓋。5.3 斷點續(xù)傳沒生效問題現(xiàn)象頁面刷新或網(wǎng)絡(luò)斷開后重新上傳所有分片又重新傳了一遍?？赡茉蛏蟼髟獢?shù)據(jù)保存在服務(wù)端內(nèi)存中服務(wù)重啟后丟失。前端查詢已上傳分片接口的返回值沒有正確使用。上傳會話過期被清理。解決思路生產(chǎn)環(huán)境將上傳元數(shù)據(jù)存入 Redis并設(shè)置合理的過期時間。前端在上傳前調(diào)用/upload/check用返回的分片集合做跳過。設(shè)置合適的過期時間比如 2 小時保證大文件有足夠時間完成。5.4 多實例部署時狀態(tài)不同步問題現(xiàn)象應(yīng)用部署了多個實例前端上傳分片被負(fù)載均衡分發(fā)到不同實例導(dǎo)致合并時提示分片不完整?？赡茉蛎總€實例都有獨立的本地內(nèi)存和臨時目錄分片文件分散在不同節(jié)點上。上傳元數(shù)據(jù)沒有共享。解決思路使用 Redis 保存上傳元數(shù)據(jù)保證多個實例讀到的狀態(tài)一致。分片臨時文件放到共享存儲NFS、MinIO、OSS。更推薦使用對象存儲的 Multipart Upload 能力服務(wù)端只負(fù)責(zé)生成憑證和編排流程。5.5 MinIO 支持?jǐn)帱c續(xù)傳嗎MinIO 本身就是對象存儲它支持 S3 兼容的 Multipart Upload所以可以實現(xiàn)斷點續(xù)傳。核心流程和手寫方案類似調(diào)用initiateMultipartUpload獲取上傳 ID。分片上傳時調(diào)用uploadPartMinIO 會返回每個分片的 ETag。如果中斷調(diào)用listParts查詢已上傳分片。最后調(diào)用completeMultipartUpload合并分片。但需要注意前端直接對接 MinIO 時不能暴露 AccessKey。更安全的做法是后端生成 STS 臨時憑證或預(yù)簽名 URL前端在憑證有效期內(nèi)上傳。5.6 分片上傳會 OOM 嗎分片上傳本身不會導(dǎo)致 OOM但使用方式不對會。前端如果一次性把文件讀入內(nèi)存再分片會 OOM。后端如果每次把分片讀入byte[]分片大小合理時通常沒問題因為單個分片只有幾 MB。后端如果合并時把所有分片一次性讀入內(nèi)存分片數(shù)量大時也會 OOM。正確做法是分片時用file.slice()讀取服務(wù)端用流式寫入合并時逐片讀取并寫入最終文件不要一次性加載所有分片。6. 最佳實踐與工程建議6.1 分片大小與并發(fā)參數(shù)參數(shù)沒有“銀彈”要根據(jù)場景做實驗。這里給一組常用參考值參數(shù)推薦值說明分片大小5MB ~ 10MB公網(wǎng)推薦 5MB內(nèi)網(wǎng)可適當(dāng)調(diào)大前端并發(fā)數(shù)3 ~ 6并發(fā)太高會增加服務(wù)器壓力Redis 過期時間2 小時根據(jù)文件大小和網(wǎng)絡(luò)速度調(diào)整分片 MD5 校驗建議開啟保證分片內(nèi)容完整防止網(wǎng)絡(luò)傳輸損壞6.2 安全校驗大文件上傳接口往往是攻擊者關(guān)注的目標(biāo)必須做好安全邊界登錄態(tài)校驗接口必須校驗用戶登錄狀態(tài)不能匿名上傳。文件類型校驗通過文件擴展名和 MIME 類型雙重校驗并且不要信任前端傳的唯一標(biāo)識。文件大小限制對分片大小、總分片數(shù)和總文件大小做限制防止惡意上傳超大文件拖垮磁盤。權(quán)限校驗只有有權(quán)限的用戶才能調(diào)用初始化、合并接口。上傳目錄不能放在可執(zhí)行目錄下防止上傳木馬后獲得執(zhí)行權(quán)限。6.3 存儲選型單機和中小項目本地磁盤存儲分片和最終文件代碼簡單部署方便。多實例項目需要共享存儲或 Redis 保存狀態(tài)否則斷點續(xù)傳會失效。云原生項目直接使用對象存儲的 Multipart Upload可靠性和擴展性最好。如果使用 MinIO建議后端封裝統(tǒng)一的文件服務(wù)接口而不是讓業(yè)務(wù)代碼直接操作桶。6.4 日志與監(jiān)控文件上傳是重 IO 操作必須記錄足夠的數(shù)據(jù)用于排查記錄每次上傳的 uploadId、文件名、文件大小、分片數(shù)。記錄每個分片的上傳耗時、重試次數(shù)。記錄合并的起止時間、最終文件路徑。監(jiān)控臨時分片目錄的占用空間定時清理過期分片。6.5 前端體驗優(yōu)化大文件計算 MD5 會阻塞主線程建議使用 Web Worker 在后臺線程計算。上傳進度條要綜合“當(dāng)前已上傳分片”和“總文件大小”來計算而不是簡單按照最后一次請求的進度。失敗時提供手動重試和自動重試按鈕自動重試次數(shù)建議不超過 3 次。頁面刷新后要能恢復(fù)上傳進度這是斷點續(xù)存在用戶層的直觀體現(xiàn)。6.6 面試官更看重什么面試中問到大文件上傳面試官真正想考察的是是否理解分片上傳的核心思路。是否考慮過失敗恢復(fù)也就是斷點續(xù)傳。是否考慮過存儲、內(nèi)存、并發(fā)的邊界情況。是否知道對象存儲的 Multipart Upload 用法。是否能結(jié)合業(yè)務(wù)場景選擇合適的方案?；卮饡r可以先用一句話總結(jié)方案再展開講分片邏輯、斷點續(xù)傳實現(xiàn)、秒傳判斷、合并流程最后補充 OOM、順序錯亂、多實例等問題。這樣能體現(xiàn)出系統(tǒng)思維。7. 總結(jié)與學(xué)習(xí)路線這篇文章圍繞“大文件上傳與斷點續(xù)傳”展開完整介紹了分片上傳、斷點續(xù)傳、秒傳三者的關(guān)系拆解了分片大小、已上傳分片記錄、服務(wù)端合并、并發(fā)控制等核心原理并給出了一個基于 Spring Boot 和原生前端的完整實戰(zhàn)示例。如果你準(zhǔn)備面試建議按以下順序建立知識體系先能用代碼實現(xiàn)一個最簡單的分片上傳。再在此基礎(chǔ)上加入已上傳分片查詢實現(xiàn)斷點續(xù)傳。接著加入 MD5 秒傳判斷。然后嘗試把上傳狀態(tài)從內(nèi)存遷移到 Redis。最后學(xué)習(xí) MinIO 或 OSS 的 Multipart Upload理解生產(chǎn)級方案。學(xué)完這些之后你還可以繼續(xù)探索分片上傳的進度恢復(fù)、后端合并的并行優(yōu)化、對象存儲的預(yù)簽名 URL、前端 Web Worker 計算大文件哈希等進階話題。每一步都有很多細(xì)節(jié)值得深挖但掌握了基礎(chǔ)鏈路之后再看這些高級方案會輕松很多。如果文章對你有幫助建議收藏備用動手敲一遍代碼比只看不練效果好得多。 大文件上傳與斷點續(xù)傳：分片原理與Spring Boot實戰(zhàn)
最近在面試候選人的時候我經(jīng)常問到一個問題“你們項目里實現(xiàn)過大文件上傳嗎斷點續(xù)傳是怎么做的”這個問題看起來基礎(chǔ)但能把大文件上傳從“能用”做到“好用”其實涉及分片、并發(fā)、合并、去重、異?；謴?fù)等一系列細(xì)節(jié)。很多候選人能說出“把文件切成幾塊傳上去再合并”這個思路但一旦追問到分片大小怎么定、斷點續(xù)傳怎么判斷、合并順序怎么保證、秒傳怎么實現(xiàn)就答不上來了。這篇文章就從面試視角出發(fā)把大文件上傳與斷點續(xù)傳的完整知識體系和可落地代碼整理出來。如果你是剛接觸文件上傳的開發(fā)者可以把它當(dāng)成一份系統(tǒng)化的入門教程如果你已經(jīng)做過普通文件上傳但沒深入過大文件場景本文也會幫你彌補方案設(shè)計和異常排查這兩塊短板。1. 背景與核心概念1.1 為什么大文件上傳經(jīng)常出問題普通文件上傳很簡單前端一個input typefile后端用MultipartFile接收幾行代碼就能跑通。但一旦文件體積上升到幾百 MB、甚至幾個 GB問題就會集中出現(xiàn)HTTP 連接超時一次請求傳輸時間過長中間網(wǎng)絡(luò)抖動一下整個文件就要重新傳。內(nèi)存溢出后端通過byte[]一次性讀取整個文件時很容易造成 JVM 堆內(nèi)存溢出OOM。無法續(xù)傳傳輸?shù)?90% 失敗沒有續(xù)傳機制只能從頭再來。帶寬浪費同一個文件在多個用戶之間重復(fù)上傳浪費存儲空間和帶寬。服務(wù)端壓力大大量用戶同時上傳大文件服務(wù)端的線程、內(nèi)存、磁盤 IO 都會被瞬間打滿。大文件上傳的核心思路就是“化整為零再聚零為整”前端把大文件切成多個小分片逐個上傳到服務(wù)端最后服務(wù)端把所有分片按順序合并成完整文件。這個過程中再配合斷點續(xù)傳、秒傳等機制就能解決上面的大部分問題。1.2 分片上傳、斷點續(xù)傳、秒傳的區(qū)別這三個概念經(jīng)常一起出現(xiàn)但含義不同。分片上傳Multipart Upload是基礎(chǔ)手段。前端把文件按照固定大小切開比如每個分片 5MB然后一個個傳上去。它的價值在于單次請求的時間變短了失敗后只需要重傳失敗的分片服務(wù)端也可以并發(fā)處理多個分片。斷點續(xù)傳是建立在分片上傳之上的。它記錄“哪些分片已經(jīng)傳成功”當(dāng)網(wǎng)絡(luò)中斷、頁面刷新、服務(wù)重啟之后已經(jīng)上傳成功的分片不需要重傳只需要從第一個失敗的分片繼續(xù)傳。實現(xiàn)斷點續(xù)傳的關(guān)鍵在于服務(wù)端要能告訴前端“你已經(jīng)有這些分片了跳過它們”。秒傳則是更高一層的優(yōu)化。它本質(zhì)上做了“文件去重”在上傳開始前先計算文件內(nèi)容哈希服務(wù)端發(fā)現(xiàn)這個哈希對應(yīng)的文件已經(jīng)存在就直接返回已有文件地址前端不再真正上傳數(shù)據(jù)。秒傳面對的場景是“同一個文件被多人上傳”而不是“文件真的能秒傳”。用一個表格來總結(jié)概念解決什么問題核心依賴分片上傳大文件傳輸超時、內(nèi)存溢出前端切片、服務(wù)端合并斷點續(xù)傳傳輸失敗后重新上傳已上傳分片記錄秒傳相同文件重復(fù)上傳文件內(nèi)容哈希去重1.3 常見應(yīng)用場景大文件上傳和斷點續(xù)傳在業(yè)務(wù)系統(tǒng)里非常常見視頻類網(wǎng)站的視頻上傳、轉(zhuǎn)碼素材上傳。網(wǎng)盤類的文檔、壓縮包、安裝包上傳。企業(yè)內(nèi)部系統(tǒng)的大數(shù)據(jù)文件導(dǎo)入、日志上傳。在線教育平臺的課件、錄播視頻上傳。對象存儲服務(wù)的前端直傳場景。這些場景往往對成功率、傳輸效率、用戶體驗都有較高要求所以需要一套比普通上傳更完整的方案。2. 整體方案設(shè)計2.1 典型技術(shù)棧與流程一個可落地的大文件上傳方案通常由三部分組成前端負(fù)責(zé)文件分片、并發(fā)控制、進度展示、失敗重試。后端負(fù)責(zé)接收分片、記錄上傳狀態(tài)、合并分片、校驗文件。存儲層保存分片臨時文件、最終文件、上傳元數(shù)據(jù)。本地磁盤、分布式文件系統(tǒng)、對象存儲都可以。整體流程如下前端選擇文件后計算文件 MD5/SHA 值并按照固定大小切成多個分片。前端調(diào)用后端初始化接口攜帶文件名、文件大小、總文件 MD5、總分片數(shù)。后端生成uploadId返回“該文件是否已經(jīng)存在秒傳判斷結(jié)果”以及“已上傳分片編號列表”。如果秒傳命中前端直接結(jié)束。如果秒傳未命中前端遍歷分片跳過已經(jīng)上傳過的分片并發(fā)上傳剩余分片。后端接收每個分片校驗分片編號、分片大小、分片 MD5把分片落盤并記錄“該分片已上傳成功”。所有分片上傳完成后前端調(diào)用合并接口。后端校驗分片是否齊全按分片編號順序合并生成最終文件。后端清理臨時分片和上傳元數(shù)據(jù)返回最終的文件訪問地址。這里的關(guān)鍵設(shè)計是服務(wù)端必須能夠回答“哪些分片已經(jīng)傳過了”這個問題這也是斷點續(xù)傳與普通分片上傳的本質(zhì)區(qū)別。2.2 需要維護哪些元數(shù)據(jù)要讓整個流程可恢復(fù)、可校驗服務(wù)端需要記錄一份上傳會話信息。通常包含以下字段字段含義uploadId上傳會話唯一標(biāo)識fileName原始文件名fileSize文件總大小fileMd5整個文件的 MD5用于秒傳判斷totalChunks總分片數(shù)chunkSize分片大小uploadedChunks已上傳成功分片編號集合status上傳狀態(tài)例如 INIT / UPLOADING / MERGED / FAILEDcreateTime / updateTime創(chuàng)建時間、更新時間在中小項目或單機部署場景下這個信息可以放在內(nèi)存Map里也可以存入數(shù)據(jù)庫。在生產(chǎn)環(huán)境中更推薦存入 Redis因為 Redis 天然支持過期時間可以自動清理長時間未完成的上傳會話而且多實例部署時狀態(tài)是共享的。3. 核心原理拆解3.1 分片大小怎么定分片大小沒有絕對標(biāo)準(zhǔn)需要結(jié)合網(wǎng)絡(luò)環(huán)境、服務(wù)器配置和業(yè)務(wù)類型來選。如果分片太小比如 1MB分片數(shù)量會非常多HTTP 請求數(shù)過多反而增加網(wǎng)絡(luò)開銷和服務(wù)端壓力。如果分片太大比如 100MB等于把大文件上傳問題又繞回來了單次請求時間過長失敗重試代價大。業(yè)界常用的范圍是2MB ~ 20MB。局域網(wǎng)內(nèi)部系統(tǒng)可以用 10MB 或 20MB公網(wǎng)環(huán)境下5MB是比較穩(wěn)妥的選擇。分片數(shù)量可以這樣計算totalChunks Math.ceil(file.size / chunkSize)比如一個 1GB 的文件使用 5MB 分片1024MB / 5MB ≈ 205也就是約 205 個分片這個數(shù)量級對服務(wù)器來說是完全可以接受的。3.2 斷點續(xù)傳的實現(xiàn)方式斷點續(xù)傳有兩種典型的實現(xiàn)思路方案一服務(wù)端記錄已上傳分片編號前端每次開始上傳前先調(diào)用查詢接口服務(wù)端返回已經(jīng)上傳成功的分片編號集合。前端篩選出未上傳的分片只上傳這些分片。這種方案的優(yōu)點是邏輯清晰、實現(xiàn)簡單適合前后端都是自己控制的場景。缺點是需要自己維護分片狀態(tài)。方案二基于對象存儲的 Multipart Upload如果使用 MinIO、阿里云 OSS、AWS S3 這類對象存儲它們本身提供了 Multipart Upload 接口。服務(wù)端先調(diào)用 InitiateMultipartUpload 獲取 uploadId然后逐片調(diào)用 UploadPart 上傳最后調(diào)用 CompleteMultipartUpload 合并。如果中途失敗可以調(diào)用 ListParts 查詢已上傳的分片。這種方案把分片存儲、合并、容災(zāi)都下沉到對象存儲適合云原生場景。但需要理解對象存儲的 API并且上傳憑證、簽名邏輯要處理好。兩種方案并不沖突。實際項目中也經(jīng)?？吹健扒岸朔制? 后端聚合 對象存儲保存最終文件”的混合模式。3.3 秒傳的哈希策略秒傳的核心是內(nèi)容去重最常用的手段是 MD5。但這里有一個坑如果文件非常大對完整文件計算 MD5 會非常耗時前端可能要卡頓幾十秒甚至幾分鐘。所以生產(chǎn)環(huán)境常用折中方案先取文件大小、修改時間做一層快速篩選。再對文件的開頭、中間、結(jié)尾各取一段字節(jié)合并計算 MD5。如果兩個文件這些特征完全一致再決定是否執(zhí)行全量 MD5。這種方案雖然存在理論上的碰撞概率但在絕大多數(shù)業(yè)務(wù)場景下已經(jīng)夠用。如果對準(zhǔn)確性要求極高可以使用 SHA-256或同時結(jié)合文件大小做二次校驗。我這里為了演示方便前端示例中還是使用 SparkMD5 對完整文件計算 MD5。實際項目如果擔(dān)心性能可以參考上面的優(yōu)化思路。3.4 服務(wù)端合并分片合并分片是大文件上傳中最容易出現(xiàn)問題的環(huán)節(jié)核心是保證順序和完整性。合并必須按照chunkIndex升序進行不能依賴文件名排序因為分片文件名可能是隨機生成的。合并過程中要校驗分片數(shù)量是否等于totalChunks每個分片大小是否符合預(yù)期。合并完成后要清理臨時分片文件避免磁盤被占滿。合并時建議使用流式讀寫不要把所有分片一次性讀入內(nèi)存。如果分片數(shù)量很多可以分批合并比如每次合并 100 個分片防止單次 IO 抖動。3.5 并發(fā)控制分片上傳的一大好處是可以并發(fā)上傳多個分片提升傳輸速度。但并發(fā)不能無上限否則服務(wù)端線程、帶寬、磁盤 IO 會被直接打滿。前端并發(fā)建議控制在3 ~ 6個后端在網(wǎng)關(guān)層或服務(wù)層也建議做總并發(fā)限制。分段并發(fā)上傳時需要前端自己實現(xiàn)一個簡單的“任務(wù)隊列”而不是Promise.all一次性把所有分片請求發(fā)出去。4. 實戰(zhàn)Spring Boot 實現(xiàn)大文件分片上傳與斷點續(xù)傳4.1 環(huán)境準(zhǔn)備本文的示例以后端 Spring Boot 前端原生 HTML/JavaScript 為主重點演示完整流程。需要準(zhǔn)備的環(huán)境如下JDK 8 或以上版本。Maven 3.6 或以上版本。Spring Boot 2.x 或 3.x本示例以常見版本為基礎(chǔ)實際請按項目情況調(diào)整。一個前端靜態(tài)目錄Spring Boot 直接放在src/main/resources/static下即可。由于分片上傳的核心邏輯和 Spring Boot 版本關(guān)系不大核心代碼在 2.x 和 3.x 上都可以運行。4.2 項目結(jié)構(gòu)upload-demo ├── pom.xml └── src/main ├── java/com/example/upload │ ├── UploadDemoApplication.java │ ├── controller/UploadController.java │ ├── dto/UploadInitDTO.java │ ├── dto/UploadChunkDTO.java │ ├── dto/UploadMergeDTO.java │ ├── service/UploadService.java │ └── vo/UploadInitVO.java └── resources └── static ├── index.html └── index.js4.3 添加依賴pom.xml只需要 Spring Boot Web 依賴和文件上傳相關(guān)依賴Spring Boot 默認(rèn)已經(jīng)引入了文件上傳能力。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency /dependencies重點說明示例中沒有引入額外工具包合并分片全部使用 JDK 原生 IO 實現(xiàn)依賴少、容易理解。4.4 后端接口設(shè)計后端一共提供 4 個接口接口方法作用/upload/initPOST初始化上傳會話返回 uploadId 和已上傳分片列表/upload/chunkPOST上傳單個分片/upload/check/{uploadId}GET查詢已上傳分片編號/upload/mergePOST合并分片我們先定義 DTO。// 文件路徑src/main/java/com/example/upload/dto/UploadInitDTO.java public class UploadInitDTO { private String fileName; private Long fileSize; private String fileMd5; private Integer totalChunks; private Integer chunkSize; // 省略 getter/setter }// 文件路徑src/main/java/com/example/upload/dto/UploadChunkDTO.java public class UploadChunkDTO { private String uploadId; private Integer chunkIndex; private Integer totalChunks; private String chunkMd5; // 省略 getter/setter }// 文件路徑src/main/java/com/example/upload/dto/UploadMergeDTO.java public class UploadMergeDTO { private String uploadId; // 省略 getter/setter }然后定義上傳會話實體。為了方便演示這里使用ConcurrentHashMap保存上傳元數(shù)據(jù)。生產(chǎn)環(huán)境建議替換為 Redis。// 文件路徑src/main/java/com/example/upload/service/UploadSession.java public class UploadSession { private String uploadId; private String fileName; private Long fileSize; private String fileMd5; private Integer totalChunks; private Integer chunkSize; private SetInteger uploadedChunks ConcurrentHashMap.newKeySet(); private String finalFilePath; }4.5 核心 Service 實現(xiàn)下面逐步實現(xiàn)UploadService。// 文件路徑src/main/java/com/example/upload/service/UploadService.java Service public class UploadService { private static final String UPLOAD_DIR System.getProperty(java.io.tmpdir) /upload-demo/; private static final String MERGE_DIR System.getProperty(java.io.tmpdir) /upload-demo/merge/; private final MapString, UploadSession sessionMap new ConcurrentHashMap(); public UploadSession initUpload(UploadInitDTO dto) { // 先做秒傳判斷如果文件已存在直接返回完整的 session并標(biāo)記為秒傳命中 String existFile findExistByMd5(dto.getFileMd5()); UploadSession session new UploadSession(); session.setUploadId(UUID.randomUUID().toString().replace(-, )); session.setFileName(dto.getFileName()); session.setFileSize(dto.getFileSize()); session.setFileMd5(dto.getFileMd5()); session.setTotalChunks(dto.getTotalChunks()); session.setChunkSize(dto.getChunkSize()); if (existFile ! null) { session.setFinalFilePath(existFile); // 給一個特殊標(biāo)記表示秒傳命中 session.setSkipUpload(true); } sessionMap.put(session.getUploadId(), session); return session; } public void uploadChunk(UploadChunkDTO dto, MultipartFile file) throws IOException { UploadSession session sessionMap.get(dto.getUploadId()); if (session null) { throw new RuntimeException(uploadId 不存在請重新初始化上傳); } // 分片編號不能超出總分片數(shù) if (dto.getChunkIndex() 0 || dto.getChunkIndex() session.getTotalChunks()) { throw new RuntimeException(分片編號不合法); } // 如果該分片已經(jīng)上傳直接返回避免重復(fù)寫盤 if (session.getUploadedChunks().contains(dto.getChunkIndex())) { return; } File chunkDir new File(UPLOAD_DIR dto.getUploadId()); if (!chunkDir.exists()) { chunkDir.mkdirs(); } // 分片文件名使用 uploadId chunkIndex便于合并時按順序讀取 File chunkFile new File(chunkDir, chunk_ dto.getChunkIndex()); try (InputStream in file.getInputStream(); FileOutputStream out new FileOutputStream(chunkFile)) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } } session.getUploadedChunks().add(dto.getChunkIndex()); sessionMap.put(dto.getUploadId(), session); } public SetInteger getUploadedChunks(String uploadId) { UploadSession session sessionMap.get(uploadId); if (session null) { throw new RuntimeException(uploadId 不存在); } return session.getUploadedChunks(); } public String mergeUpload(UploadMergeDTO dto) throws IOException { UploadSession session sessionMap.get(dto.getUploadId()); if (session null) { throw new RuntimeException(uploadId 不存在); } // 檢查分片是否齊全 if (session.getUploadedChunks().size() ! session.getTotalChunks()) { throw new RuntimeException(分片不完整已上傳 session.getUploadedChunks().size() / session.getTotalChunks()); } File mergeDir new File(MERGE_DIR); if (!mergeDir.exists()) { mergeDir.mkdirs(); } String targetFileName session.getFileMd5() _ session.getFileName(); File targetFile new File(mergeDir, targetFileName); // 使用 RandomAccessFile 按順序?qū)懳募?try (RandomAccessFile raf new RandomAccessFile(targetFile, rw)) { for (int i 0; i session.getTotalChunks(); i) { File chunkFile new File(UPLOAD_DIR dto.getUploadId(), chunk_ i); if (!chunkFile.exists()) { throw new RuntimeException(第 i 個分片不存在); } byte[] bytes Files.readAllBytes(chunkFile.toPath()); raf.seek(raf.length()); raf.write(bytes); } } // 合并成功后清理臨時分片 File chunkDir new File(UPLOAD_DIR dto.getUploadId()); if (chunkDir.exists()) { for (File f : chunkDir.listFiles()) { f.delete(); } chunkDir.delete(); } session.setFinalFilePath(targetFile.getAbsolutePath()); sessionMap.put(dto.getUploadId(), session); return targetFile.getAbsolutePath(); } private String findExistByMd5(String fileMd5) { // 簡化邏輯遍歷 sessionMap 中已經(jīng)合并過的文件 // 生產(chǎn)環(huán)境改為查詢數(shù)據(jù)庫或?qū)ο蟠鎯?return null; } }這里需要解釋幾個關(guān)鍵點分片文件名使用的是chunk_0、chunk_1這種命名方式合并時直接按編號遍歷即可不依賴文件修改時間或隨機名。RandomAccessFile寫入時先定位到文件末尾再寫入保證分片按順序追加。合并之后清理臨時目錄避免磁盤空間被不斷占用。findExistByMd5在示例中返回null實際項目中可以查詢數(shù)據(jù)庫中的文件表判斷是否存在同 MD5 的文件。4.6 Controller 實現(xiàn)// 文件路徑src/main/java/com/example/upload/controller/UploadController.java RestController RequestMapping(/upload) public class UploadController { private final UploadService uploadService; public UploadController(UploadService uploadService) { this.uploadService uploadService; } PostMapping(/init) public UploadSession init(RequestBody UploadInitDTO dto) { return uploadService.initUpload(dto); } PostMapping(/chunk) public MapString, Object uploadChunk(UploadChunkDTO dto, RequestParam(file) MultipartFile file) throws IOException { uploadService.uploadChunk(dto, file); MapString, Object result new HashMap(); result.put(uploadId, dto.getUploadId()); result.put(chunkIndex, dto.getChunkIndex()); return result; } GetMapping(/check/{uploadId}) public SetInteger check(PathVariable String uploadId) { return uploadService.getUploadedChunks(uploadId); } PostMapping(/merge) public MapString, String merge(RequestBody UploadMergeDTO dto) throws IOException { String path uploadService.mergeUpload(dto); MapString, String result new HashMap(); result.put(filePath, path); return result; } }注意/upload/chunk接口接收的是MultipartFile所以前端上傳分片時分片文件要放在表單的file字段中其他參數(shù)放在表單字段中。4.7 前端實現(xiàn)前端使用原生 HTML JavaScript Axios 實現(xiàn)。先寫一個簡單的頁面。!-- 文件路徑src/main/resources/static/index.html -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 title大文件分片上傳示例/title /head body input typefile idfileInput / button iduploadBtn開始上傳/button div idprogress等待選擇文件.../div script srchttps://cdn.jsdelivr.net/npm/axios/dist/axios.min.js/script script srchttps://cdn.jsdelivr.net/npm/spark-md53.0.2/spark-md5.min.js/script script srcindex.js/script /body /html然后寫核心的 JavaScript 邏輯。// 文件路徑src/main/resources/static/index.js const CHUNK_SIZE 5 * 1024 * 1024; // 5MB const MAX_CONCURRENT 3; // 同時上傳 3 個分片 document.getElementById(uploadBtn).addEventListener(click, async () { const fileInput document.getElementById(fileInput); const file fileInput.files[0]; if (!file) { alert(請先選擇文件); return; } // 1. 計算文件 MD5用于秒傳判斷 const fileMd5 await calcFileMD5(file); console.log(文件 MD5:, fileMd5); // 2. 計算總分片數(shù) const totalChunks Math.ceil(file.size / CHUNK_SIZE); // 3. 初始化上傳 const initRes await axios.post(/upload/init, { fileName: file.name, fileSize: file.size, fileMd5: fileMd5, totalChunks: totalChunks, chunkSize: CHUNK_SIZE }); const uploadId initRes.data.uploadId; // 如果服務(wù)端判斷命中了秒傳直接結(jié)束 if (initRes.data.skipUpload) { document.getElementById(progress).textContent 秒傳成功文件已存在; return; } // 4. 查詢已上傳的分片編號這里用 set 提升查找效率 const checkRes await axios.get(/upload/check/ uploadId); const uploadedChunks new Set(checkRes.data); // 5. 構(gòu)造待上傳分片隊列 const chunkTasks []; for (let i 0; i totalChunks; i) { if (uploadedChunks.has(i)) { continue; } const start i * CHUNK_SIZE; const end Math.min(start CHUNK_SIZE, file.size); const chunk file.slice(start, end); chunkTasks.push({ index: i, chunk: chunk }); } if (chunkTasks.length 0) { // 所有分片都已上傳過只需要合并 await mergeFile(uploadId); return; } // 6. 并發(fā)控制上傳 await uploadChunksInConcurrency(chunkTasks, uploadId, totalChunks); // 7. 合并分片 await mergeFile(uploadId); }); function uploadChunksInConcurrency(tasks, uploadId, totalChunks) { return new Promise((resolve, reject) { let index 0; let active 0; let completed 0; function next() { if (index tasks.length active 0) { resolve(); return; } while (active MAX_CONCURRENT index tasks.length) { const task tasks[index]; index; active; uploadOneChunk(task, uploadId) .then(() { active--; completed; const percent Math.floor(completed / totalChunks * 100); document.getElementById(progress).textContent 上傳進度 percent %; next(); }) .catch((err) { active--; console.error(上傳失敗, err); reject(err); }); } } next(); }); } function uploadOneChunk(task, uploadId) { const formData new FormData(); formData.append(file, task.chunk); formData.append(uploadId, uploadId); formData.append(chunkIndex, task.index); formData.append(totalChunks, task.totalChunks); return axios.post(/upload/chunk, formData); } function mergeFile(uploadId) { return axios.post(/upload/merge, { uploadId }).then((res) { document.getElementById(progress).textContent 合并完成文件路徑 res.data.filePath; }); } function calcFileMD5(file) { return new Promise((resolve, reject) { const reader new FileReader(); const spark new SparkMD5.ArrayBuffer(); let currentChunk 0; const chunkSize 2 * 1024 * 1024; // 讀取 MD5 時也用分片避免大文件卡死瀏覽器 function readNext() { const start currentChunk * chunkSize; const end Math.min(start chunkSize, file.size); reader.readAsArrayBuffer(file.slice(start, end)); } reader.onload (e) { spark.append(e.target.result); currentChunk; if (currentChunk Math.ceil(file.size / chunkSize)) { readNext(); } else { resolve(spark.end()); } }; reader.onerror (err) { reject(err); }; readNext(); }); }前端代碼中calcFileMD5使用分片讀取的方式計算 MD5而不是一次性readAsArrayBuffer整個文件這樣可以避免大文件導(dǎo)致瀏覽器內(nèi)存暴漲。uploadChunksInConcurrency函數(shù)實現(xiàn)了一個簡單的并發(fā)隊列保證同一時間最多只有 3 個分片在傳輸。這種寫法比Promise.all一次性發(fā)出所有請求更安全。4.8 運行與驗證啟動 Spring Boot 應(yīng)用后瀏覽器訪問http://localhost:8080/index.html選擇一個比較大的文件比如幾百 MB點擊“開始上傳”觀察控制臺輸出。預(yù)期效果前端按 5MB 大小切分文件。后端臨時目錄下出現(xiàn)uploadId/chunk_0、chunk_1等分片文件?？刂婆_顯示上傳進度。所有分片上傳結(jié)束后后端合并文件并清理臨時目錄。如果想驗證斷點續(xù)傳可以在上傳過程中手動關(guān)閉后端服務(wù)然后重新啟動再次選擇同一個文件上傳。前端會通過/upload/check接口拿到已上傳分片跳過它們只補傳失敗的分片。5. 常見問題與排查思路5.1 上傳大文件時 OOM問題現(xiàn)象上傳過程中服務(wù)端拋出OutOfMemoryError: Java heap space。可能原因后端使用byte[]直接接收整個文件文件過大導(dǎo)致堆內(nèi)存溢出。前端使用readAsArrayBuffer讀取整個文件瀏覽器標(biāo)簽頁內(nèi)存飆升。并發(fā)分片太多每個請求都緩存了較大的分片數(shù)據(jù)。解決思路后端接收分片時用MultipartFile.getInputStream()流式讀取不要轉(zhuǎn)成byte[]。前端計算 MD5 時也要分片讀取。控制并發(fā)數(shù)量避免同時多個大請求占用內(nèi)存。5.2 合并后文件損壞問題現(xiàn)象分片上傳全部成功但合并后的文件無法打開或文件大小不一致?？赡茉蚝喜r未按照chunkIndex排序分片順序錯亂。某個分片上傳失敗但被記錄為成功。分片文件被多個請求同時寫入。解決思路合并時嚴(yán)格按下標(biāo)順序遍歷分片文件。服務(wù)端接收分片時校驗分片大小如果分片大小與預(yù)期不符則不標(biāo)記為成功。分片文件采用uploadId chunkIndex唯一命名防止并發(fā)覆蓋。5.3 斷點續(xù)傳沒生效問題現(xiàn)象頁面刷新或網(wǎng)絡(luò)斷開后重新上傳所有分片又重新傳了一遍?？赡茉蛏蟼髟獢?shù)據(jù)保存在服務(wù)端內(nèi)存中服務(wù)重啟后丟失。前端查詢已上傳分片接口的返回值沒有正確使用。上傳會話過期被清理。解決思路生產(chǎn)環(huán)境將上傳元數(shù)據(jù)存入 Redis并設(shè)置合理的過期時間。前端在上傳前調(diào)用/upload/check用返回的分片集合做跳過。設(shè)置合適的過期時間比如 2 小時保證大文件有足夠時間完成。5.4 多實例部署時狀態(tài)不同步問題現(xiàn)象應(yīng)用部署了多個實例前端上傳分片被負(fù)載均衡分發(fā)到不同實例導(dǎo)致合并時提示分片不完整?？赡茉蛎總€實例都有獨立的本地內(nèi)存和臨時目錄分片文件分散在不同節(jié)點上。上傳元數(shù)據(jù)沒有共享。解決思路使用 Redis 保存上傳元數(shù)據(jù)保證多個實例讀到的狀態(tài)一致。分片臨時文件放到共享存儲NFS、MinIO、OSS。更推薦使用對象存儲的 Multipart Upload 能力服務(wù)端只負(fù)責(zé)生成憑證和編排流程。5.5 MinIO 支持?jǐn)帱c續(xù)傳嗎MinIO 本身就是對象存儲它支持 S3 兼容的 Multipart Upload所以可以實現(xiàn)斷點續(xù)傳。核心流程和手寫方案類似調(diào)用initiateMultipartUpload獲取上傳 ID。分片上傳時調(diào)用uploadPartMinIO 會返回每個分片的 ETag。如果中斷調(diào)用listParts查詢已上傳分片。最后調(diào)用completeMultipartUpload合并分片。但需要注意前端直接對接 MinIO 時不能暴露 AccessKey。更安全的做法是后端生成 STS 臨時憑證或預(yù)簽名 URL前端在憑證有效期內(nèi)上傳。5.6 分片上傳會 OOM 嗎分片上傳本身不會導(dǎo)致 OOM但使用方式不對會。前端如果一次性把文件讀入內(nèi)存再分片會 OOM。后端如果每次把分片讀入byte[]分片大小合理時通常沒問題因為單個分片只有幾 MB。后端如果合并時把所有分片一次性讀入內(nèi)存分片數(shù)量大時也會 OOM。正確做法是分片時用file.slice()讀取服務(wù)端用流式寫入合并時逐片讀取并寫入最終文件不要一次性加載所有分片。6. 最佳實踐與工程建議6.1 分片大小與并發(fā)參數(shù)參數(shù)沒有“銀彈”要根據(jù)場景做實驗。這里給一組常用參考值參數(shù)推薦值說明分片大小5MB ~ 10MB公網(wǎng)推薦 5MB內(nèi)網(wǎng)可適當(dāng)調(diào)大前端并發(fā)數(shù)3 ~ 6并發(fā)太高會增加服務(wù)器壓力Redis 過期時間2 小時根據(jù)文件大小和網(wǎng)絡(luò)速度調(diào)整分片 MD5 校驗建議開啟保證分片內(nèi)容完整防止網(wǎng)絡(luò)傳輸損壞6.2 安全校驗大文件上傳接口往往是攻擊者關(guān)注的目標(biāo)必須做好安全邊界登錄態(tài)校驗接口必須校驗用戶登錄狀態(tài)不能匿名上傳。文件類型校驗通過文件擴展名和 MIME 類型雙重校驗并且不要信任前端傳的唯一標(biāo)識。文件大小限制對分片大小、總分片數(shù)和總文件大小做限制防止惡意上傳超大文件拖垮磁盤。權(quán)限校驗只有有權(quán)限的用戶才能調(diào)用初始化、合并接口。上傳目錄不能放在可執(zhí)行目錄下防止上傳木馬后獲得執(zhí)行權(quán)限。6.3 存儲選型單機和中小項目本地磁盤存儲分片和最終文件代碼簡單部署方便。多實例項目需要共享存儲或 Redis 保存狀態(tài)否則斷點續(xù)傳會失效。云原生項目直接使用對象存儲的 Multipart Upload可靠性和擴展性最好。如果使用 MinIO建議后端封裝統(tǒng)一的文件服務(wù)接口而不是讓業(yè)務(wù)代碼直接操作桶。6.4 日志與監(jiān)控文件上傳是重 IO 操作必須記錄足夠的數(shù)據(jù)用于排查記錄每次上傳的 uploadId、文件名、文件大小、分片數(shù)。記錄每個分片的上傳耗時、重試次數(shù)。記錄合并的起止時間、最終文件路徑。監(jiān)控臨時分片目錄的占用空間定時清理過期分片。6.5 前端體驗優(yōu)化大文件計算 MD5 會阻塞主線程建議使用 Web Worker 在后臺線程計算。上傳進度條要綜合“當(dāng)前已上傳分片”和“總文件大小”來計算而不是簡單按照最后一次請求的進度。失敗時提供手動重試和自動重試按鈕自動重試次數(shù)建議不超過 3 次。頁面刷新后要能恢復(fù)上傳進度這是斷點續(xù)存在用戶層的直觀體現(xiàn)。6.6 面試官更看重什么面試中問到大文件上傳面試官真正想考察的是是否理解分片上傳的核心思路。是否考慮過失敗恢復(fù)也就是斷點續(xù)傳。是否考慮過存儲、內(nèi)存、并發(fā)的邊界情況。是否知道對象存儲的 Multipart Upload 用法。是否能結(jié)合業(yè)務(wù)場景選擇合適的方案?；卮饡r可以先用一句話總結(jié)方案再展開講分片邏輯、斷點續(xù)傳實現(xiàn)、秒傳判斷、合并流程最后補充 OOM、順序錯亂、多實例等問題。這樣能體現(xiàn)出系統(tǒng)思維。7. 總結(jié)與學(xué)習(xí)路線這篇文章圍繞“大文件上傳與斷點續(xù)傳”展開完整介紹了分片上傳、斷點續(xù)傳、秒傳三者的關(guān)系拆解了分片大小、已上傳分片記錄、服務(wù)端合并、并發(fā)控制等核心原理并給出了一個基于 Spring Boot 和原生前端的完整實戰(zhàn)示例。如果你準(zhǔn)備面試建議按以下順序建立知識體系先能用代碼實現(xiàn)一個最簡單的分片上傳。再在此基礎(chǔ)上加入已上傳分片查詢實現(xiàn)斷點續(xù)傳。接著加入 MD5 秒傳判斷。然后嘗試把上傳狀態(tài)從內(nèi)存遷移到 Redis。最后學(xué)習(xí) MinIO 或 OSS 的 Multipart Upload理解生產(chǎn)級方案。學(xué)完這些之后你還可以繼續(xù)探索分片上傳的進度恢復(fù)、后端合并的并行優(yōu)化、對象存儲的預(yù)簽名 URL、前端 Web Worker 計算大文件哈希等進階話題。每一步都有很多細(xì)節(jié)值得深挖但掌握了基礎(chǔ)鏈路之后再看這些高級方案會輕松很多。如果文章對你有幫助建議收藏備用動手敲一遍代碼比只看不練效果好得多。