最近做了一套基于Spring Boot的網(wǎng)盤類管理系統(tǒng)核心功能就是個人云盤。像這種Spring Boot 前端JS的Title其實是很典型的Java Web練手項目網(wǎng)上也有各種各樣的教程但絕大多數(shù)都是跑通就完事真正像工程一樣考慮細節(jié)的很少。這篇文章就按我實際開發(fā)這套個人云盤管理系統(tǒng)的經(jīng)驗把這個題目的技術架構、數(shù)據(jù)庫、核心功能、中間踩的坑從頭梳理一遍給想拿這個題目做畢業(yè)設計或者練手的同學一個可以直接照抄的參考。整個系統(tǒng)功能覆蓋得很完整用戶注冊登錄、文件上傳下載、文件夾管理、分享鏈接、回收站恢復、圖片和文本在線預覽。別看這些功能聽起來簡單真正做起來文件目錄層級、分片上傳、邏輯刪除、權限校驗這些模塊單獨拎出來都能寫很多文章。所以我這里會把重點放在整體設計和最容易踩坑的實現(xiàn)細節(jié)上而不是貼幾百行代碼充數(shù)。1. 項目整體設計與技術選型思路1.1 核心需求拆解個人云盤聽起來簡單但真正拆開需求以后會發(fā)現(xiàn)很多東西如果不提前理清楚開發(fā)到后面很容易自己把自己繞暈。我把需求分成四塊。第一塊是用戶相關。登錄、注冊、退出、獲取當前登錄用戶信息。這個系統(tǒng)定位是個人云盤所以權限模型不需要做多角色只要認準當前登錄的用戶是誰就行。所有文件數(shù)據(jù)都歸屬于某個用戶IDA用戶看不到B用戶的文件。第二塊是文件管理。這是核心中的核心包括上傳文件、下載文件、新建文件夾、重命名、刪除、移動、文件列表展示、回收站恢復。其中文件列表的樹形展示或者叫目錄結構是很多新手容易卡住的地方。因為文件系統(tǒng)是有層級關系的不是平鋪的列表。第三塊是分享功能。文件可以生成一個分享鏈接加上提取碼發(fā)給別人對方在瀏覽器里打開鏈接輸入提取碼后能看到文件詳情或者直接下載文件。分享鏈接有過期時間過期后自動失效。第四塊是其他輔助功能比如文件圖標展示、圖片預覽、文本預覽、磁盤使用情況統(tǒng)計之類的。這屬于加分項但實際開發(fā)時也要考慮進去因為頁面展示的時候得根據(jù)文件類型做不同的標識。需求拆解完以后最好不要急著寫代碼先設計一下數(shù)據(jù)表。數(shù)據(jù)表設計得好后面編碼會很順暢數(shù)據(jù)表設計得有問題后面會不斷返工。所以我把數(shù)據(jù)庫設計放在開發(fā)之前一步。1.2 為什么選Spring Boot 前端JS這個技術組合在畢業(yè)設計和各類實戰(zhàn)項目里出現(xiàn)頻率非常高。后端用Spring Boot核心原因在于它把Spring家族的配置簡化到了不需要XML的程度內(nèi)嵌Tomcat容器一個main方法就能啟動服務。相比傳統(tǒng)的SSHSpring Struts Hibernate或者SSMSpring Spring MVC MyBatis方案省去大量配置時間讓開發(fā)者能把精力集中在業(yè)務邏輯上。另外Spring Boot有非常成熟的生態(tài)后面我們用到Web上傳、攔截器、配置文件多環(huán)境切換都有現(xiàn)成方案。前端選擇JavaScript方向具體我用了Vue框架加Element UI組件庫。Vue的寫法比原生JS更清晰數(shù)據(jù)驅動視圖文件列表、上傳彈窗這些交互用組件化開發(fā)會舒服很多。當然如果說題目里只寫了基于JS用原生JS照樣可以做只是開發(fā)速度慢一些。我的建議是如果自己有Vue基礎就用Vue如果完全不會框架用原生JS配合jQuery也能完成只要確保和后端交互是標準HTTP接口即可。前后端分離以后開發(fā)的時候啟動兩個服務前端開發(fā)服務器和后端Java進程。遇到跨域問題不要怕后面我會專門講CORS怎么配。重要的是不要在前端JS里寫死絕對路徑所有環(huán)境相關配置放到全局配置里統(tǒng)一管理。1.3 系統(tǒng)架構設計整個系統(tǒng)的架構并不復雜思路如下。前端頁面通過瀏覽器發(fā)起HTTP請求請求走到后端的Controller層。Controller負責接收參數(shù)、校驗參數(shù)、調用Service再返回統(tǒng)一格式的JSON給前端。Service層處理具體業(yè)務邏輯比如文件上傳時判斷大小、生成存儲路徑、更新數(shù)據(jù)庫記錄。數(shù)據(jù)訪問用MyBatis Plus內(nèi)置的BaseMapper常規(guī)的增刪改查不需要手寫SQL只有遞歸查詢目錄、多表統(tǒng)計這種特殊場景需要自定義XML。工程內(nèi)的包結構大概是controller控制層service業(yè)務層mapper數(shù)據(jù)訪問層entity數(shù)據(jù)庫實體dto前端出入?yún)⒎庋bconfig配置類utils工具類另外為了統(tǒng)一返回消息我寫了一個單獨的結果封裝類比如返回碼200表示成功500表示業(yè)務異常。所有Controller接口都返回這個封裝前端根據(jù)返回碼統(tǒng)一處理錯誤提示這樣不需要每個接口單獨寫異常邏輯。提示前期架構可以簡單但結果封裝和異常處理務必要統(tǒng)一。前期偷懶只返回裸數(shù)據(jù)后期加了復雜頁面之后前端會被各種非標準返回搞得焦頭爛額。2. 數(shù)據(jù)庫設計與核心表結構2.1 用戶表設計用戶表我用了這張結構字段名id、username、password、nickname、avatar、create_time、status。id是自增主鍵。username要加唯一索引避免注冊時重名。password存BCrypt加密后的密文絕對禁止明文。avatar可以先存一個字符串路徑指向服務器上的頭像圖片鏈接也可以不做頭像功能完全省掉。status用于禁用賬戶1表示正常0表示禁用。注冊接口的邏輯很簡單先檢查用戶名是否已存在存在則提示用戶名已被注冊不存在則用BCrypt工具類加密密碼寫入。登錄接口查詢用戶名和密碼匹配匹配成功生成JWT令牌返回給前端。這里要注意用戶密碼的密文長度一般60位在數(shù)據(jù)庫里字段長度不要建短了我遇到過有人把密碼字段設置成varchar(32)結果BCrypt密文根本存不下。2.2 文件信息表設計文件表是整個系統(tǒng)的核心字段比較多。我用的核心字段是id文件IDfile_name文件名file_size文件大小單位字節(jié)file_type文件類型比如image/png、application/pdffile_path存儲的相對路徑不含根目錄前綴user_id所屬用戶IDparent_id父目錄ID0表示根目錄folder_flag是否文件夾1是0否del_flag邏輯刪除標記0正常1已刪除create_time創(chuàng)建時間update_time更新時間這里有一個關鍵點很多初學者喜歡把文件的實際存儲路徑直接存一個絕對路徑比如C:\server\data\user1\abc.txt。這個在本地跑沒問題但是部署到服務器上服務器環(huán)境和本地不一致很可能路徑就失效了。正確做法是存相對路徑比如user/1/2025/03/abc.txt在啟動配置里設置一個根目錄結合起來才是完整物理路徑。我做的系統(tǒng)就是上傳后先根據(jù)用戶ID生成一個目錄用戶ID然后把文件寫到根目錄下的用戶ID目錄里數(shù)據(jù)庫中只存用戶ID/文件名的相對路徑。第二個關鍵點是文件夾本身也要在文件表里占一條記錄。folder_flag1表示這條記錄是一個文件夾記錄沒有實際物理文件file_path可以為空但有parent_id用于確定歸屬。這樣文件夾樹和管理操作全都是同一張表不需要額外的目錄表。2.3 分享表設計分享功能只需要一張表。字段包括id分享IDshare_token隨機生成的短鏈接標志用UUID去掉橫線的形式user_id分享者IDfile_id被分享的文件IDextract_code提取碼4到6位隨機數(shù)字expire_time過期時間status狀態(tài)1有效0失效每次生成分享時后端生成share_token和extract_code把文件ID和分享者ID寫進去。其他用戶訪問分享鏈接時后端通過share_token拿到分享記錄判斷是否過期。然后前端頁面上輸入提取碼比對成功后返回文件信息文件信息如果是文件夾則返回該文件夾下的文件列表如果是一個普通文件則可以直接觸發(fā)下載。這里要注意分享文件夾的場景在提取碼校驗通過后訪問文件夾下的子文件時還需要校驗子文件的歸屬是否確實在這個分享文件夾下不然容易被越權訪問。2.4 回收站與邏輯刪除設計回收站我不建議單獨建表原因很簡單文件表已經(jīng)足夠承載這個邏輯了。在文件表里加一個del_flag字段刪除文件時只是把del_flag改成1同時更新時間置為當前時間。回收站頁面查詢時條件加上del_flag1就能把刪除過的文件撈出來。點擊恢復時把del_flag改回0同時可能需要檢查父ID是否還存在防止父目錄已經(jīng)被徹底刪除導致無法掛載。徹底刪除時才真正刪除數(shù)據(jù)庫記錄并調用文件工具類刪除物理文件。這個邏輯對比單獨建回收站表要清爽很多也便于后面加回收站保留天數(shù)這樣的擴展需求。注意邏輯刪除容易出現(xiàn)的一個坑是查詢文件列表時忘了加del_flag0條件導致回收站里的文件出現(xiàn)在正常列表里。如果使用MyBatis Plus可以給文件表實體加TableLogic注解做全局邏輯刪除這樣內(nèi)置的selectList方法會自動追加del_flag0條件省心很多。3. 核心功能模塊的實現(xiàn)細節(jié)3.1 用戶認證與JWT權限控制登錄認證這塊我選擇了JWT。原因是項目一旦前后端分離服務端如果還用Session就會面臨跨域共享Session、跨服務部署Session不一致的問題。JWT的思路是登錄成功后把用戶ID和過期時間聲明進一個加密的Token前端保存Token之后每個請求在Header里帶上。后端寫一個攔截器統(tǒng)一解析效率高也不需要額外的Redis存儲。JWT工具類我封裝了兩個方法一個是生成Token一個是解析Token。生成Token時把用戶ID作為claim放進去同時設置過期時間為24小時。攔截器在每個請求里讀取Header的Authorization字段去掉Bearer前綴后解析。如果解析成功就把用戶ID放入ThreadLocal如果解析失敗則返回401錯誤。登錄注冊等少數(shù)公開接口需要放行。攔截器注冊的時候要特別注意放行順序。比如用Spring Boot的注冊方式攔截器對所有路徑生效需要在addPathPatterns時設置放行路徑列表。我在實際開發(fā)中就把文件下載接口忘記放行結果前端跳轉瀏覽器的下載鏈接全部被攔截排查了很久才發(fā)現(xiàn)問題是攔截器把所有下載請求攔截了不僅沒有返回文件流還返回了JSON錯誤瀏覽器直接下載了一個json錯誤文件。這個經(jīng)驗值得記住。3.2 文件上傳與分片秒傳實現(xiàn)文件上傳是最容易出問題的模塊。常規(guī)上傳后端接口就是接收MultipartFile參數(shù)獲取文件名和大小然后把文件寫到磁盤上再保存一條記錄到數(shù)據(jù)庫。但真實業(yè)務里大文件上傳如果不做處理用戶傳幾個GB的文件基本必失敗不是連接超時就是內(nèi)存溢出。我的方案是分片上傳。前端把文件切片每片大小5MB然后循環(huán)調用上傳接口上傳接口接收文件分片以及一個分片編號還有一個上傳ID用來標識同一個文件的分片集合。每個分片作為臨時文件存到臨時目錄全部上傳完成后前端調用合并接口后端把所有分片按編號拼接成一個完整文件。這樣即使傳到一半網(wǎng)絡斷了也能重新上傳未完成的分片而不需要重頭再傳。這里核心代碼如下Controller接收分片時用到MultipartFile和RequestParamPostMapping(/upload/chunk) public Result uploadChunk(RequestParam(file) MultipartFile file, RequestParam(uploadId) String uploadId, RequestParam(chunkIndex) int chunkIndex) { String tempDir storageConfig.getRootPath() /tmp/ uploadId; File dir new File(tempDir); if (!dir.exists()) dir.mkdirs(); file.transferTo(new File(dir, String.valueOf(chunkIndex))); return Result.ok(); }秒傳功能就是另一個思路了。上傳前前端用JavaScript讀取文件的MD5值調用后端接口查詢該文件是否已經(jīng)存在于共用文件庫中。如果存在直接給當前用戶生成一條文件記錄不再寫入實際文件。我做的個人云盤系統(tǒng)里沒有做全局去重庫但可以先在用戶自己的文件目錄里查詢?nèi)绻琈D5文件已存在則直接建立引用關系避免重復存儲。實際開發(fā)時推薦加一個獨立的文件指紋表字段包括MD5、文件大小、物理路徑、被引用次數(shù)這樣才能支撐真正的秒傳。分片上傳的合并操作要小心不要把所有分片內(nèi)容一次性讀入內(nèi)存應該用InputStream循環(huán)讀取每個分片文件然后按順序寫入OutputStream。合并完成之后再刪除臨時分片文件。這個過程中還要注意處理并發(fā)上傳同一個上傳ID的情況避免合并時文件被占用。3.3 文件下載與在線預覽文件下載接口的核心是返回文件流。我用了Spring的ResponseEntity 讀取文件為Resource設置Content-Type和Content-Disposition。這里的坑主要在中英文文件名。中文文件名如果直接放到Content-Disposition里不同瀏覽器展示效果不一樣最穩(wěn)妥的做法是用URLEncoder編碼然后前端或者瀏覽器會自動解碼。另外自己拼接HTTP響應頭時要注意header不能包含換行符否則會在安全掃描中被判為注入漏洞。在線預覽的話圖片和文本最簡單。圖片直接通過接口返回原始二進制前端用一個組件接收blob流來展示。文本文件讀取時要注意編碼UTF-8文件正常GBK文件會出現(xiàn)亂碼。我的處理方式是先通過工具讀取文件的前幾百個字節(jié)嘗試判斷編碼然后按對應編碼讀取內(nèi)容再轉成UTF-8返回給前端。這樣預覽體驗會好很多。PDF和Office文件預覽要復雜一些需要第三方組件轉碼或者使用在線預覽服務依賴環(huán)境我在畢設項目中就沒有做復雜的在線編輯只展示了圖片、文本、視頻音頻這幾種常見的。3.4 文件管理接口設計文件管理包括根目錄列表、進入子目錄、新建文件夾、重命名、移動文件、刪除文件。接口設計其實都圍繞文件表。根目錄列表就是查詢user_id當前用戶ID AND parent_id0 AND del_flag0的所有文件。進入子目錄就是查詢parent_id某個ID的文件列表。新建文件夾就插入一條folder_flag1的記錄。重命名很簡單直接更新file_name字段。移動文件就是修改parent_id。刪除文件則是邏輯刪除。文件夾的刪除是特殊的因為它是遞歸結構。后端刪除文件夾時不能只刪當前記錄需要先把文件夾下所有子文件找出來。我的處理辦法是用一個遞歸方法先查詢當前文件夾的所有直接子節(jié)點對每個子節(jié)點如果是文件夾則遞歸調用如果是文件則刪除當前記錄最后再刪除當前文件夾記錄。在邏輯刪除模式下也可以只刪除當前文件夾記錄然后讓子文件的信息在文件夾樹中懸掛但這種狀態(tài)恢復時很容易出錯還是老老實實遞歸處理。前端展示文件樹時我建議不要一次性把所有層級的文件夾全部查出來?？梢园葱杓虞d點擊文件夾時請求一次子文件接口。這樣接口簡單數(shù)據(jù)量也小。如果確實需要展示整棵樹那就后端遞歸組裝樹形JSON前端用Vue的遞歸組件渲染。3.5 分享鏈接生成與回收站邏輯分享鏈接我在實現(xiàn)時用了兩個隨機值。一個是share_token作為鏈接的唯一標識直接放在URL里另一個是extract_code作為輸入提取碼用戶訪問分享頁面時必須輸入。分享者可以選擇分享有效天數(shù)比如1天、7天、永久。對應后端記錄過期時間。校驗時先比對share_token是否存在然后比對提取碼最后判斷是否過期。分享鏈接的生成邏輯很簡單核心就是創(chuàng)建一條分享記錄public Share createShare(Long userId, Long fileId, Integer expireDays) { Share share new Share(); share.setUserId(userId); share.setFileId(fileId); share.setShareToken(UUID.randomUUID().toString().replace(-, )); share.setExtractCode(RandomUtil.randomNumbers(4)); if (expireDays ! null expireDays 0) { share.setExpireTime(LocalDateTime.now().plusDays(expireDays)); } share.setStatus(1); shareMapper.insert(share); return share; }回收站邏輯我在文件表里用del_flag實現(xiàn)文件表里有一個delete_time字段方便定時清理超過保留期的記錄。回收站頁面復用文件列表接口只不過查詢條件換成了del_flag1并且按刪除時間倒序?；謴筒僮骱蛣h除正好相反將del_flag重置為0。徹底刪除時后臺會同時調用物理文件刪除方法。如果文件在多個地方被引用比如秒傳引用物理文件刪除還需要處理引用計數(shù)不能直接刪否則可能導致其他用戶文件缺失。我的系統(tǒng)沒有做跨用戶引用所以沒有這個顧慮但做擴展時要注意。4. 實操過程中的關鍵配置與調試4.1 核心依賴與配置文件這個項目的pom.xml里依賴不需要很多主要包括spring-boot-starter-web、spring-boot-starter-validation、mybatis-plus-boot-starter、mysql-connector-java、jjwt、hutool-all、lombok。hutool這個工具包幫了很大忙生成隨機數(shù)、計算文件MD5、日期工具都用它省下大量重復代碼。application.yml這里沒有特別難的東西但有幾個配置容易出錯。第一個是數(shù)據(jù)源url數(shù)據(jù)庫名要和本地建的一致時區(qū)必須加serverTimezoneAsia/Shanghai否則JDBC連接會報時區(qū)異常。第二個是MyBatis Plus的mapper-locations配置如果XML文件沒放到默認classpath下需要手動指定。第三個是文件上傳大小我設置了max-file-size: 512MBmax-request-size: 1GB。第四個是自定義存儲路徑Spring Boot里使用ConfigurationProperties讀取比如cloud.storage.root-path: ./data。這里的相對路徑要小心啟動時的工作目錄不同會指向不同位置建議部署時使用絕對路徑。我貼上最核心的配置片段可以直接改用自己的spring: servlet: multipart: max-file-size: 512MB max-request-size: 1GB datasource: url: jdbc:mysql://localhost:3306/cloud_disk?serverTimezoneAsia/Shanghai username: root password: 123456 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl cloud: storage: root-path: ./data4.2 CORS跨域問題前后端分離后跨域問題基本是必踩的。如果前端項目跑在http://localhost:8080后端接口在http://localhost:8081這時候前端直接調后端接口瀏覽器就會因為跨域攔截。解決方式是在后端寫一個配置類實現(xiàn)WebMvcConfigurer在addCorsMappings方法里配置允許的源、方法、請求頭。我當時的經(jīng)驗是允許源可以直接用allowedOriginPatterns(*)開發(fā)環(huán)境這么配最省事。allowedHeaders需要把Authorization放進去否則帶了Token的請求會被瀏覽器預檢攔下來。配置類寫起來也不復雜直接貼出來Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }另外如果自己實現(xiàn)了攔截器跨域配置和攔截器之間還有順序問題。前端的預檢請求是OPTIONS方法攔截器如果攔了OPTIONS請求就會導致預檢失敗。解決辦法是在攔截器里面判斷請求方法如果為OPTIONS則直接放行。4.3 上傳大小限制的完整配置Spring Boot對文件上傳的限制來自兩個地方。一是Spring MVC的配置spring.servlet.multipart.max-file-size和max-request-size默認只有1MB和10MB不修改的話傳大文件馬上報FileSizeLimitExceededException。二是Tomcat服務器本身的連接器限制如果超過這個限制可能返回Connection reset前端看起來像是連接被服務器斷開。我在做分片上傳時因為每一片只有幾MB主要是把分片大小調好整體上傳接口的max-file-size還不能設太小否則即使分片沒超過限制后端臨時文件處理也可能不被允許。綜合下來我直接把單文件上傳限制改成512MB請求總大小改成1GB基本能滿足大多數(shù)使用場景。這里補充一個容易忽略的知識點Spring Boot 2.x以上版本中如果使用了自定義的MultipartConfigElement配置類它的優(yōu)先級會覆蓋配置文件中的spring.servlet.multipart配置。我建議不要同時用兩種配置只保留yml配置就好否則出了問題排查時會很困惑。4.4 日志配置與接口調試調試階段強烈建議把日志級別調到DEBUG至少在開發(fā)環(huán)境要調。MyBatis Plus會在控制臺打印SQL日志你可以看到執(zhí)行的每條SQL對于排查數(shù)據(jù)有沒有查對很有幫助。另外可以開啟Spring Boot的web日志查看請求和響應的基本狀態(tài)。我習慣把項目里所有Controller接口的出入?yún)⒃贏OP里打一條日志打印請求地址、請求參數(shù)、耗時這個做法在聯(lián)調時省了無數(shù)口舌。前端調試我推薦用瀏覽器開發(fā)者工具配合Postman。遇到上傳類接口異常先看請求體里file字段名稱和后端MultipartFile參數(shù)名是否一致不一致的話后端拿到的file就是null。遇到下載接口異常直接用Postman請求下載地址看返回的Content-Type和Content-Disposition是不是正確。如果返回的是JSON錯誤則說明請求被攔截器或者異常處理接管了。5. 常見問題與避坑指南5.1 中文文件名亂碼問題這個幾乎是所有網(wǎng)盤類項目都會碰上的問題。表現(xiàn)是前端上傳中文文件后端保存到磁盤后文件名變成亂碼下載時設置的文件名也是亂碼。原因有兩層一是HTTP傳輸時編碼不是UTF-8二是Content-Disposition頭里不能直接放中文。解決辦法是前端在FormData里正常傳文件名后端獲取文件名后到輸出響應時用URLEncoder.encode(fileName, UTF-8)重新編碼。如果保存到磁盤的文件名亂碼檢查一下服務器操作系統(tǒng)字符集和Tomcat的URIEncoding配置通常設成UTF-8就能解決。我寫下載接口的時候對響應頭做了一定處理關鍵在于文件名要編碼而不是直接拼接String encodedFileName URLEncoder.encode(fileName, UTF-8); response.setHeader(Content-Disposition, attachment; filename\ encodedFileName \);5.2 跨域配置正確但請求依然失敗遇到過一次很迷惑的問題跨域配置看起來沒問題但前端帶Authorization的請求依然失敗。后來發(fā)現(xiàn)是攔截器把OPTIONS預檢請求攔了。瀏覽器在發(fā)起復雜請求時會先發(fā)一個OPTIONS請求如果后端返回的不是成功響應真實請求就不會發(fā)出。解決辦法很簡單攔截器里對OPTIONS請求直接返回成功。這個坑我之前提過一次但值得再強調因為排查時很容易忽略攔截器的存在。5.3 文件路徑與部署環(huán)境不兼容本地寫的是絕對路徑比如某個盤符下的目錄部署到Linux服務器上直接找不到路徑。這是因為操作系統(tǒng)的路徑分隔符和磁盤掛載方式完全不同。規(guī)范做法是數(shù)據(jù)庫存相對路徑根目錄通過配置文件指定。我在制作這個系統(tǒng)時就把存儲根目錄放到配置文件里所有物理文件寫入時獲取根目錄再拼相對路徑這樣換機器只需要改一個配置項。另外在Java里拼接文件路徑時不要手寫斜杠統(tǒng)一用Paths.get或者File.separator否則在不同操作系統(tǒng)上會出現(xiàn)斜杠方向不一致的問題。5.4 回收站恢復后文件夾結構錯亂恢復一個處于回收站的文件夾時如果原本的父目錄已經(jīng)被徹底刪除了會出現(xiàn)一條記錄指向一個不存在的父目錄。前端打開這個文件夾就會查不到數(shù)據(jù)。解決辦法是恢復時先檢查父目錄是否存在如果不存在則把parent_id置為0也就是回到用戶根目錄。順帶還要檢查重命名沖突如果目標位置已經(jīng)有同名文件恢復時自動在文件名后面加一個后綴。5.5 文件流下載時無法終止連接下載大文件時如果用戶點擊了取消后端的輸出流可能還在寫入最終導致鏈路占用很久。如果并發(fā)下載的人多連接數(shù)會飆升。我給下載接口的ResponseEntity設置緩沖區(qū)并且前端取消時瀏覽器會關閉連接后端需要在寫入時處理IOException遇到異常就及時退出循環(huán)不要繼續(xù)寫。另外可以考慮用Servlet的異步輸出做高并發(fā)優(yōu)化但這個系統(tǒng)作為個人云盤并發(fā)量很小不用過度設計。這套個人云盤管理系統(tǒng)做下來我個人體感最難的其實不是寫代碼而是把文件操作的邏輯想清楚尤其是目錄層級、回收站、分享這些和“文件關系”相關的功能。一旦數(shù)據(jù)表設計合理后端的每個接口都很直白如果一開始就草草建表后面補字段、改邏輯會非常痛苦。最后分享一個實用小技巧在開發(fā)時可以提前在本地準備一些不同類型的測試文件比如大文件、圖片、中文文件名、無擴展名文件上傳下載和預覽每個環(huán)節(jié)都測一遍很多問題是在這些邊界文件上會暴露出來。希望這篇文章能幫到準備做類似項目的朋友。