簡介面向Java Web初學者和SSM開發(fā)者這份資源完整演示了SpringSpringMvcMybatis框架下圖片上傳、入庫與回顯的落地流程。項目從Controller接收MultipartFile、本地文件存儲、Mybatis Mapper寫入圖片元數(shù)據(jù)到前端用img標簽動態(tài)展示形成一套可直接復用的閉環(huán)實現(xiàn)并附cet.sql建表腳本方便快速初始化環(huán)境。壓縮包共120個文件、約17.5MB以53個jar依賴、18個xml配置、13個java源碼和11個jsp頁面為主同時包含class編譯文件、properties配置和sql腳本基本覆蓋SSM項目運行所需。已有5471人學習下載。資源還兼顧了文件類型校驗、路徑安全等防惡意上傳細節(jié)對理解文件上傳完整鏈路、積累實戰(zhàn)排錯經(jīng)驗都很有價值。1. SSM(SpringSpringMvcMybatis)圖片上傳保存到數(shù)據(jù)庫與回顯sql這個項目到底在驗證什么能力SSM(SpringSpringMvcMybatis)圖片上傳保存到數(shù)據(jù)庫與回顯sql聽起來是爛大街的課程設計但它真正考驗的東西一點都不過時一張圖片從瀏覽器出發(fā)進入 SpringMvc 的 Controller被封裝成 MultipartFile經(jīng)過 MyBatis 的 INSERT 落成數(shù)據(jù)庫里一行 LONGBLOB再通過一條 SELECT 把二進制撈回來最終渲染成頁面上的一個 img 標簽。這條鏈路里任何一環(huán)沒接好你看到的就是“上傳成功但圖不顯示”這種詭異現(xiàn)象而問題往往不在瀏覽器而在后端的 Content-Type、MyBatis 的 jdbcType甚至是 form 表單漏了一個 enctype。如果你是第一次接觸 SSM 的開發(fā)者這個標題值得完整做一遍它能把分層、參數(shù)綁定、事務邊界一次講透如果你在帶新人或做內(nèi)部小系統(tǒng)這條鏈路也可以當作快速驗證團隊基礎能力的入門題。生產(chǎn)環(huán)境里我們通常不會把圖片二進制塞進數(shù)據(jù)庫但搞清楚它為什么不行、什么規(guī)模下又能用才是做這個項目的真正收獲。2. 建表 SQL 與依賴準備先定圖片在數(shù)據(jù)庫里的形態(tài)再寫上傳代碼動手寫代碼之前有兩個決定會影響后續(xù)所有實現(xiàn)圖片內(nèi)容以什么形式入庫以及 SpringMvc 用哪個解析器接管文件上傳。這兩個問題都在“寫第一行 Controller 之前”就該定下來否則后面會反復改表結構、改 Mapper、改回顯方式改到懷疑人生。2.1 選型對照LONGBLOB 存二進制還是 MEDIUMTEXT 存 Base64圖片存數(shù)據(jù)庫常見做法就兩條路直接把二進制字節(jié)塞進 LONGBLOB 字段或者把圖片轉成 Base64 字符串存進 TEXT/MEDIUMTEXT 字段。兩條路都能實現(xiàn)“保存到數(shù)據(jù)庫與回顯”但后續(xù)的 SQL、Mapper、回顯代碼完全不同。存儲方案數(shù)據(jù)庫字段類型回顯方式體積開銷適用場景byte[] 二進制LONGBLOBController 動態(tài)輸出圖片流img 的 src 指向圖片接口與原圖體積一致課程設計、內(nèi)部系統(tǒng)、需要保留原始文件信息Base64 文本MEDIUMTEXT接口返回 data:image/jpeg;base64,xxximg 的 src 直接寫這一串比原圖多約三分之一小圖片、接口直接吐 JSON、不想額外寫一個流式接口我一般會優(yōu)先選 LONGBLOB 方案。原因有三個第一它不增加額外編碼開銷Base64 會把每 3 個字節(jié)變成 4 個字符數(shù)據(jù)庫膨脹 33%圖片只要上 1MB這 1MB 的字符串傳輸和序列化都會拖慢接口第二LONGBLOB 方案里圖片類型、文件名、大小都能作為獨立字段保存回顯時能精確控制 Content-Type第三課程設計和面試演示里面試官想看的往往就是“二進制怎么進庫、怎么出庫”LONGBLOB 這條鏈路更完整。Base64 方案也有它的價值后面回顯章節(jié)我會單獨演示但主鏈路按 LONGBLOB 走。2.2 建表 SQLt_image 表結構與兩個容易被忽略的字段選定 LONGBLOB 后表結構就圍繞“圖片本身 圖片元信息”來設計。下面是這個項目完整可執(zhí)行的建表腳本我通常會把建庫語句也放進去方便在本地 MySQL 里一鍵初始化。CREATE DATABASE IF NOT EXISTS ssm_image_demo DEFAULT CHARACTER SET utf8mb4; USE ssm_image_demo; CREATE TABLE t_image ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 主鍵, image_name VARCHAR(100) NOT NULL COMMENT 上傳時的原始文件名, image_data LONGBLOB NOT NULL COMMENT 圖片的二進制內(nèi)容, image_type VARCHAR(50) NOT NULL COMMENT MIME類型例如image/jpeg、image/png, image_size INT NOT NULL COMMENT 圖片字節(jié)數(shù), create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 上傳時間 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT圖片上傳演示表;這段 SQL 里有三個點容易被新手跳過。第一image_type 不是可有可無回顯時要用它來設置 HTTP 響應頭里的 Content-Type存成 image/jpeg 還是 image/png 直接決定瀏覽器把響應當圖片渲染還是當亂碼下載寫死成 image/jpeg 會在傳 PNG 時翻車。第二image_data 用 LONGBLOB 而不是 BLOBBLOB 最大只有 64KB手機拍一張照片就超了LONGBLOB 上限 4GB課程設計場景下足夠。第三image_size 雖然技術上可以不算但列表頁展示、后續(xù)做圖片體積校驗都靠它省掉以后再補就是一次表結構變更。如果堅持走 Base64 方案只需要把 image_data 的字段類型從 LONGBLOB 換成 MEDIUMTEXT其余字段保持不變Mapper 里的 jdbcType 也要同步調(diào)整這個差異在下一章會專門說明。2.3 Maven 依賴與 MultipartResolver 配置版本組合和一個不能改名的 Bean圖片上傳要能工作SpringMvc 必須知道“誰來解析 multipart 請求”。在 SSM 項目里最經(jīng)典、踩坑最少的組合是 commons-fileupload 配合 CommonsMultipartResolver。先看 pom 里需要哪些依賴dependencies !-- Spring 全家桶 -- dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version5.3.x/version /dependency !-- MyBatis 與 Spring 整合 -- dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version3.5.x/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version2.x/version /dependency !-- MySQL 驅動 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.x/version /dependency !-- 文件上傳解析器 -- dependency groupIdcommons-fileupload/groupId artifactIdcommons-fileupload/artifactId version1.4/version /dependency /dependencies版本這里我寫的是大版本區(qū)間實際用 5.3.x 配 3.5.x、mybatis-spring 2.x 是一套經(jīng)過大量項目驗證的組合JDK8 環(huán)境下很穩(wěn)。不推薦一上來就上 Spring 6Spring 6 的包名從 javax 換成了 jakartaServlet 容器要求也變了很多課程設計的 Tomcat 版本根本跑不起來白白增加環(huán)境成本。依賴加好之后SpringMvc 的配置文件里必須注冊文件上傳解析器bean idmultipartResolver classorg.springframework.web.multipart.commons.CommonsMultipartResolver property namedefaultEncoding valueUTF-8 / property namemaxUploadSize value5242880 / property namemaxUploadSizePerFile value2097152 / /bean三個配置項都有實際意義。defaultEncoding 必須寫成 UTF-8否則中文文件名上傳后可能亂碼maxUploadSize 是單次請求總大小上限5242880 就是 5MBmaxUploadSizePerFile 是單個文件大小上限2097152 即 2MB。這里的 5MB 和 2MB 是我建議的起步值圖片內(nèi)容入庫的場景本身就不適合大文件2MB 的圖片轉成 Base64 字符串都夠頁面喝一壺了所以把限制設在外面比讓 MySQL 去扛更有性價比。還要強調(diào)的是這個 bean 的 id 必須叫 multipartResolver不能改成別的名字DispatcherServlet 初始化時會按這個名字查找名字不對文件上傳解析器就不會生效RequestParam(file) 直接拿不到值。這種問題報錯還不太明顯經(jīng)常被歸類到“玄學”里實際上是配置命名沒對齊。3. 從 MultipartFile 到 INSERT寫通上傳鏈路的三層代碼依賴和表結構就緒后就可以開始寫上傳主鏈路了。這里的核心不是代碼多復雜而是每一層只干自己該干的事頁面負責提交 multipart 表單Controller 負責接收文件和組裝實體Service 負責業(yè)務校驗和事務控制Mapper 只負責把參數(shù)寫進 SQL。3.1 前端表單enctype 才是上傳的第一個秘密前端頁面別急著上那些花哨的富文本組件先老老實實寫一個原生表單把提交行為跑通再往上疊體驗。下面是這個項目最簡單的一版上傳頁% page contentTypetext/html;charsetUTF-8 languagejava % html head titleSSM 圖片上傳/title /head body h2SSM 圖片上傳演示/h2 form action${pageContext.request.contextPath}/image/upload methodpost enctypemultipart/form-data input typefile namefile acceptimage/* requiredrequired / button typesubmit上傳圖片/button /form pa href${pageContext.request.contextPath}/image/list查看已上傳圖片/a/p /body /htmlform 表單里最容易漏的就是 enctypemultipart/form-data。普通表單默認的 application/x-www-form-urlencoded 只會把文件內(nèi)容變成一串文本字符提交后端收到后根本組裝不出 MultipartFile。這個屬性不寫Controller 里 RequestParam(file) 拿到的是 null或者直接拋 MissingServletRequestPartException。input 的 name 值也必須和后端參數(shù)名一致我習慣統(tǒng)一叫 file簡單直接。acceptimage/* 只是瀏覽器給用戶的文件選擇提示它沒有任何安全作用后端的文件類型校驗一句都不能省。3.2 ControllerRequestParam 綁定文件redirect 防重復提交Controller 是整個鏈路的編排者不要在這一層寫業(yè)務邏輯。圖片接收、實體組裝、跳轉方向都放在這里核心代碼如下Controller RequestMapping(/image) public class ImageController { private final ImageService imageService; public ImageController(ImageService imageService) { this.imageService imageService; } PostMapping(/upload) public String upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return redirect:/image/uploadPage?errorempty; } ImageEntity entity buildEntity(file); imageService.saveImage(entity); return redirect:/image/list; } private ImageEntity buildEntity(MultipartFile file) { ImageEntity entity new ImageEntity(); entity.setImageName(StringUtils.getFilename(file.getOriginalFilename())); entity.setImageType(file.getContentType()); entity.setImageSize((int) file.getSize()); try { entity.setImageData(file.getBytes()); } catch (IOException e) { throw new RuntimeException(讀取上傳文件失敗, e); } return entity; } }這里幾個細節(jié)值得說明。file.isEmpty() 是上傳鏈路的第一道檢查比直接調(diào)用 getBytes() 更安全空文件沒必要進數(shù)據(jù)庫。StringUtils.getFilename 是 Spring 自帶的工具方法它的作用是剝離路徑信息因為部分瀏覽器和前端框架提交時會把完整路徑帶上來比如 C:\fake\folder\a.png不處理的話這個路徑會直接存進數(shù)據(jù)庫回顯列表里出現(xiàn)一長串垃圾字符。entity 的 imageType 直接取 file.getContentType()這一步就保證了后續(xù)回顯時不同格式圖片都能拿到正確的 MIME。最后返回 redirect 而不是 forward是為了避免用戶刷新頁面時表單重復提交這個習慣在圖片上傳場景里尤其重要一次重復提交就是一張重復的圖片數(shù)據(jù)。3.3 Service 與 Mapper事務只包 INSERTBLOB 要顯式聲明 jdbcTypeService 層這一層把事務和業(yè)務判斷收攏在一起。Mapper 的 insert 方法需要特別注意 jdbcType 的寫法否則個別 JDBC 驅動會報 no typehandler 錯誤。三個文件一起看Service public class ImageServiceImpl implements ImageService { private final ImageMapper imageMapper; public ImageServiceImpl(ImageMapper imageMapper) { this.imageMapper imageMapper; } Override Transactional public void saveImage(ImageEntity image) { if (image.getImageData() null || image.getImageData().length 0) { throw new IllegalArgumentException(圖片內(nèi)容為空); } imageMapper.insert(image); } Override public ImageEntity getImageById(Integer id) { return imageMapper.selectById(id); } Override public ListImageEntity listImages() { return imageMapper.selectList(); } }public interface ImageMapper { int insert(ImageEntity image); ImageEntity selectById(Param(id) Integer id); ListImageEntity selectList(); }insert idinsert parameterTypecom.demo.po.ImageEntity INSERT INTO t_image (image_name, image_data, image_type, image_size) VALUES (#{imageName}, #{imageData,jdbcTypeBLOB}, #{imageType}, #{imageSize}) /insert select idselectList resultTypecom.demo.po.ImageEntity SELECT id, image_name, image_type, image_size, create_time FROM t_image ORDER BY id DESC /select select idselectById resultTypecom.demo.po.ImageEntity SELECT id, image_name, image_data, image_type, image_size, create_time FROM t_image WHERE id #{id} /select這段代碼里有一個最關鍵的設計selectList 不查 image_data 字段。列表頁通常只需要文件名、類型、大小這些元數(shù)據(jù)如果 SELECT * 一次把整張表的 LONGBLOB 全端出來圖片一多頁面會卡到失去響應內(nèi)存直接被打滿。正確做法是列表只返回元數(shù)據(jù)img 標簽的 src 指向詳情接口由詳情接口按需把單條 image_data 查出來回顯。insert 語句里的 #{imageData,jdbcTypeBLOB} 是血淚經(jīng)驗MyBatis 默認的 byte[] TypeHandler 大多能處理二進制但顯式聲明 BLOB 類型可以繞開不同驅動之間的映射差異報錯概率明顯下降。如果實體里的字段不是 byte[] 而是 Blob 對象這里還要換成 BlobTypeHandler所以我在實體里統(tǒng)一用 byte[]最簡單也最可控。selectById 查出來的 image_data 會由 MyBatis 自動映射回實體的 byte[] 屬性回顯時直接取用即可。4. 讓圖片從數(shù)據(jù)庫回到瀏覽器流式回顯與 Base64 內(nèi)聯(lián)兩條路圖片入庫之后回顯是另一個獨立工程。這里要回答的問題只有一個img 標簽的 src 到底指向什么。答案是兩種一種指向一個后端接口后端把 LONGBLOB 作為圖片流寫回響應另一種是后端把圖片轉成 Base64 字符串直接發(fā)給前端前端把它塞進 data URI。兩條路我都走過適用場景完全不同。4.1 方式一ResponseEntity 輸出圖片流Content-Type 從數(shù)據(jù)庫讀流式回顯是我在 SSM 項目里的默認方案它對列表頁和大圖更友好。Controller 里再加一個方法GetMapping(/{id}) public ResponseEntitybyte[] image(PathVariable(id) Integer id) { ImageEntity image imageService.getImageById(id); if (image null || image.getImageData() null) { return ResponseEntity.notFound().build(); } MediaType mediaType MediaType.parseMediaType(image.getImageType()); return ResponseEntity.ok() .contentType(mediaType) .contentLength(image.getImageData().length) .body(image.getImageData()); }這個方法值得注意的細節(jié)有三個。第一Content-Type 一定用 image.getImageType() 動態(tài)獲取不要寫死 image/jpeg數(shù)據(jù)庫里存了 image/png 的圖片響應頭卻寫 jpeg瀏覽器能否顯示完全看運氣這就是很多人說的“PNG 圖回顯出來是黑屏”的常見原因。第二controller 里同時存在 /list 和 /{id} 兩個方法時不會沖突Spring 的路徑匹配會優(yōu)先選擇更具體的 /list不會把 list 當成 id 傳進去。第三contentLength 讓瀏覽器提前知道圖片大小大圖加載時能正常顯示進度狀態(tài)。如果 Client 端通過方式訪問瀏覽器會自動攜帶 Accept 頭后端不需要額外處理。4.2 方式二Base64 字符串回顯JSON 接口的備選方案如果你的接口設計是“前端拉一個 JSON直接在頁面渲染”或者圖片本身很小Base64 方案可以省掉一次圖片請求。后端轉一下即可GetMapping(/base64/{id}) ResponseBody public MapString, Object base64(PathVariable(id) Integer id) { ImageEntity image imageService.getImageById(id); String base64Src data: image.getImageType() ;base64, Base64.getEncoder().encodeToString(image.getImageData()); MapString, Object result new HashMap(); result.put(name, image.getImageName()); result.put(src, base64Src); return result; }前端拿到數(shù)據(jù)后img 的 src 就是 result.src不需要再發(fā)一次圖片請求。這個方案的優(yōu)點是鏈路短、跨域也方便缺點是每張圖片都會產(chǎn)生一份膨脹 33% 的字符串圖片一旦上了幾百 KB接口響應體和頁面體積會同時變大列表頁超過五張圖的時候瀏覽器渲染時間會肉眼可見地變長。所以我的習慣是單圖預覽、小圖頭像、接口直接返回 JSON 的場景用 Base64列表頁、大圖、需要瀏覽器緩存圖片的場景堅決用流式回顯。4.3 回顯路徑與靜態(tài)資源配置別讓 DispatcherServlet 吃掉圖片請求SSM 項目常見的坑之一是部署后頁面樣式和圖片全部 404問題出在 web.xml 里 DispatcherServlet 攔截了 / 路徑把靜態(tài)資源請求也送進了 SpringMvc。圖片接口既然走 /image/{id}就應確保它只被 Controller 處理而 css/js/靜態(tài)圖片放行給容器默認 Servlet。SpringMvc 配置里加一行即可mvc:default-servlet-handler/ mvc:resources mapping/static/** location/static//default-servlet-handler 會把 SpringMvc 沒匹配到的請求交給容器默認 Servlet 處理這樣 /static 下的 css、js 不受影響。需要注意它的副作用一旦開啟所有未匹配的路徑都不會再報 404 而是交給容器所以 Controller 里的路徑映射必須寫準確否則一個手誤的 /image/listt 會直接打到容器上得到一個莫名其妙的響應。5. 圖片入庫與回顯避坑清單這條鏈路上我翻過車的 5 個真實場景圖片上傳這條鏈路短但每一環(huán)都有它的脾氣。下面這些坑沒有一個是小眾冷門全是實戰(zhàn)里反復出現(xiàn)的典型問題每一條我都按現(xiàn)象、原因、解決三個步驟整理遇到同樣問題可以直接對著排查。5.1 上傳按鈕點了沒反應后端報 Part 缺失現(xiàn)象前端表單一切正常文件也能選中但提交后 SpringMvc 直接拋 MissingServletRequestPartException或者 RequestParam(file) 拿到的是 null。原因form 標簽沒有聲明 enctypemultipart/form-data。瀏覽器默認用 application/x-www-form-urlencoded 編碼提交文件內(nèi)容會被當成普通文本字段發(fā)送MultipartFile 根本不會被構建出來。這個問題在硬編碼 HTML 時最容易犯因為寫 form 的時候容易順手抄一個沒有 enctype 的模板。解決在 form 標簽上補上 enctypemultipart/form-data。如果用的是 AJAX 提交需要 new FormData() 然后把 FormData 對象作為 body 傳給 xhr不要手動設置 Content-Type 為 application/json也不要手動把文件塞進 JSON 字符串。5.2 數(shù)據(jù)庫里有圖片數(shù)據(jù)img 標簽卻一片空白現(xiàn)象上傳流程走完數(shù)據(jù)庫里能看到 image_data 字段有值列表頁也渲染出了記錄但圖片區(qū)域空白。打開瀏覽器開發(fā)者工具圖片請求的狀態(tài)碼是 200響應體卻是一段亂碼。原因后端返回 byte[] 時沒有正確設置 Content-Type。常見寫法是 Controller 方法返回 byte[] 但只加了 ResponseBody沒有指定 produces或者方法返回值類型是 StringSpring 把 byte[] 轉成了字符串輸出瀏覽器拿到后無法識別成圖片。解決用 ResponseEntitybyte[] 寫法顯式設置 contentType。不要依賴方法上的 produces 屬性因為圖片類型存在數(shù)據(jù)庫里動態(tài)讀出來再設置才可靠。我排查的時候第一步都是看響應頭里的 Content-Type 是什么如果顯示 text/html 或者 application/json就說明返回鏈路根本沒走到圖片渲染這條路。5.3 MySQL 報 PacketTooBigException小圖沒事大圖一插就掛現(xiàn)象幾百 KB 的圖片上傳成功一張 1MB 以上的圖片插入時報錯錯誤信息里有 Max allowed packet 字樣數(shù)據(jù)庫連接隨之斷開。原因這是 MySQL 服務端的限制不是 Java 或 MyBatis 的問題。MySQL 默認的 max_allowed_packet 比較小單條 INSERT 語句超過這個大小就會被服務端拒絕LONGBLOB 字段里的圖片數(shù)據(jù)正是典型的“大包”。很多人改代碼改了半天其實問題在數(shù)據(jù)庫參數(shù)上。解決臨時調(diào)大服務端參數(shù)SET GLOBAL max_allowed_packet 64 * 1024 * 1024;或者直接在 my.ini / my.cnf 里寫死成 64M。這只是兜底手段真正的工程解法是在應用層限制上傳大小上一章已經(jīng)提到了 CommonsMultipartResolver 里的 maxUploadSizePerFile把它設成 2MB從入口擋住超限圖片。5.4 列表頁越來越慢看一眼監(jiān)控發(fā)現(xiàn)內(nèi)存快被打滿現(xiàn)象圖片只有幾十張列表頁打開要好幾秒服務器內(nèi)存曲線明顯上漲甚至頻繁 Full GC。原因列表查詢把 image_data 字段也查出來了。SELECT * 會把每張圖片的 LONGBLOB 內(nèi)容全部加載進內(nèi)存幾十張圖就是幾百 MBMyBatis 再把它們逐個映射成 byte[]內(nèi)存自然遭不住。這是我在前面反復強調(diào) selectList 不查 image_data 的原因。解決列表查詢 SQL 只寫元數(shù)據(jù)字段id、image_name、image_type、image_size、create_time 這幾列就夠頁面展示真正要顯示圖片時img 的 src 再單獨請求詳情接口。這個設計也能捎帶解決列表頁圖片展示的懶加載問題用戶沒滾動到的地方不觸發(fā)圖片請求。5.5 圖片顯示成下載而不是預覽F12 一看到響應頭就明白了現(xiàn)象瀏覽器直接訪問圖片地址圖片沒有在頁面里展示反而彈出了文件下載框或者在 img 標簽里打開是正常的單獨訪問卻觸發(fā)下載。原因響應頭里出現(xiàn)了 Content-Disposition: attachment或者返回的 Content-Type 被設置成了 application/octet-stream。attachment 會強制瀏覽器下載octet-stream 則讓瀏覽器無法判斷用什么方式渲染。解決圖片回顯接口的響應頭應該是 Content-Disposition: inline同時 Content-Type 用數(shù)據(jù)庫里的 image_type。檢查方法很簡單用 curl -I 看響應頭如果 Content-Type 是 image/jpeg 且沒有 attachment瀏覽器就會正常渲染。開發(fā)期順手給圖片接口加上 Cache-Control: max-age86400一天之內(nèi)相同的圖片請求不會再打回數(shù)據(jù)庫對 DB 壓力是明顯的緩解。6. 最后留一個進階習慣把圖片存儲抽象成接口再做兩個驗證項目跑通之后我最想建議你做的不是急著加功能而是把圖片存取這一層重新封裝一下。上面的實現(xiàn)里 Controller 直接依賴 ImageServiceService 直接依賴 ImageMapper一旦將來你想從“數(shù)據(jù)庫存圖片”換成“磁盤存文件”或者“對象存儲”Controller、Service、Mapper 要改一大片。常見的做法是抽出一個 ImageStore 接口把保存、讀取、刪除三個動作定義清楚public interface ImageStore { String save(byte[] imageData, String imageType); byte[] load(String id); void delete(String id); }Controller 的回顯方法只依賴 ImageStore不再關心后端是查表還是讀文件。數(shù)據(jù)庫實現(xiàn)、磁盤實現(xiàn)、對象存儲實現(xiàn)各自完成自己的邏輯Spring 容器里切換一個 Bean 聲明對外暴露的 /image/{id} 地址不變前端代碼一行不用改。這個抽象是這類項目最值得帶走的設計思路也是你以后做真實系統(tǒng)時不會被“圖片到底存哪”這個問題綁死的保障。抽象做好之后建議養(yǎng)成兩個驗證習慣。第一用 curl -I 檢查圖片接口的響應頭確認 Content-Type、Content-Length、Cache-Control 三個值都符合預期這一步能把回顯問題從“玄學”變成可定量的指標。第二上傳幾張不同格式、不同大小的圖片直接在數(shù)據(jù)庫里對比 volume看 LONGBLOB 方案和 Base64 方案的體積差異這個數(shù)據(jù)能幫你以后在兩種方案里做決策而不是憑感覺選。我自己的習慣是把這張圖片鏈路的每個環(huán)節(jié)都留注釋和邊界說明因為這類項目往往是團隊里新人的第一個任務代碼即文檔。圖片進庫這個方案不會是大系統(tǒng)的最終答案但把這條鏈路吃透你也就把 SSM 三層最核心的交互方式吃透了。希望幫到你。本文還有配套的精品資源點擊獲取