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