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