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