最近在面試候選人的時候我經常問到一個問題“你們項目里實現過大文件上傳嗎斷點續傳是怎么做的”這個問題看起來基礎但能把大文件上傳從“能用”做到“好用”其實涉及分片、并發、合并、去重、異常恢復等一系列細節。很多候選人能說出“把文件切成幾塊傳上去再合并”這個思路但一旦追問到分片大小怎么定、斷點續傳怎么判斷、合并順序怎么保證、秒傳怎么實現就答不上來了。這篇文章就從面試視角出發把大文件上傳與斷點續傳的完整知識體系和可落地代碼整理出來。如果你是剛接觸文件上傳的開發者可以把它當成一份系統化的入門教程如果你已經做過普通文件上傳但沒深入過大文件場景本文也會幫你彌補方案設計和異常排查這兩塊短板。1. 背景與核心概念1.1 為什么大文件上傳經常出問題普通文件上傳很簡單前端一個input typefile后端用MultipartFile接收幾行代碼就能跑通。但一旦文件體積上升到幾百 MB、甚至幾個 GB問題就會集中出現HTTP 連接超時一次請求傳輸時間過長中間網絡抖動一下整個文件就要重新傳。內存溢出后端通過byte[]一次性讀取整個文件時很容易造成 JVM 堆內存溢出OOM。無法續傳傳輸到 90% 失敗沒有續傳機制只能從頭再來。帶寬浪費同一個文件在多個用戶之間重復上傳浪費存儲空間和帶寬。服務端壓力大大量用戶同時上傳大文件服務端的線程、內存、磁盤 IO 都會被瞬間打滿。大文件上傳的核心思路就是“化整為零再聚零為整”前端把大文件切成多個小分片逐個上傳到服務端最后服務端把所有分片按順序合并成完整文件。這個過程中再配合斷點續傳、秒傳等機制就能解決上面的大部分問題。1.2 分片上傳、斷點續傳、秒傳的區別這三個概念經常一起出現但含義不同。分片上傳Multipart Upload是基礎手段。前端把文件按照固定大小切開比如每個分片 5MB然后一個個傳上去。它的價值在于單次請求的時間變短了失敗后只需要重傳失敗的分片服務端也可以并發處理多個分片。斷點續傳是建立在分片上傳之上的。它記錄“哪些分片已經傳成功”當網絡中斷、頁面刷新、服務重啟之后已經上傳成功的分片不需要重傳只需要從第一個失敗的分片繼續傳。實現斷點續傳的關鍵在于服務端要能告訴前端“你已經有這些分片了跳過它們”。秒傳則是更高一層的優化。它本質上做了“文件去重”在上傳開始前先計算文件內容哈希服務端發現這個哈希對應的文件已經存在就直接返回已有文件地址前端不再真正上傳數據。秒傳面對的場景是“同一個文件被多人上傳”而不是“文件真的能秒傳”。用一個表格來總結概念解決什么問題核心依賴分片上傳大文件傳輸超時、內存溢出前端切片、服務端合并斷點續傳傳輸失敗后重新上傳已上傳分片記錄秒傳相同文件重復上傳文件內容哈希去重1.3 常見應用場景大文件上傳和斷點續傳在業務系統里非常常見視頻類網站的視頻上傳、轉碼素材上傳。網盤類的文檔、壓縮包、安裝包上傳。企業內部系統的大數據文件導入、日志上傳。在線教育平臺的課件、錄播視頻上傳。對象存儲服務的前端直傳場景。這些場景往往對成功率、傳輸效率、用戶體驗都有較高要求所以需要一套比普通上傳更完整的方案。2. 整體方案設計2.1 典型技術棧與流程一個可落地的大文件上傳方案通常由三部分組成前端負責文件分片、并發控制、進度展示、失敗重試。后端負責接收分片、記錄上傳狀態、合并分片、校驗文件。存儲層保存分片臨時文件、最終文件、上傳元數據。本地磁盤、分布式文件系統、對象存儲都可以。整體流程如下前端選擇文件后計算文件 MD5/SHA 值并按照固定大小切成多個分片。前端調用后端初始化接口攜帶文件名、文件大小、總文件 MD5、總分片數。后端生成uploadId返回“該文件是否已經存在秒傳判斷結果”以及“已上傳分片編號列表”。如果秒傳命中前端直接結束。如果秒傳未命中前端遍歷分片跳過已經上傳過的分片并發上傳剩余分片。后端接收每個分片校驗分片編號、分片大小、分片 MD5把分片落盤并記錄“該分片已上傳成功”。所有分片上傳完成后前端調用合并接口。后端校驗分片是否齊全按分片編號順序合并生成最終文件。后端清理臨時分片和上傳元數據返回最終的文件訪問地址。這里的關鍵設計是服務端必須能夠回答“哪些分片已經傳過了”這個問題這也是斷點續傳與普通分片上傳的本質區別。2.2 需要維護哪些元數據要讓整個流程可恢復、可校驗服務端需要記錄一份上傳會話信息。通常包含以下字段字段含義uploadId上傳會話唯一標識fileName原始文件名fileSize文件總大小fileMd5整個文件的 MD5用于秒傳判斷totalChunks總分片數chunkSize分片大小uploadedChunks已上傳成功分片編號集合status上傳狀態例如 INIT / UPLOADING / MERGED / FAILEDcreateTime / updateTime創建時間、更新時間在中小項目或單機部署場景下這個信息可以放在內存Map里也可以存入數據庫。在生產環境中更推薦存入 Redis因為 Redis 天然支持過期時間可以自動清理長時間未完成的上傳會話而且多實例部署時狀態是共享的。3. 核心原理拆解3.1 分片大小怎么定分片大小沒有絕對標準需要結合網絡環境、服務器配置和業務類型來選。如果分片太小比如 1MB分片數量會非常多HTTP 請求數過多反而增加網絡開銷和服務端壓力。如果分片太大比如 100MB等于把大文件上傳問題又繞回來了單次請求時間過長失敗重試代價大。業界常用的范圍是2MB ~ 20MB。局域網內部系統可以用 10MB 或 20MB公網環境下5MB是比較穩妥的選擇。分片數量可以這樣計算totalChunks Math.ceil(file.size / chunkSize)比如一個 1GB 的文件使用 5MB 分片1024MB / 5MB ≈ 205也就是約 205 個分片這個數量級對服務器來說是完全可以接受的。3.2 斷點續傳的實現方式斷點續傳有兩種典型的實現思路方案一服務端記錄已上傳分片編號前端每次開始上傳前先調用查詢接口服務端返回已經上傳成功的分片編號集合。前端篩選出未上傳的分片只上傳這些分片。這種方案的優點是邏輯清晰、實現簡單適合前后端都是自己控制的場景。缺點是需要自己維護分片狀態。方案二基于對象存儲的 Multipart Upload如果使用 MinIO、阿里云 OSS、AWS S3 這類對象存儲它們本身提供了 Multipart Upload 接口。服務端先調用 InitiateMultipartUpload 獲取 uploadId然后逐片調用 UploadPart 上傳最后調用 CompleteMultipartUpload 合并。如果中途失敗可以調用 ListParts 查詢已上傳的分片。這種方案把分片存儲、合并、容災都下沉到對象存儲適合云原生場景。但需要理解對象存儲的 API并且上傳憑證、簽名邏輯要處理好。兩種方案并不沖突。實際項目中也經常看到“前端分片 后端聚合 對象存儲保存最終文件”的混合模式。3.3 秒傳的哈希策略秒傳的核心是內容去重最常用的手段是 MD5。但這里有一個坑如果文件非常大對完整文件計算 MD5 會非常耗時前端可能要卡頓幾十秒甚至幾分鐘。所以生產環境常用折中方案先取文件大小、修改時間做一層快速篩選。再對文件的開頭、中間、結尾各取一段字節合并計算 MD5。如果兩個文件這些特征完全一致再決定是否執行全量 MD5。這種方案雖然存在理論上的碰撞概率但在絕大多數業務場景下已經夠用。如果對準確性要求極高可以使用 SHA-256或同時結合文件大小做二次校驗。我這里為了演示方便前端示例中還是使用 SparkMD5 對完整文件計算 MD5。實際項目如果擔心性能可以參考上面的優化思路。3.4 服務端合并分片合并分片是大文件上傳中最容易出現問題的環節核心是保證順序和完整性。合并必須按照chunkIndex升序進行不能依賴文件名排序因為分片文件名可能是隨機生成的。合并過程中要校驗分片數量是否等于totalChunks每個分片大小是否符合預期。合并完成后要清理臨時分片文件避免磁盤被占滿。合并時建議使用流式讀寫不要把所有分片一次性讀入內存。如果分片數量很多可以分批合并比如每次合并 100 個分片防止單次 IO 抖動。3.5 并發控制分片上傳的一大好處是可以并發上傳多個分片提升傳輸速度。但并發不能無上限否則服務端線程、帶寬、磁盤 IO 會被直接打滿。前端并發建議控制在3 ~ 6個后端在網關層或服務層也建議做總并發限制。分段并發上傳時需要前端自己實現一個簡單的“任務隊列”而不是Promise.all一次性把所有分片請求發出去。4. 實戰Spring Boot 實現大文件分片上傳與斷點續傳4.1 環境準備本文的示例以后端 Spring Boot 前端原生 HTML/JavaScript 為主重點演示完整流程。需要準備的環境如下JDK 8 或以上版本。Maven 3.6 或以上版本。Spring Boot 2.x 或 3.x本示例以常見版本為基礎實際請按項目情況調整。一個前端靜態目錄Spring Boot 直接放在src/main/resources/static下即可。由于分片上傳的核心邏輯和 Spring Boot 版本關系不大核心代碼在 2.x 和 3.x 上都可以運行。4.2 項目結構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 依賴和文件上傳相關依賴Spring Boot 默認已經引入了文件上傳能力。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 實現依賴少、容易理解。4.4 后端接口設計后端一共提供 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保存上傳元數據。生產環境建議替換為 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 實現下面逐步實現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并標記為秒傳命中 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); // 給一個特殊標記表示秒傳命中 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 不存在請重新初始化上傳); } // 分片編號不能超出總分片數 if (dto.getChunkIndex() 0 || dto.getChunkIndex() session.getTotalChunks()) { throw new RuntimeException(分片編號不合法); } // 如果該分片已經上傳直接返回避免重復寫盤 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 按順序寫文件 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 中已經合并過的文件 // 生產環境改為查詢數據庫或對象存儲 return null; } }這里需要解釋幾個關鍵點分片文件名使用的是chunk_0、chunk_1這種命名方式合并時直接按編號遍歷即可不依賴文件修改時間或隨機名。RandomAccessFile寫入時先定位到文件末尾再寫入保證分片按順序追加。合并之后清理臨時目錄避免磁盤空間被不斷占用。findExistByMd5在示例中返回null實際項目中可以查詢數據庫中的文件表判斷是否存在同 MD5 的文件。4.6 Controller 實現// 文件路徑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字段中其他參數放在表單字段中。4.7 前端實現前端使用原生 HTML JavaScript Axios 實現。先寫一個簡單的頁面。!-- 文件路徑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. 計算總分片數 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; // 如果服務端判斷命中了秒傳直接結束 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. 構造待上傳分片隊列 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. 并發控制上傳 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整個文件這樣可以避免大文件導致瀏覽器內存暴漲。uploadChunksInConcurrency函數實現了一個簡單的并發隊列保證同一時間最多只有 3 個分片在傳輸。這種寫法比Promise.all一次性發出所有請求更安全。4.8 運行與驗證啟動 Spring Boot 應用后瀏覽器訪問http://localhost:8080/index.html選擇一個比較大的文件比如幾百 MB點擊“開始上傳”觀察控制臺輸出。預期效果前端按 5MB 大小切分文件。后端臨時目錄下出現uploadId/chunk_0、chunk_1等分片文件。控制臺顯示上傳進度。所有分片上傳結束后后端合并文件并清理臨時目錄。如果想驗證斷點續傳可以在上傳過程中手動關閉后端服務然后重新啟動再次選擇同一個文件上傳。前端會通過/upload/check接口拿到已上傳分片跳過它們只補傳失敗的分片。5. 常見問題與排查思路5.1 上傳大文件時 OOM問題現象上傳過程中服務端拋出OutOfMemoryError: Java heap space。可能原因后端使用byte[]直接接收整個文件文件過大導致堆內存溢出。前端使用readAsArrayBuffer讀取整個文件瀏覽器標簽頁內存飆升。并發分片太多每個請求都緩存了較大的分片數據。解決思路后端接收分片時用MultipartFile.getInputStream()流式讀取不要轉成byte[]。前端計算 MD5 時也要分片讀取。控制并發數量避免同時多個大請求占用內存。5.2 合并后文件損壞問題現象分片上傳全部成功但合并后的文件無法打開或文件大小不一致。可能原因合并時未按照chunkIndex排序分片順序錯亂。某個分片上傳失敗但被記錄為成功。分片文件被多個請求同時寫入。解決思路合并時嚴格按下標順序遍歷分片文件。服務端接收分片時校驗分片大小如果分片大小與預期不符則不標記為成功。分片文件采用uploadId chunkIndex唯一命名防止并發覆蓋。5.3 斷點續傳沒生效問題現象頁面刷新或網絡斷開后重新上傳所有分片又重新傳了一遍。可能原因上傳元數據保存在服務端內存中服務重啟后丟失。前端查詢已上傳分片接口的返回值沒有正確使用。上傳會話過期被清理。解決思路生產環境將上傳元數據存入 Redis并設置合理的過期時間。前端在上傳前調用/upload/check用返回的分片集合做跳過。設置合適的過期時間比如 2 小時保證大文件有足夠時間完成。5.4 多實例部署時狀態不同步問題現象應用部署了多個實例前端上傳分片被負載均衡分發到不同實例導致合并時提示分片不完整。可能原因每個實例都有獨立的本地內存和臨時目錄分片文件分散在不同節點上。上傳元數據沒有共享。解決思路使用 Redis 保存上傳元數據保證多個實例讀到的狀態一致。分片臨時文件放到共享存儲NFS、MinIO、OSS。更推薦使用對象存儲的 Multipart Upload 能力服務端只負責生成憑證和編排流程。5.5 MinIO 支持斷點續傳嗎MinIO 本身就是對象存儲它支持 S3 兼容的 Multipart Upload所以可以實現斷點續傳。核心流程和手寫方案類似調用initiateMultipartUpload獲取上傳 ID。分片上傳時調用uploadPartMinIO 會返回每個分片的 ETag。如果中斷調用listParts查詢已上傳分片。最后調用completeMultipartUpload合并分片。但需要注意前端直接對接 MinIO 時不能暴露 AccessKey。更安全的做法是后端生成 STS 臨時憑證或預簽名 URL前端在憑證有效期內上傳。5.6 分片上傳會 OOM 嗎分片上傳本身不會導致 OOM但使用方式不對會。前端如果一次性把文件讀入內存再分片會 OOM。后端如果每次把分片讀入byte[]分片大小合理時通常沒問題因為單個分片只有幾 MB。后端如果合并時把所有分片一次性讀入內存分片數量大時也會 OOM。正確做法是分片時用file.slice()讀取服務端用流式寫入合并時逐片讀取并寫入最終文件不要一次性加載所有分片。6. 最佳實踐與工程建議6.1 分片大小與并發參數參數沒有“銀彈”要根據場景做實驗。這里給一組常用參考值參數推薦值說明分片大小5MB ~ 10MB公網推薦 5MB內網可適當調大前端并發數3 ~ 6并發太高會增加服務器壓力Redis 過期時間2 小時根據文件大小和網絡速度調整分片 MD5 校驗建議開啟保證分片內容完整防止網絡傳輸損壞6.2 安全校驗大文件上傳接口往往是攻擊者關注的目標必須做好安全邊界登錄態校驗接口必須校驗用戶登錄狀態不能匿名上傳。文件類型校驗通過文件擴展名和 MIME 類型雙重校驗并且不要信任前端傳的唯一標識。文件大小限制對分片大小、總分片數和總文件大小做限制防止惡意上傳超大文件拖垮磁盤。權限校驗只有有權限的用戶才能調用初始化、合并接口。上傳目錄不能放在可執行目錄下防止上傳木馬后獲得執行權限。6.3 存儲選型單機和中小項目本地磁盤存儲分片和最終文件代碼簡單部署方便。多實例項目需要共享存儲或 Redis 保存狀態否則斷點續傳會失效。云原生項目直接使用對象存儲的 Multipart Upload可靠性和擴展性最好。如果使用 MinIO建議后端封裝統一的文件服務接口而不是讓業務代碼直接操作桶。6.4 日志與監控文件上傳是重 IO 操作必須記錄足夠的數據用于排查記錄每次上傳的 uploadId、文件名、文件大小、分片數。記錄每個分片的上傳耗時、重試次數。記錄合并的起止時間、最終文件路徑。監控臨時分片目錄的占用空間定時清理過期分片。6.5 前端體驗優化大文件計算 MD5 會阻塞主線程建議使用 Web Worker 在后臺線程計算。上傳進度條要綜合“當前已上傳分片”和“總文件大小”來計算而不是簡單按照最后一次請求的進度。失敗時提供手動重試和自動重試按鈕自動重試次數建議不超過 3 次。頁面刷新后要能恢復上傳進度這是斷點續存在用戶層的直觀體現。6.6 面試官更看重什么面試中問到大文件上傳面試官真正想考察的是是否理解分片上傳的核心思路。是否考慮過失敗恢復也就是斷點續傳。是否考慮過存儲、內存、并發的邊界情況。是否知道對象存儲的 Multipart Upload 用法。是否能結合業務場景選擇合適的方案。回答時可以先用一句話總結方案再展開講分片邏輯、斷點續傳實現、秒傳判斷、合并流程最后補充 OOM、順序錯亂、多實例等問題。這樣能體現出系統思維。7. 總結與學習路線這篇文章圍繞“大文件上傳與斷點續傳”展開完整介紹了分片上傳、斷點續傳、秒傳三者的關系拆解了分片大小、已上傳分片記錄、服務端合并、并發控制等核心原理并給出了一個基于 Spring Boot 和原生前端的完整實戰示例。如果你準備面試建議按以下順序建立知識體系先能用代碼實現一個最簡單的分片上傳。再在此基礎上加入已上傳分片查詢實現斷點續傳。接著加入 MD5 秒傳判斷。然后嘗試把上傳狀態從內存遷移到 Redis。最后學習 MinIO 或 OSS 的 Multipart Upload理解生產級方案。學完這些之后你還可以繼續探索分片上傳的進度恢復、后端合并的并行優化、對象存儲的預簽名 URL、前端 Web Worker 計算大文件哈希等進階話題。每一步都有很多細節值得深挖但掌握了基礎鏈路之后再看這些高級方案會輕松很多。如果文章對你有幫助建議收藏備用動手敲一遍代碼比只看不練效果好得多。 大文件上傳與斷點續傳：分片原理與Spring Boot實戰
最近在面試候選人的時候我經常問到一個問題“你們項目里實現過大文件上傳嗎斷點續傳是怎么做的”這個問題看起來基礎但能把大文件上傳從“能用”做到“好用”其實涉及分片、并發、合并、去重、異常恢復等一系列細節。很多候選人能說出“把文件切成幾塊傳上去再合并”這個思路但一旦追問到分片大小怎么定、斷點續傳怎么判斷、合并順序怎么保證、秒傳怎么實現就答不上來了。這篇文章就從面試視角出發把大文件上傳與斷點續傳的完整知識體系和可落地代碼整理出來。如果你是剛接觸文件上傳的開發者可以把它當成一份系統化的入門教程如果你已經做過普通文件上傳但沒深入過大文件場景本文也會幫你彌補方案設計和異常排查這兩塊短板。1. 背景與核心概念1.1 為什么大文件上傳經常出問題普通文件上傳很簡單前端一個input typefile后端用MultipartFile接收幾行代碼就能跑通。但一旦文件體積上升到幾百 MB、甚至幾個 GB問題就會集中出現HTTP 連接超時一次請求傳輸時間過長中間網絡抖動一下整個文件就要重新傳。內存溢出后端通過byte[]一次性讀取整個文件時很容易造成 JVM 堆內存溢出OOM。無法續傳傳輸到 90% 失敗沒有續傳機制只能從頭再來。帶寬浪費同一個文件在多個用戶之間重復上傳浪費存儲空間和帶寬。服務端壓力大大量用戶同時上傳大文件服務端的線程、內存、磁盤 IO 都會被瞬間打滿。大文件上傳的核心思路就是“化整為零再聚零為整”前端把大文件切成多個小分片逐個上傳到服務端最后服務端把所有分片按順序合并成完整文件。這個過程中再配合斷點續傳、秒傳等機制就能解決上面的大部分問題。1.2 分片上傳、斷點續傳、秒傳的區別這三個概念經常一起出現但含義不同。分片上傳Multipart Upload是基礎手段。前端把文件按照固定大小切開比如每個分片 5MB然后一個個傳上去。它的價值在于單次請求的時間變短了失敗后只需要重傳失敗的分片服務端也可以并發處理多個分片。斷點續傳是建立在分片上傳之上的。它記錄“哪些分片已經傳成功”當網絡中斷、頁面刷新、服務重啟之后已經上傳成功的分片不需要重傳只需要從第一個失敗的分片繼續傳。實現斷點續傳的關鍵在于服務端要能告訴前端“你已經有這些分片了跳過它們”。秒傳則是更高一層的優化。它本質上做了“文件去重”在上傳開始前先計算文件內容哈希服務端發現這個哈希對應的文件已經存在就直接返回已有文件地址前端不再真正上傳數據。秒傳面對的場景是“同一個文件被多人上傳”而不是“文件真的能秒傳”。用一個表格來總結概念解決什么問題核心依賴分片上傳大文件傳輸超時、內存溢出前端切片、服務端合并斷點續傳傳輸失敗后重新上傳已上傳分片記錄秒傳相同文件重復上傳文件內容哈希去重1.3 常見應用場景大文件上傳和斷點續傳在業務系統里非常常見視頻類網站的視頻上傳、轉碼素材上傳。網盤類的文檔、壓縮包、安裝包上傳。企業內部系統的大數據文件導入、日志上傳。在線教育平臺的課件、錄播視頻上傳。對象存儲服務的前端直傳場景。這些場景往往對成功率、傳輸效率、用戶體驗都有較高要求所以需要一套比普通上傳更完整的方案。2. 整體方案設計2.1 典型技術棧與流程一個可落地的大文件上傳方案通常由三部分組成前端負責文件分片、并發控制、進度展示、失敗重試。后端負責接收分片、記錄上傳狀態、合并分片、校驗文件。存儲層保存分片臨時文件、最終文件、上傳元數據。本地磁盤、分布式文件系統、對象存儲都可以。整體流程如下前端選擇文件后計算文件 MD5/SHA 值并按照固定大小切成多個分片。前端調用后端初始化接口攜帶文件名、文件大小、總文件 MD5、總分片數。后端生成uploadId返回“該文件是否已經存在秒傳判斷結果”以及“已上傳分片編號列表”。如果秒傳命中前端直接結束。如果秒傳未命中前端遍歷分片跳過已經上傳過的分片并發上傳剩余分片。后端接收每個分片校驗分片編號、分片大小、分片 MD5把分片落盤并記錄“該分片已上傳成功”。所有分片上傳完成后前端調用合并接口。后端校驗分片是否齊全按分片編號順序合并生成最終文件。后端清理臨時分片和上傳元數據返回最終的文件訪問地址。這里的關鍵設計是服務端必須能夠回答“哪些分片已經傳過了”這個問題這也是斷點續傳與普通分片上傳的本質區別。2.2 需要維護哪些元數據要讓整個流程可恢復、可校驗服務端需要記錄一份上傳會話信息。通常包含以下字段字段含義uploadId上傳會話唯一標識fileName原始文件名fileSize文件總大小fileMd5整個文件的 MD5用于秒傳判斷totalChunks總分片數chunkSize分片大小uploadedChunks已上傳成功分片編號集合status上傳狀態例如 INIT / UPLOADING / MERGED / FAILEDcreateTime / updateTime創建時間、更新時間在中小項目或單機部署場景下這個信息可以放在內存Map里也可以存入數據庫。在生產環境中更推薦存入 Redis因為 Redis 天然支持過期時間可以自動清理長時間未完成的上傳會話而且多實例部署時狀態是共享的。3. 核心原理拆解3.1 分片大小怎么定分片大小沒有絕對標準需要結合網絡環境、服務器配置和業務類型來選。如果分片太小比如 1MB分片數量會非常多HTTP 請求數過多反而增加網絡開銷和服務端壓力。如果分片太大比如 100MB等于把大文件上傳問題又繞回來了單次請求時間過長失敗重試代價大。業界常用的范圍是2MB ~ 20MB。局域網內部系統可以用 10MB 或 20MB公網環境下5MB是比較穩妥的選擇。分片數量可以這樣計算totalChunks Math.ceil(file.size / chunkSize)比如一個 1GB 的文件使用 5MB 分片1024MB / 5MB ≈ 205也就是約 205 個分片這個數量級對服務器來說是完全可以接受的。3.2 斷點續傳的實現方式斷點續傳有兩種典型的實現思路方案一服務端記錄已上傳分片編號前端每次開始上傳前先調用查詢接口服務端返回已經上傳成功的分片編號集合。前端篩選出未上傳的分片只上傳這些分片。這種方案的優點是邏輯清晰、實現簡單適合前后端都是自己控制的場景。缺點是需要自己維護分片狀態。方案二基于對象存儲的 Multipart Upload如果使用 MinIO、阿里云 OSS、AWS S3 這類對象存儲它們本身提供了 Multipart Upload 接口。服務端先調用 InitiateMultipartUpload 獲取 uploadId然后逐片調用 UploadPart 上傳最后調用 CompleteMultipartUpload 合并。如果中途失敗可以調用 ListParts 查詢已上傳的分片。這種方案把分片存儲、合并、容災都下沉到對象存儲適合云原生場景。但需要理解對象存儲的 API并且上傳憑證、簽名邏輯要處理好。兩種方案并不沖突。實際項目中也經常看到“前端分片 后端聚合 對象存儲保存最終文件”的混合模式。3.3 秒傳的哈希策略秒傳的核心是內容去重最常用的手段是 MD5。但這里有一個坑如果文件非常大對完整文件計算 MD5 會非常耗時前端可能要卡頓幾十秒甚至幾分鐘。所以生產環境常用折中方案先取文件大小、修改時間做一層快速篩選。再對文件的開頭、中間、結尾各取一段字節合并計算 MD5。如果兩個文件這些特征完全一致再決定是否執行全量 MD5。這種方案雖然存在理論上的碰撞概率但在絕大多數業務場景下已經夠用。如果對準確性要求極高可以使用 SHA-256或同時結合文件大小做二次校驗。我這里為了演示方便前端示例中還是使用 SparkMD5 對完整文件計算 MD5。實際項目如果擔心性能可以參考上面的優化思路。3.4 服務端合并分片合并分片是大文件上傳中最容易出現問題的環節核心是保證順序和完整性。合并必須按照chunkIndex升序進行不能依賴文件名排序因為分片文件名可能是隨機生成的。合并過程中要校驗分片數量是否等于totalChunks每個分片大小是否符合預期。合并完成后要清理臨時分片文件避免磁盤被占滿。合并時建議使用流式讀寫不要把所有分片一次性讀入內存。如果分片數量很多可以分批合并比如每次合并 100 個分片防止單次 IO 抖動。3.5 并發控制分片上傳的一大好處是可以并發上傳多個分片提升傳輸速度。但并發不能無上限否則服務端線程、帶寬、磁盤 IO 會被直接打滿。前端并發建議控制在3 ~ 6個后端在網關層或服務層也建議做總并發限制。分段并發上傳時需要前端自己實現一個簡單的“任務隊列”而不是Promise.all一次性把所有分片請求發出去。4. 實戰Spring Boot 實現大文件分片上傳與斷點續傳4.1 環境準備本文的示例以后端 Spring Boot 前端原生 HTML/JavaScript 為主重點演示完整流程。需要準備的環境如下JDK 8 或以上版本。Maven 3.6 或以上版本。Spring Boot 2.x 或 3.x本示例以常見版本為基礎實際請按項目情況調整。一個前端靜態目錄Spring Boot 直接放在src/main/resources/static下即可。由于分片上傳的核心邏輯和 Spring Boot 版本關系不大核心代碼在 2.x 和 3.x 上都可以運行。4.2 項目結構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 依賴和文件上傳相關依賴Spring Boot 默認已經引入了文件上傳能力。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 實現依賴少、容易理解。4.4 后端接口設計后端一共提供 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保存上傳元數據。生產環境建議替換為 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 實現下面逐步實現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并標記為秒傳命中 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); // 給一個特殊標記表示秒傳命中 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 不存在請重新初始化上傳); } // 分片編號不能超出總分片數 if (dto.getChunkIndex() 0 || dto.getChunkIndex() session.getTotalChunks()) { throw new RuntimeException(分片編號不合法); } // 如果該分片已經上傳直接返回避免重復寫盤 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 按順序寫文件 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 中已經合并過的文件 // 生產環境改為查詢數據庫或對象存儲 return null; } }這里需要解釋幾個關鍵點分片文件名使用的是chunk_0、chunk_1這種命名方式合并時直接按編號遍歷即可不依賴文件修改時間或隨機名。RandomAccessFile寫入時先定位到文件末尾再寫入保證分片按順序追加。合并之后清理臨時目錄避免磁盤空間被不斷占用。findExistByMd5在示例中返回null實際項目中可以查詢數據庫中的文件表判斷是否存在同 MD5 的文件。4.6 Controller 實現// 文件路徑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字段中其他參數放在表單字段中。4.7 前端實現前端使用原生 HTML JavaScript Axios 實現。先寫一個簡單的頁面。!-- 文件路徑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. 計算總分片數 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; // 如果服務端判斷命中了秒傳直接結束 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. 構造待上傳分片隊列 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. 并發控制上傳 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整個文件這樣可以避免大文件導致瀏覽器內存暴漲。uploadChunksInConcurrency函數實現了一個簡單的并發隊列保證同一時間最多只有 3 個分片在傳輸。這種寫法比Promise.all一次性發出所有請求更安全。4.8 運行與驗證啟動 Spring Boot 應用后瀏覽器訪問http://localhost:8080/index.html選擇一個比較大的文件比如幾百 MB點擊“開始上傳”觀察控制臺輸出。預期效果前端按 5MB 大小切分文件。后端臨時目錄下出現uploadId/chunk_0、chunk_1等分片文件。控制臺顯示上傳進度。所有分片上傳結束后后端合并文件并清理臨時目錄。如果想驗證斷點續傳可以在上傳過程中手動關閉后端服務然后重新啟動再次選擇同一個文件上傳。前端會通過/upload/check接口拿到已上傳分片跳過它們只補傳失敗的分片。5. 常見問題與排查思路5.1 上傳大文件時 OOM問題現象上傳過程中服務端拋出OutOfMemoryError: Java heap space。可能原因后端使用byte[]直接接收整個文件文件過大導致堆內存溢出。前端使用readAsArrayBuffer讀取整個文件瀏覽器標簽頁內存飆升。并發分片太多每個請求都緩存了較大的分片數據。解決思路后端接收分片時用MultipartFile.getInputStream()流式讀取不要轉成byte[]。前端計算 MD5 時也要分片讀取。控制并發數量避免同時多個大請求占用內存。5.2 合并后文件損壞問題現象分片上傳全部成功但合并后的文件無法打開或文件大小不一致。可能原因合并時未按照chunkIndex排序分片順序錯亂。某個分片上傳失敗但被記錄為成功。分片文件被多個請求同時寫入。解決思路合并時嚴格按下標順序遍歷分片文件。服務端接收分片時校驗分片大小如果分片大小與預期不符則不標記為成功。分片文件采用uploadId chunkIndex唯一命名防止并發覆蓋。5.3 斷點續傳沒生效問題現象頁面刷新或網絡斷開后重新上傳所有分片又重新傳了一遍。可能原因上傳元數據保存在服務端內存中服務重啟后丟失。前端查詢已上傳分片接口的返回值沒有正確使用。上傳會話過期被清理。解決思路生產環境將上傳元數據存入 Redis并設置合理的過期時間。前端在上傳前調用/upload/check用返回的分片集合做跳過。設置合適的過期時間比如 2 小時保證大文件有足夠時間完成。5.4 多實例部署時狀態不同步問題現象應用部署了多個實例前端上傳分片被負載均衡分發到不同實例導致合并時提示分片不完整。可能原因每個實例都有獨立的本地內存和臨時目錄分片文件分散在不同節點上。上傳元數據沒有共享。解決思路使用 Redis 保存上傳元數據保證多個實例讀到的狀態一致。分片臨時文件放到共享存儲NFS、MinIO、OSS。更推薦使用對象存儲的 Multipart Upload 能力服務端只負責生成憑證和編排流程。5.5 MinIO 支持斷點續傳嗎MinIO 本身就是對象存儲它支持 S3 兼容的 Multipart Upload所以可以實現斷點續傳。核心流程和手寫方案類似調用initiateMultipartUpload獲取上傳 ID。分片上傳時調用uploadPartMinIO 會返回每個分片的 ETag。如果中斷調用listParts查詢已上傳分片。最后調用completeMultipartUpload合并分片。但需要注意前端直接對接 MinIO 時不能暴露 AccessKey。更安全的做法是后端生成 STS 臨時憑證或預簽名 URL前端在憑證有效期內上傳。5.6 分片上傳會 OOM 嗎分片上傳本身不會導致 OOM但使用方式不對會。前端如果一次性把文件讀入內存再分片會 OOM。后端如果每次把分片讀入byte[]分片大小合理時通常沒問題因為單個分片只有幾 MB。后端如果合并時把所有分片一次性讀入內存分片數量大時也會 OOM。正確做法是分片時用file.slice()讀取服務端用流式寫入合并時逐片讀取并寫入最終文件不要一次性加載所有分片。6. 最佳實踐與工程建議6.1 分片大小與并發參數參數沒有“銀彈”要根據場景做實驗。這里給一組常用參考值參數推薦值說明分片大小5MB ~ 10MB公網推薦 5MB內網可適當調大前端并發數3 ~ 6并發太高會增加服務器壓力Redis 過期時間2 小時根據文件大小和網絡速度調整分片 MD5 校驗建議開啟保證分片內容完整防止網絡傳輸損壞6.2 安全校驗大文件上傳接口往往是攻擊者關注的目標必須做好安全邊界登錄態校驗接口必須校驗用戶登錄狀態不能匿名上傳。文件類型校驗通過文件擴展名和 MIME 類型雙重校驗并且不要信任前端傳的唯一標識。文件大小限制對分片大小、總分片數和總文件大小做限制防止惡意上傳超大文件拖垮磁盤。權限校驗只有有權限的用戶才能調用初始化、合并接口。上傳目錄不能放在可執行目錄下防止上傳木馬后獲得執行權限。6.3 存儲選型單機和中小項目本地磁盤存儲分片和最終文件代碼簡單部署方便。多實例項目需要共享存儲或 Redis 保存狀態否則斷點續傳會失效。云原生項目直接使用對象存儲的 Multipart Upload可靠性和擴展性最好。如果使用 MinIO建議后端封裝統一的文件服務接口而不是讓業務代碼直接操作桶。6.4 日志與監控文件上傳是重 IO 操作必須記錄足夠的數據用于排查記錄每次上傳的 uploadId、文件名、文件大小、分片數。記錄每個分片的上傳耗時、重試次數。記錄合并的起止時間、最終文件路徑。監控臨時分片目錄的占用空間定時清理過期分片。6.5 前端體驗優化大文件計算 MD5 會阻塞主線程建議使用 Web Worker 在后臺線程計算。上傳進度條要綜合“當前已上傳分片”和“總文件大小”來計算而不是簡單按照最后一次請求的進度。失敗時提供手動重試和自動重試按鈕自動重試次數建議不超過 3 次。頁面刷新后要能恢復上傳進度這是斷點續存在用戶層的直觀體現。6.6 面試官更看重什么面試中問到大文件上傳面試官真正想考察的是是否理解分片上傳的核心思路。是否考慮過失敗恢復也就是斷點續傳。是否考慮過存儲、內存、并發的邊界情況。是否知道對象存儲的 Multipart Upload 用法。是否能結合業務場景選擇合適的方案。回答時可以先用一句話總結方案再展開講分片邏輯、斷點續傳實現、秒傳判斷、合并流程最后補充 OOM、順序錯亂、多實例等問題。這樣能體現出系統思維。7. 總結與學習路線這篇文章圍繞“大文件上傳與斷點續傳”展開完整介紹了分片上傳、斷點續傳、秒傳三者的關系拆解了分片大小、已上傳分片記錄、服務端合并、并發控制等核心原理并給出了一個基于 Spring Boot 和原生前端的完整實戰示例。如果你準備面試建議按以下順序建立知識體系先能用代碼實現一個最簡單的分片上傳。再在此基礎上加入已上傳分片查詢實現斷點續傳。接著加入 MD5 秒傳判斷。然后嘗試把上傳狀態從內存遷移到 Redis。最后學習 MinIO 或 OSS 的 Multipart Upload理解生產級方案。學完這些之后你還可以繼續探索分片上傳的進度恢復、后端合并的并行優化、對象存儲的預簽名 URL、前端 Web Worker 計算大文件哈希等進階話題。每一步都有很多細節值得深挖但掌握了基礎鏈路之后再看這些高級方案會輕松很多。如果文章對你有幫助建議收藏備用動手敲一遍代碼比只看不練效果好得多。