文件上傳這件事說簡(jiǎn)單也簡(jiǎn)單一個(gè)MultipartFile參數(shù)接住就完事了說復(fù)雜也復(fù)雜一旦要把文件真正落到生產(chǎn)環(huán)境的存儲(chǔ)上坑就一個(gè)接一個(gè)冒出來了。我在帶團(tuán)隊(duì)做 SpringBootWeb 項(xiàng)目的時(shí)候見過太多人本地跑得好好的一部署到服務(wù)器就出問題——要么文件存本地磁盤結(jié)果多實(shí)例部署后找不到文件要么直接懟到應(yīng)用服務(wù)器上導(dǎo)致磁盤爆滿要么上傳大文件直接超時(shí)。這篇內(nèi)容就圍繞 SpringBootWeb 場(chǎng)景下的文件上傳重點(diǎn)講清楚怎么把文件從請(qǐng)求里接住、怎么校驗(yàn)、怎么對(duì)接云端對(duì)象存儲(chǔ)以及那些文檔里不會(huì)寫的實(shí)操細(xì)節(jié)。適合已經(jīng)能跑通基礎(chǔ) SpringBoot 接口、準(zhǔn)備把文件上傳功能真正用到項(xiàng)目里的開發(fā)者參考也適合想搞清楚為什么不能直接存本地這個(gè)問題的同學(xué)。1. 為什么文件上傳不能只停留在本地磁盤很多人第一次做文件上傳思路特別直接MultipartFile拿到之后transferTo到項(xiàng)目目錄下的某個(gè)文件夾返回一個(gè)相對(duì)路徑存進(jìn)數(shù)據(jù)庫前端拼上域名就能訪問。本地開發(fā)階段這套邏輯確實(shí)能跑但只要項(xiàng)目稍微往真實(shí)場(chǎng)景靠一靠問題就會(huì)集中爆發(fā)。我先把這些問題的根子講透你才知道后面為什么要引入對(duì)象存儲(chǔ)。1.1 本地存儲(chǔ)在多實(shí)例部署下的致命缺陷單體應(yīng)用單機(jī)部署的時(shí)候文件寫在應(yīng)用服務(wù)器本地磁盤上讀寫都在同一臺(tái)機(jī)器確實(shí)沒問題。但現(xiàn)在稍微正規(guī)一點(diǎn)的項(xiàng)目后端基本都是多實(shí)例部署前面掛個(gè)負(fù)載均衡。這時(shí)候用戶第一次上傳文件請(qǐng)求被轉(zhuǎn)發(fā)到實(shí)例 A文件落在 A 的磁盤上用戶第二次訪問這個(gè)文件請(qǐng)求被轉(zhuǎn)發(fā)到實(shí)例 BB 的磁盤上根本沒有這個(gè)文件直接 404。這不是配置問題是架構(gòu)層面的必然結(jié)果。有人會(huì)說那我搞個(gè)共享存儲(chǔ)掛載到每臺(tái)機(jī)器上行不行可以NFS 之類的方案確實(shí)能解決多實(shí)例讀取問題但隨之而來的是新的麻煩掛載點(diǎn)的網(wǎng)絡(luò)延遲、單點(diǎn)故障、權(quán)限配置、擴(kuò)容時(shí)的同步問題。而且應(yīng)用服務(wù)器和存儲(chǔ)服務(wù)器耦合在一起應(yīng)用做水平擴(kuò)容的時(shí)候存儲(chǔ)這塊還得單獨(dú)維護(hù)運(yùn)維成本直線上升。文件存儲(chǔ)這件事本質(zhì)上和業(yè)務(wù)計(jì)算是兩種不同的資源需求硬綁在一起遲早出問題。還有一個(gè)更現(xiàn)實(shí)的隱患應(yīng)用服務(wù)器的磁盤容量是有限的而且通常不會(huì)給太大。用戶上傳的圖片、文檔、視頻越積越多磁盤遲早被撐爆。一旦磁盤滿了不只是上傳功能掛掉整個(gè)應(yīng)用寫日志、寫臨時(shí)文件都會(huì)受影響直接導(dǎo)致服務(wù)不可用。這種故障在生產(chǎn)環(huán)境里非常典型排查起來還容易被忽略因?yàn)榇蠹业谝环磻?yīng)往往是查代碼邏輯很少有人先去看磁盤使用率。1.2 對(duì)象存儲(chǔ)解決了哪些實(shí)際問題對(duì)象存儲(chǔ)比如常見的云廠商提供的 OSS 類服務(wù)本質(zhì)上是把文件存儲(chǔ)這件事從應(yīng)用服務(wù)器上剝離出去交給專門的基礎(chǔ)設(shè)施來做。它帶來的好處不是單點(diǎn)的而是一整套無限擴(kuò)容存儲(chǔ)容量按需增長(zhǎng)不用提前規(guī)劃磁盤也不用擔(dān)心撐爆。天然支持多實(shí)例所有實(shí)例訪問的是同一個(gè)存儲(chǔ)服務(wù)不存在文件找不到的問題。訪問性能好對(duì)象存儲(chǔ)通常自帶 CDN 加速能力文件讀取走的是專門的通道不占用應(yīng)用服務(wù)器帶寬?？煽啃愿叨喔北救哂啻鎯?chǔ)單塊硬件故障不會(huì)導(dǎo)致文件丟失。權(quán)限可控可以通過簽名 URL、訪問策略等方式精細(xì)控制文件的讀寫權(quán)限。從架構(gòu)角度看應(yīng)用服務(wù)器只負(fù)責(zé)接收文件、校驗(yàn)文件、把文件轉(zhuǎn)交給存儲(chǔ)服務(wù)這三件事文件的實(shí)際存儲(chǔ)和分發(fā)完全交給對(duì)象存儲(chǔ)。職責(zé)清晰擴(kuò)容獨(dú)立這才是生產(chǎn)環(huán)境該有的樣子。所以下面我講的方案核心就是把文件上傳的落點(diǎn)從本地磁盤換成對(duì)象存儲(chǔ)同時(shí)把中間環(huán)節(jié)的校驗(yàn)、命名、異常處理都補(bǔ)齊。2. 接口層怎么把文件穩(wěn)穩(wěn)接住在對(duì)接對(duì)象存儲(chǔ)之前第一步是讓 SpringBoot 的接口能正確接收前端傳來的文件。這一步看著簡(jiǎn)單但參數(shù)綁定、大小限制、編碼這些細(xì)節(jié)沒處理好后面全是坑。2.1 MultipartFile 的接收方式與參數(shù)命名SpringBootWeb 里接收文件標(biāo)準(zhǔn)做法是用MultipartFile類型作為方法參數(shù)。這里有個(gè)容易被忽略的點(diǎn)前端表單里文件字段的name屬性必須和接口參數(shù)的變量名一致否則綁定不上MultipartFile會(huì)是 null。比如前端這樣寫form action/upload methodpost enctypemultipart/form-data input typefile namefile button typesubmit上傳/button /form后端接口就得是PostMapping(/upload) public String upload(RequestParam(file) MultipartFile file) { // 處理文件 }注意enctypemultipart/form-data這個(gè)屬性絕對(duì)不能漏漏了的話瀏覽器會(huì)用默認(rèn)的表單編碼方式提交文件內(nèi)容根本傳不過來后端拿到的MultipartFile要么是 null要么內(nèi)容為空。這個(gè)坑我見過不止一次尤其是前端同學(xué)用 axios 發(fā)請(qǐng)求的時(shí)候如果手動(dòng)設(shè)置了Content-Type: application/json文件就傳不過去必須讓瀏覽器或者請(qǐng)求庫自動(dòng)設(shè)置成multipart/form-data并帶上正確的 boundary。如果一次要傳多個(gè)文件參數(shù)可以寫成MultipartFile[] files前端對(duì)應(yīng)的多個(gè) input 用同一個(gè) name 即可。不過實(shí)際項(xiàng)目里多文件上傳更常見的做法是一個(gè)文件一個(gè)請(qǐng)求前端并發(fā)發(fā)起這樣單個(gè)文件失敗不影響其他文件重試邏輯也更好做。2.2 上傳大小限制的兩處配置SpringBoot 默認(rèn)對(duì)上傳文件大小是有限制的單文件默認(rèn) 1MB單次請(qǐng)求總大小默認(rèn) 10MB。超過限制會(huì)直接拋MaxUploadSizeExceededException前端收到的是 500 錯(cuò)誤體驗(yàn)很差。所以要根據(jù)業(yè)務(wù)實(shí)際調(diào)整這個(gè)限制配置寫在application.yml里spring: servlet: multipart: max-file-size: 10MB max-request-size: 50MBmax-file-size是單個(gè)文件的上限max-request-size是一次請(qǐng)求的總上限多文件上傳時(shí)是所有文件加起來。這兩個(gè)值要配合業(yè)務(wù)來定比如頭像上傳給 2MB 就夠了文檔上傳可能要給到 20MB視頻就得更大了。這里有個(gè)實(shí)操經(jīng)驗(yàn)限制值不要設(shè)得過大。有些人圖省事直接設(shè)成 1GB覺得反正不限制結(jié)果帶來兩個(gè)問題。一是大文件上傳會(huì)長(zhǎng)時(shí)間占用連接和內(nèi)存并發(fā)一高服務(wù)器就扛不住二是惡意用戶可能利用大文件上傳做資源消耗攻擊。合理的做法是按業(yè)務(wù)類型分接口設(shè)置不同的限制比如圖片接口和視頻接口分開各自配置合適的閾值。另外超過限制的異常最好用全局異常處理器捕獲返回友好的提示信息而不是讓用戶看到一個(gè)白頁的 500 錯(cuò)誤。2.3 臨時(shí)文件目錄的隱患MultipartFile在接收大文件時(shí)Spring 默認(rèn)會(huì)把內(nèi)容先寫到臨時(shí)目錄通常是系統(tǒng)的/tmp而不是全部放在內(nèi)存里。這個(gè)機(jī)制本身是為了防止內(nèi)存溢出但臨時(shí)目錄也有坑如果臨時(shí)目錄所在的分區(qū)空間不足上傳就會(huì)失敗如果應(yīng)用運(yùn)行在容器里容器的臨時(shí)目錄可能掛載的是內(nèi)存盤大文件直接撐爆內(nèi)存?？梢栽谂渲美镲@式指定臨時(shí)文件目錄spring: servlet: multipart: location: /data/tmp/upload指定到一個(gè)磁盤空間充足、有定期清理機(jī)制的位置。同時(shí)要注意這個(gè)目錄的權(quán)限得給應(yīng)用進(jìn)程可寫否則一樣報(bào)錯(cuò)。這個(gè)細(xì)節(jié)在本地開發(fā)時(shí)幾乎不會(huì)暴露因?yàn)楸镜嘏R時(shí)目錄通?？臻g充足但上了生產(chǎn)環(huán)境尤其是容器化部署就很容易踩到。3. 文件校驗(yàn)別把什么都往存儲(chǔ)里塞文件接住之后不能直接就往對(duì)象存儲(chǔ)里扔。用戶傳上來的東西五花八門有超大文件、有偽裝成圖片的可執(zhí)行文件、有空文件不做校驗(yàn)直接存輕則浪費(fèi)存儲(chǔ)空間重則帶來安全隱患。校驗(yàn)這塊我分成幾個(gè)層次來講。3.1 空文件與大小校驗(yàn)第一層校驗(yàn)最簡(jiǎn)單也最必要判斷文件是否為空。file.isEmpty()為 true 的時(shí)候直接拒絕返回明確提示。這個(gè)判斷看著多余但前端在某些異常情況下確實(shí)會(huì)提交空文件后端不攔就會(huì)在后續(xù)處理中報(bào)莫名其妙的錯(cuò)。大小校驗(yàn)除了依賴前面配置的全局限制業(yè)務(wù)層最好再做一次精確判斷。因?yàn)槿窒拗剖嵌档讟I(yè)務(wù)層才是精準(zhǔn)控制。比如頭像上傳業(yè)務(wù)規(guī)定不超過 2MB那就在代碼里顯式判斷l(xiāng)ong maxSize 2 * 1024 * 1024; if (file.getSize() maxSize) { throw new BusinessException(頭像大小不能超過 2MB); }這樣做的好處是錯(cuò)誤提示更精確用戶知道具體是哪個(gè)限制沒滿足而不是籠統(tǒng)的上傳失敗。全局配置和業(yè)務(wù)校驗(yàn)兩層配合前者防資源耗盡后者保業(yè)務(wù)規(guī)則。3.2 文件類型的雙重校驗(yàn)文件類型校驗(yàn)是安全的重災(zāi)區(qū)。很多人只校驗(yàn)文件擴(kuò)展名看后綴是不是.jpg、.png這遠(yuǎn)遠(yuǎn)不夠因?yàn)閿U(kuò)展名是可以隨便改的把一個(gè)可執(zhí)行文件改名成.jpg照樣能傳上來。正確的做法是雙重校驗(yàn)擴(kuò)展名白名單只允許業(yè)務(wù)需要的后綴比如圖片只允許 jpg、jpeg、png、gif、webp。MIME 類型校驗(yàn)通過file.getContentType()拿到瀏覽器聲明的類型做白名單比對(duì)。但要注意getContentType()是瀏覽器根據(jù)文件后綴推斷出來的同樣可以偽造。真正可靠的做法是讀取文件頭部的魔數(shù)magic number來判斷真實(shí)類型。比如 JPEG 文件開頭是FF D8 FFPNG 是89 50 4E 47。不過魔數(shù)校驗(yàn)實(shí)現(xiàn)起來稍復(fù)雜對(duì)于一般業(yè)務(wù)擴(kuò)展名加 MIME 雙重白名單已經(jīng)能擋住絕大多數(shù)問題如果業(yè)務(wù)對(duì)安全要求高再上魔數(shù)校驗(yàn)。這里有個(gè)實(shí)操細(xì)節(jié)擴(kuò)展名判斷要統(tǒng)一轉(zhuǎn)小寫再比較因?yàn)橛脩艨赡軅?JPG直接字符串比較會(huì)漏掉。另外文件名里可能包含路徑穿越字符比如../雖然現(xiàn)代框架一般會(huì)處理但保險(xiǎn)起見最終存儲(chǔ)用的文件名不要直接用用戶傳的原始文件名而是自己生成一個(gè)唯一名稱原始文件名只作為元數(shù)據(jù)保存。3.3 用唯一文件名避免覆蓋與沖突文件存到對(duì)象存儲(chǔ)里需要一個(gè)對(duì)象鍵object key相當(dāng)于文件在存儲(chǔ)里的路徑。如果直接用用戶上傳的原始文件名兩個(gè)用戶傳了同名文件后傳的就把先傳的覆蓋了這是絕對(duì)不能接受的。所以對(duì)象鍵必須自己生成保證全局唯一。常見的生成方式有幾種UUID、時(shí)間戳加隨機(jī)數(shù)、雪花算法 ID。我一般用日期目錄 UUID 原擴(kuò)展名的組合比如2024/06/15/550e8400-e29b-41d4-a716-446655440000.jpg。這樣做的考慮是按日期分目錄方便后續(xù)按時(shí)間歸檔和清理UUID 保證唯一性保留擴(kuò)展名方便識(shí)別文件類型。原始文件名可以單獨(dú)存到數(shù)據(jù)庫里用于展示和下載時(shí)還原。String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); String objectKey LocalDate.now().format(DateTimeFormatter.ofPattern(yyyy/MM/dd)) / UUID.randomUUID() ext;這段代碼里有個(gè)小坑如果文件名沒有擴(kuò)展名lastIndexOf(.)返回 -1substring(-1)會(huì)拋異常。所以要先判斷有沒有點(diǎn)號(hào)沒有的話要么拒絕要么給個(gè)默認(rèn)擴(kuò)展名。這種邊界情況在實(shí)際運(yùn)行中一定會(huì)遇到提前處理掉能省很多排查時(shí)間。4. 對(duì)接對(duì)象存儲(chǔ)的完整落地流程校驗(yàn)通過之后就到了核心環(huán)節(jié)把文件交給對(duì)象存儲(chǔ)。這里我以通用的對(duì)象存儲(chǔ) SDK 使用邏輯來講不同云廠商的 SDK 類名和方法名會(huì)有差異但整體流程是一致的初始化客戶端、構(gòu)造上傳請(qǐng)求、執(zhí)行上傳、處理返回結(jié)果。4.1 客戶端初始化與配置管理對(duì)象存儲(chǔ)的客戶端需要幾個(gè)關(guān)鍵配置服務(wù)端點(diǎn)endpoint、訪問密鑰access key 和 secret key、存儲(chǔ)空間名稱bucket。這些配置絕對(duì)不能硬編碼在代碼里必須放到配置文件或者配置中心通過ConfigurationProperties注入。storage: endpoint: your-endpoint access-key: your-access-key secret-key: your-secret-key bucket: your-bucket-name對(duì)應(yīng)的配置類ConfigurationProperties(prefix storage) Component public class StorageProperties { private String endpoint; private String accessKey; private String secretKey; private String bucket; // getter/setter 省略 }客戶端實(shí)例本身是線程安全的而且創(chuàng)建成本較高內(nèi)部維護(hù)連接池所以應(yīng)該做成單例在應(yīng)用啟動(dòng)時(shí)初始化一次而不是每次上傳都 new 一個(gè)?？梢杂肂ean的方式在配置類里創(chuàng)建交給 Spring 容器管理生命周期。這里有個(gè)安全提醒訪問密鑰屬于敏感信息不要提交到代碼倉庫。本地開發(fā)用本地配置文件并加入.gitignore生產(chǎn)環(huán)境通過環(huán)境變量或者配置中心注入。如果密鑰不小心泄露了要第一時(shí)間在云控制臺(tái)禁用并輪換這個(gè)流程團(tuán)隊(duì)里最好提前約定好。4.2 上傳請(qǐng)求的構(gòu)造與執(zhí)行上傳的核心邏輯就是構(gòu)造一個(gè)上傳請(qǐng)求對(duì)象把文件流、對(duì)象鍵、內(nèi)容類型設(shè)置進(jìn)去然后調(diào)用客戶端的上傳方法。以常見的 SDK 風(fēng)格為例大致是這樣public String upload(MultipartFile file, String objectKey) { try (InputStream inputStream file.getInputStream()) { ObjectMetadata metadata new ObjectMetadata(); metadata.setContentLength(file.getSize()); metadata.setContentType(file.getContentType()); storageClient.putObject(bucket, objectKey, inputStream, metadata); return buildFileUrl(objectKey); } catch (IOException e) { throw new BusinessException(文件讀取失敗, e); } }幾個(gè)關(guān)鍵點(diǎn)值得展開說。第一用try-with-resources管理輸入流確保上傳完成后流被正確關(guān)閉否則連接泄漏時(shí)間長(zhǎng)了連接池耗盡上傳功能整體掛掉。第二ContentLength一定要設(shè)置有些 SDK 不設(shè)置也能傳但會(huì)走分塊傳輸效率低且容易出問題。第三ContentType設(shè)置正確這樣瀏覽器訪問文件時(shí)能正確識(shí)別類型圖片能直接預(yù)覽而不是被當(dāng)成下載。上傳方法本身可能拋異常網(wǎng)絡(luò)抖動(dòng)、存儲(chǔ)服務(wù)限流、權(quán)限配置錯(cuò)誤都會(huì)導(dǎo)致失敗。所以上傳邏輯要包在 try-catch 里把底層異常轉(zhuǎn)換成業(yè)務(wù)異常同時(shí)記錄日志注意日志里不要打印密鑰等敏感信息。對(duì)于失敗的情況可以考慮加重試機(jī)制但要區(qū)分異常類型網(wǎng)絡(luò)超時(shí)這類瞬時(shí)故障適合重試權(quán)限錯(cuò)誤這類確定性故障重試多少次都沒用反而浪費(fèi)資源。4.3 返回給前端的訪問地址怎么給文件上傳成功后前端通常需要一個(gè)能訪問的 URL。這里有兩種常見做法各有適用場(chǎng)景。第一種是公開讀的存儲(chǔ)空間文件上傳后直接拼接一個(gè)固定的域名前綴返回比如https://your-domain.com/2024/06/15/xxx.jpg。這種方式簡(jiǎn)單直接適合頭像、商品圖這類本來就公開的資源。但要注意公開讀意味著任何人拿到 URL 都能訪問如果文件涉及隱私就不能這么干。第二種是私有讀加簽名 URL文件默認(rèn)不可公開訪問后端生成一個(gè)帶簽名和有效期的臨時(shí) URL 返回給前端。這種方式安全性高適合合同、證件這類敏感文件。簽名 URL 的有效期要按業(yè)務(wù)設(shè)置太短用戶還沒看完就失效了太長(zhǎng)又削弱了安全意義一般幾分鐘到幾小時(shí)不等。public String generateSignedUrl(String objectKey, Duration expire) { Date expiration new Date(System.currentTimeMillis() expire.toMillis()); return storageClient.generatePresignedUrl(bucket, objectKey, expiration).toString(); }實(shí)際項(xiàng)目里我傾向于默認(rèn)用私有讀需要公開的資源再單獨(dú)配置。因?yàn)橐坏┯昧斯_讀后面想改成私有讀所有已經(jīng)發(fā)出去的 URL 都會(huì)失效遷移成本很高。反過來私有讀改公開讀就容易多了。這個(gè)選擇在項(xiàng)目初期就要定好別等上線了再糾結(jié)。5. 那些文檔里不會(huì)寫的踩坑記錄前面講的都是應(yīng)該怎么做這一節(jié)講講實(shí)際做的時(shí)候會(huì)遇到什么。這些經(jīng)驗(yàn)基本都是從真實(shí)故障里攢出來的文檔里通常不會(huì)提。5.1 上傳成功但訪問 404 的排查鏈路這個(gè)現(xiàn)象特別典型接口返回成功URL 也拿到了但瀏覽器打開就是 404。排查的時(shí)候按這個(gè)順序走先確認(rèn)對(duì)象鍵對(duì)不對(duì)。把返回的 URL 和存儲(chǔ)控制臺(tái)里實(shí)際的文件路徑對(duì)比看是不是多了或少了斜杠、目錄層級(jí)對(duì)不對(duì)。對(duì)象鍵里如果開頭多了個(gè)/有些存儲(chǔ)服務(wù)會(huì)把它當(dāng)成一個(gè)空目錄導(dǎo)致路徑不匹配。再確認(rèn)存儲(chǔ)空間和區(qū)域。URL 里的域名對(duì)應(yīng)的區(qū)域和文件實(shí)際存儲(chǔ)的區(qū)域是不是一致?？鐓^(qū)域訪問有時(shí)候會(huì)返回 404 而不是明確的錯(cuò)誤。然后確認(rèn)權(quán)限。如果是私有讀的空間直接訪問肯定 404 或者 403得用簽名 URL。很多人忘了這一點(diǎn)以為上傳失敗其實(shí)是權(quán)限問題。最后看 CDN 緩存。如果前面掛了 CDN新上傳的文件可能因?yàn)榫彺孢€沒刷新而訪問不到等幾分鐘或者手動(dòng)刷新緩存再試。這個(gè)排查順序的邏輯是從近到遠(yuǎn)先看自己代碼生成的對(duì)象鍵再看存儲(chǔ)服務(wù)的配置最后看外圍的 CDN。大部分問題都出在第一步對(duì)象鍵拼接錯(cuò)誤是最常見的原因。5.2 大文件上傳超時(shí)與分片文件一大普通的單次上傳就容易超時(shí)。一方面是網(wǎng)絡(luò)傳輸時(shí)間長(zhǎng)另一方面是應(yīng)用服務(wù)器處理時(shí)間長(zhǎng)中間任何一環(huán)超時(shí)都會(huì)導(dǎo)致失敗。對(duì)于超過幾十 MB 的文件應(yīng)該考慮分片上傳把大文件切成多個(gè)小塊分別上傳最后在存儲(chǔ)服務(wù)端合并。分片上傳的邏輯比單次上傳復(fù)雜不少要處理分片編號(hào)、上傳 ID、斷點(diǎn)續(xù)傳、分片合并等。如果業(yè)務(wù)確實(shí)有大文件需求建議直接用存儲(chǔ)服務(wù)提供的分片上傳 SDK不要自己從頭實(shí)現(xiàn)。如果只是偶爾傳個(gè)大文件也可以適當(dāng)調(diào)大超時(shí)時(shí)間但要注意這只是緩解不是根治。還有個(gè)容易被忽略的點(diǎn)應(yīng)用服務(wù)器前面的網(wǎng)關(guān)或者負(fù)載均衡往往也有請(qǐng)求大小和超時(shí)限制。你代碼里配置得再寬松網(wǎng)關(guān)那一層攔住了照樣失敗。所以調(diào)大文件上傳限制的時(shí)候要把整條鏈路上的限制都檢查一遍前端、網(wǎng)關(guān)、應(yīng)用服務(wù)器、存儲(chǔ)服務(wù)缺一不可。5.3 并發(fā)上傳時(shí)的命名與冪等高并發(fā)場(chǎng)景下文件上傳還有兩個(gè)細(xì)節(jié)要注意。一是文件名生成的唯一性UUID 基本能保證不沖突但如果用了時(shí)間戳加隨機(jī)數(shù)的方案并發(fā)高的時(shí)候有極小概率撞車所以還是推薦 UUID。二是冪等性同一個(gè)文件重復(fù)上傳是每次都存一份新的還是識(shí)別出重復(fù)直接復(fù)用如果業(yè)務(wù)允許重復(fù)存儲(chǔ)那不用管如果要求去重就得在存儲(chǔ)前算文件內(nèi)容的哈希值用哈希值做對(duì)象鍵或者先查重。去重這件事要權(quán)衡。算哈希需要把整個(gè)文件讀一遍大文件會(huì)拖慢上傳速度而且哈希碰撞雖然概率極低但理論上存在。我的建議是除非業(yè)務(wù)明確要求去重比如某些文檔管理系統(tǒng)否則不要主動(dòng)加這個(gè)邏輯保持簡(jiǎn)單。真要去重也要把哈希計(jì)算放在異步流程里不要阻塞上傳主流程。5.4 密鑰泄露與權(quán)限最小化最后說個(gè)安全相關(guān)的。訪問密鑰一旦泄露別人就能以你的身份操作存儲(chǔ)空間刪文件、傳文件、甚至產(chǎn)生費(fèi)用。所以密鑰管理要遵循幾個(gè)原則不在代碼和日志里出現(xiàn)明文密鑰不同環(huán)境用不同的密鑰給密鑰配置最小必要權(quán)限比如只允許上傳和讀取指定空間不允許刪除和列舉。如果團(tuán)隊(duì)規(guī)模稍大建議用臨時(shí)憑證代替長(zhǎng)期密鑰。很多云廠商支持通過角色扮演的方式獲取有時(shí)效性的臨時(shí)憑證應(yīng)用運(yùn)行時(shí)動(dòng)態(tài)獲取這樣即使憑證泄露影響時(shí)間也有限。這套機(jī)制配置起來稍麻煩但對(duì)于安全要求高的項(xiàng)目是值得的。6. 把上傳功能組織成可復(fù)用的模塊講完單個(gè)環(huán)節(jié)最后說說代碼組織。文件上傳在很多項(xiàng)目里不是一處用到用戶頭像、商品圖片、附件、導(dǎo)入文件到處都要傳。如果每個(gè)地方都寫一遍上傳邏輯代碼重復(fù)不說改一處配置要改好幾個(gè)地方很容易漏。合理的做法是抽一個(gè)上傳服務(wù)出來。6.1 服務(wù)層的職責(zé)劃分我一般會(huì)定義一個(gè)FileStorageService接口把上傳刪除生成訪問地址這幾個(gè)核心能力抽象出來具體實(shí)現(xiàn)類對(duì)接不同的存儲(chǔ)后端。這樣業(yè)務(wù)代碼只依賴接口將來換存儲(chǔ)服務(wù)或者加個(gè)本地存儲(chǔ)的降級(jí)實(shí)現(xiàn)都不用改業(yè)務(wù)代碼。public interface FileStorageService { String upload(MultipartFile file, String bizType); void delete(String objectKey); String getAccessUrl(String objectKey); }bizType這個(gè)參數(shù)用來區(qū)分業(yè)務(wù)類型比如avatar、product、attachment實(shí)現(xiàn)類里可以根據(jù)它做不同的校驗(yàn)規(guī)則和目錄規(guī)劃。這樣校驗(yàn)邏輯也集中到一處不會(huì)散落在各個(gè) Controller 里。6.2 校驗(yàn)邏輯的集中管理校驗(yàn)規(guī)則如果分散在各個(gè)接口里很容易出現(xiàn)這個(gè)接口校驗(yàn)了大小那個(gè)接口忘了校驗(yàn)的情況。把校驗(yàn)抽成一個(gè)獨(dú)立的組件比如FileValidator按業(yè)務(wù)類型配置不同的規(guī)則業(yè)務(wù)類型允許擴(kuò)展名大小上限是否公開讀avatarjpg/jpeg/png/webp2MB是productjpg/jpeg/png5MB是attachmentpdf/doc/docx/xls/xlsx20MB否contractpdf10MB否這張表放在配置文件里校驗(yàn)組件讀取配置執(zhí)行校驗(yàn)。新增業(yè)務(wù)類型只需要加一行配置不用改代碼。這種配置驅(qū)動(dòng)的思路在文件上傳這種規(guī)則多變的場(chǎng)景里特別合適。6.3 異常處理與用戶提示上傳過程中的異常要統(tǒng)一處理給用戶明確的提示。常見的異常和對(duì)應(yīng)提示文件為空請(qǐng)選擇要上傳的文件超過大小限制文件大小不能超過 X MB類型不允許不支持的文件格式請(qǐng)上傳 X 格式存儲(chǔ)服務(wù)異常上傳失敗請(qǐng)稍后重試用全局異常處理器RestControllerAdvice把這些異常統(tǒng)一攔截轉(zhuǎn)換成統(tǒng)一的響應(yīng)結(jié)構(gòu)。這樣前端拿到的錯(cuò)誤信息是一致的不用為每個(gè)接口單獨(dú)處理。同時(shí)存儲(chǔ)服務(wù)的底層異常不要直接暴露給用戶里面可能包含內(nèi)部地址、密鑰片段等信息要轉(zhuǎn)換成友好的提示詳細(xì)錯(cuò)誤記到日志里供排查。7. 上線前的自查清單功能寫完不等于能上線文件上傳這塊有幾個(gè)點(diǎn)必須在部署前確認(rèn)。我把它們整理成清單每次上線前過一遍能避開大部分事故。上傳大小限制在整條鏈路上是否一致前端、網(wǎng)關(guān)、應(yīng)用服務(wù)器、存儲(chǔ)服務(wù)任何一層不一致都會(huì)出問題。臨時(shí)文件目錄是否指向空間充足的位置是否有定期清理機(jī)制。訪問密鑰是否通過環(huán)境變量或配置中心注入代碼倉庫里是否殘留明文密鑰。存儲(chǔ)空間的讀寫權(quán)限是否符合業(yè)務(wù)預(yù)期公開讀的資源是否確實(shí)可以公開。上傳失敗是否有重試和告警日志里是否能定位到具體失敗原因。大文件場(chǎng)景是否驗(yàn)證過分片上傳超時(shí)時(shí)間是否合理。并發(fā)上傳壓測(cè)是否做過文件名唯一性和存儲(chǔ)服務(wù)限流是否扛得住。這份清單里我最想強(qiáng)調(diào)的是第一條和第三條。鏈路限制不一致導(dǎo)致的失敗最難排查因?yàn)槊恳粚訂为?dú)看都正常合起來就是不行密鑰泄露則是后果最嚴(yán)重的一旦出事影響面很大。這兩條每次上線都值得花五分鐘確認(rèn)一遍。文件上傳這個(gè)功能代碼量不大但涉及的面很廣請(qǐng)求處理、參數(shù)校驗(yàn)、安全、存儲(chǔ)、網(wǎng)絡(luò)、并發(fā)每一塊都有細(xì)節(jié)。把上面這些環(huán)節(jié)都照顧到功能才算真正可用而不是本地能跑。后續(xù)如果業(yè)務(wù)量上來了還可以在這個(gè)基礎(chǔ)上加文件訪問統(tǒng)計(jì)、存儲(chǔ)成本分析、生命周期清理策略這些能力那是另一個(gè)層面的事了。