前陣子幫人調(diào)試一套基于Springboot的仿淘寶購(gòu)物管理系統(tǒng)說句實(shí)話這類項(xiàng)目在很多平臺(tái)上一搜一大把但真正拿到源碼能順利跑起來(lái)、看完文檔能搞清楚業(yè)務(wù)邏輯的還真不多見。今天借著這套系統(tǒng)把我從導(dǎo)入項(xiàng)目到二次開發(fā)過程中遇到的坑、梳理出來(lái)的設(shè)計(jì)思路、以及代碼里值得反復(fù)揣摩的核心部分一次性整理清楚。如果你正在做課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)或者單純想找一套電商項(xiàng)目來(lái)實(shí)操Springboot這篇文章應(yīng)該能讓你少走不少?gòu)澛?。這套系統(tǒng)的定位很明確模仿主流電商平臺(tái)的購(gòu)物流程把用戶、商品、購(gòu)物車、訂單、支付、收貨、評(píng)價(jià)這一條完整鏈路串起來(lái)。它不是那種只有一個(gè)CRUD的空殼項(xiàng)目而是把權(quán)限、事務(wù)、并發(fā)、文件存儲(chǔ)這些實(shí)際開發(fā)中繞不開的點(diǎn)都塞了進(jìn)去所以拿來(lái)練手或者二次開發(fā)都很合適。1. 項(xiàng)目概覽為什么這類購(gòu)物系統(tǒng)這么適合練手1.1 電商項(xiàng)目覆蓋的技術(shù)面足夠廣我在帶新人或者幫人看項(xiàng)目時(shí)一直建議優(yōu)先選擇電商類項(xiàng)目作為Springboot練手目標(biāo)。原因很簡(jiǎn)單一個(gè)完整的購(gòu)物系統(tǒng)天然就能拆出多個(gè)模塊每個(gè)模塊都能對(duì)應(yīng)到不同的技術(shù)難點(diǎn)。用戶模塊要處理注冊(cè)、登錄、權(quán)限驗(yàn)證這涉及密碼加密和JWT鑒權(quán)商品模塊要處理分類、搜索、圖片上傳這涉及文件存儲(chǔ)和條件查詢購(gòu)物車模塊要維護(hù)用戶和商品的關(guān)系需要考慮合并、數(shù)量修改訂單模塊最麻煩既要保證事務(wù)一致性又要處理庫(kù)存扣減的并發(fā)問題支付模塊雖然通常對(duì)接模擬支付但回調(diào)通知、訂單狀態(tài)流轉(zhuǎn)這些邏輯一點(diǎn)都不能少。這套基于Springboot的淘寶購(gòu)物管理系統(tǒng)表面上看是一個(gè)麻雀雖小五臟俱全的商城實(shí)際上它把Springboot、MyBatis-Plus、Redis、Minio、JWT這些常用組件的整合方式都演示了一遍。對(duì)于初學(xué)者來(lái)說跟著源碼把這些模塊逐個(gè)過一遍比看十遍理論都管用。1.2 角色與核心功能矩陣系統(tǒng)里分了三種角色買家、賣家和管理員。有些項(xiàng)目會(huì)把賣家和管理員合并但這套系統(tǒng)是分開的權(quán)限粒度更清晰。角色核心功能涉及模塊游客瀏覽商品、搜索商品、查看商品詳情商品模塊買家登錄注冊(cè)、管理購(gòu)物車、下單、支付、收貨、評(píng)價(jià)、查看訂單用戶、購(gòu)物車、訂單、支付、評(píng)價(jià)賣家管理自家商品、處理訂單發(fā)貨、查看銷售情況商品、訂單管理員管理用戶、審核商品、管理分類、數(shù)據(jù)統(tǒng)計(jì)管理端三個(gè)角色對(duì)應(yīng)的是三套不同的接口權(quán)限這也是很多同學(xué)拿到源碼后最容易疑惑的地方為什么同一個(gè)接口不同角色調(diào)用返回的結(jié)果不一樣其實(shí)就是在攔截器里做了角色判斷后面我會(huì)把這塊的代碼邏輯拆開講。1.3 從瀏覽到收貨的完整業(yè)務(wù)閉環(huán)拿一次完整的購(gòu)物流程舉例游客在前臺(tái)頁(yè)面看到商品列表點(diǎn)擊進(jìn)詳情頁(yè)如果想下單需要先注冊(cè)并登錄登錄后把商品加入購(gòu)物車然后在購(gòu)物車?yán)锕催x要結(jié)算的商品生成訂單。訂單生成時(shí)系統(tǒng)會(huì)扣減庫(kù)存同時(shí)開啟支付倒計(jì)時(shí)用戶支付成功后才算真正下單完成。賣家在后臺(tái)看到新訂單執(zhí)行發(fā)貨操作買家收到貨后確認(rèn)收貨再對(duì)商品進(jìn)行評(píng)價(jià)。整個(gè)閉環(huán)里涉及的所有狀態(tài)變化這套系統(tǒng)都用數(shù)據(jù)庫(kù)字段和狀態(tài)更新記錄下來(lái)了。理解這個(gè)閉環(huán)很重要因?yàn)楹竺嫠心K的代碼都是圍繞這條鏈路展開的。我在給文檔寫說明時(shí)也是按照這個(gè)流程來(lái)分章節(jié)而不是單純按代碼目錄結(jié)構(gòu)來(lái)講。2. 技術(shù)選型與工程結(jié)構(gòu)每一步都要有理由2.1 技術(shù)棧清單及選型理由這套系統(tǒng)的技術(shù)棧是典型的Springboot全家桶組合我列個(gè)表把每個(gè)組件解決什么問題寫清楚。技術(shù)組件版本建議解決的問題Spring Boot2.7.x提供自動(dòng)配置和快速啟動(dòng)降低整合成本MyBatis-Plus3.5.x簡(jiǎn)化單表CRUD提供分頁(yè)插件和條件構(gòu)造器MySQL8.0存儲(chǔ)業(yè)務(wù)數(shù)據(jù)支持事務(wù)和復(fù)雜查詢Redis6.x / 7.x緩存驗(yàn)證碼、商品詳情、購(gòu)物車數(shù)據(jù)也能做分布式鎖Minio8.x商品圖片、頭像等文件的對(duì)象存儲(chǔ)服務(wù)JWT Spring Interceptor-無(wú)狀態(tài)登錄鑒權(quán)區(qū)分角色權(quán)限有人會(huì)問為什么不用Spring Data JPA我的觀點(diǎn)是電商項(xiàng)目的查詢條件往往是動(dòng)態(tài)拼接的比如商品列表要按照價(jià)格區(qū)間、分類、關(guān)鍵字過濾MyBatis-Plus的條件構(gòu)造器寫起來(lái)比JPA的Specification直觀得多而且很多老項(xiàng)目的Mapper XML可以直接遷移復(fù)用。另外MyBatis-Plus對(duì)分頁(yè)、邏輯刪除、自動(dòng)填充都有現(xiàn)成支持能省不少代碼量。Redis在這個(gè)項(xiàng)目里承擔(dān)的是性能加速器角色。商品詳情頁(yè)的點(diǎn)擊量最高如果每次請(qǐng)求都打數(shù)據(jù)庫(kù)壓力會(huì)很大所以項(xiàng)目里把熱門商品的詳情緩存到了Redis并設(shè)置了過期時(shí)間。購(gòu)物車數(shù)據(jù)也存在Redis里用Hash結(jié)構(gòu)存儲(chǔ)key是用戶IDfield是商品IDvalue是商品數(shù)量這樣查詢購(gòu)物車就很輕量。2.2 后端工程目錄是怎么拆的我拿到源碼后第一件事就是看目錄結(jié)構(gòu)。這套項(xiàng)目的結(jié)構(gòu)很標(biāo)準(zhǔn)但有一點(diǎn)值得拿出來(lái)說它在controller層和service層之間加入了一個(gè)dto包和一個(gè)vo包。com.example.mall ├── controller // 接口層只做參數(shù)接收和結(jié)果封裝 ├── service // 業(yè)務(wù)層事務(wù)控制在這里 │ └── impl ├── mapper // MyBatis-Plus的Mapper接口對(duì)應(yīng)數(shù)據(jù)庫(kù)操作 ├── entity // 數(shù)據(jù)庫(kù)實(shí)體類跟表結(jié)構(gòu)一一對(duì)應(yīng) ├── dto // 接收前端參數(shù)的傳輸對(duì)象 ├── vo // 返回給前端的視圖對(duì)象 ├── config // 配置類比如Redis、Minio、攔截器配置 ├── interceptor // 登錄鑒權(quán)攔截器 ├── common // 統(tǒng)一結(jié)果封裝、異常處理、工具類 └── ...很多課程設(shè)計(jì)項(xiàng)目喜歡把所有類都堆在controller和service兩層短期內(nèi)看著簡(jiǎn)單一旦加功能就會(huì)亂。這套系統(tǒng)的dto和vo是分開的這一點(diǎn)很關(guān)鍵。前端傳過來(lái)的參數(shù)用dto接收返回給前端的數(shù)據(jù)用vo封裝避免把數(shù)據(jù)庫(kù)實(shí)體直接暴露出去。比如用戶對(duì)象里有密碼字段如果直接把entity返回給前端密碼就泄露了。用vo只返回id、nickname、avatar這些字段安全性會(huì)好很多。2.3 數(shù)據(jù)庫(kù)設(shè)計(jì)核心表關(guān)系一覽數(shù)據(jù)庫(kù)一共十幾張表核心的幾張是tb_user、tb_category、tb_product、tb_cart、tb_order、tb_order_item、tb_address、tb_evaluation。表之間關(guān)系并不復(fù)雜但有兩張表的設(shè)計(jì)值得特別說明tb_order和tb_order_item是一對(duì)多拆開的。訂單主表存收貨地址、總金額、狀態(tài)等概要信息訂單商品表存每個(gè)商品的快照信息。訂單商品表必須冗余一份商品名稱、商品主圖、單價(jià)作為快照不能直接關(guān)聯(lián)商品表。為什么因?yàn)橛脩粝聠沃筚u家可能修改商品價(jià)格或者下架商品如果訂單詳情還要實(shí)時(shí)去查商品表用戶看到的價(jià)格和下單時(shí)就會(huì)對(duì)不上。這里冗余字段屬于用空間換正確性。另外這個(gè)項(xiàng)目統(tǒng)一使用了邏輯刪除所有表都有deleted字段用MyBatis-Plus的TableLogic注解處理。對(duì)于一個(gè)購(gòu)物系統(tǒng)用戶誤刪地址、賣家誤刪商品都是常見操作邏輯刪除給數(shù)據(jù)恢復(fù)留了后路這也是很多公司生產(chǎn)環(huán)境的通用做法。3. 核心模塊的實(shí)現(xiàn)要點(diǎn)不只是增刪改查3.1 用戶登錄與JWT鑒權(quán)的落地姿勢(shì)登錄這塊項(xiàng)目用的是JWT作為令牌整個(gè)流程可以簡(jiǎn)化成三步用戶輸入賬號(hào)密碼后端校驗(yàn)通過后生成Token返回前端前端把Token存在本地之后每次請(qǐng)求都在請(qǐng)求頭里帶上Authorization后端寫一個(gè)攔截器攔截所有需要登錄的接口從Token中解析用戶ID和角色放行或拒絕。代碼層面的關(guān)鍵點(diǎn)是攔截器的注冊(cè)方式。項(xiàng)目里有一個(gè)WebMvcConfig實(shí)現(xiàn)了WebMvcConfigurer重寫addInterceptors方法把自定義的LoginInterceptor注冊(cè)進(jìn)去并且設(shè)置excludePathPatterns把登錄、注冊(cè)、商品瀏覽這些接口放行。這里有個(gè)新手經(jīng)常踩的坑放行路徑寫錯(cuò)導(dǎo)致登錄接口也被攔截結(jié)果前端登錄請(qǐng)求拿著用戶名密碼卻進(jìn)不來(lái)排查半天不知道問題在哪。如果你自己調(diào)試記得先確認(rèn)excludePathPatterns里的路徑跟Controller里的RequestMapping前綴完全一致。Token解析時(shí)項(xiàng)目用JWT的SecretKey來(lái)簽名和驗(yàn)簽。需要注意的是JWT本身是不加密的里面不要放敏感信息我見過有人在Token里直接塞用戶手機(jī)號(hào)雖然能用但一旦Token被人拿到信息就泄露了。這個(gè)項(xiàng)目只在Token里放了用戶ID和角色編碼這是比較穩(wěn)妥的做法。3.2 商品模塊與Minio文件存儲(chǔ)的整合商品模塊涉及分類、品牌、上下架狀態(tài)、多圖展示。這里我想重點(diǎn)聊聊圖片上傳。項(xiàng)目用Minio做對(duì)象存儲(chǔ)而不是直接把圖片存到本地磁盤。原因很直接本地存儲(chǔ)的圖片不好管理、不好遷移而且生產(chǎn)環(huán)境部署時(shí)服務(wù)器磁盤空間有限。Minio本身是開源的對(duì)象存儲(chǔ)服務(wù)跟阿里云OSS這類云服務(wù)在API使用上很接近你學(xué)會(huì)接Minio后面換云存儲(chǔ)時(shí)改動(dòng)成本很低。文件上傳的流程是這樣的前端請(qǐng)求上傳接口后端接收MultipartFile生成新的對(duì)象名稱通常是UUID文件擴(kuò)展名調(diào)用Minio客戶端把文件流上傳到指定桶最后返回文件的訪問URL。這個(gè)URL會(huì)被存到商品表的image字段和商品圖片表里。我特別提一下文件名生成很多同學(xué)習(xí)慣直接用原始文件名如果兩個(gè)人上傳同一個(gè)名字的文件后一個(gè)會(huì)覆蓋前一個(gè)。所以用UUID或者日期隨機(jī)數(shù)重命名是必須的。Minio的配置也很簡(jiǎn)單核心就是四個(gè)參數(shù)endpoint、accessKey、secretKey、bucketName。我在實(shí)際跑這個(gè)項(xiàng)目時(shí)本地直接下載了Minio客戶端開啟一個(gè)9000端口的服務(wù)然后配置好賬號(hào)密碼基本就通了。如果在云服務(wù)器上部署記得把Minio的安全組和防火墻端口打開不然圖片URL會(huì)一直加載不出來(lái)。3.3 購(gòu)物車與生成訂單時(shí)的事務(wù)控制購(gòu)物車在Redis里的實(shí)現(xiàn)前面提過但我在這里要強(qiáng)調(diào)一下購(gòu)物車數(shù)據(jù)從Redis轉(zhuǎn)成訂單時(shí)的處理。用戶勾選購(gòu)物車商品點(diǎn)擊去結(jié)算時(shí)后端得一次性接收多個(gè)商品ID到Redis里取出對(duì)應(yīng)的商品信息然后查數(shù)據(jù)庫(kù)拿到最新價(jià)格計(jì)算總金額生成訂單主記錄和訂單明細(xì)記錄同時(shí)扣減庫(kù)存。這個(gè)操作牽扯到多張表的寫入必須加Transactional事務(wù)注解。不加或者加錯(cuò)位置就會(huì)出大問題。比如訂單生成成功了但庫(kù)存沒扣減或者扣了庫(kù)存但訂單沒生成這兩種情況在并發(fā)用戶同時(shí)下單時(shí)會(huì)立刻暴露。事務(wù)注解要加到service層實(shí)現(xiàn)類的方法上不要加到controller方法上也不要在service方法內(nèi)部自調(diào)用。這兩條后面我會(huì)在踩坑章節(jié)單獨(dú)展開因?yàn)檎娴奶嗳嗽谶@兩個(gè)地方栽過跟頭。4. 訂單狀態(tài)機(jī)與并發(fā)兜底項(xiàng)目里最值得研究的部分4.1 訂單狀態(tài)機(jī)的設(shè)計(jì)訂單模塊是整個(gè)購(gòu)物系統(tǒng)的心臟因?yàn)橛唵螤顟B(tài)不是隨便改的每個(gè)狀態(tài)之間的流轉(zhuǎn)都有明確條件。這套系統(tǒng)里訂單狀態(tài)用一個(gè)status字段表示狀態(tài)編碼含義下一步操作0待支付用戶支付或超時(shí)自動(dòng)取消1待發(fā)貨賣家發(fā)貨2待收貨買家確認(rèn)收貨3已完成買家可評(píng)價(jià)4已取消無(wú)后續(xù)操作5退款中賣家處理退款狀態(tài)流轉(zhuǎn)有一條鐵律除非特殊業(yè)務(wù)否則不允許跨狀態(tài)跳轉(zhuǎn)。比如一筆待支付訂單不能直接變成已完成。在代碼里項(xiàng)目通過在updateOrderStatus方法里傳oldStatus和newStatus用更新語(yǔ)句的WHERE條件帶上前置狀態(tài)來(lái)實(shí)現(xiàn)狀態(tài)的受控流轉(zhuǎn)。這個(gè)做法叫樂觀鎖在狀態(tài)更新上的應(yīng)用核心SQL是這樣的UPDATE tb_order SET status #{newStatus}, update_time NOW() WHERE id #{orderId} AND status #{oldStatus}當(dāng)兩個(gè)請(qǐng)求同時(shí)試圖更新同一筆訂單時(shí)只有一個(gè)請(qǐng)求能被成功執(zhí)行另一個(gè)影響行數(shù)為0業(yè)務(wù)代碼根據(jù)影響行數(shù)判斷是否流轉(zhuǎn)失敗。相比先SELECT再UPDATE的方式這種方式避免了并發(fā)狀態(tài)下讀取到的舊數(shù)據(jù)被覆蓋的問題。4.2 庫(kù)存扣減樂觀鎖加唯一索引雙重兜底秒殺場(chǎng)景下庫(kù)存超賣是經(jīng)典的并發(fā)問題。這個(gè)項(xiàng)目雖然沒做秒殺但庫(kù)存扣減的邏輯已經(jīng)考慮了并發(fā)情況。正?？蹘?kù)存的代碼不能是先查庫(kù)存數(shù)量夠再更新這種兩步走因?yàn)樵诟卟l(fā)下兩個(gè)請(qǐng)求同時(shí)查到庫(kù)存還剩1都判定可以購(gòu)買最后執(zhí)行更新時(shí)庫(kù)存就會(huì)變成負(fù)數(shù)。項(xiàng)目里用的是帶條件的更新boolean success inventoryService.deductStock(productId, quantity); // 實(shí)際SQL: UPDATE tb_product SET stock stock - #{quantity} // WHERE id #{productId} AND stock #{quantity}stock #{quantity}這個(gè)條件非常關(guān)鍵。它讓數(shù)據(jù)庫(kù)在更新時(shí)自行判斷庫(kù)存是否足夠如果不夠更新操作影響的行數(shù)就是0業(yè)務(wù)層捕獲到這個(gè)結(jié)果直接提示用戶庫(kù)存不足。配合tb_order_item表上的order_id product_id唯一索引還能防止同一用戶在同一訂單里重復(fù)添加同一商品導(dǎo)致的數(shù)據(jù)混亂。我之前幫人從源碼里找bug發(fā)現(xiàn)他把庫(kù)存扣減寫成了UPDATE tb_product SET stock stock - #{quantity} WHERE id #{productId}少了庫(kù)存判斷條件并發(fā)測(cè)試一打就超賣。這個(gè)案例我印象很深因?yàn)榇a就差一個(gè)條件線上出事故就可能是從這種細(xì)節(jié)開始的。4.3 超時(shí)未支付自動(dòng)取消的兩種實(shí)現(xiàn)訂單生成后通常要設(shè)置一個(gè)支付時(shí)限比如30分鐘。這個(gè)項(xiàng)目里給了兩種實(shí)現(xiàn)思路文檔里也寫了對(duì)比第一種是定時(shí)掃描。寫一個(gè)Scheduled注解的定時(shí)任務(wù)每隔一分鐘掃描一次訂單表把狀態(tài)為待支付且order_time超過30分鐘的訂單批量更新為已取消。這種方式實(shí)現(xiàn)簡(jiǎn)單但會(huì)有延遲最壞情況下訂單被取消的時(shí)間會(huì)晚一分鐘而且掃表全量數(shù)據(jù)時(shí)如果訂單量大對(duì)數(shù)據(jù)庫(kù)壓力不小。第二種是延遲消息。用Redis的過期鍵監(jiān)聽或者消息隊(duì)列的延遲隊(duì)列來(lái)實(shí)現(xiàn)到期通知精度更高但實(shí)現(xiàn)復(fù)雜度明顯上升。對(duì)于課程設(shè)計(jì)和中小型項(xiàng)目定時(shí)掃描完全夠用。這個(gè)項(xiàng)目源碼里默認(rèn)用的是定時(shí)掃描你在部署的時(shí)候稍微注意一下定時(shí)任務(wù)的開關(guān)配置就行別把整個(gè)任務(wù)類給注釋掉不然超時(shí)訂單永遠(yuǎn)取消不了。5. 源碼和文檔拿到手怎么才能用起來(lái)5.1 項(xiàng)目導(dǎo)入三步走很多人拿到源碼后第一步就卡住了因?yàn)閷?dǎo)入項(xiàng)目的細(xì)節(jié)沒搞明白。這套系統(tǒng)我建議按下面三個(gè)步驟來(lái)操作第一步準(zhǔn)備環(huán)境。裝好JDK 1.8或11、Maven 3.6、MySQL 8.0、Redis另外要有一個(gè)可用的Minio服務(wù)。MySQL執(zhí)行項(xiàng)目里提供的mall.sql腳本把數(shù)據(jù)庫(kù)和初始數(shù)據(jù)建好。Redis和Minio在本地起默認(rèn)服務(wù)就行。第二步改配置。打開application.yml按自己的實(shí)際環(huán)境修改數(shù)據(jù)源地址、Redis地址、Minio的endpoint和密鑰。這里最容易踩的坑是數(shù)據(jù)庫(kù)時(shí)區(qū)問題建議在數(shù)據(jù)庫(kù)連接參數(shù)里加上serverTimezoneAsia/Shanghai不然日期字段會(huì)差8個(gè)小時(shí)表現(xiàn)為訂單創(chuàng)建時(shí)間和實(shí)際時(shí)間對(duì)不上。第三步啟動(dòng)項(xiàng)目。先啟動(dòng)Minio再啟動(dòng)Redis然后是Spring Boot應(yīng)用。后端起來(lái)后用接口文檔或前端頁(yè)面的登錄接口試一下能拿到Token基本就說明環(huán)境和代碼都通了。如果項(xiàng)目里有前端頁(yè)面通常是Vue寫的一個(gè)簡(jiǎn)單管理頁(yè)npm install之后跑npm run dev或者打包放進(jìn)Springboot的static目錄看項(xiàng)目自帶文檔里的說明別自己瞎猜路徑。5.2 源碼結(jié)構(gòu)哪些能直接復(fù)用哪些要改這套系統(tǒng)的源碼目錄我前面已經(jīng)大致介紹過這里再補(bǔ)充一下哪些部分能直接當(dāng)工具代碼用。common包里的Result統(tǒng)一結(jié)果集、GlobalExceptionHandler全局異常處理以及JwtUtils工具類基本是可以直接搬到其他Springboot項(xiàng)目里的這三個(gè)文件寫得很規(guī)整沒什么項(xiàng)目耦合。config包里的MyBatisPlusConfig配置了分頁(yè)插件RedisConfig配置了RedisTemplate的序列化方式。我特別提醒一下RedisTemplate的序列化很多項(xiàng)目默認(rèn)用JDK序列化導(dǎo)致在Redis可視化工具里看到一堆轉(zhuǎn)義字符不方便排查。這個(gè)項(xiàng)目把Key設(shè)成了String序列化Value設(shè)成了Jackson序列化整個(gè)體驗(yàn)會(huì)清爽很多這個(gè)配置建議你也沿用。要改的地方主要在業(yè)務(wù)包。entity里的表字段如果和你的需求對(duì)不上記得先改數(shù)據(jù)庫(kù)表再改實(shí)體類保證字段名能映射上。另外dto層的參數(shù)校驗(yàn)注解比如NotBlank、Email也會(huì)因?yàn)榍岸藗鲄⒏袷讲煌枰{(diào)整。5.3 文檔里真正值錢的幾頁(yè)很多人不看文檔其實(shí)這套項(xiàng)目自帶的文檔里有幾個(gè)部分比源碼還值錢。首先是數(shù)據(jù)庫(kù)設(shè)計(jì)文檔它會(huì)畫一張ER圖并寫明每張表每個(gè)字段的含義這能幫你快速理解為什么訂單表要冗余商品快照、為什么地址表要保留省市區(qū)多級(jí)字段。其次是接口文檔里面把每個(gè)接口的請(qǐng)求參數(shù)、響應(yīng)示例、狀態(tài)碼都列出來(lái)了前后端聯(lián)調(diào)時(shí)直接照著文檔對(duì)就行。還有一個(gè)容易被忽略的部分是運(yùn)行部署說明里面包含了一些奇怪的坑。比如有個(gè)細(xì)節(jié)Minio的bucket在創(chuàng)建時(shí)如果沒做公開訪問策略上傳成功后的圖片URL即便存在數(shù)據(jù)庫(kù)里也是訪問不了的因?yàn)檎?qǐng)求沒有簽名。文檔里專門寫了一句話讓你執(zhí)行一條mc policy set public命令或者通過控制臺(tái)設(shè)置桶策略。我當(dāng)時(shí)就是沒看這頁(yè)卡了半小時(shí)最后翻文檔才發(fā)現(xiàn)。6. 真實(shí)踩坑記錄這些坑你大概率也會(huì)遇到6.1 JSON序列化循環(huán)引用導(dǎo)致的請(qǐng)求超時(shí)在開發(fā)商品評(píng)價(jià)功能時(shí)我遇到過一個(gè)現(xiàn)象前端請(qǐng)求某個(gè)接口等了好一會(huì)兒才返回有時(shí)候直接超時(shí)。剛開始我以為是數(shù)據(jù)庫(kù)慢后來(lái)查日志發(fā)現(xiàn)是JSON序列化耗時(shí)太長(zhǎng)。原因出在實(shí)體類雙向關(guān)聯(lián)上商品的Vo里關(guān)聯(lián)了評(píng)價(jià)列表評(píng)價(jià)的Vo里又關(guān)聯(lián)了商品信息序列化時(shí)兩個(gè)對(duì)象互相引用Jackson來(lái)回解析就卡住了。解決辦法有兩個(gè)方向。一是在字段上加JsonIgnore避免雙向暴露二是用JsonIgnoreProperties在引用端忽略對(duì)方字段。這套項(xiàng)目里很多Vo對(duì)象已經(jīng)做了隔離但如果你在二次開發(fā)時(shí)新增了關(guān)聯(lián)字段一定要留意這個(gè)坑。我建議所有返回給前端的對(duì)象關(guān)聯(lián)關(guān)系最多只展開一層不要圖省事把整個(gè)對(duì)象圖都序列化出去否則接口性能會(huì)越來(lái)越差。6.2Transactional自調(diào)用導(dǎo)致事務(wù)不回滾這是Spring事務(wù)里最經(jīng)典的一個(gè)坑。在一個(gè)Service里方法A調(diào)用了同類里的方法B方法B加了Transactional但方法A沒有加你猜B的事務(wù)生效嗎答案是不生效。因?yàn)镾pring事務(wù)是通過AOP代理實(shí)現(xiàn)的同類內(nèi)部直接調(diào)用拿到的是原始對(duì)象不是代理對(duì)象事務(wù)注解就被繞過了。我在這套系統(tǒng)的訂單模塊里就發(fā)現(xiàn)過這樣的寫法createOrder方法內(nèi)部調(diào)用了deductStock方法deductStock上標(biāo)了事務(wù)但createOrder沒有標(biāo)。結(jié)果訂單插入成功后庫(kù)存扣減失敗了整筆數(shù)據(jù)就是錯(cuò)的。正確的做法是把事務(wù)注解加在createOrder上讓整個(gè)方法體變成一個(gè)事務(wù)或者把deductStock挪到另一個(gè)Service類里通過注入的Bean來(lái)調(diào)用。檢查你手上的源碼時(shí)多留意這類自調(diào)用。6.3 性能優(yōu)化緩存預(yù)熱與頁(yè)面靜態(tài)化項(xiàng)目跑通之后如果想做性能優(yōu)化有兩個(gè)性價(jià)比很高的方向。一是商品熱門數(shù)據(jù)的緩存預(yù)熱可以在項(xiàng)目啟動(dòng)時(shí)把數(shù)據(jù)庫(kù)里點(diǎn)擊量最高的前幾十個(gè)商品加載到Redis避免第一個(gè)訪問用戶直接打到數(shù)據(jù)庫(kù)。二是用定時(shí)統(tǒng)計(jì)替代實(shí)時(shí)統(tǒng)計(jì)比如商品銷量這類數(shù)值沒必要每次下單都更新商品表的sales字段可以定時(shí)把訂單表聚合出來(lái)的數(shù)據(jù)回填到商品表減少對(duì)商品主表的頻繁更新。還有一個(gè)可以優(yōu)化的點(diǎn)是圖片懶加載和壓縮。Minio里存的原圖可能很大前端展示列表頁(yè)時(shí)會(huì)造成流量壓力。可以用Minio的圖片縮放功能生成縮略圖列表頁(yè)加載縮略圖詳情頁(yè)加載原圖。這個(gè)方案不需要改太多代碼只需要在返回URL時(shí)拼上壓縮參數(shù)實(shí)測(cè)效果很明顯。6.4 前后端聯(lián)調(diào)時(shí)的跨域處理如果前端是獨(dú)立端口運(yùn)行的Vue項(xiàng)目跨域問題跑不掉。這套系統(tǒng)的后端已經(jīng)寫了一個(gè)CorsConfig里面定義了允許的源IP、請(qǐng)求頭和方法。你需要檢查allowedOriginPatterns是否包含你前端的地址比如http://localhost:5173。如果前端請(qǐng)求是攜帶Token的還要允許Authorization請(qǐng)求頭否則預(yù)檢請(qǐng)求直接不過。我在第一次運(yùn)行這套系統(tǒng)時(shí)前端登錄頁(yè)點(diǎn)了半天沒反應(yīng)打開控制臺(tái)看到Access-Control-Allow-Origin錯(cuò)誤去配置里改了一下源地址馬上就好了。這種問題非常常見但很多人會(huì)在前端代理上繞來(lái)繞去其實(shí)后端把跨域配置允許好才是正路。最后再說兩句這套基于Springboot的淘寶購(gòu)物管理系統(tǒng)我前后也幫人部署和改過幾次整體感受是代碼結(jié)構(gòu)和注釋質(zhì)量在同類項(xiàng)目里屬于中上水平尤其是訂單狀態(tài)機(jī)、庫(kù)存扣減、JWT鑒權(quán)這幾塊對(duì)剛接觸Springboot的人來(lái)說是很好的學(xué)習(xí)樣本。源碼里附帶的文檔雖然篇幅不大但確實(shí)把數(shù)據(jù)庫(kù)設(shè)計(jì)和接口約定寫清楚了配合著學(xué)能少掉很多頭發(fā)。如果你準(zhǔn)備拿它做畢業(yè)設(shè)計(jì)或課程設(shè)計(jì)我建議不要只滿足于跑起來(lái)交差。試著去改一個(gè)功能比如把商品搜索改成支持多字段排序或者把支付回調(diào)改成模擬微信支付的通知格式這個(gè)過程會(huì)讓你真正理解這套系統(tǒng)是怎么工作的。遇到問題時(shí)也別急著換項(xiàng)目靜下心來(lái)看看日志、看看源碼里已經(jīng)寫好的處理方式收獲會(huì)超出你的預(yù)期。