SpringBoot籃球用品網(wǎng)購(gòu)系統(tǒng)開發(fā)實(shí)錄從零搭建到上線全記錄做電商系統(tǒng)開發(fā)這么多年幫人改過的購(gòu)物車代碼比我吃過的飯都多。但每次拿到類似SpringBoot籃球用品網(wǎng)購(gòu)系統(tǒng)這種垂直類電商項(xiàng)目我還是會(huì)覺得有意思——因?yàn)樗倪壿嫃?fù)雜度和大廠電商沒有本質(zhì)區(qū)別只是業(yè)務(wù)規(guī)模更聚焦。今天我想把這個(gè)項(xiàng)目的完整開發(fā)過程和設(shè)計(jì)思路合盤托出從前臺(tái)的商品瀏覽、購(gòu)物車、訂單支付到后臺(tái)的商品管理、庫(kù)存維護(hù)、訂單處理每一步都附上實(shí)測(cè)過的配置和踩坑記錄。不管你是準(zhǔn)備拿它做畢業(yè)設(shè)計(jì)、接外包定制還是純粹想用SpringBoot跑通一個(gè)完整的電商閉環(huán)這篇都能給你一份可以直接照著抄的作業(yè)。我自己平時(shí)也會(huì)接觸PHP、Python、C#的項(xiàng)目但做這類系統(tǒng)我?guī)缀鯚o腦選Java技術(shù)棧。不是別的語言不行而是SpringBoot這套生態(tài)實(shí)在太適合跑電商了——事務(wù)處理穩(wěn)定、并發(fā)支撐成熟、現(xiàn)成的組件豐富社區(qū)資料多到你能搜到的坑基本都有人踩過。而且對(duì)剛?cè)腴T的朋友來說學(xué)SpringBoot順帶練手一個(gè)完整系統(tǒng)這個(gè)技術(shù)投資是真的值。1. 項(xiàng)目定位與功能全景1.1 為什么選擇垂直品類做電商系統(tǒng)很多初學(xué)者一上來就想做一個(gè)淘寶全品類的通用商城我勸你冷靜。籃球用品網(wǎng)購(gòu)系統(tǒng)這種垂直定位的電商項(xiàng)目其實(shí)更容易把每個(gè)環(huán)節(jié)做扎實(shí)。買籃球鞋、籃球服的用戶需求非常明確搜索關(guān)鍵詞集中庫(kù)存SKU數(shù)量可控訂單量級(jí)適合單機(jī)部署——這些特點(diǎn)都讓它成為教學(xué)和畢設(shè)場(chǎng)景下的理想選擇。從商品維度看一個(gè)籃球用品店通常只有球類、鞋類、服飾、護(hù)具、配件這幾個(gè)大類。每類的屬性差異不像服裝那樣細(xì)碎商品規(guī)格可以控制在顏色、尺碼、型號(hào)這幾項(xiàng)極大降低了SKU管理的復(fù)雜度。但從業(yè)務(wù)流程看它又是一個(gè)完整的B2C閉環(huán)用戶注冊(cè)登錄、瀏覽商品、加入購(gòu)物車、下單、結(jié)算、模擬支付、訂單查詢、后臺(tái)發(fā)貨一步都不能少。我接手這個(gè)項(xiàng)目時(shí)最開始的定位就是麻雀雖小五臟俱全系統(tǒng)要覆蓋電商核心鏈路但不做大而全的會(huì)員積分、優(yōu)惠券裂變這類邊緣功能。把主營(yíng)業(yè)務(wù)跑通、跑穩(wěn)比堆功能更有價(jià)值。1.2 系統(tǒng)核心功能模塊拆解我相信對(duì)于絕大多數(shù)學(xué)習(xí)者來說最關(guān)心的就是這個(gè)系統(tǒng)到底有哪些功能。我直接給你一張功能全景圖前臺(tái)用戶端用戶注冊(cè)與登錄手機(jī)號(hào)或郵箱注冊(cè)BCrypt加密存儲(chǔ)首頁輪播圖與熱門商品推薦位商品分類導(dǎo)航籃球、球鞋、服飾、護(hù)具、配件商品列表頁支持關(guān)鍵詞搜索、價(jià)格區(qū)間篩選、按銷量/價(jià)格/上架時(shí)間排序商品詳情頁多圖展示、SKU規(guī)格選擇、庫(kù)存展示購(gòu)物車加入、修改數(shù)量、刪除、批量結(jié)算訂單確認(rèn)頁收貨地址管理、訂單金額明細(xì)模擬支付流程對(duì)接支付寶沙箱或簡(jiǎn)單的余額支付個(gè)人中心訂單列表、訂單詳情、取消訂單、確認(rèn)收貨后臺(tái)管理端管理員登錄與權(quán)限校驗(yàn)商品管理發(fā)布、上下架、編輯、庫(kù)存調(diào)整、多圖上傳類目管理樹形分類的增刪改查訂單管理訂單列表、查看詳情、發(fā)貨處理用戶管理用戶列表、狀態(tài)禁用與啟用輪播圖管理前端首頁Banner的配置這些模塊加起來也就是十幾張表的規(guī)模但每個(gè)模塊都有設(shè)計(jì)細(xì)節(jié)。比如商品上下架時(shí)庫(kù)存怎么聯(lián)動(dòng)、訂單取消后庫(kù)存怎么回滾這類問題才是真正考驗(yàn)開發(fā)功力的地方。1.3 項(xiàng)目的三種典型使用場(chǎng)景那么問題來了這套系統(tǒng)究竟適合什么人我總結(jié)了三類最常見的場(chǎng)景第一類是畢業(yè)設(shè)計(jì)比例大約占七成。一個(gè)SpringBoot Vue的完整前后端分離項(xiàng)目功能完整、技術(shù)棧主流、文檔好寫答辯時(shí)能講的東西很多——數(shù)據(jù)庫(kù)設(shè)計(jì)、事務(wù)控制、并發(fā)處理、前后端交互隨便拿一個(gè)點(diǎn)都能展開講十幾分鐘。第二類是外包接單要么直接定制定做要么在這個(gè)基礎(chǔ)上替換成PHP、Python或C#的版本。這種垂直電商的邏輯是通用的換語言只是語法不同業(yè)務(wù)模型可以直接平移。第三類是個(gè)人學(xué)習(xí)。SpringBoot入門容易但想真正理解一個(gè)業(yè)務(wù)系統(tǒng)的完整鏈路沒有比從零實(shí)現(xiàn)一個(gè)電商更好的練手方式了。學(xué)完框架語法之后拿一個(gè)真實(shí)項(xiàng)目把知識(shí)點(diǎn)串起來效果甩看十套教程幾條街。2. SpringBoot技術(shù)選型與項(xiàng)目搭建全流程2.1 技術(shù)棧選型的底層邏輯用SpringBoot做這類系統(tǒng)技術(shù)選型的核心是夠用、好維護(hù)、教程多。在實(shí)際項(xiàng)目中我基本固定用這樣一套組合SpringBoot 2.7.x MyBatis-Plus MySQL 8.0 Redis MinIO Vue 2/Vue 3 Element UI。早期版本的SpringBoot 3.x引入了Jakarta命名空間很多老教程的示例代碼直接抄會(huì)報(bào)錯(cuò)對(duì)于新手非常不友好所以我更推薦先用2.7.x版本跑通業(yè)務(wù)后期再平滑升級(jí)。Java版本選JDK 8或JDK 11穩(wěn)定可靠。MyBatis-Plus確實(shí)是國(guó)內(nèi)開發(fā)者的福音單表CRUD幾乎不需要寫SQL條件構(gòu)造器讓動(dòng)態(tài)查詢變得非常直觀。Redis用于緩存熱門商品和輪播圖數(shù)據(jù)緩解數(shù)據(jù)庫(kù)壓力MinIO則負(fù)責(zé)商品圖片的存儲(chǔ)后面我會(huì)專門講為什么不用傳統(tǒng)本地路徑存儲(chǔ)。選這套技術(shù)棧的另一個(gè)原因是社區(qū)資料極其豐富。你搜SpringBoot整合XX前十條結(jié)果幾乎都是有效內(nèi)容。這一點(diǎn)在排錯(cuò)時(shí)比什么高深架構(gòu)都重要因?yàn)閯e人踩過的坑你大概率也會(huì)踩一遍。2.2 從零搭建SpringBoot項(xiàng)目的關(guān)鍵步驟項(xiàng)目初始化我建議直接走Spring Initializrstart.spring.io別手動(dòng)建目錄。選擇Java 8、Spring Boot 2.7.18依賴勾選Spring Web、MySQL Driver、Spring Data Redis、Lombok、Validation。生成后手動(dòng)引入MyBatis-Plus的依賴因?yàn)檫@不在初始化器的選項(xiàng)里。pom.xml里需要加的核心依賴大概是這樣的dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdio.minio/groupId artifactIdminio/artifactId version8.5.7/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency配置文件我也直接給出一份實(shí)測(cè)可用的application.yml核心片段server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/basketball_shop?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto這里有個(gè)特別容易踩的坑MySQL連接URL一定要指定serverTimezone不然系統(tǒng)時(shí)間和數(shù)據(jù)庫(kù)時(shí)間對(duì)不上可能導(dǎo)致日期字段錯(cuò)亂。我見過太多人因?yàn)樯倭诉@個(gè)參數(shù)訂單時(shí)間整整齊齊差了8個(gè)小時(shí)。2.3 Java與PHP、Python、C#方案的技術(shù)橫評(píng)標(biāo)題里提到了Java、PHP、Python、C#四個(gè)方向的方案很多朋友會(huì)糾結(jié)做畢設(shè)時(shí)到底選哪條路。我四個(gè)方向都做過交付給你一份我自己的橫向?qū)Ρ燃夹g(shù)路線學(xué)習(xí)門檻電商開發(fā)效率并發(fā)與事務(wù)能力部署環(huán)境要求典型適用人群Java SpringBoot中高高組件生態(tài)全強(qiáng)JVM稍吃內(nèi)存想做長(zhǎng)期后端開發(fā)的PHPThinkPHP/Laravel低很高上手快中輕量便宜追求快速交付、低成本部署PythonDjango/Flask低中中中偏向數(shù)據(jù)分析、AI方向的C#.NET Core中高強(qiáng)Windows/Linux均兼容Windows生態(tài)重度用戶我個(gè)人對(duì)PHP的評(píng)價(jià)是做小項(xiàng)目真的快數(shù)據(jù)模型一條命令生成后臺(tái)管理框架現(xiàn)成的多如果你只是想要一個(gè)能演示的商城PHP可能一天就能跑起來。但SpringBoot的優(yōu)勢(shì)在復(fù)雜業(yè)務(wù)的可靠性。電商系統(tǒng)最怕的不是寫不出來而是并發(fā)一高就出亂七八糟的數(shù)據(jù)問題。Java對(duì)線程、事務(wù)、鎖的支持以及強(qiáng)大的生態(tài)積累是長(zhǎng)期演進(jìn)最穩(wěn)的方案。還有一點(diǎn)比較功利但很現(xiàn)實(shí)招聘市場(chǎng)上Java后端崗位最多簡(jiǎn)歷里寫SpringBoot電商項(xiàng)目的認(rèn)可度要比PHP/Python項(xiàng)目高一個(gè)檔次。如果你是技術(shù)新人僅僅從求職角度講我也會(huì)建議你選Java路線。3. 數(shù)據(jù)庫(kù)設(shè)計(jì)與核心業(yè)務(wù)模塊落地3.1 籃球用品系統(tǒng)的表結(jié)構(gòu)設(shè)計(jì)思路數(shù)據(jù)庫(kù)設(shè)計(jì)直接決定了業(yè)務(wù)邏輯能不能順暢實(shí)現(xiàn)。對(duì)于一個(gè)垂直電商系統(tǒng)我建議最少設(shè)計(jì)這些表表名核心字段業(yè)務(wù)說明t_userid, username, password, nickname, phone, avatar, status用戶表status區(qū)分是否禁用t_addressid, user_id, receiver_name, receiver_phone, province, city, detail收貨地址表用戶可配多個(gè)t_categoryid, parent_id, name, sort類目表樹形結(jié)構(gòu)t_productid, category_id, name, subtitle, main_image, price, stock, sales, status, detail商品主表t_product_imageid, product_id, image_url, sort商品圖片表一個(gè)商品多圖t_cartid, user_id, product_id, quantity, checked購(gòu)物車表t_orderid, order_no, user_id, total_amount, pay_amount, status, address_snapshot, create_time訂單主表t_order_itemid, order_id, product_id, product_name, product_image, price, quantity訂單明細(xì)表t_carouselid, image_url, link_url, sort首頁輪播圖表有兩個(gè)設(shè)計(jì)細(xì)節(jié)我必須特別強(qiáng)調(diào)。訂單地址我用了快照的方式也就是下單那一刻把收貨地址的完整信息復(fù)制一份存到訂單表里而不是只存一個(gè)address_id。因?yàn)橛脩舻氖肇浀刂泛罄m(xù)可能修改如果只存ID訂單歷史數(shù)據(jù)就會(huì)出現(xiàn)地址漂移問題——下單的地址和后來看到的地址對(duì)不上。商品名稱和圖片同樣做快照將來商品改名或下架老訂單依然能正常展示歷史信息。這種快照思想在整個(gè)系統(tǒng)里其實(shí)很重要。電商業(yè)務(wù)里數(shù)據(jù)是動(dòng)態(tài)的而訂單是靜態(tài)的歷史事實(shí)兩者必須分開處理。每次下單都從實(shí)時(shí)數(shù)據(jù)生成快照這樣即使主表數(shù)據(jù)變動(dòng)你的訂單永遠(yuǎn)是好查的。3.2 商品SKU與庫(kù)存扣減的并發(fā)控制庫(kù)存扣減是電商系統(tǒng)的經(jīng)典考題也是面試官最愛問的點(diǎn)?；@球鞋有尺碼籃球服有顏色所以SKU設(shè)計(jì)通常有兩種做法簡(jiǎn)單一點(diǎn)是直接在商品表里放總庫(kù)存復(fù)雜一點(diǎn)是單獨(dú)建SKU表每個(gè)規(guī)格組合一條記錄。對(duì)于畢設(shè)和中小型項(xiàng)目我建議折中處理單規(guī)格商品直接庫(kù)存放在商品表上多規(guī)格商品用SKU表管理。SKU表字段大概是id, product_id, spec_infoJSON格式比如{color:紅色,size:42}), stock, price。這樣既能應(yīng)對(duì)多規(guī)格場(chǎng)景又不至于讓系統(tǒng)結(jié)構(gòu)過于臃腫。庫(kù)存扣減必須考慮并發(fā)安全。最經(jīng)典的寫法是樂觀鎖// 扣減庫(kù)存注意stock 0條件防止超賣 int count productMapper.deductStock(productId, quantity); if (count 0) { throw new BusinessException(庫(kù)存不足); }對(duì)應(yīng)的SQL邏輯在Mapper里update iddeductStock update t_product set stock stock - #{quantity}, sales sales #{quantity} where id #{productId} and stock #{quantity} /update這個(gè)寫法的巧妙之處在于它把檢查庫(kù)存和扣減庫(kù)存合并成了一個(gè)原子操作利用數(shù)據(jù)庫(kù)的行鎖保證并發(fā)扣減不超賣。在實(shí)際壓測(cè)里這種方案在單機(jī)和主從復(fù)制場(chǎng)景下的表現(xiàn)完全夠用。別再問我為什么不用悲觀鎖——性能差一截而且這種場(chǎng)景用樂觀鎖恰到好處。3.3 購(gòu)物車到訂單的完整事務(wù)鏈路購(gòu)物車和訂單是電商系統(tǒng)里最容易寫亂的部分。我建議把邏輯分層購(gòu)物車只管存什么訂單管怎么結(jié)算。購(gòu)物車的增刪改查沒有事務(wù)復(fù)雜度核心是下單那一刻的邏輯要設(shè)計(jì)嚴(yán)謹(jǐn)。下單接口的處理流程我整理成了七步校驗(yàn)用戶登錄態(tài)和購(gòu)物車中的勾選商品遍歷勾選商品預(yù)扣庫(kù)存用上面提到的樂觀鎖計(jì)算訂單金額商品單價(jià) × 數(shù)量注意判空防止價(jià)格不合法生成唯一訂單號(hào)并創(chuàng)建訂單主記錄批量創(chuàng)建訂單明細(xì)清空已結(jié)算的購(gòu)物車記錄全部成功則提交事務(wù)任一步失敗則回滾這里必須加Transactional注解。我見過最典型的問題是下單時(shí)庫(kù)存扣了但是購(gòu)物車沒清空或者訂單明細(xì)沒寫進(jìn)去導(dǎo)致數(shù)據(jù)對(duì)不上賬。給整個(gè)方法加上事務(wù)任何一步拋出異常都會(huì)被自動(dòng)回滾不會(huì)出現(xiàn)庫(kù)存少了但訂單沒生成這種事故。Transactional(rollbackFor Exception.class) public Order createOrder(Long userId, ListLong cartIds) { // 1. 查詢購(gòu)物車信息 // 2. 預(yù)扣庫(kù)存 // 3. 生成訂單號(hào) // 4. 創(chuàng)建訂單與明細(xì) // 5. 清理購(gòu)物車 }有一個(gè)細(xì)節(jié)要提醒訂單號(hào)和訂單金額一定要在事務(wù)內(nèi)生成不能直接拿前端傳過來的金額入庫(kù)。這是安全底線——你把價(jià)格參數(shù)暴露給前端數(shù)據(jù)包被別人改了怎么辦正確做法是后端根據(jù)商品庫(kù)存表實(shí)時(shí)計(jì)算金額前端傳的金額只做頁面展示參考后端必須重新計(jì)算。4. 前后端分離部署與MinIO對(duì)象存儲(chǔ)實(shí)戰(zhàn)4.1 商品圖片存儲(chǔ)為什么放棄本地路徑直存我見過太多SpringBoot教程里商品圖片傳著傳著就存在了E:/upload/這種本地路徑數(shù)據(jù)庫(kù)里存?zhèn)€http://localhost:8080/upload/xxx.jpg完事。誠(chéng)然本地直存最簡(jiǎn)單但部署時(shí)就成了大麻煩換服務(wù)器需要遷移圖片集群部署時(shí)文件不一致服務(wù)器故障圖片全丟而且還涉及靜態(tài)資源的路徑配置權(quán)限問題。實(shí)際上商品圖片這類非結(jié)構(gòu)化數(shù)據(jù)正確的姿勢(shì)是用對(duì)象存儲(chǔ)。大廠用阿里云OSS個(gè)人開發(fā)者用MinIO搭建私有對(duì)象存儲(chǔ)最合適。MinIO是一個(gè)開源的S3兼容對(duì)象存儲(chǔ)服務(wù)本地一臺(tái)服務(wù)器幾分鐘就能跑起來社區(qū)免費(fèi)版沒有功能閹割用來做畢設(shè)和中小項(xiàng)目綽綽有余。打個(gè)比方吧如果把應(yīng)用服務(wù)器比作一個(gè)便利店本地存儲(chǔ)就是在便利店倉(cāng)庫(kù)里堆雜物貨架滿了、倉(cāng)庫(kù)搬家都麻煩MinIO就是物美價(jià)廉的獨(dú)立物流倉(cāng)庫(kù)便利店只管收貨和驗(yàn)貨商品集中存儲(chǔ)在倉(cāng)庫(kù)中哪個(gè)門店需要就從倉(cāng)庫(kù)調(diào)貨完全不占門店空間。4.2 SpringBoot整合MinIO的關(guān)鍵步驟和代碼把MinIO加到SpringBoot項(xiàng)目里核心就是配好依賴、定義客戶端、寫工具類。首先是依賴我在pom.xml里用的是8.5.7版本連接地址直接用9000端口。配置文件的寫法如下minio: endpoint: http://localhost:9000 access-key: yourAccessKey secret-key: yourSecretKey bucket-name: basketball-shop工具類封裝我給出一個(gè)精簡(jiǎn)可用的版本Component public class MinioUtil { Value(${minio.endpoint}) private String endpoint; Value(${minio.access-key}) private String accessKey; Value(${minio.secret-key}) private String secretKey; Value(${minio.bucket-name}) private String bucketName; private MinioClient client; PostConstruct public void init() { client MinioClient.builder() .endpoint(endpoint) .credentials(accessKey, secretKey) .build(); } public String upload(MultipartFile file, String objectName) throws Exception { // 保證bucket存在 boolean exists client.bucketExists(BucketExistsArgs.builder().bucket(bucketName).build()); if (!exists) { client.makeBucket(MakeBucketArgs.builder().bucket(bucketName).build()); } client.putObject(PutObjectArgs.builder() .bucket(bucketName) .object(objectName) .stream(file.getInputStream(), file.getSize(), -1) .contentType(file.getContentType()) .build()); return endpoint / bucketName / objectName; } }對(duì)象名建議用UUID或者時(shí)間戳拼接避免中文文件名和重復(fù)文件覆蓋問題。另外注意一件事MinIO的endpoint地址在前端展示圖片時(shí)必須是前端能直接訪問到的地址。如果前端部署在80端口而后端MinIO在9000端口跨端口訪問會(huì)涉及跨域和網(wǎng)絡(luò)策略問題實(shí)測(cè)中建議給MinIO配一個(gè)nginx反向代理路徑用統(tǒng)一的域名入口解決。4.3 Vue打包產(chǎn)物與SpringBoot統(tǒng)一部署很多朋友用Vue寫了前端但不知道最后怎么把前后端合并部署。這里我直接說結(jié)論開發(fā)期用Vite/Webpack的代理轉(zhuǎn)發(fā)放后端上線期把Vue產(chǎn)物直接丟進(jìn)SpringBoot的src/main/resources/static目錄或者通過nginx反向代理指向兩者端口。最省事的方式是Vue打包后把dist目錄里的文件復(fù)制到SpringBoot的static目錄然后配置一個(gè)WebMvcConfigurer放行靜態(tài)資源。這樣用戶訪問8080端口就能同時(shí)拿到前端頁面和調(diào)用后端接口一個(gè)端口搞定全部。前端路由如果用了history模式還需要補(bǔ)充一個(gè)接口把404請(qǐng)求轉(zhuǎn)發(fā)到index.html否則刷新二級(jí)頁面會(huì)白屏。這個(gè)問題新手必踩提前幫你排掉Component public class WebConfig implements WebMvcConfigurer { Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController(/{path:[^\\.]*}).setViewName(forward:/index.html); } }這樣做的好處就是——部署只需要一個(gè)SpringBoot的jar包加一個(gè)MinIO服務(wù)結(jié)構(gòu)非常清爽。推薦有條件的朋友直接用docker-compose把MySQL、Redis、MinIO、SpringBoot四件套編排起來一條命令啟動(dòng)整棧演示時(shí)是真的省心。5. 核心業(yè)務(wù)邏輯與Java高頻技巧實(shí)戰(zhàn)5.1 商品搜索排序場(chǎng)景的MyBatis-Plus實(shí)踐商品列表頁的業(yè)務(wù)邏輯看起來簡(jiǎn)單實(shí)際寫代碼時(shí)有不少細(xì)節(jié)。前端會(huì)傳當(dāng)前頁碼、每頁條數(shù)、分類ID、搜索關(guān)鍵詞、價(jià)格區(qū)間、排序字段這些參數(shù)組合起來就是一次典型的動(dòng)態(tài)SQL查詢。MyBatis-Plus的LambdaQueryWrapper在這個(gè)場(chǎng)景非常好用public PageProductVO pageProducts(ProductQuery query) { PageProduct page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); // 分類篩選 if (query.getCategoryId() ! null) { ListLong categoryIds categoryService.getChildCategoryIds(query.getCategoryId()); wrapper.in(Product::getCategoryId, categoryIds); } // 關(guān)鍵詞搜索 if (StringUtils.hasText(query.getKeyword())) { wrapper.like(Product::getName, query.getKeyword()); } // 價(jià)格區(qū)間 if (query.getMinPrice() ! null) { wrapper.ge(Product::getPrice, query.getMinPrice()); } if (query.getMaxPrice() ! null) { wrapper.le(Product::getPrice, query.getMaxPrice()); } // 排序 if (price_asc.equals(query.getSort())) { wrapper.orderByAsc(Product::getPrice); } else if (price_desc.equals(query.getSort())) { wrapper.orderByDesc(Product::getPrice); } else if (sales_desc.equals(query.getSort())) { wrapper.orderByDesc(Product::getSales); } else { wrapper.orderByDesc(Product::getCreateTime); } return productMapper.selectPage(page, wrapper); }這里有個(gè)經(jīng)驗(yàn)之談排序字段不要直接拼接前端傳參要用白名單映射。前端要什么排序就先映射成固定選項(xiàng)再把對(duì)應(yīng)的排序條件寫死進(jìn)代碼。否則用戶傳一個(gè)ordername desc, password, 配合拼接可能就出SQL注入的洞這類安全底線不能破。5.2 訂單號(hào)生成與字符串截取處理的實(shí)戰(zhàn)細(xì)節(jié)有些朋友會(huì)直接拿數(shù)據(jù)庫(kù)自增ID當(dāng)訂單號(hào)這樣做的風(fēng)險(xiǎn)顯而易見訂單號(hào)可以被猜測(cè)競(jìng)爭(zhēng)對(duì)手能通過訂單號(hào)推算你的日單量。正確的做法是生成獨(dú)立的業(yè)務(wù)訂單號(hào)我常用的方案是時(shí)間戳 用戶ID 隨機(jī)數(shù)組合public String generateOrderNo(Long userId) { // 格式年月日時(shí)分秒 用戶ID后四位 四位隨機(jī)數(shù) String timePart new SimpleDateFormat(yyyyMMddHHmmss).format(new Date()); String userPart String.format(%04d, userId % 10000); String randomPart String.format(%04d, new Random().nextInt(10000)); return timePart userPart randomPart; }這個(gè)訂單號(hào)方案生成出來的長(zhǎng)度是22位左右可讀性好、不重復(fù)、不容易被推算出業(yè)務(wù)量在中小項(xiàng)目里非常夠用。訂單號(hào)還有一個(gè)場(chǎng)景需要處理取消訂單和退款時(shí)用什么保證請(qǐng)求的冪等性每次對(duì)同一個(gè)訂單發(fā)起取消不能重復(fù)回滾庫(kù)存。我的做法是在訂單表加一個(gè)status字段用UPDATE t_order SET status 5 WHERE id ? AND status 3這種帶條件的更新如果更新影響行數(shù)為0說明訂單狀態(tài)已變化或不允許取消直接返回失敗。這種做法非常樸素但極其可靠簡(jiǎn)單業(yè)務(wù)場(chǎng)景就不需要上分布式鎖了。說到字符串處理Java里截取、格式化、拼接這些操作在業(yè)務(wù)開發(fā)中比算法題里的所謂高級(jí)用法出現(xiàn)頻率高得多。比如截取訂單號(hào)的日期部分、處理手機(jī)號(hào)脫敏中間四位打碼、把URL參數(shù)里的字符串轉(zhuǎn)數(shù)字——這類通過String.substring、Integer.parseInt、StringBuilder就能解決的問題多寫幾輪業(yè)務(wù)代碼自然就熟練了。5.3 事務(wù)邊界、冪等設(shè)計(jì)與并發(fā)防護(hù)的組合拳SpringBoot里做事務(wù)管理核心就是搞清楚什么方法該加事務(wù)、事務(wù)邊界放在哪。我總結(jié)的實(shí)操原則很簡(jiǎn)單事務(wù)的粒度要盡可能小放在服務(wù)層不要放在控制器層?？刂破鲗邮墙涌谌肟谌绻谶@里加Transactional增大了事務(wù)范圍還會(huì)讓接口的異常處理和事務(wù)邏輯耦合在一起代碼很難看。在Service層方法上加上Transactional(rollbackFor Exception.class)一旦方法內(nèi)部拋出異常所有數(shù)據(jù)庫(kù)操作都會(huì)回滾。rollbackFor要指定成Exception.class因?yàn)镾pring默認(rèn)只對(duì)運(yùn)行時(shí)異?；貪L對(duì)于檢查異常默認(rèn)不會(huì)回滾這個(gè)坑很隱蔽。購(gòu)物車到訂單的鏈路能不能串起來核心就在于用戶狀態(tài)、商品狀態(tài)、庫(kù)存狀態(tài)這三者的聯(lián)動(dòng)。我在這里用了一個(gè)小技巧用商品ID 用戶ID 添加時(shí)間作為購(gòu)物車行的唯一排查線索一旦出現(xiàn)加購(gòu)商品和下單商品不一致的詭異問題可以通過日志快速定位。冪等設(shè)計(jì)里比較典型的就是支付回調(diào)。如果用支付寶沙箱支付成功后的異步回調(diào)可能會(huì)重復(fù)通知。處理方式是在回調(diào)接口里先查訂單當(dāng)前狀態(tài)如果已經(jīng)是已支付直接返回成功不再重復(fù)處理。這樣既能保證冪等也能避免重復(fù)更新訂單導(dǎo)致異常。6. 安全防護(hù)、部署優(yōu)化與問題排查實(shí)錄6.1 用戶認(rèn)證與權(quán)限控制的落地做法電商系統(tǒng)最怕什么最怕用戶隨意篡改數(shù)據(jù)、越權(quán)訪問他人訂單。我用JWT做登錄態(tài)管理登錄成功后簽發(fā)一個(gè)Token返回給前端前端每次請(qǐng)求都在請(qǐng)求頭帶上Authorization: Bearer xxx后端定義攔截器統(tǒng)一解析校驗(yàn)。JWT的核心邏輯不復(fù)雜我常用jjwt實(shí)現(xiàn)public String createToken(Long userId, String username) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(username, username) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }密碼存儲(chǔ)的問題也必須重視。我見過一些老項(xiàng)目把密碼明文存數(shù)據(jù)庫(kù)一旦數(shù)據(jù)泄露全部賬號(hào)裸奔這種低級(jí)失誤不能犯。更不要自己寫什么加密算法直接用業(yè)界公認(rèn)的BCrypt就可以用法也簡(jiǎn)單注冊(cè)時(shí)BCrypt.hashpw加密入庫(kù)登錄時(shí)BCrypt.checkpw比對(duì)。這種加鹽哈希的方案在暴力破解面前安全性遠(yuǎn)比MD5、SHA1可靠得多。權(quán)限控制方面后臺(tái)管理接口必須校驗(yàn)管理員身份而不是只靠前端隱藏按鈕。思路也很樸素定義一個(gè)RequireAdmin注解配合攔截器對(duì)/admin/**路徑統(tǒng)一校驗(yàn)Token的role字段。別小看這一行配置沒有它你的后臺(tái)管理接口等于裸奔——任何人只要知道接口路徑就能調(diào)用。6.2 SQL注入、越權(quán)與接口防刷的防護(hù)清單我總結(jié)了電商系統(tǒng)上線前必須要過的安全檢查缺任何一個(gè)都可能出事SQL注入MyBatis-Plus的LambdaQueryWrapper天然防注入但手寫SQL拼接時(shí)必須用#{}而不是${}。傳表名、排序字段這種必須動(dòng)態(tài)的部分就做白名單校驗(yàn)。越權(quán)訪問查詢訂單詳情必須先校驗(yàn)訂單的user_id是否等于當(dāng)前登錄用戶。光靠前端隱藏按鈕防不了直接發(fā)HTTP請(qǐng)求后端必須層層校驗(yàn)。接口防刷登錄接口和發(fā)送驗(yàn)證碼接口容易被腳本刷。簡(jiǎn)單方案是Redis存接口調(diào)用計(jì)數(shù)同一IP一分鐘內(nèi)超過N次直接拒絕。不追求性能的話用Guava RateLimiter做單機(jī)限流也行。文件上傳檢查文件擴(kuò)展名和Content-Type限制上傳大小上傳目錄禁止解析腳本。如果上傳了惡意文件被當(dāng)作靜態(tài)資源訪問那就是妥妥的服務(wù)器淪陷了。接口參數(shù)校驗(yàn)用JSR 303的NotNull、Min、Max這種注解在Controller層做基礎(chǔ)校驗(yàn)業(yè)務(wù)層再校驗(yàn)業(yè)務(wù)規(guī)則防御縱深才有意義。我還補(bǔ)一個(gè)很隱蔽但常見的坑商城項(xiàng)目里redis存的購(gòu)物車臨時(shí)數(shù)據(jù)key一定要加userId區(qū)分不然用戶A登錄后能看到用戶B的購(gòu)物車。6.3 高頻部署問題排查速查表最后送你一份我自己項(xiàng)目上線的避坑清單全是實(shí)測(cè)遇到過的問題現(xiàn)象根本原因解決方案前端能打開但接口請(qǐng)求404前端路由history模式刷新失敗配置forward到index.html圖片上傳成功但頁面不顯示MinIO地址未做路徑代理或桶權(quán)限是私有設(shè)置桶訪問策略為public或nginx代理數(shù)據(jù)庫(kù)中文亂碼URL未指定UTF-8或表字符集不對(duì)連接URL加characterEncodingutf8表用utf8mb4登錄后接口返回401前端沒帶Token頭或Token過期檢查攔截器放行白名單前端統(tǒng)一請(qǐng)求攔截器加頭端口被占用上一次運(yùn)行的進(jìn)程沒殺掉netstat -ano應(yīng)用啟動(dòng)報(bào)連接池錯(cuò)誤MySQL沒啟動(dòng)或賬號(hào)密碼錯(cuò)先本地客戶端測(cè)試連接再排查配置靜態(tài)資源加載緩慢文件沒走CDN/反代nginx部署靜態(tài)資源并開啟gzip壓縮部署后時(shí)間差8小時(shí)時(shí)區(qū)配置不一致JVM參數(shù)加-Duser.timezoneGMT8數(shù)據(jù)庫(kù)連接加serverTimezone從建表到下單從上傳到部署整個(gè)SpringBoot籃球用品網(wǎng)購(gòu)系統(tǒng)做下來我最大的感觸是框架本身沒那么神奇真正值錢的是對(duì)業(yè)務(wù)細(xì)節(jié)的把控。我在一個(gè)實(shí)際項(xiàng)目里被訂單金額對(duì)不上賬這個(gè)問題折磨過整整一天——最后發(fā)現(xiàn)是因?yàn)榍岸税焉唐穯蝺r(jià)傳給后端而我只是想當(dāng)然地直接用了這個(gè)值。從那以后所有金額一律以數(shù)據(jù)庫(kù)為準(zhǔn)前端傳上來的數(shù)字只做展示校驗(yàn)。最后再分享一個(gè)小技巧開發(fā)階段一定把MyBatis-Plus的SQL日志打開用StdOutImpl打印到控制臺(tái)調(diào)試時(shí)看一眼實(shí)際執(zhí)行的SQL比什么都直觀。等你SQL日志看熟了很多玄學(xué)bug其實(shí)一眼就能定位是邏輯問題還是數(shù)據(jù)問題。這個(gè)系統(tǒng)后續(xù)的擴(kuò)展空間也不小你可以加一個(gè)秒殺模塊練練Redis分布式鎖也可以加一個(gè)數(shù)據(jù)統(tǒng)計(jì)面板用定時(shí)任務(wù)算出每日銷量走勢(shì)。技術(shù)在迭代業(yè)務(wù)是相通的把這套電商流程吃透了以后接什么垂直品類的單子都不慌。