1. 項目緣起為什么大文件上傳下載是個“技術(shù)活”最近在做一個內(nèi)部知識庫項目需要支持用戶上傳各種設(shè)計稿、視頻和項目文檔。剛開始圖省事直接用了Spring Boot默認的文件上傳前端Vue 3那邊一個input typefile配合axios就搞定了。結(jié)果測試同事上傳一個2GB的安裝包時瀏覽器直接卡死然后頁面就白了。刷新一看后端日志里赫然一個OutOfMemoryError。這場景但凡做過Web開發(fā)的估計都似曾相識。傳統(tǒng)表單上傳文件會被整個讀入內(nèi)存對于大文件來說這無異于自殺。網(wǎng)絡(luò)稍微一波動傳輸中斷用戶就得從頭再來體驗極差。所以“分片上傳與下載”就成了處理大文件的標(biāo)配方案。它的核心思想很簡單就是“化整為零分而治之”把一個大文件切成若干個小塊分片逐個上傳。服務(wù)器收到所有分片后再按順序拼接成完整的文件。下載時同理可以支持斷點續(xù)傳和并行下載提升效率。這個需求太普遍了從網(wǎng)盤應(yīng)用到企業(yè)級文檔管理幾乎無處不在。但真要自己從頭實現(xiàn)里面門道不少分片策略怎么定前端怎么切文件后端怎么接收和合并怎么保證上傳的原子性要么全成功要么全失敗怎么實現(xiàn)秒傳和斷點續(xù)傳這次我就結(jié)合Spring Boot和Vue 3把一整套從理論到實踐的實現(xiàn)過程以及我踩過的坑詳細拆解一遍。2. 核心架構(gòu)設(shè)計從前端切片到后端合并的全鏈路實現(xiàn)大文件上傳下載不是一個點而是一條鏈。我們需要從前端、后端到存儲每個環(huán)節(jié)都設(shè)計好。2.1 前端Vue 3的核心職責(zé)前端是整個流程的發(fā)起者和調(diào)度者它的工作不僅僅是選擇文件更重要的是負責(zé)“分”和“控”。文件分片策略首先得決定怎么切。通常有兩種策略固定大小分片和動態(tài)分片。固定大小最簡單比如固定每片5MB。動態(tài)分片則可能根據(jù)文件類型、網(wǎng)絡(luò)狀況調(diào)整。對于大多數(shù)場景固定大小完全夠用也便于后端處理。這里有個關(guān)鍵參數(shù)分片大小Chunk Size。設(shè)置太小會導(dǎo)致請求次數(shù)過多增加開銷設(shè)置太大則失去了分片的意義且單個請求失敗代價高。經(jīng)過實踐對于百MB到GB級的文件1MB到5MB是一個比較理想的區(qū)間。我們以2MB為例。計算文件指紋File Hash這是實現(xiàn)“秒傳”和“校驗”的基礎(chǔ)。秒傳指的是如果服務(wù)器上已經(jīng)存在相同內(nèi)容的文件用戶就無需再次上傳。我們需要在文件分片前計算整個文件的唯一標(biāo)識通常使用文件的MD5或SHA-256哈希值。注意計算大文件的哈希本身也可能比較耗時可以考慮使用Web Worker放到后臺線程執(zhí)行避免阻塞UI。調(diào)度與控制邏輯這是前端的“大腦”。它需要讀取文件并按設(shè)定大小進行切片。為每個分片生成一個唯一序號index從0開始。發(fā)起上傳請求控制并發(fā)數(shù)比如同時上傳3-5片避免瀏覽器壓力過大。監(jiān)聽每個分片的上傳結(jié)果成功/失敗。如果某個分片失敗進行重試可設(shè)置最大重試次數(shù)。所有分片成功后通知后端進行合并操作。斷點續(xù)傳的實現(xiàn)關(guān)鍵在于持久化上傳進度。我們可以將文件指紋、文件總大小、分片大小、已成功上傳的分片索引列表等信息存儲到瀏覽器的localStorage或IndexedDB中。當(dāng)用戶刷新頁面或再次打開時先檢查本地是否有該文件的未完成記錄如果有則只上傳剩余的分片而不是從頭開始。2.2 后端Spring Boot的核心職責(zé)后端是數(shù)據(jù)的接收站、倉庫和管理員需要穩(wěn)健可靠。接收分片數(shù)據(jù)不能再用RequestParam(“file”) MultipartFile file這種接收整個文件的方式了。我們需要一個接口專門接收分片。這個接口的入?yún)⑼ǔ０╢ile: 當(dāng)前分片的二進制數(shù)據(jù)依然是MultipartFile。chunkNumber: 當(dāng)前分片的序號從0或1開始。chunkSize: 分片大小。totalChunks: 總分片數(shù)。totalSize: 文件總大小。identifier: 文件唯一標(biāo)識即前端計算的文件哈希。filename: 原始文件名。分片臨時存儲收到分片后不能直接往最終位置寫。我們需要一個臨時存儲區(qū)。通常的做法是在服務(wù)器上創(chuàng)建一個以identifier文件哈希命名的臨時目錄然后將每個分片以其chunkNumber命名如0.part,1.part保存到這個目錄下。這樣做的好處是同一個文件的上傳即使來自不同會話其分片也能歸集到一起。分片合并當(dāng)前端通知所有分片已上傳完畢時后端需要執(zhí)行合并操作。合并的邏輯是按分片序號順序讀取臨時目錄下的所有.part文件將它們的內(nèi)容依次寫入到一個新的文件中這個新文件就是最終文件。合并完成后刪除臨時目錄。這里有一個非常重要的細節(jié)合并操作必須是冪等的并且要加鎖處理防止多個合并請求同時操作同一個文件導(dǎo)致錯亂。接口設(shè)計至少需要三個核心接口POST /upload/chunk: 上傳文件分片。POST /upload/merge: 通知合并文件。GET /upload/check: 檢查文件上傳狀態(tài)用于秒傳和斷點續(xù)傳查詢。存儲考量對于合并后的最終文件你可以存儲在服務(wù)器的本地磁盤也可以上傳到云存儲如阿里云OSS、騰訊云COS。如果存儲在本地需要考慮磁盤空間、備份以及分布式部署時的文件共享問題此時可能需要引入共享存儲如NFS或MinIO。云存儲通常是更省心、可擴展性更強的選擇。3. 前端Vue 3實現(xiàn)詳解從文件讀取到并發(fā)控制理論說完了我們上代碼。這里使用Vue 3的Composition API配合script setup語法會更清晰。3.1 計算文件哈希與分片首先我們需要一個工具函數(shù)來計算文件的MD5。這里使用spark-md5庫它特別適合計算大文件的哈希因為它可以增量更新。npm install spark-md5然后在Vue組件中template div input typefile changehandleFileChange / button clickhandleUpload :disabled!file || uploading開始上傳/button div進度{{ progress }}%/div /div /template script setup import { ref } from vue; import SparkMD5 from spark-md5; import axios from axios; const file ref(null); const uploading ref(false); const progress ref(0); // 計算文件MD5 const calculateFileHash (file) { return new Promise((resolve, reject) { const chunkSize 2 * 1024 * 1024; // 2MB一片用于計算哈希 const chunks Math.ceil(file.size / chunkSize); const spark new SparkMD5.ArrayBuffer(); const fileReader new FileReader(); let currentChunk 0; fileReader.onload (e) { spark.append(e.target.result); currentChunk; if (currentChunk chunks) { loadNext(); } else { resolve(spark.end()); // 得到最終的MD5 } }; fileReader.onerror () { reject(new Error(文件讀取失敗)); }; function loadNext() { const start currentChunk * chunkSize; const end start chunkSize file.size ? file.size : start chunkSize; fileReader.readAsArrayBuffer(file.slice(start, end)); } loadNext(); }); }; const handleFileChange (e) { const selectedFile e.target.files[0]; if (selectedFile) { file.value selectedFile; } }; /script注意這里用于計算哈希的分片大小2MB和實際傳輸?shù)姆制笮】梢允遣煌?。計算哈希為了速度可以適當(dāng)大一點而傳輸分片為了靈活性和容錯可以小一點。3.2 實現(xiàn)分片上傳與并發(fā)控制接下來是核心的上傳邏輯。我們定義一個uploadFile函數(shù)。// 在script setup中繼續(xù) const CHUNK_SIZE 2 * 1024 * 1024; // 實際傳輸分片大小2MB const MAX_CONCURRENT 3; // 最大并發(fā)數(shù) const handleUpload async () { if (!file.value) return; uploading.value true; progress.value 0; try { // 1. 計算文件哈希 const fileHash await calculateFileHash(file.value); console.log(文件哈希, fileHash); // 2. 檢查文件狀態(tài)秒傳、斷點續(xù)傳 const { data: checkResult } await axios.get(/api/upload/check, { params: { identifier: fileHash, filename: file.value.name } }); // 如果服務(wù)器已存在該文件秒傳成功 if (checkResult.uploaded) { progress.value 100; alert(秒傳成功); uploading.value false; return; } // 3. 準備分片 const chunkList []; const totalSize file.value.size; const totalChunks Math.ceil(totalSize / CHUNK_SIZE); let uploadedChunks checkResult.uploadedChunks || []; // 服務(wù)器返回的已上傳分片列表 for (let i 0; i totalChunks; i) { const start i * CHUNK_SIZE; const end Math.min(start CHUNK_SIZE, totalSize); const chunk file.value.slice(start, end); chunkList.push({ chunk, index: i, hash: ${fileHash}-${i} // 分片唯一標(biāo)識也可用于校驗 }); } // 4. 過濾掉已上傳的分片 const chunksToUpload chunkList.filter(chunk !uploadedChunks.includes(chunk.index)); const totalToUpload chunksToUpload.length; let uploadedCount 0; // 5. 并發(fā)控制上傳 const uploadChunk async (chunkData) { const formData new FormData(); formData.append(file, chunkData.chunk); formData.append(chunkNumber, chunkData.index); formData.append(totalChunks, totalChunks); formData.append(identifier, fileHash); formData.append(filename, file.value.name); try { await axios.post(/api/upload/chunk, formData, { headers: { Content-Type: multipart/form-data } }); // 上傳成功 uploadedCount; progress.value Math.round(((uploadedChunks.length uploadedCount) / totalChunks) * 100); // 可以在這里更新本地存儲的上傳進度 } catch (error) { console.error(分片 ${chunkData.index} 上傳失敗:, error); // 實現(xiàn)重試邏輯這里簡化處理實際應(yīng)加入重試隊列 throw error; } }; // 簡單的并發(fā)控制函數(shù) const runTasksWithConcurrency async (tasks, maxConcurrent) { const executing new Set(); const results []; for (const task of tasks) { const p task().then(res { executing.delete(p); return res; }); executing.add(p); results.push(p); if (executing.size maxConcurrent) { await Promise.race(executing); } } return Promise.all(results); }; // 創(chuàng)建上傳任務(wù)數(shù)組 const uploadTasks chunksToUpload.map(chunkData () uploadChunk(chunkData)); await runTasksWithConcurrency(uploadTasks, MAX_CONCURRENT); // 6. 所有分片上傳完成通知合并 if (uploadedCount totalToUpload) { await axios.post(/api/upload/merge, { identifier: fileHash, filename: file.value.name, totalChunks: totalChunks }); alert(文件上傳并合并成功); } } catch (error) { console.error(上傳過程出錯, error); alert(上傳失敗請重試); } finally { uploading.value false; } };這段代碼實現(xiàn)了帶并發(fā)控制的分片上傳核心流程。其中runTasksWithConcurrency函數(shù)是一個簡單的并發(fā)控制器它確保同時運行的上傳任務(wù)不超過MAX_CONCURRENT個。3.3 斷點續(xù)傳與本地狀態(tài)持久化為了實現(xiàn)刷新頁面后繼續(xù)上傳我們需要把關(guān)鍵信息存起來。// 在組件中增加狀態(tài)保存與恢復(fù)邏輯 import { onMounted } from vue; const UPLOAD_STATUS_KEY file_upload_status; const saveUploadStatus (identifier, status) { const allStatus JSON.parse(localStorage.getItem(UPLOAD_STATUS_KEY) || {}); allStatus[identifier] status; localStorage.setItem(UPLOAD_STATUS_KEY, JSON.stringify(allStatus)); }; const getUploadStatus (identifier) { const allStatus JSON.parse(localStorage.getItem(UPLOAD_STATUS_KEY) || {}); return allStatus[identifier] || null; }; const clearUploadStatus (identifier) { const allStatus JSON.parse(localStorage.getItem(UPLOAD_STATUS_KEY) || {}); delete allStatus[identifier]; localStorage.setItem(UPLOAD_STATUS_KEY, JSON.stringify(allStatus)); }; // 在handleUpload函數(shù)中檢查完服務(wù)器狀態(tài)后可以合并本地狀態(tài) // 假設(shè)checkResult返回了服務(wù)器已上傳的列表 serverUploadedChunks // 我們可以從本地存儲獲取之前可能上傳的部分 const localStatus getUploadStatus(fileHash); const localUploadedChunks localStatus ? localStatus.uploadedChunks : []; // 合并服務(wù)器和本地的已上傳列表取并集實際應(yīng)以服務(wù)器為準本地作為輔助 const allUploadedChunks [...new Set([...uploadedChunks, ...localUploadedChunks])]; // 在每個分片上傳成功后更新本地狀態(tài) // 在uploadChunk函數(shù)的成功回調(diào)里 const newUploadedChunks [...allUploadedChunks, chunkData.index]; saveUploadStatus(fileHash, { filename: file.value.name, uploadedChunks: newUploadedChunks }); // 在所有分片上傳并合并成功后清除本地狀態(tài) // 在合并請求成功后 clearUploadStatus(fileHash); // 組件掛載時可以嘗試恢復(fù)上一個未完成的上傳可選功能 onMounted(() { const allStatus JSON.parse(localStorage.getItem(UPLOAD_STATUS_KEY) || {}); // 這里可以展示一個列表讓用戶選擇是否繼續(xù)上傳 });實操心得本地存儲的斷點續(xù)傳狀態(tài)更多是用于改善用戶體驗如刷新后進度條還在以及應(yīng)對網(wǎng)絡(luò)瞬時中斷。最終已上傳分片的權(quán)威記錄必須保存在服務(wù)端。因為前端狀態(tài)不可靠用戶可能換瀏覽器、清緩存。所以/check接口返回的uploadedChunks才是金標(biāo)準。前端本地狀態(tài)應(yīng)與服務(wù)端同步并在合并成功后及時清理。4. 后端Spring Boot實現(xiàn)詳解從接口設(shè)計到文件合并前端把活干得漂漂亮亮后端必須接得住。我們一步步來構(gòu)建穩(wěn)健的后端服務(wù)。4.1 環(huán)境準備與依賴創(chuàng)建一個Spring Boot項目確保pom.xml中包含Web和必要的工具依賴。dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 用于生成MD5等 -- dependency groupIdcommons-codec/groupId artifactIdcommons-codec/artifactId /dependency !-- 可選用于更優(yōu)雅的Path操作 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency !-- 如果你打算用Lombok簡化代碼 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies在application.yml中配置一下上傳文件的臨時路徑和最終存儲路徑。app: upload: temp-dir: /tmp/upload_tmp # 臨時分片存儲目錄 final-dir: /data/upload_final # 最終文件存儲目錄 # 或者如果你用云存儲這里配置OSS/COS的Bucket和密鑰4.2 核心數(shù)據(jù)結(jié)構(gòu)與工具類我們先定義幾個用于接收請求和返回結(jié)果的DTOData Transfer Object。import lombok.Data; import org.springframework.web.multipart.MultipartFile; Data public class UploadChunkRequest { private MultipartFile file; private Integer chunkNumber; private Integer totalChunks; private String identifier; // 文件唯一標(biāo)識哈希 private String filename; // 可以根據(jù)需要添加 chunkSize, totalSize 等字段 } Data public class MergeFileRequest { private String identifier; private String filename; private Integer totalChunks; } Data public class CheckFileResponse { private Boolean uploaded; // 是否已完整上傳秒傳 private Integer[] uploadedChunks; // 已上傳的分片索引列表 }再創(chuàng)建一個文件操作的工具類FileStorageUtil負責(zé)處理臨時文件和最終文件的讀寫。import lombok.extern.slf4j.Slf4j; import org.apache.commons.codec.digest.DigestUtils; import org.springframework.beans.factory.annotation.Value; import org.springframework.stereotype.Component; import org.springframework.util.StringUtils; import java.io.*; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.nio.file.StandardCopyOption; import java.util.Arrays; import java.util.Comparator; import java.util.stream.Stream; Slf4j Component public class FileStorageUtil { Value(${app.upload.temp-dir}) private String tempDirPath; Value(${app.upload.final-dir}) private String finalDirPath; /** * 獲取指定文件的臨時分片存儲目錄路徑 */ public Path getChunkDirPath(String identifier) { return Paths.get(tempDirPath, identifier); } /** * 獲取最終文件的存儲路徑 */ public Path getFinalFilePath(String identifier, String filename) { // 使用identifier和原文件后綴生成最終文件名避免重名 String extension StringUtils.getFilenameExtension(filename); String finalFilename identifier (StringUtils.hasText(extension) ? . extension : ); return Paths.get(finalDirPath, finalFilename); } /** * 保存分片到臨時目錄 */ public void saveChunk(MultipartFile chunk, String identifier, Integer chunkNumber) throws IOException { Path chunkDir getChunkDirPath(identifier); if (!Files.exists(chunkDir)) { Files.createDirectories(chunkDir); } Path chunkFilePath chunkDir.resolve(chunkNumber.toString()); // 用序號作為分片文件名 // 使用Files.copy并替換已存在的文件 Files.copy(chunk.getInputStream(), chunkFilePath, StandardCopyOption.REPLACE_EXISTING); log.info(分片保存成功: identifier{}, chunkNumber{}, identifier, chunkNumber); } /** * 合并所有分片為最終文件 */ public void mergeChunks(String identifier, String originalFilename, Integer totalChunks) throws IOException { Path chunkDir getChunkDirPath(identifier); Path finalFilePath getFinalFilePath(identifier, originalFilename); // 確保最終文件目錄存在 Files.createDirectories(finalFilePath.getParent()); try (BufferedOutputStream outputStream new BufferedOutputStream(new FileOutputStream(finalFilePath.toFile()))) { // 按分片序號順序讀取并合并 for (int i 0; i totalChunks; i) { Path chunkPath chunkDir.resolve(String.valueOf(i)); if (!Files.exists(chunkPath)) { throw new IOException(分片缺失: chunkPath); } byte[] buffer Files.readAllBytes(chunkPath); outputStream.write(buffer); log.debug(已合并分片: {}, i); } outputStream.flush(); } log.info(文件合并成功: identifier{}, finalPath{}, identifier, finalFilePath); // 合并成功后刪除臨時分片目錄可選建議保留一段時間以供核查 deleteDirectory(chunkDir); } /** * 檢查文件狀態(tài)是否已完整存在以及已上傳了哪些分片 */ public CheckFileResponse checkFileStatus(String identifier, String filename) { CheckFileResponse response new CheckFileResponse(); Path finalFilePath getFinalFilePath(identifier, filename); // 1. 檢查是否已完整上傳秒傳 if (Files.exists(finalFilePath) Files.isRegularFile(finalFilePath)) { response.setUploaded(true); response.setUploadedChunks(new Integer[0]); // 完整文件已存在無需關(guān)心分片 return response; } response.setUploaded(false); // 2. 檢查已上傳的分片 Path chunkDir getChunkDirPath(identifier); if (Files.exists(chunkDir) Files.isDirectory(chunkDir)) { try (StreamPath stream Files.list(chunkDir)) { Integer[] uploadedIndices stream.map(p - { try { return Integer.parseInt(p.getFileName().toString()); } catch (NumberFormatException e) { return -1; // 忽略非數(shù)字命名的文件 } }) .filter(i - i 0) .sorted() .toArray(Integer[]::new); response.setUploadedChunks(uploadedIndices); } catch (IOException e) { log.error(讀取分片目錄失敗: {}, chunkDir, e); response.setUploadedChunks(new Integer[0]); } } else { response.setUploadedChunks(new Integer[0]); } return response; } /** * 遞歸刪除目錄用于清理臨時文件 */ private void deleteDirectory(Path dir) throws IOException { if (Files.exists(dir) Files.isDirectory(dir)) { try (StreamPath walk Files.walk(dir)) { walk.sorted(Comparator.reverseOrder()) .map(Path::toFile) .forEach(File::delete); } log.info(臨時目錄已刪除: {}, dir); } } }這個工具類封裝了所有與文件系統(tǒng)交互的底層操作保持Controller層的簡潔。4.3 核心控制器Controller實現(xiàn)現(xiàn)在創(chuàng)建FileUploadController來處理前端請求。import lombok.RequiredArgsConstructor; import lombok.extern.slf4j.Slf4j; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.*; import org.springframework.web.multipart.MultipartFile; import javax.validation.Valid; import java.io.IOException; import java.util.concurrent.ConcurrentHashMap; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; Slf4j RestController RequestMapping(/api/upload) RequiredArgsConstructor public class FileUploadController { private final FileStorageUtil fileStorageUtil; // 使用一個簡單的內(nèi)存鎖Map防止同一文件的合并請求并發(fā)執(zhí)行。生產(chǎn)環(huán)境建議用分布式鎖如Redis。 private final ConcurrentHashMapString, Lock mergeLocks new ConcurrentHashMap(); /** * 檢查文件狀態(tài)秒傳、斷點續(xù)傳查詢 */ GetMapping(/check) public ResponseEntityCheckFileResponse checkFile( RequestParam String identifier, RequestParam String filename) { log.info(檢查文件狀態(tài): identifier{}, filename{}, identifier, filename); CheckFileResponse status fileStorageUtil.checkFileStatus(identifier, filename); return ResponseEntity.ok(status); } /** * 上傳文件分片 */ PostMapping(/chunk) public ResponseEntityVoid uploadChunk(Valid UploadChunkRequest request) { log.info(收到分片上傳請求: identifier{}, chunk{}/{}, filename{}, request.getIdentifier(), request.getChunkNumber(), request.getTotalChunks(), request.getFilename()); try { fileStorageUtil.saveChunk(request.getFile(), request.getIdentifier(), request.getChunkNumber()); return ResponseEntity.ok().build(); } catch (IOException e) { log.error(分片保存失敗, e); return ResponseEntity.internalServerError().build(); } } /** * 合并文件分片 */ PostMapping(/merge) public ResponseEntityString mergeFile(Valid RequestBody MergeFileRequest request) { log.info(收到合并請求: identifier{}, filename{}, totalChunks{}, request.getIdentifier(), request.getFilename(), request.getTotalChunks()); // 獲取或創(chuàng)建該文件對應(yīng)的鎖確保合并操作的原子性 Lock mergeLock mergeLocks.computeIfAbsent(request.getIdentifier(), k - new ReentrantLock()); mergeLock.lock(); try { // 再次檢查是否已合并防止重復(fù)合并 CheckFileResponse status fileStorageUtil.checkFileStatus(request.getIdentifier(), request.getFilename()); if (status.getUploaded()) { log.warn(文件已存在無需重復(fù)合并: identifier{}, request.getIdentifier()); return ResponseEntity.ok(文件已存在合并跳過); } fileStorageUtil.mergeChunks(request.getIdentifier(), request.getFilename(), request.getTotalChunks()); return ResponseEntity.ok(文件合并成功); } catch (IOException e) { log.error(文件合并失敗, e); return ResponseEntity.internalServerError().body(合并失敗); } catch (Exception e) { log.error(合并過程發(fā)生未知錯誤, e); return ResponseEntity.internalServerError().body(服務(wù)器內(nèi)部錯誤); } finally { mergeLock.unlock(); // 可選合并完成后移除鎖防止內(nèi)存泄漏。對于低頻操作也可以不清理。 mergeLocks.remove(request.getIdentifier()); } } }這個控制器清晰地定義了三個接口邏輯也比較直白。有幾個關(guān)鍵點需要注意/check接口這是實現(xiàn)秒傳和斷點續(xù)傳的基石。前端在上傳前先調(diào)用它后端返回文件整體是否存在以及哪些分片已經(jīng)傳過了。/chunk接口接收分片。這里參數(shù)使用了Valid注解需要你確保UploadChunkRequest類中有相應(yīng)的驗證注解如NotNull。/merge接口這是最復(fù)雜的一環(huán)。我使用了ReentrantLock配合ConcurrentHashMap來實現(xiàn)一個簡單的應(yīng)用級鎖確保對同一個identifier即同一個文件的合并請求不會并發(fā)執(zhí)行。這在單機部署時是有效的。如果是分布式部署多臺服務(wù)器這個內(nèi)存鎖就失效了必須引入分布式鎖例如基于Redis或ZooKeeper。4.4 進階優(yōu)化分布式鎖與云存儲集成分布式鎖實現(xiàn)在生產(chǎn)環(huán)境中你的Spring Boot應(yīng)用很可能部署在多臺機器上。這時內(nèi)存鎖就不管用了。我們需要一個所有實例都能訪問的鎖服務(wù)。這里以Redis為例使用Spring Integration或直接使用Redisson客戶端。首先添加Redisson依賴dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.27.0/version !-- 使用最新穩(wěn)定版 -- /dependency然后修改mergeFile方法中的鎖邏輯import org.redisson.api.RLock; import org.redisson.api.RedissonClient; import javax.annotation.Resource; Resource private RedissonClient redissonClient; PostMapping(/merge) public ResponseEntityString mergeFile(Valid RequestBody MergeFileRequest request) { String lockKey FILE_MERGE_LOCK: request.getIdentifier(); RLock lock redissonClient.getLock(lockKey); // 嘗試加鎖等待10秒鎖持有時間30秒應(yīng)大于合并操作的最大可能時間 boolean isLocked false; try { isLocked lock.tryLock(10, 30, TimeUnit.SECONDS); if (!isLocked) { return ResponseEntity.status(423).body(系統(tǒng)正忙請稍后重試); // 423 Locked } // ... 原有的合并邏輯 ... } catch (InterruptedException e) { Thread.currentThread().interrupt(); return ResponseEntity.internalServerError().body(操作被中斷); } finally { if (isLocked lock.isHeldByCurrentThread()) { lock.unlock(); } } }集成云存儲將最終文件存到本地磁盤在分布式和擴展性上都有局限。集成阿里云OSS或騰訊云COS是更優(yōu)解。以阿里云OSS為例引入OSS SDK依賴。在FileStorageUtil中注入OSS客戶端。修改mergeChunks方法不再寫入本地finalDirPath而是將合并后的流直接上傳到OSS?；蛘吒咝У淖龇ㄊ鞘褂肙SS的分片上傳Multipart UploadAPI。這樣后端在接收到前端分片后可以直接轉(zhuǎn)發(fā)到OSS最后由OSS服務(wù)端完成合并。這能極大減輕你應(yīng)用服務(wù)器的I/O和存儲壓力。不過實現(xiàn)起來稍復(fù)雜需要維護OSS的UploadId和分片ETag等信息。5. 大文件下載與斷點續(xù)傳實現(xiàn)上傳搞定了下載也不能含糊。大文件下載同樣需要支持分片范圍請求和斷點續(xù)傳。5.1 服務(wù)端支持范圍請求Range RequestHTTP協(xié)議本身支持范圍請求關(guān)鍵在于服務(wù)端要正確響應(yīng)Range頭。Spring Boot可以很方便地支持。import org.springframework.core.io.Resource; import org.springframework.core.io.UrlResource; import org.springframework.http.HttpHeaders; import org.springframework.http.HttpRange; import org.springframework.http.HttpStatus; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RequestHeader; import org.springframework.web.bind.annotation.RestController; import java.nio.file.Files; import java.nio.file.Path; import java.util.List; RestController RequestMapping(/api/download) public class FileDownloadController { private final FileStorageUtil fileStorageUtil; GetMapping(/{identifier}) public ResponseEntityResource downloadFile( PathVariable String identifier, RequestHeader(value Range, required false) String rangeHeader) throws IOException { // 這里簡化處理假設(shè)identifier就是最終存儲的文件名。實際應(yīng)根據(jù)業(yè)務(wù)邏輯查找真實文件路徑。 Path filePath fileStorageUtil.getFinalFilePath(identifier, identifier); if (!Files.exists(filePath)) { return ResponseEntity.notFound().build(); } Resource resource new UrlResource(filePath.toUri()); long fileLength Files.size(filePath); // 如果沒有Range頭返回整個文件 if (rangeHeader null) { return ResponseEntity.ok() .header(HttpHeaders.CONTENT_DISPOSITION, attachment; filename\ resource.getFilename() \) .header(HttpHeaders.CONTENT_LENGTH, String.valueOf(fileLength)) .body(resource); } // 解析Range頭支持形如 bytes0-999 或 bytes0- ListHttpRange ranges HttpRange.parseRanges(rangeHeader); if (ranges.size() ! 1) { // 本示例只處理單個范圍請求 return ResponseEntity.status(HttpStatus.REQUESTED_RANGE_NOT_SATISFIABLE) .header(HttpHeaders.CONTENT_RANGE, bytes */ fileLength) .build(); } HttpRange range ranges.get(0); long start range.getRangeStart(fileLength); long end range.getRangeEnd(fileLength); long rangeLength end - start 1; // 讀取文件指定范圍的數(shù)據(jù) // 這里可以使用RandomAccessFile或Files.newByteChannel進行高效的范圍讀取 // 為了簡化Spring的ResourceRegion可以輔助返回部分資源但需要額外配置。 // 更直接的方式是手動設(shè)置響應(yīng)頭和流。 // 示例使用ResourceRegion (需要Spring 4.3) // ResourceRegion region new ResourceRegion(resource, start, rangeLength); // return ResponseEntity.status(HttpStatus.PARTIAL_CONTENT) // .header(HttpHeaders.CONTENT_RANGE, bytes start - end / fileLength) // .body(region); // 手動實現(xiàn)概念性代碼 // 設(shè)置206 Partial Content狀態(tài)碼和Content-Range頭 HttpHeaders headers new HttpHeaders(); headers.add(HttpHeaders.CONTENT_RANGE, bytes start - end / fileLength); headers.setContentLength(rangeLength); // 需要返回一個能讀取文件指定部分的Resource實現(xiàn)這里省略具體實現(xiàn)。 // 通常可以自定義一個Resource在其getInputStream()方法中跳轉(zhuǎn)到start位置。 RangeResource rangeResource new RangeResource(resource, start, rangeLength); return ResponseEntity.status(HttpStatus.PARTIAL_CONTENT) .headers(headers) .body(rangeResource); } }實現(xiàn)一個RangeResource是相對復(fù)雜的它需要包裝原始的Resource并在創(chuàng)建輸入流時跳過指定字節(jié)。你可以搜索“Spring Boot Range Resource”找到現(xiàn)成的實現(xiàn)方案。更簡單的方式是使用像Apache Commons FileUpload的一些工具或者直接使用RandomAccessFile在Controller中手動寫流但這樣不夠優(yōu)雅。5.2 前端實現(xiàn)分片下載前端下載大文件時也可以利用Range頭實現(xiàn)并發(fā)下載和斷點續(xù)傳?，F(xiàn)代瀏覽器fetch API和axios都支持設(shè)置請求頭。// 前端分片下載示例使用axios async function downloadFileByChunks(url, filename, totalSize, chunkSize 5 * 1024 * 1024) { const totalChunks Math.ceil(totalSize / chunkSize); const chunks []; const downloadPromises []; for (let i 0; i totalChunks; i) { const start i * chunkSize; const end Math.min(start chunkSize - 1, totalSize - 1); const promise axios.get(url, { headers: { Range: bytes${start}-${end} }, responseType: blob // 重要 }).then(response { chunks[i] response.data; // 按順序存儲Blob }); downloadPromises.push(promise); } // 控制并發(fā)下載數(shù) await runTasksWithConcurrency(downloadPromises, 3); // 所有分片下載完成后合并并觸發(fā)瀏覽器下載 const fullBlob new Blob(chunks, { type: application/octet-stream }); const link document.createElement(a); link.href URL.createObjectURL(fullBlob); link.download filename; link.click(); URL.revokeObjectURL(link.href); }注意瀏覽器對于并發(fā)請求數(shù)有限制同域名下通常6個。上述并發(fā)控制是必要的。另外合并大量Blob在內(nèi)存中進行對于超大文件比如幾十GB可能導(dǎo)致內(nèi)存問題。更高級的做法是使用Streams API進行流式合并但這會復(fù)雜很多。對于超大文件下載更好的方案是讓服務(wù)端提供直接下載鏈接或者使用專門的下載工具。6. 生產(chǎn)環(huán)境部署的坑與優(yōu)化建議代碼跑通只是第一步要上線穩(wěn)定運行還有很多細節(jié)要考慮。6.1 安全性加固文件校驗前端計算的MD5和后端收到所有分片后合并計算的MD5應(yīng)該做一次比對確保文件傳輸過程中沒有損壞或被篡改。可以在merge成功后計算最終文件的哈希與identifier對比。惡意文件過濾不能相信前端傳的文件名和類型。在后端一定要根據(jù)文件內(nèi)容魔數(shù)進行校驗防止用戶上傳可執(zhí)行文件等危險內(nèi)容?？梢允褂肁pache Tika等工具進行文件類型檢測。路徑遍歷攻擊確保identifier和filename參數(shù)中不包含../等路徑遍歷字符。在拼接文件路徑時使用Paths.get(baseDir, sanitizedIdentifier)避免直接拼接字符串。大小與頻率限制在application.yml中配置spring.servlet.multipart.max-file-size和max-request-size。同時在業(yè)務(wù)層面要對用戶上傳的總文件數(shù)、頻率進行限制防止濫用。權(quán)限控制上傳和下載接口必須加入身份認證和授權(quán)邏輯確保用戶只能操作自己有權(quán)限的文件。6.2 性能與穩(wěn)定性臨時文件清理臨時分片目錄會占用磁盤空間。需要有一個定時任務(wù)如Spring Scheduler定期清理超過一定時間如24小時未被合并的臨時目錄。磁盤I/O優(yōu)化合并文件時如果文件非常大一次性讀入所有分片到內(nèi)存再寫入可能內(nèi)存溢出。應(yīng)該使用緩沖流BufferedInputStream/BufferedOutputStream進行流式合并。對于超大文件甚至可以考慮使用FileChannel進行傳輸效率更高。超時與重試網(wǎng)絡(luò)是不穩(wěn)定的。前端上傳分片時要有重試機制前面代碼已簡單提及。后端接口也要設(shè)置合理的超時時間避免長時間占用連接。負載均衡與會話保持如果你的應(yīng)用是多實例部署且文件暫存于本地磁盤那么必須保證同一個文件的所有分片請求以及最終的合并請求都能被路由到同一個后端實例。這可以通過Nginx的ip_hash或基于identifier的定制化負載均衡策略來實現(xiàn)。否則A實例收到了1、2分片B實例收到了3、4分片合并請求到了C實例它找不到所有分片就會失敗。這也是為什么強烈建議將分片直接上傳到云存儲或共享存儲如MinIO的原因它能徹底解耦應(yīng)用實例和存儲。監(jiān)控與日志記錄關(guān)鍵操作日志如分片上傳開始/結(jié)束、合并開始/結(jié)束、文件校驗結(jié)果等。監(jiān)控磁盤空間、接口響應(yīng)時間、錯誤率。6.3 擴展性思考秒傳的優(yōu)化目前的秒傳是基于文件完整哈希的。對于超大文件計算哈希本身就很耗時。可以考慮使用文件頭尾哈?；虺闃庸５冉扑惴ㄟM行快速預(yù)判雖然有一定碰撞概率但在大多數(shù)場景下可以大幅提升體驗。分片大小動態(tài)調(diào)整可以根據(jù)網(wǎng)絡(luò)速度動態(tài)調(diào)整分片大小。網(wǎng)絡(luò)好時用大分片減少請求次數(shù)網(wǎng)絡(luò)差時用小分片提升容錯性。并行合并對于超大型文件合并操作本身也可能成為瓶頸。如果存儲系統(tǒng)支持如某些對象存儲的API可以探索并行合并的可能性。這套從Spring Boot到Vue 3的大文件分片上傳下載方案基本覆蓋了從零到一的核心流程和關(guān)鍵細節(jié)。在實際項目中你需要根據(jù)具體的業(yè)務(wù)需求、基礎(chǔ)設(shè)施是否用云存儲和團隊技術(shù)棧進行裁剪和增強。記住文件上傳下載看似簡單但細節(jié)決定成敗尤其是在處理海量、大體積文件時每一個環(huán)節(jié)的穩(wěn)健性都至關(guān)重要。