：從部署到核心模塊與避坑指南)
前陣子幫人調(diào)試一套基于Springboot的仿淘寶購物管理系統(tǒng)說句實(shí)話這類項(xiàng)目在很多平臺(tái)上一搜一大把但真正拿到源碼能順利跑起來、看完文檔能搞清楚業(yè)務(wù)邏輯的還真不多見。今天借著這套系統(tǒng)把我從導(dǎo)入項(xiàng)目到二次開發(fā)過程中遇到的坑、梳理出來的設(shè)計(jì)思路、以及代碼里值得反復(fù)揣摩的核心部分一次性整理清楚。如果你正在做課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)或者單純想找一套電商項(xiàng)目來實(shí)操Springboot這篇文章應(yīng)該能讓你少走不少彎路。這套系統(tǒng)的定位很明確模仿主流電商平臺(tái)的購物流程把用戶、商品、購物車、訂單、支付、收貨、評(píng)價(jià)這一條完整鏈路串起來。它不是那種只有一個(gè)CRUD的空殼項(xiàng)目而是把權(quán)限、事務(wù)、并發(fā)、文件存儲(chǔ)這些實(shí)際開發(fā)中繞不開的點(diǎn)都塞了進(jìn)去所以拿來練手或者二次開發(fā)都很合適。1. 項(xiàng)目概覽為什么這類購物系統(tǒng)這么適合練手1.1 電商項(xiàng)目覆蓋的技術(shù)面足夠廣我在帶新人或者幫人看項(xiàng)目時(shí)一直建議優(yōu)先選擇電商類項(xiàng)目作為Springboot練手目標(biāo)。原因很簡單一個(gè)完整的購物系統(tǒng)天然就能拆出多個(gè)模塊每個(gè)模塊都能對(duì)應(yīng)到不同的技術(shù)難點(diǎn)。用戶模塊要處理注冊(cè)、登錄、權(quán)限驗(yàn)證這涉及密碼加密和JWT鑒權(quán)商品模塊要處理分類、搜索、圖片上傳這涉及文件存儲(chǔ)和條件查詢購物車模塊要維護(hù)用戶和商品的關(guān)系需要考慮合并、數(shù)量修改訂單模塊最麻煩既要保證事務(wù)一致性又要處理庫存扣減的并發(fā)問題支付模塊雖然通常對(duì)接模擬支付但回調(diào)通知、訂單狀態(tài)流轉(zhuǎn)這些邏輯一點(diǎn)都不能少。這套基于Springboot的淘寶購物管理系統(tǒng)表面上看是一個(gè)麻雀雖小五臟俱全的商城實(shí)際上它把Springboot、MyBatis-Plus、Redis、Minio、JWT這些常用組件的整合方式都演示了一遍。對(duì)于初學(xué)者來說跟著源碼把這些模塊逐個(gè)過一遍比看十遍理論都管用。1.2 角色與核心功能矩陣系統(tǒng)里分了三種角色買家、賣家和管理員。有些項(xiàng)目會(huì)把賣家和管理員合并但這套系統(tǒng)是分開的權(quán)限粒度更清晰。角色核心功能涉及模塊游客瀏覽商品、搜索商品、查看商品詳情商品模塊買家登錄注冊(cè)、管理購物車、下單、支付、收貨、評(píng)價(jià)、查看訂單用戶、購物車、訂單、支付、評(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)拿一次完整的購物流程舉例游客在前臺(tái)頁面看到商品列表點(diǎn)擊進(jìn)詳情頁如果想下單需要先注冊(cè)并登錄登錄后把商品加入購物車然后在購物車?yán)锕催x要結(jié)算的商品生成訂單。訂單生成時(shí)系統(tǒng)會(huì)扣減庫存同時(shí)開啟支付倒計(jì)時(shí)用戶支付成功后才算真正下單完成。賣家在后臺(tái)看到新訂單執(zhí)行發(fā)貨操作買家收到貨后確認(rèn)收貨再對(duì)商品進(jìn)行評(píng)價(jià)。整個(gè)閉環(huán)里涉及的所有狀態(tài)變化這套系統(tǒng)都用數(shù)據(jù)庫字段和狀態(tài)更新記錄下來了。理解這個(gè)閉環(huán)很重要因?yàn)楹竺嫠心K的代碼都是圍繞這條鏈路展開的。我在給文檔寫說明時(shí)也是按照這個(gè)流程來分章節(jié)而不是單純按代碼目錄結(jié)構(gòu)來講。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簡化單表CRUD提供分頁插件和條件構(gòu)造器MySQL8.0存儲(chǔ)業(yè)務(wù)數(shù)據(jù)支持事務(wù)和復(fù)雜查詢Redis6.x / 7.x緩存驗(yàn)證碼、商品詳情、購物車數(shù)據(jù)也能做分布式鎖Minio8.x商品圖片、頭像等文件的對(duì)象存儲(chǔ)服務(wù)JWT Spring Interceptor-無狀態(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)造器寫起來比JPA的Specification直觀得多而且很多老項(xiàng)目的Mapper XML可以直接遷移復(fù)用。另外MyBatis-Plus對(duì)分頁、邏輯刪除、自動(dòng)填充都有現(xiàn)成支持能省不少代碼量。Redis在這個(gè)項(xiàng)目里承擔(dān)的是性能加速器角色。商品詳情頁的點(diǎn)擊量最高如果每次請(qǐng)求都打數(shù)據(jù)庫壓力會(huì)很大所以項(xiàng)目里把熱門商品的詳情緩存到了Redis并設(shè)置了過期時(shí)間。購物車數(shù)據(jù)也存在Redis里用Hash結(jié)構(gòu)存儲(chǔ)key是用戶IDfield是商品IDvalue是商品數(shù)量這樣查詢購物車就很輕量。2.2 后端工程目錄是怎么拆的我拿到源碼后第一件事就是看目錄結(jié)構(gòu)。這套項(xiàng)目的結(jié)構(gòu)很標(biāo)準(zhǔn)但有一點(diǎn)值得拿出來說它在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ù)庫操作 ├── entity // 數(shù)據(jù)庫實(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)看著簡單一旦加功能就會(huì)亂。這套系統(tǒng)的dto和vo是分開的這一點(diǎn)很關(guān)鍵。前端傳過來的參數(shù)用dto接收返回給前端的數(shù)據(jù)用vo封裝避免把數(shù)據(jù)庫實(shí)體直接暴露出去。比如用戶對(duì)象里有密碼字段如果直接把entity返回給前端密碼就泄露了。用vo只返回id、nickname、avatar這些字段安全性會(huì)好很多。2.3 數(shù)據(jù)庫設(shè)計(jì)核心表關(guān)系一覽數(shù)據(jù)庫一共十幾張表核心的幾張是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è)購物系統(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è)流程可以簡化成三步用戶輸入賬號(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)不來排查半天不知道問題在哪。如果你自己調(diào)試記得先確認(rèn)excludePathPatterns里的路徑跟Controller里的RequestMapping前綴完全一致。Token解析時(shí)項(xiàng)目用JWT的SecretKey來簽名和驗(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的配置也很簡單核心就是四個(gè)參數(shù)endpoint、accessKey、secretKey、bucketName。我在實(shí)際跑這個(gè)項(xiàng)目時(shí)本地直接下載了Minio客戶端開啟一個(gè)9000端口的服務(wù)然后配置好賬號(hào)密碼基本就通了。如果在云服務(wù)器上部署記得把Minio的安全組和防火墻端口打開不然圖片URL會(huì)一直加載不出來。3.3 購物車與生成訂單時(shí)的事務(wù)控制購物車在Redis里的實(shí)現(xiàn)前面提過但我在這里要強(qiáng)調(diào)一下購物車數(shù)據(jù)從Redis轉(zhuǎn)成訂單時(shí)的處理。用戶勾選購物車商品點(diǎn)擊去結(jié)算時(shí)后端得一次性接收多個(gè)商品ID到Redis里取出對(duì)應(yīng)的商品信息然后查數(shù)據(jù)庫拿到最新價(jià)格計(jì)算總金額生成訂單主記錄和訂單明細(xì)記錄同時(shí)扣減庫存。這個(gè)操作牽扯到多張表的寫入必須加Transactional事務(wù)注解。不加或者加錯(cuò)位置就會(huì)出大問題。比如訂單生成成功了但庫存沒扣減或者扣了庫存但訂單沒生成這兩種情況在并發(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è)購物系統(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已取消無后續(xù)操作5退款中賣家處理退款狀態(tài)流轉(zhuǎn)有一條鐵律除非特殊業(yè)務(wù)否則不允許跨狀態(tài)跳轉(zhuǎn)。比如一筆待支付訂單不能直接變成已完成。在代碼里項(xiàng)目通過在updateOrderStatus方法里傳oldStatus和newStatus用更新語句的WHERE條件帶上前置狀態(tà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 庫存扣減樂觀鎖加唯一索引雙重兜底秒殺場景下庫存超賣是經(jīng)典的并發(fā)問題。這個(gè)項(xiàng)目雖然沒做秒殺但庫存扣減的邏輯已經(jīng)考慮了并發(fā)情況。正?？蹘齑娴拇a不能是先查庫存數(shù)量夠再更新這種兩步走因?yàn)樵诟卟l(fā)下兩個(gè)請(qǐng)求同時(shí)查到庫存還剩1都判定可以購買最后執(zhí)行更新時(shí)庫存就會(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ù)庫在更新時(shí)自行判斷庫存是否足夠如果不夠更新操作影響的行數(shù)就是0業(yè)務(wù)層捕獲到這個(gè)結(jié)果直接提示用戶庫存不足。配合tb_order_item表上的order_id product_id唯一索引還能防止同一用戶在同一訂單里重復(fù)添加同一商品導(dǎo)致的數(shù)據(jù)混亂。我之前幫人從源碼里找bug發(fā)現(xiàn)他把庫存扣減寫成了UPDATE tb_product SET stock stock - #{quantity} WHERE id #{productId}少了庫存判斷條件并發(fā)測試一打就超賣。這個(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)簡單但會(huì)有延遲最壞情況下訂單被取消的時(shí)間會(huì)晚一分鐘而且掃表全量數(shù)據(jù)時(shí)如果訂單量大對(duì)數(shù)據(jù)庫壓力不小。第二種是延遲消息。用Redis的過期鍵監(jiān)聽或者消息隊(duì)列的延遲隊(duì)列來實(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. 源碼和文檔拿到手怎么才能用起來5.1 項(xiàng)目導(dǎo)入三步走很多人拿到源碼后第一步就卡住了因?yàn)閷?dǎo)入項(xiàng)目的細(xì)節(jié)沒搞明白。這套系統(tǒng)我建議按下面三個(gè)步驟來操作第一步準(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ù)庫和初始數(shù)據(jù)建好。Redis和Minio在本地起默認(rèn)服務(wù)就行。第二步改配置。打開application.yml按自己的實(shí)際環(huán)境修改數(shù)據(jù)源地址、Redis地址、Minio的endpoint和密鑰。這里最容易踩的坑是數(shù)據(jù)庫時(shí)區(qū)問題建議在數(shù)據(jù)庫連接參數(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)用。后端起來后用接口文檔或前端頁面的登錄接口試一下能拿到Token基本就說明環(huán)境和代碼都通了。如果項(xiàng)目里有前端頁面通常是Vue寫的一個(gè)簡單管理頁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配置了分頁插件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ù)庫表再改實(shí)體類保證字段名能映射上。另外dto層的參數(shù)校驗(yàn)注解比如NotBlank、Email也會(huì)因?yàn)榍岸藗鲄⒏袷讲煌枰{(diào)整。5.3 文檔里真正值錢的幾頁很多人不看文檔其實(shí)這套項(xiàng)目自帶的文檔里有幾個(gè)部分比源碼還值錢。首先是數(shù)據(jù)庫設(shè)計(jì)文檔它會(huì)畫一張ER圖并寫明每張表每個(gè)字段的含義這能幫你快速理解為什么訂單表要冗余商品快照、為什么地址表要保留省市區(qū)多級(jí)字段。其次是接口文檔里面把每個(gè)接口的請(qǐng)求參數(shù)、響應(yīng)示例、狀態(tài)碼都列出來了前后端聯(lián)調(diào)時(shí)直接照著文檔對(duì)就行。還有一個(gè)容易被忽略的部分是運(yùn)行部署說明里面包含了一些奇怪的坑。比如有個(gè)細(xì)節(jié)Minio的bucket在創(chuàng)建時(shí)如果沒做公開訪問策略上傳成功后的圖片URL即便存在數(shù)據(jù)庫里也是訪問不了的因?yàn)檎?qǐng)求沒有簽名。文檔里專門寫了一句話讓你執(zhí)行一條mc policy set public命令或者通過控制臺(tái)設(shè)置桶策略。我當(dāng)時(shí)就是沒看這頁卡了半小時(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ù)庫慢后來查日志發(fā)現(xiàn)是JSON序列化耗時(shí)太長。原因出在實(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來回解析就卡住了。解決辦法有兩個(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ì)越來越差。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é)果訂單插入成功后庫存扣減失敗了整筆數(shù)據(jù)就是錯(cuò)的。正確的做法是把事務(wù)注解加在createOrder上讓整個(gè)方法體變成一個(gè)事務(wù)或者把deductStock挪到另一個(gè)Service類里通過注入的Bean來調(diào)用。檢查你手上的源碼時(shí)多留意這類自調(diào)用。6.3 性能優(yōu)化緩存預(yù)熱與頁面靜態(tài)化項(xiàng)目跑通之后如果想做性能優(yōu)化有兩個(gè)性價(jià)比很高的方向。一是商品熱門數(shù)據(jù)的緩存預(yù)熱可以在項(xiàng)目啟動(dòng)時(shí)把數(shù)據(jù)庫里點(diǎn)擊量最高的前幾十個(gè)商品加載到Redis避免第一個(gè)訪問用戶直接打到數(shù)據(jù)庫。二是用定時(shí)統(tǒng)計(jì)替代實(shí)時(shí)統(tǒng)計(jì)比如商品銷量這類數(shù)值沒必要每次下單都更新商品表的sales字段可以定時(shí)把訂單表聚合出來的數(shù)據(jù)回填到商品表減少對(duì)商品主表的頻繁更新。還有一個(gè)可以優(yōu)化的點(diǎn)是圖片懶加載和壓縮。Minio里存的原圖可能很大前端展示列表頁時(shí)會(huì)造成流量壓力?？梢杂肕inio的圖片縮放功能生成縮略圖列表頁加載縮略圖詳情頁加載原圖。這個(gè)方案不需要改太多代碼只需要在返回URL時(shí)拼上壓縮參數(shù)實(shí)測效果很明顯。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í)前端登錄頁點(diǎn)了半天沒反應(yīng)打開控制臺(tái)看到Access-Control-Allow-Origin錯(cuò)誤去配置里改了一下源地址馬上就好了。這種問題非常常見但很多人會(huì)在前端代理上繞來繞去其實(shí)后端把跨域配置允許好才是正路。最后再說兩句這套基于Springboot的淘寶購物管理系統(tǒng)我前后也幫人部署和改過幾次整體感受是代碼結(jié)構(gòu)和注釋質(zhì)量在同類項(xiàng)目里屬于中上水平尤其是訂單狀態(tài)機(jī)、庫存扣減、JWT鑒權(quán)這幾塊對(duì)剛接觸Springboot的人來說是很好的學(xué)習(xí)樣本。源碼里附帶的文檔雖然篇幅不大但確實(shí)把數(shù)據(jù)庫設(shè)計(jì)和接口約定寫清楚了配合著學(xué)能少掉很多頭發(fā)。如果你準(zhǔn)備拿它做畢業(yè)設(shè)計(jì)或課程設(shè)計(jì)我建議不要只滿足于跑起來交差。試著去改一個(gè)功能比如把商品搜索改成支持多字段排序或者把支付回調(diào)改成模擬微信支付的通知格式這個(gè)過程會(huì)讓你真正理解這套系統(tǒng)是怎么工作的。遇到問題時(shí)也別急著換項(xiàng)目靜下心來看看日志、看看源碼里已經(jīng)寫好的處理方式收獲會(huì)超出你的預(yù)期。 Spring Boot仿淘寶購物系統(tǒng)：從部署到核心模塊與避坑指南
前陣子幫人調(diào)試一套基于Springboot的仿淘寶購物管理系統(tǒng)說句實(shí)話這類項(xiàng)目在很多平臺(tái)上一搜一大把但真正拿到源碼能順利跑起來、看完文檔能搞清楚業(yè)務(wù)邏輯的還真不多見。今天借著這套系統(tǒng)把我從導(dǎo)入項(xiàng)目到二次開發(fā)過程中遇到的坑、梳理出來的設(shè)計(jì)思路、以及代碼里值得反復(fù)揣摩的核心部分一次性整理清楚。如果你正在做課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)或者單純想找一套電商項(xiàng)目來實(shí)操Springboot這篇文章應(yīng)該能讓你少走不少彎路。這套系統(tǒng)的定位很明確模仿主流電商平臺(tái)的購物流程把用戶、商品、購物車、訂單、支付、收貨、評(píng)價(jià)這一條完整鏈路串起來。它不是那種只有一個(gè)CRUD的空殼項(xiàng)目而是把權(quán)限、事務(wù)、并發(fā)、文件存儲(chǔ)這些實(shí)際開發(fā)中繞不開的點(diǎn)都塞了進(jìn)去所以拿來練手或者二次開發(fā)都很合適。1. 項(xiàng)目概覽為什么這類購物系統(tǒng)這么適合練手1.1 電商項(xiàng)目覆蓋的技術(shù)面足夠廣我在帶新人或者幫人看項(xiàng)目時(shí)一直建議優(yōu)先選擇電商類項(xiàng)目作為Springboot練手目標(biāo)。原因很簡單一個(gè)完整的購物系統(tǒng)天然就能拆出多個(gè)模塊每個(gè)模塊都能對(duì)應(yīng)到不同的技術(shù)難點(diǎn)。用戶模塊要處理注冊(cè)、登錄、權(quán)限驗(yàn)證這涉及密碼加密和JWT鑒權(quán)商品模塊要處理分類、搜索、圖片上傳這涉及文件存儲(chǔ)和條件查詢購物車模塊要維護(hù)用戶和商品的關(guān)系需要考慮合并、數(shù)量修改訂單模塊最麻煩既要保證事務(wù)一致性又要處理庫存扣減的并發(fā)問題支付模塊雖然通常對(duì)接模擬支付但回調(diào)通知、訂單狀態(tài)流轉(zhuǎn)這些邏輯一點(diǎn)都不能少。這套基于Springboot的淘寶購物管理系統(tǒng)表面上看是一個(gè)麻雀雖小五臟俱全的商城實(shí)際上它把Springboot、MyBatis-Plus、Redis、Minio、JWT這些常用組件的整合方式都演示了一遍。對(duì)于初學(xué)者來說跟著源碼把這些模塊逐個(gè)過一遍比看十遍理論都管用。1.2 角色與核心功能矩陣系統(tǒng)里分了三種角色買家、賣家和管理員。有些項(xiàng)目會(huì)把賣家和管理員合并但這套系統(tǒng)是分開的權(quán)限粒度更清晰。角色核心功能涉及模塊游客瀏覽商品、搜索商品、查看商品詳情商品模塊買家登錄注冊(cè)、管理購物車、下單、支付、收貨、評(píng)價(jià)、查看訂單用戶、購物車、訂單、支付、評(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)拿一次完整的購物流程舉例游客在前臺(tái)頁面看到商品列表點(diǎn)擊進(jìn)詳情頁如果想下單需要先注冊(cè)并登錄登錄后把商品加入購物車然后在購物車?yán)锕催x要結(jié)算的商品生成訂單。訂單生成時(shí)系統(tǒng)會(huì)扣減庫存同時(shí)開啟支付倒計(jì)時(shí)用戶支付成功后才算真正下單完成。賣家在后臺(tái)看到新訂單執(zhí)行發(fā)貨操作買家收到貨后確認(rèn)收貨再對(duì)商品進(jìn)行評(píng)價(jià)。整個(gè)閉環(huán)里涉及的所有狀態(tài)變化這套系統(tǒng)都用數(shù)據(jù)庫字段和狀態(tài)更新記錄下來了。理解這個(gè)閉環(huán)很重要因?yàn)楹竺嫠心K的代碼都是圍繞這條鏈路展開的。我在給文檔寫說明時(shí)也是按照這個(gè)流程來分章節(jié)而不是單純按代碼目錄結(jié)構(gòu)來講。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簡化單表CRUD提供分頁插件和條件構(gòu)造器MySQL8.0存儲(chǔ)業(yè)務(wù)數(shù)據(jù)支持事務(wù)和復(fù)雜查詢Redis6.x / 7.x緩存驗(yàn)證碼、商品詳情、購物車數(shù)據(jù)也能做分布式鎖Minio8.x商品圖片、頭像等文件的對(duì)象存儲(chǔ)服務(wù)JWT Spring Interceptor-無狀態(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)造器寫起來比JPA的Specification直觀得多而且很多老項(xiàng)目的Mapper XML可以直接遷移復(fù)用。另外MyBatis-Plus對(duì)分頁、邏輯刪除、自動(dòng)填充都有現(xiàn)成支持能省不少代碼量。Redis在這個(gè)項(xiàng)目里承擔(dān)的是性能加速器角色。商品詳情頁的點(diǎn)擊量最高如果每次請(qǐng)求都打數(shù)據(jù)庫壓力會(huì)很大所以項(xiàng)目里把熱門商品的詳情緩存到了Redis并設(shè)置了過期時(shí)間。購物車數(shù)據(jù)也存在Redis里用Hash結(jié)構(gòu)存儲(chǔ)key是用戶IDfield是商品IDvalue是商品數(shù)量這樣查詢購物車就很輕量。2.2 后端工程目錄是怎么拆的我拿到源碼后第一件事就是看目錄結(jié)構(gòu)。這套項(xiàng)目的結(jié)構(gòu)很標(biāo)準(zhǔn)但有一點(diǎn)值得拿出來說它在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ù)庫操作 ├── entity // 數(shù)據(jù)庫實(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)看著簡單一旦加功能就會(huì)亂。這套系統(tǒng)的dto和vo是分開的這一點(diǎn)很關(guān)鍵。前端傳過來的參數(shù)用dto接收返回給前端的數(shù)據(jù)用vo封裝避免把數(shù)據(jù)庫實(shí)體直接暴露出去。比如用戶對(duì)象里有密碼字段如果直接把entity返回給前端密碼就泄露了。用vo只返回id、nickname、avatar這些字段安全性會(huì)好很多。2.3 數(shù)據(jù)庫設(shè)計(jì)核心表關(guān)系一覽數(shù)據(jù)庫一共十幾張表核心的幾張是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è)購物系統(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è)流程可以簡化成三步用戶輸入賬號(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)不來排查半天不知道問題在哪。如果你自己調(diào)試記得先確認(rèn)excludePathPatterns里的路徑跟Controller里的RequestMapping前綴完全一致。Token解析時(shí)項(xiàng)目用JWT的SecretKey來簽名和驗(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的配置也很簡單核心就是四個(gè)參數(shù)endpoint、accessKey、secretKey、bucketName。我在實(shí)際跑這個(gè)項(xiàng)目時(shí)本地直接下載了Minio客戶端開啟一個(gè)9000端口的服務(wù)然后配置好賬號(hào)密碼基本就通了。如果在云服務(wù)器上部署記得把Minio的安全組和防火墻端口打開不然圖片URL會(huì)一直加載不出來。3.3 購物車與生成訂單時(shí)的事務(wù)控制購物車在Redis里的實(shí)現(xiàn)前面提過但我在這里要強(qiáng)調(diào)一下購物車數(shù)據(jù)從Redis轉(zhuǎn)成訂單時(shí)的處理。用戶勾選購物車商品點(diǎn)擊去結(jié)算時(shí)后端得一次性接收多個(gè)商品ID到Redis里取出對(duì)應(yīng)的商品信息然后查數(shù)據(jù)庫拿到最新價(jià)格計(jì)算總金額生成訂單主記錄和訂單明細(xì)記錄同時(shí)扣減庫存。這個(gè)操作牽扯到多張表的寫入必須加Transactional事務(wù)注解。不加或者加錯(cuò)位置就會(huì)出大問題。比如訂單生成成功了但庫存沒扣減或者扣了庫存但訂單沒生成這兩種情況在并發(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è)購物系統(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已取消無后續(xù)操作5退款中賣家處理退款狀態(tài)流轉(zhuǎn)有一條鐵律除非特殊業(yè)務(wù)否則不允許跨狀態(tài)跳轉(zhuǎn)。比如一筆待支付訂單不能直接變成已完成。在代碼里項(xiàng)目通過在updateOrderStatus方法里傳oldStatus和newStatus用更新語句的WHERE條件帶上前置狀態(tà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 庫存扣減樂觀鎖加唯一索引雙重兜底秒殺場景下庫存超賣是經(jīng)典的并發(fā)問題。這個(gè)項(xiàng)目雖然沒做秒殺但庫存扣減的邏輯已經(jīng)考慮了并發(fā)情況。正?？蹘齑娴拇a不能是先查庫存數(shù)量夠再更新這種兩步走因?yàn)樵诟卟l(fā)下兩個(gè)請(qǐng)求同時(shí)查到庫存還剩1都判定可以購買最后執(zhí)行更新時(shí)庫存就會(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ù)庫在更新時(shí)自行判斷庫存是否足夠如果不夠更新操作影響的行數(shù)就是0業(yè)務(wù)層捕獲到這個(gè)結(jié)果直接提示用戶庫存不足。配合tb_order_item表上的order_id product_id唯一索引還能防止同一用戶在同一訂單里重復(fù)添加同一商品導(dǎo)致的數(shù)據(jù)混亂。我之前幫人從源碼里找bug發(fā)現(xiàn)他把庫存扣減寫成了UPDATE tb_product SET stock stock - #{quantity} WHERE id #{productId}少了庫存判斷條件并發(fā)測試一打就超賣。這個(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)簡單但會(huì)有延遲最壞情況下訂單被取消的時(shí)間會(huì)晚一分鐘而且掃表全量數(shù)據(jù)時(shí)如果訂單量大對(duì)數(shù)據(jù)庫壓力不小。第二種是延遲消息。用Redis的過期鍵監(jiān)聽或者消息隊(duì)列的延遲隊(duì)列來實(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. 源碼和文檔拿到手怎么才能用起來5.1 項(xiàng)目導(dǎo)入三步走很多人拿到源碼后第一步就卡住了因?yàn)閷?dǎo)入項(xiàng)目的細(xì)節(jié)沒搞明白。這套系統(tǒng)我建議按下面三個(gè)步驟來操作第一步準(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ù)庫和初始數(shù)據(jù)建好。Redis和Minio在本地起默認(rèn)服務(wù)就行。第二步改配置。打開application.yml按自己的實(shí)際環(huán)境修改數(shù)據(jù)源地址、Redis地址、Minio的endpoint和密鑰。這里最容易踩的坑是數(shù)據(jù)庫時(shí)區(qū)問題建議在數(shù)據(jù)庫連接參數(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)用。后端起來后用接口文檔或前端頁面的登錄接口試一下能拿到Token基本就說明環(huán)境和代碼都通了。如果項(xiàng)目里有前端頁面通常是Vue寫的一個(gè)簡單管理頁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配置了分頁插件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ù)庫表再改實(shí)體類保證字段名能映射上。另外dto層的參數(shù)校驗(yàn)注解比如NotBlank、Email也會(huì)因?yàn)榍岸藗鲄⒏袷讲煌枰{(diào)整。5.3 文檔里真正值錢的幾頁很多人不看文檔其實(shí)這套項(xiàng)目自帶的文檔里有幾個(gè)部分比源碼還值錢。首先是數(shù)據(jù)庫設(shè)計(jì)文檔它會(huì)畫一張ER圖并寫明每張表每個(gè)字段的含義這能幫你快速理解為什么訂單表要冗余商品快照、為什么地址表要保留省市區(qū)多級(jí)字段。其次是接口文檔里面把每個(gè)接口的請(qǐng)求參數(shù)、響應(yīng)示例、狀態(tài)碼都列出來了前后端聯(lián)調(diào)時(shí)直接照著文檔對(duì)就行。還有一個(gè)容易被忽略的部分是運(yùn)行部署說明里面包含了一些奇怪的坑。比如有個(gè)細(xì)節(jié)Minio的bucket在創(chuàng)建時(shí)如果沒做公開訪問策略上傳成功后的圖片URL即便存在數(shù)據(jù)庫里也是訪問不了的因?yàn)檎?qǐng)求沒有簽名。文檔里專門寫了一句話讓你執(zhí)行一條mc policy set public命令或者通過控制臺(tái)設(shè)置桶策略。我當(dāng)時(shí)就是沒看這頁卡了半小時(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ù)庫慢后來查日志發(fā)現(xiàn)是JSON序列化耗時(shí)太長。原因出在實(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來回解析就卡住了。解決辦法有兩個(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ì)越來越差。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é)果訂單插入成功后庫存扣減失敗了整筆數(shù)據(jù)就是錯(cuò)的。正確的做法是把事務(wù)注解加在createOrder上讓整個(gè)方法體變成一個(gè)事務(wù)或者把deductStock挪到另一個(gè)Service類里通過注入的Bean來調(diào)用。檢查你手上的源碼時(shí)多留意這類自調(diào)用。6.3 性能優(yōu)化緩存預(yù)熱與頁面靜態(tài)化項(xiàng)目跑通之后如果想做性能優(yōu)化有兩個(gè)性價(jià)比很高的方向。一是商品熱門數(shù)據(jù)的緩存預(yù)熱可以在項(xiàng)目啟動(dòng)時(shí)把數(shù)據(jù)庫里點(diǎn)擊量最高的前幾十個(gè)商品加載到Redis避免第一個(gè)訪問用戶直接打到數(shù)據(jù)庫。二是用定時(shí)統(tǒng)計(jì)替代實(shí)時(shí)統(tǒng)計(jì)比如商品銷量這類數(shù)值沒必要每次下單都更新商品表的sales字段可以定時(shí)把訂單表聚合出來的數(shù)據(jù)回填到商品表減少對(duì)商品主表的頻繁更新。還有一個(gè)可以優(yōu)化的點(diǎn)是圖片懶加載和壓縮。Minio里存的原圖可能很大前端展示列表頁時(shí)會(huì)造成流量壓力?？梢杂肕inio的圖片縮放功能生成縮略圖列表頁加載縮略圖詳情頁加載原圖。這個(gè)方案不需要改太多代碼只需要在返回URL時(shí)拼上壓縮參數(shù)實(shí)測效果很明顯。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í)前端登錄頁點(diǎn)了半天沒反應(yīng)打開控制臺(tái)看到Access-Control-Allow-Origin錯(cuò)誤去配置里改了一下源地址馬上就好了。這種問題非常常見但很多人會(huì)在前端代理上繞來繞去其實(shí)后端把跨域配置允許好才是正路。最后再說兩句這套基于Springboot的淘寶購物管理系統(tǒng)我前后也幫人部署和改過幾次整體感受是代碼結(jié)構(gòu)和注釋質(zhì)量在同類項(xiàng)目里屬于中上水平尤其是訂單狀態(tài)機(jī)、庫存扣減、JWT鑒權(quán)這幾塊對(duì)剛接觸Springboot的人來說是很好的學(xué)習(xí)樣本。源碼里附帶的文檔雖然篇幅不大但確實(shí)把數(shù)據(jù)庫設(shè)計(jì)和接口約定寫清楚了配合著學(xué)能少掉很多頭發(fā)。如果你準(zhǔn)備拿它做畢業(yè)設(shè)計(jì)或課程設(shè)計(jì)我建議不要只滿足于跑起來交差。試著去改一個(gè)功能比如把商品搜索改成支持多字段排序或者把支付回調(diào)改成模擬微信支付的通知格式這個(gè)過程會(huì)讓你真正理解這套系統(tǒng)是怎么工作的。遇到問題時(shí)也別急著換項(xiàng)目靜下心來看看日志、看看源碼里已經(jīng)寫好的處理方式收獲會(huì)超出你的預(yù)期。