簡介一份基于 Java Web 技術(shù)的圖片管理系統(tǒng)的本科畢業(yè)設(shè)計論文面向計算機專業(yè)學(xué)生、畢業(yè)設(shè)計選題者以及 JSPMySQL 開發(fā)初學(xué)者。文檔采用 B/S 架構(gòu)以 JSP 為前端、MySQL 為后臺從課題研究的目的與意義出發(fā)完整覆蓋用戶功能需求、性能需求、系統(tǒng)功能分析、處理流程設(shè)計、系統(tǒng)用例圖、數(shù)據(jù)庫表結(jié)構(gòu)、E-R 圖與數(shù)據(jù)庫連接技術(shù)等核心內(nèi)容。針對圖片管理場景詳細設(shè)計了用戶登錄、圖像類別管理、圖像信息管理、圖片信息查詢模塊并給出數(shù)據(jù)增加、修改、刪除流程為讀者提供了可復(fù)用的畢業(yè)設(shè)計框架。壓縮包內(nèi)僅有 1 個 doc 格式文件大小 328KB內(nèi)容集中便于查閱目前已有 226 人學(xué)習(xí)/下載適合需要借鑒完整畢業(yè)設(shè)計結(jié)構(gòu)或?qū)W習(xí) Java Web 圖片管理項目開發(fā)思路的讀者。文檔還包含系統(tǒng)調(diào)試與測試、安全性問題討論和結(jié)論可幫助讀者理解從設(shè)計到實現(xiàn)的全流程具有較好的參考價值。1. 圖片管理系統(tǒng)這個Java-Web題目到底在考什么圖片管理系統(tǒng)是Java-Web方向里出現(xiàn)頻率最高的一類綜合性題目。它不只是一個上傳圖片再展示的CRUD而是把文件存儲、數(shù)據(jù)庫設(shè)計、HTTP傳輸、靜態(tài)資源映射和前端渲染全部串起來的業(yè)務(wù)系統(tǒng)。很多人接手后的第一反應(yīng)是“這不就是文件上傳嗎”做到一半才發(fā)現(xiàn)真正費時間的不是上傳接口而是圖片怎么存、路徑怎么組織、列表怎么分頁、換一臺服務(wù)器為什么全掛。這篇筆記面向兩類人正在做課設(shè)或畢設(shè)、需要把設(shè)計文檔寫成可運行系統(tǒng)的人以及小團隊里想用最低成本搭一套圖片管理后臺的開發(fā)者。我會從存儲設(shè)計一路講到上線常見的坑讓新手能跟完也讓熟手能直接拿走參數(shù)和排查思路。2. 先定存儲再寫代碼磁盤目錄、數(shù)據(jù)庫表與圖片ID的設(shè)計動手寫代碼之前先把存儲模型定下來。圖片管理系統(tǒng)最典型的翻車原因只有一個把圖片文件本身當成數(shù)據(jù)庫的BLOB字段存或者把文件路徑隨手寫在業(yè)務(wù)代碼里。圖片和普通業(yè)務(wù)數(shù)據(jù)的最大區(qū)別是體量——一條記錄幾百字節(jié)一張圖片少說幾十KB原圖可能是幾十MB。所以第一原則是文件放磁盤數(shù)據(jù)庫只放元數(shù)據(jù)。這個邊界定清楚后面所有問題都變成“路徑怎么記、文件怎么找”而不是“文件怎么進數(shù)據(jù)庫”。2.1 圖片物理存儲項目內(nèi)目錄、外部目錄與哈希目錄的取舍物理存儲方案常見做法有三種選型時主要看部署環(huán)境和圖片總量。第一種是直接存項目內(nèi)比如放在webapp/uploads/或者resources/static/uploads/。開發(fā)階段最省事但打包發(fā)布時這些目錄會被覆蓋或清空而且每次部署都要手動備份圖片屬于典型的坑。只適合純演示項目。第二種是存項目外的固定目錄比如 Linux 上的/data/picstore/或者 Windows 上的D:/picstore/。這個方案我個人最常用。部署時指定一個根目錄圖片全部落在這個根目錄里應(yīng)用重打包、換版本都不會動到圖片備份時也只需要單獨備份這個目錄。第三種是接入對象存儲把圖片扔到云上。成熟且省心但一個圖片管理系統(tǒng)如果只是內(nèi)部用引入對象存儲意味著要處理鑒權(quán)、上傳直傳、CDN 回源等一堆額外邏輯對課設(shè)和小項目來說太重了。確定根目錄之后目錄內(nèi)部怎么組織也有講究。我一般按時間分目錄比如uploads/2025/01/15/xxx.jpg因為圖片管理天然有時間維度列表頁按日期篩選時路徑本身就是索引。如果你的系統(tǒng)強調(diào)業(yè)務(wù)分類比如相冊、素材庫、合同掃描件那可以按照uploads/album/、uploads/material/來分。還有一種適合海量圖片的做法是按哈希值分目錄比如根據(jù) MD5 前兩位生成 256 個子目錄文件分布最均勻但目錄層級深人工排查不方便。三種方式的取舍可以看這張表組織方式適用場景優(yōu)點缺點按日期yyyy/MM/dd時間線、日志、通用后臺查找直觀按時間歸檔單日量大時目錄內(nèi)文件多按業(yè)務(wù)分類相冊、素材、文檔附件語義清晰權(quán)限好控制分類改動要遷移文件按哈希前綴海量圖片、上傳頻率高分布均勻單目錄壓力小可讀性差管理不直觀不管用哪種目錄結(jié)構(gòu)都只決定物理位置真正對上層業(yè)務(wù)透明的是“相對路徑 訪問 URL”。后面所有的代碼都圍繞這個相對路徑展開。2.2 圖片信息表怎么建字段、索引與建表SQL圖片元數(shù)據(jù)表的核心字段不復(fù)雜但有幾個容易漏原始文件名必須單獨存因為落盤時會被 UUID 替換掉不存原始名的話頁面展示會很丑縮略圖路徑也要存否則列表頁每次都要現(xiàn)算縮略圖文件大小用字節(jié)數(shù)存用 BIGINT 而不是 INT手機照片動輒 10MB也就 1000 萬字節(jié)INT 上限是 21 億看起來夠但存原圖的企業(yè)場景容易超。下面這套建表 SQL 是跑過多個圖片管理項目的通用版本可以直接抄。CREATE TABLE picture ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 圖片ID, original_name VARCHAR(255) NOT NULL COMMENT 原始文件名僅用于展示, storage_name VARCHAR(64) NOT NULL COMMENT 落盤文件名UUID重命名后的名字, storage_path VARCHAR(255) NOT NULL COMMENT 相對路徑如 uploads/2025/01/15/a1b2c3d4.jpg, thumb_path VARCHAR(255) DEFAULT NULL COMMENT 縮略圖相對路徑, file_url VARCHAR(255) NOT NULL COMMENT 對外訪問的相對URL, file_size BIGINT NOT NULL COMMENT 文件大小單位字節(jié), content_type VARCHAR(64) NOT NULL COMMENT MIME類型, category VARCHAR(32) NOT NULL DEFAULT default COMMENT 分類標識, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0已刪除(邏輯刪除), upload_time DATETIME NOT NULL COMMENT 上傳時間, KEY idx_category_time (category, upload_time), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT圖片元數(shù)據(jù)表;字段設(shè)計說明storage_name和storage_path分開是有意的前者是文件名后者是包含目錄的完整相對路徑這樣在做文件遷移時可以通過 SQL 直接改storage_path前綴。file_url看起來有點冗余但對前端很友好——訪問時直接拿這個字段拼img的src后端不需要再動態(tài)拼路徑。索引方面idx_category_time覆蓋了后臺最常見的“按分類 按時間倒序”查詢idx_status是為了邏輯刪除后過濾垃圾數(shù)據(jù)。圖片 ID 我建議直接用自增主鍵不要在業(yè)務(wù)層生成 UUID 當主鍵。自增主鍵在數(shù)據(jù)庫分頁場景下性能最好而且圖片 ID 經(jīng)常要出現(xiàn)在 URL 里比如/pics/12345短 ID 比 32 位 UUID 可讀性強很多。UUID 只用在文件名上它的作用是在磁盤層面避免重名和數(shù)據(jù)庫主鍵不沖突。2.3 對外URL靜態(tài)資源映射與相對路徑的拼法圖片落盤之后對外訪問要經(jīng)過一層靜態(tài)資源映射。Spring Boot 項目最常見做法是把外部目錄映射成一個/uploads/**的虛擬路徑代碼里永遠只操作相對路徑。Configuration public class WebConfig implements WebMvcConfigurer { Value(${pic.storage.root}) private String storageRoot; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/uploads/**) .addResourceLocations(file: storageRoot /); } }配置說明pic.storage.root放在application.yml里比如/data/picstore注意結(jié)尾不要帶斜杠。這里有個關(guān)鍵點——addResourceLocations的file:前綴不能丟否則 Spring 會認為你在映射 classpath 資源而不是磁盤目錄。映射后的效果是數(shù)據(jù)庫里存storage_path uploads/2025/01/15/a1b2c3d4.jpg前端直接請求/uploads/2025/01/15/a1b2c3d4.jpg就能訪問到。另外一個值得養(yǎng)成的習(xí)慣是數(shù)據(jù)庫里面永遠只存相對路徑不要存D:/picstore/uploads/...這種絕對路徑。我在實際項目里見過太多人把帶盤符的絕對路徑直接塞進庫里當時本地跑得好好的部署到 Linux 服務(wù)器全部 404一點后悔藥都沒有。相對路徑的好處是無論應(yīng)用部署在哪臺機器、什么系統(tǒng)只要pic.storage.root配對了URL 就永遠不用改。3. 上傳鏈路與縮略圖從MultipartFile到磁盤落點的完整實現(xiàn)存儲模型定好之后上傳鏈路就是整個系統(tǒng)的核心。一條完整的上傳鏈路包括前端表單接收、后端格式校驗、磁盤寫入、數(shù)據(jù)庫插入和縮略圖生成五步。任何一個環(huán)節(jié)做不干凈后面列表頁都是災(zāi)難。3.1 上傳接口MultipartFile參數(shù)、大小限制與格式白名單上傳接口用 Spring MVC 的MultipartFile接收文件同時接收一個可選的分類參數(shù)。接口本身不復(fù)雜復(fù)雜的是校驗邏輯。RestController RequestMapping(/api/pic) public class PictureController { Value(${pic.storage.root}) private String storageRoot; PostMapping(/upload) public Result upload(RequestParam(file) MultipartFile file, RequestParam(value category, defaultValue default) String category) { if (file null || file.isEmpty()) { return Result.error(文件為空); } String ext StringUtils.getFilenameExtension( file.getOriginalFilename()); SetString allowedExt Set.of(jpg, jpeg, png, gif, webp, bmp); if (ext null || !allowedExt.contains(ext.toLowerCase())) { return Result.error(不支持的圖片格式); } // 保存文件返回相對路徑 String storagePath saveFile(file, ext); // 生成縮略圖 String thumbPath createThumbnail(storagePath); Picture pic new Picture(); pic.setOriginalName(file.getOriginalFilename()); pic.setStorageName(StringUtils.getFilename(storagePath)); pic.setStoragePath(storagePath); pic.setThumbPath(thumbPath); pic.setFileUrl(/uploads/ storagePath.substring(uploads/.length())); pic.setFileSize(file.getSize()); pic.setContentType(file.getContentType()); pic.setCategory(category); pic.setUploadTime(LocalDateTime.now()); pictureMapper.insert(pic); return Result.success(pic); } }這里兩個參數(shù)需要說明。Set.of(jpg, ...)是只讀集合Java 9 以上可用老項目就用Arrays.asList再包一層HashSet。StringUtils.getFilenameExtension方法是 Spring 自帶的能正確處理photo.JPG這種帶大小寫的文件名拿到擴展名后強制toLowerCase()再比對避免用戶傳PNG但白名單里只有png導(dǎo)致誤傷。格式校驗只做后綴是不夠的后文避坑章節(jié)會講文件頭校驗這里先讓接口能跑通。3.2 服務(wù)端落盤目錄創(chuàng)建、UUID重命名與防路徑穿越落盤這一段是最容易寫崩的地方。不少人直接file.transferTo(new File(/data/picstore/ file.getOriginalFilename()))這種寫法至少有三個問題原始文件名重復(fù)會互相覆蓋、中文文件名在跨系統(tǒng)時可能亂碼、如果文件名里帶../會出現(xiàn)路徑穿越。我一般這樣寫private String saveFile(MultipartFile file, String ext) throws IOException { // 按日期生成相對目錄uploads/2025/01/15 String dateDir LocalDate.now() .format(DateTimeFormatter.ofPattern(yyyy/MM/dd)); String root storageRoot; // /data/picstore Path targetDir Paths.get(root, dateDir); // 目錄不存在時創(chuàng)建createDirectories會一次建多級 if (!Files.exists(targetDir)) { Files.createDirectories(targetDir); } // 用UUID重命名避免文件名沖突和中文亂碼 String storageName UUID.randomUUID().toString() .replace(-, ) . ext; Path targetPath targetDir.resolve(storageName); // transferTo內(nèi)部會處理輸入輸出流關(guān)閉 file.transferTo(targetPath.toFile()); return dateDir / storageName; }關(guān)鍵點有三個。第一createDirectories會遞歸創(chuàng)建多級目錄不需要自己一層層mkdir。第二UUID 文件名是 32 位十六進制串不含任何特殊字符徹底避開中文文件名和../路徑穿越問題。第三transferTo的目標路徑必須是從storageRoot解析出來的絕對路徑不能用相對路徑否則服務(wù)進程的工作目錄一變就找不到位置。數(shù)據(jù)庫里存的是2025/01/15/a1b2c3d4.jpg這種相對路徑前面我已經(jīng)說過原因。這里補一個細節(jié)storage_path字段不要包含uploads/前綴還是包含團隊內(nèi)部要統(tǒng)一。我習(xí)慣數(shù)據(jù)庫存完整的uploads/2025/01/15/a1b2c3d4.jpg這樣file_url可以直接用/storage_path拼映射配置也簡單。3.3 縮略圖生成尺寸、質(zhì)量參數(shù)與格式選擇列表頁的加載速度很大程度上取決于縮略圖有沒有做對。很多圖片管理項目不做縮略圖直接把原圖懟給前端一張手機照片 5MB列表 20 張就是 100MB頁面不卡才怪。縮略圖生成用 Thumbnailator 比較省心幾行代碼就夠private String createThumbnail(String storagePath) throws IOException { Path fullPath Paths.get(storageRoot, storagePath); String thumbName thumb_ StringUtils.getFilename(storagePath); Path thumbPath fullPath.getParent().resolve(thumbName); Thumbnails.of(fullPath.toFile()) .size(400, 400) // 寬高都限制在400px內(nèi) .keepAspectRatio(true) // 保持寬高比不裁剪 .outputFormat(jpg) // 統(tǒng)一轉(zhuǎn)成jpg .outputQuality(0.8) // 壓縮質(zhì)量 .toFile(thumbPath.toFile()); // 返回縮略圖的完整相對路徑 return storagePath _thumb.jpg; }參數(shù)調(diào)優(yōu)說明size(400, 400)配keepAspectRatio(true)的效果是“寬或高哪個超了就縮到 400”不會拉伸變形豎圖仍然保持豎圖。outputQuality(0.8)是 0 到 1 之間的壓縮質(zhì)量0.8 肉眼幾乎看不出差異但文件體積比原圖小一個數(shù)量級。outputFormat(jpg)會把 PNG、WebP 統(tǒng)一轉(zhuǎn)成 JPEG缺點是透明背景會變黑如果你的系統(tǒng)大量處理透明 PNG這里要改成保持原格式只縮尺寸不轉(zhuǎn)格式。這里有一個常見誤用有人在 JS 里用 canvas 做前端壓縮后再上傳服務(wù)端不再生成縮略圖。前端壓縮確實能減上傳流量但不能替代服務(wù)端縮略圖——因為不同前端設(shè)備、不同瀏覽器壓縮出來的質(zhì)量和尺寸不一樣服務(wù)端要保證給列表頁的圖規(guī)格統(tǒng)一必須在自己的代碼里生成。兩者不沖突可以同時做。4. 圖片列表與檢索分頁、懶加載和分類篩選的參數(shù)細節(jié)圖片列表頁是用戶真正每天都在用的東西。很多系統(tǒng)上傳做得沒問題一到列表頁就卡點下一頁也慢根源多半是分頁參數(shù)沒調(diào)對或者把原圖當成縮略圖加載。4.1 分頁查詢PageHelper參數(shù)和排序字段的選擇分頁我用 MyBatis 的 PageHelper配置和接口代碼都簡單GetMapping(/list) public Result list(RequestParam(defaultValue 1) int page, RequestParam(defaultValue 20) int size, RequestParam(required false) String category, RequestParam(required false) String keyword) { // 注意PageHelper只對緊隨其后的第一條查詢生效 PageHelper.startPage(page, size); ListPicture list pictureMapper.selectByCondition(category, keyword); PageInfoPicture pageInfo new PageInfo(list); return Result.success(pageInfo); }參數(shù)說明page從 1 開始size默認給 20圖片列表每頁 20 張是體驗和性能的平衡點——小于 10 太碎大于 50 首屏加載會變慢。PageHelper.startPage必須緊跟著查詢語句執(zhí)行中間不能插其他 SQL 操作否則分頁會作用在錯的查詢上這是 PageHelper 最典型的玄學(xué)問題。排序字段這里有個細節(jié)很多人只按upload_time desc排序但如果同一秒內(nèi)上傳多張圖排序結(jié)果不穩(wěn)定翻頁時會出現(xiàn)同一張圖重復(fù)出現(xiàn)或漏掉的詭異現(xiàn)象。我的習(xí)慣是ORDER BY upload_time DESC, id DESC用自增主鍵兜底保證同一時間點內(nèi)的順序是確定的。這個坑不容易發(fā)現(xiàn)但一旦用戶反饋“翻頁圖片重復(fù)”就能定位到它。4.2 前端列表渲染縮略圖拼接、懶加載與onerror兜底列表頁的前端渲染核心是三件事拼對縮略圖 URL、懶加載、圖片加載失敗時給占位圖。div classpic-grid img>select idselectByCondition resultTypecom.example.pic.Picture SELECT id, original_name, thumb_path, category, upload_time FROM picture WHERE status 1 if testcategory ! null and category ! AND category #{category} /if if testkeyword ! null and keyword ! AND original_name LIKE CONCAT(%, #{keyword}, %) /if if teststartTime ! null AND upload_time gt; #{startTime} /if ORDER BY upload_time DESC, id DESC LIMIT 100 /select這個 SQL 的寫法要注意兩個點。第一所有用戶輸入都通過#{}綁定參數(shù)不能用${}直接拼字符串${}拼進去就是 SQL 注入圖片管理系統(tǒng)雖然不像支付系統(tǒng)那么敏感但審計不過關(guān)也是麻煩。第二LIKE語句里的連接符要用CONCAT(%, #{keyword}, %)不要寫成%#{keyword}%后者在 MyBatis 里會被當成純字符串字面量查啥都查不到。startTime條件里之所以寫成gt;是因為 XML 里和是保留字符不轉(zhuǎn)義的話解析會報錯。LIMIT 100 是我故意加的。圖片管理系統(tǒng)很少真的讓用戶翻幾百頁最多看前幾十頁LIMIT 兜底可以防止惡意請求一次拉全表。真正的海量翻頁應(yīng)該用游標或者基于 ID 的深度分頁這個在后文進階章節(jié)提。5. 圖片管理系統(tǒng)五個必踩坑從中文文件名到物理文件清理這章寫我見過的真實踩坑記錄每條都是“現(xiàn)象 → 原因 → 解決”的結(jié)構(gòu)方便你遇到問題時直接對號入座。5.1 中文文件名上傳成功但訪問404現(xiàn)象上傳一張風(fēng)景照.jpg接口返回成功數(shù)據(jù)庫記錄也有但頁面img地址死活打不開直接訪問 URL 也是 404。原因文件名里的中文在 URL 中沒有被正確編碼。數(shù)據(jù)庫存的是uploads/2025/01/15/風(fēng)景照.jpg前端拼出的是中文路徑而瀏覽器和容器對非 ASCII 字符的轉(zhuǎn)碼處理不一致。另外原始文件名里的空格、#、?等特殊字符也會在 URL 中引起歧義。解決服務(wù)端落盤時強制換成 UUID 文件名這個前面已經(jīng)講過是根治辦法。數(shù)據(jù)庫保留original_name字段只用于img的alt屬性和搜索場景。前端展示時如果必須用原始文件名拼 URL記得encodeURIComponent編碼但這只是補丁根子上的路徑傳輸還是要靠 UUID 重命名。5.2 大圖上傳報錯Spring和Tomcat兩層大小限制現(xiàn)象上傳 20MB 的相機原圖接口直接拋MaxUploadSizeExceededException或者連請求都進不來就報 400。原因Spring MVC 和底層容器各有一層大小限制。Spring Boot 默認max-file-size只有 1MB超過就拋異常Tomcat 在 8.5 之前的版本maxPostSize默認只有 2MB表單請求超過這個值直接被容器拒絕。兩層限制任何一個沒放開大圖都傳不上來。解決在application.yml里顯式調(diào)大限制spring: servlet: multipart: enabled: true max-file-size: 20MB max-request-size: 50MB如果用了老式 Tomcat 還需要額外配置maxPostSize但 Spring Boot 內(nèi)置的 Tomcat 8.5 默認不限制這一般不是瓶頸。max-file-size是單文件上限max-request-size是單次請求所有文件的總大小做多圖上傳時兩個參數(shù)必須同時調(diào)整否則 10 張 20MB 的圖一起傳會被第二個參數(shù)卡住。5.3 絕對路徑入庫換服務(wù)器就全掛現(xiàn)象本地 Windows 開發(fā)一切正常部署到 Linux 服務(wù)器后所有歷史圖片全部 404重新上傳的圖又是好的。原因數(shù)據(jù)庫里存的是D:/picstore/uploads/...這種開發(fā)機的絕對路徑。換服務(wù)器后路徑不存在訪問當然失敗。這類問題的隱蔽性在于開發(fā)環(huán)境和生產(chǎn)環(huán)境的路徑長得完全不一樣出錯時很容易誤以為環(huán)境部署有問題排查半天才發(fā)現(xiàn)數(shù)據(jù)層存錯了東西。解決數(shù)據(jù)庫只存相對路徑這是硬規(guī)矩。部署時在配置文件中指定根目錄通過前面的addResourceHandlers映射到 URL。如果你已經(jīng)踩了這個坑寫一段一次性腳本把storage_path字段里的絕對路徑前綴批量替換成uploads/開頭即可但前提是歷史文件確實還留在服務(wù)器上。這個腳本我一般會先查一下數(shù)據(jù)再執(zhí)行-- 先看有多少臟數(shù)據(jù)再決定怎么改 SELECT COUNT(*) FROM picture WHERE storage_path LIKE D:/% OR storage_path LIKE /data/%;5.4 縮略圖未生成列表頁加載慢到崩潰現(xiàn)象上傳后列表頁能顯示但非常慢每加載一頁要十幾秒瀏覽器開發(fā)者工具里看到每張圖都是幾百 KB 到幾 MB。原因后端根本沒有生成縮略圖前端直接加載原圖。一張手機照片隨便就是 5MB20 張原圖同時加載就是 100MB 流量慢是必然的。更隱蔽的是有些系統(tǒng)只生成了縮略圖文件但列表頁接口返回的是原圖路徑等于縮略圖白做。解決上傳流程里必須生成縮略圖列表接口必須返回thumbUrl。生成時機可以選兩個上傳時同步生成簡單直接但上傳接口耗時會增加幾十毫秒或者上傳時只記錄原圖用異步任務(wù)生成縮略圖適合圖片大、上傳頻率高的場景。我建議第一階段同步生成等并發(fā)上來了再改異步。縮略圖尺寸統(tǒng)一為 400px 寬高以內(nèi)質(zhì)量 0.8這樣單張縮略圖體積控制在 20KB 到 50KB列表頁再快都不成問題。5.5 物理文件與數(shù)據(jù)庫不一致刪了文件但列表還在現(xiàn)象刪除圖片后列表里偶爾還看得到這張圖或者反過來數(shù)據(jù)庫中已經(jīng)沒有記錄但磁盤文件還在占著空間。原因刪除操作的代碼寫成了“先刪數(shù)據(jù)庫記錄再刪物理文件”如果第二步拋異常比如文件被占用、權(quán)限不足數(shù)據(jù)記錄已經(jīng)沒了物理文件成了孤兒頁面請求找不到記錄自然顯示異常。另一種情況是先刪物理文件后刪數(shù)據(jù)庫數(shù)據(jù)庫刪除失敗記錄殘留就成了“死鏈”。解決刪除操作拆成兩步走。第一步把status置為 0做邏輯刪除列表查詢默認過濾status1第二步異步清理物理文件清理失敗記錄到一張clean_task表里后臺定時任務(wù)重試。這樣即使文件刪不掉也不影響頁面正常顯示數(shù)據(jù)刪不掉也只是多占一行記錄文件還在不會有死鏈。同時物理文件刪除前要再查一次數(shù)據(jù)庫確認沒有其他記錄指向同一個文件路徑避免一張圖被多條記錄引用時誤刪。6. 把系統(tǒng)做成能上線的樣子內(nèi)容校驗、并發(fā)控制與存儲擴展前面幾章解決的是“能跑”最后一章聊怎么變成“能扛住真實使用”。三個方向每個都不復(fù)雜但能顯著提升系統(tǒng)的可用性。先說內(nèi)容校驗。后綴白名單只能擋住半吊子攻擊者真正要做的是文件內(nèi)容校驗。圖片文件頭有固定的魔術(shù)數(shù)字JPEG 開頭是FF D8 FFPNG 開頭是89 50 4E 47GIF 是47 49 46 38。上傳時讀文件頭幾個字節(jié)跟白名單比對能有效攔截“改后綴的 HTML 文件”這類偽裝上傳。校驗代碼很簡單byte[] header new byte[4]; try (InputStream in file.getInputStream()) { in.read(header, 0, 4); } boolean isJpeg (header[0] 0xFF) 0xFF (header[1] 0xFF) 0xD8; boolean isPng (header[0] 0xFF) 0x89 (header[1] 0xFF) 0x50 (header[2] 0xFF) 0x4E;再說并發(fā)控制?？s略圖生成這一步比較吃 CPU如果上傳量突然上來幾十個請求同時跑縮略圖服務(wù)器容易被打懵。簡單做法是給縮略圖生成加一個線程池限制并發(fā)數(shù)比如 4 個線程其余任務(wù)排隊。圖片管理系統(tǒng)的并發(fā)上限通常不在數(shù)據(jù)庫而在磁盤 IO控制住縮略圖生成并發(fā)就等于控制住了最重的 IO 壓力。最后是存儲擴展。前文所有代碼都直接操作本地文件路徑如果哪天要把存儲換成對象存儲改動會很大。所以我會在項目里定義一個FileStorage接口本地實現(xiàn)類做磁盤讀寫云存儲實現(xiàn)類做桶操作。數(shù)據(jù)庫里存的相對路徑不變只是saveFile和deleteFile方法內(nèi)部實現(xiàn)不同。切換時只需要改一個Qualifier注解前端完全無感。我最早做圖片管理系統(tǒng)時把物理路徑直接塞進數(shù)據(jù)庫換了一次服務(wù)器全部 404從那以后我給自己定了條規(guī)矩數(shù)據(jù)庫里永遠只存相對路徑和 URL物理根目錄寫進配置文件文件操作全部走接口。這套習(xí)慣后來幫我避開了很多坑。做這個方向先把存儲想明白后面的路就會順很多希望幫到你。本文還有配套的精品資源點擊獲取