實(shí)戰(zhàn)：從數(shù)據(jù)庫(kù)設(shè)計(jì)到部署上線)
去年接了一個(gè)服裝批發(fā)客戶的單子需求很直接要做一套商城系統(tǒng)前端能展示商品、加購(gòu)物車(chē)、下單后臺(tái)要管商品、訂單、庫(kù)存和會(huì)員還得留出以后接優(yōu)惠券、拼團(tuán)這些營(yíng)銷(xiāo)功能的余地。我最終選了SpringBoot Vue3這套組合來(lái)落地整套系統(tǒng)從前端頁(yè)面到后端接口全部自己搭前后花了差不多三周時(shí)間完成核心流程。這套“springbootvue3服裝商城銷(xiāo)售管理系統(tǒng)”做完之后無(wú)論是拿來(lái)接私活還是作為畢業(yè)設(shè)計(jì)都很值得復(fù)盤(pán)一遍。這個(gè)項(xiàng)目的價(jià)值不在于“商城”本身有多復(fù)雜而在于它把電商業(yè)務(wù)里最典型的幾個(gè)環(huán)節(jié)——商品中心、購(gòu)物車(chē)、訂單流轉(zhuǎn)、庫(kù)存扣減、權(quán)限控制——完整地串起來(lái)了。前端用 Vue3 的組合式 API 配合 Pinia 管理狀態(tài)后端用 SpringBoot 做 RESTful 接口安全認(rèn)證走 JWT RBAC數(shù)據(jù)層用 MyBatis-Plus 操作 MySQL。整套方案不吊高難度但每個(gè)模塊都是實(shí)實(shí)在在能跑的很適合想系統(tǒng)掌握前后端分離開(kāi)發(fā)流程的人拿來(lái)練手。1. 項(xiàng)目整體定位與方案拆解1.1 商城系統(tǒng)的核心需求到底有哪些做系統(tǒng)之前先別急著寫(xiě)代碼把需求拆清楚比什么技術(shù)選型都重要。服裝商城這類(lèi)銷(xiāo)售管理系統(tǒng)表面上是“賣(mài)衣服”實(shí)際上拆開(kāi)來(lái)看需求可以分成三條主線面向顧客的購(gòu)物流程、面向運(yùn)營(yíng)的商品管理、面向財(cái)務(wù)和管理層的訂單與數(shù)據(jù)統(tǒng)計(jì)。顧客端的完整鏈路是注冊(cè)登錄 → 瀏覽商品列表/詳情 → 搜索和篩選按品類(lèi)、價(jià)格、顏色、尺碼 → 加入購(gòu)物車(chē) → 提交訂單 → 模擬支付 → 查看訂單狀態(tài)。運(yùn)營(yíng)端的鏈路是維護(hù)商品分類(lèi) → 上架/下架商品 → 管理商品規(guī)格SKU價(jià)格和庫(kù)存 → 處理訂單發(fā)貨、備注 → 查看會(huì)員列表。管理層關(guān)心的則是銷(xiāo)售數(shù)據(jù)這部分我用了一個(gè)簡(jiǎn)單的統(tǒng)計(jì)接口來(lái)支撐比如按日/按月匯總銷(xiāo)售額、熱門(mén)商品排行等。這個(gè)項(xiàng)目里我把用戶端和管理端合并成了一個(gè)前端工程通過(guò)路由權(quán)限來(lái)區(qū)分角色。管理員登錄后能看到后臺(tái)菜單普通用戶只能看到商城頁(yè)面。這么做的好處是部署簡(jiǎn)單不用維護(hù)兩套前端應(yīng)用也方便統(tǒng)一處理登錄態(tài)。1.2 為什么是 SpringBoot Vue3而不是別的組合技術(shù)選型這件事我一直秉持“夠用、順手、好招人”的原則。SpringBoot 不用多說(shuō)Java 后端在電商這塊的生態(tài)太成熟了MyBatis-Plus 做單表 CRUD 幾乎零成本Spring Security 或者簡(jiǎn)單的攔截器都能搞定鑒權(quán)數(shù)據(jù)庫(kù)用 MySQL 也完全扛得住商城這個(gè)量級(jí)。前端選 Vue3 而不是 Vue2核心原因是組合式 API 在邏輯復(fù)用上太舒服了。商城這種業(yè)務(wù)購(gòu)物車(chē)邏輯、登錄態(tài)邏輯、商品篩選邏輯都是跨頁(yè)面復(fù)用的用 composable自定義組合函數(shù)可以把這些邏輯抽出來(lái)比 Vue2 時(shí)代寫(xiě) mixin 要清晰得多。配套的 Element Plus 組件庫(kù)在后臺(tái)管理界面上完全是量身定做表格、表單、彈窗、分頁(yè)全都現(xiàn)成。還有一個(gè)很實(shí)際的原因Vue3 的生態(tài)現(xiàn)在已經(jīng)很成熟了。Vite 的啟動(dòng)速度比 Webpack 快一個(gè)量級(jí)開(kāi)發(fā)體驗(yàn)好很多。Pinia 相比 Vuex 的樣板代碼少了一大截修改狀態(tài)不需要寫(xiě)一堆 mutation直接改 store 里的 state 就行這對(duì)商城這種狀態(tài)交互頻繁的場(chǎng)景特別友好。1.3 前后端分離的項(xiàng)目結(jié)構(gòu)這樣規(guī)劃整個(gè)工程我拆成了兩個(gè)目錄互不干擾clothing-server/ # SpringBoot 后端工程 ├── src/main/java/com/cshop │ ├── controller/ # 接口層 │ ├── service/ # 業(yè)務(wù)邏輯層 │ ├── mapper/ # MyBatis-Plus 數(shù)據(jù)訪問(wèn)層 │ ├── entity/ # 實(shí)體類(lèi) │ ├── dto/ # 前端傳參對(duì)象 │ ├── vo/ # 返回給前端的數(shù)據(jù)對(duì)象 │ ├── config/ # 配置類(lèi)跨域、攔截器、MyBatis-Plus │ ├── utils/ # JWT工具、統(tǒng)一返回結(jié)果封裝 │ └── CShopApplication.java └── src/main/resources/ ├── application.yml └── mapper/ # 復(fù)雜SQL的XML文件 clothing-web/ # Vue3 前端工程 ├── src/ │ ├── api/ # 接口請(qǐng)求封裝 │ ├── assets/ # 靜態(tài)資源 │ ├── components/ # 通用組件商品卡片、分頁(yè)等 │ ├── composables/ # 組合式函數(shù)購(gòu)物車(chē)、登錄態(tài) │ ├── router/ # 路由配置含權(quán)限守衛(wèi) │ ├── stores/ # Pinia 狀態(tài)管理 │ ├── views/ # 頁(yè)面商城首頁(yè)、商品詳情、后臺(tái)管理 │ └── utils/ # axios實(shí)例、工具函數(shù) └── vite.config.js后端按“Controller → Service → Mapper”三層去寫(xiě)Controller 只管參數(shù)接收和結(jié)果返回業(yè)務(wù)邏輯全在 Service 層。這樣后期如果要把某個(gè)接口拆成微服務(wù)或者引入消息隊(duì)列做訂單異步處理改動(dòng)成本都控制得住。前端按“頁(yè)面 → 組件 → API”分層所有請(qǐng)求都走src/api里封裝的函數(shù)不放裸 axios 調(diào)用在頁(yè)面里。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)與核心表建模2.1 商品表SPU 和 SKU 必須分開(kāi)建商品建模是商城系統(tǒng)的地基這塊設(shè)計(jì)錯(cuò)了后面全是坑。服裝類(lèi)商品有個(gè)典型特點(diǎn)一件衛(wèi)衣SPU會(huì)有多個(gè)顏色、多個(gè)尺碼每個(gè)顏色尺碼組合對(duì)應(yīng)一個(gè)價(jià)格和一份庫(kù)存這就是 SKUStock Keeping Unit。如果把顏色尺碼直接橫著寫(xiě)在商品表里加一個(gè)顏色就要改表結(jié)構(gòu)想想就頭大。我建了兩張表CREATE TABLE spu ( id bigint PRIMARY KEY AUTO_INCREMENT, name varchar(255) NOT NULL COMMENT 商品名稱, category_id bigint COMMENT 所屬類(lèi)目ID, main_image varchar(255) COMMENT 主圖URL, detail text COMMENT 商品詳情富文本, status tinyint DEFAULT 1 COMMENT 1上架 0下架, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE sku ( id bigint PRIMARY KEY AUTO_INCREMENT, spu_id bigint NOT NULL COMMENT 所屬SPU, color varchar(50) COMMENT 顏色, size varchar(20) COMMENT 尺碼, price decimal(10,2) NOT NULL COMMENT 售價(jià), stock int NOT NULL DEFAULT 0 COMMENT 庫(kù)存, image varchar(255) COMMENT SKU圖片, status tinyint DEFAULT 1 );查詢商品詳情的時(shí)候先查 SPU 基本信息再根據(jù) SPU ID 查 SKU 列表。前端展示的時(shí)候用color和size兩個(gè)維度做聯(lián)動(dòng)選擇。價(jià)格區(qū)間比如“199-299”可以直接用 SQLMIN(price)和MAX(price)聚合出來(lái)不用額外冗余字段。2.2 訂單與庫(kù)存表庫(kù)存扣減的兩種模式訂單這塊我用了電商最標(biāo)準(zhǔn)的“訂單主表 訂單明細(xì)表”結(jié)構(gòu)另外單拆了一張購(gòu)物車(chē)表。訂單主表存收貨人信息、訂單總金額、訂單狀態(tài)明細(xì)表存每個(gè) SKU 的購(gòu)買(mǎi)數(shù)量、成交單價(jià)、商品快照。商品快照這個(gè)字段很重要因?yàn)樯唐穬r(jià)格、名稱可能會(huì)變但歷史訂單里的信息必須保持下單那一刻的樣子。CREATE TABLE orders ( id bigint PRIMARY KEY AUTO_INCREMENT, order_no varchar(64) NOT NULL UNIQUE COMMENT 訂單號(hào), user_id bigint NOT NULL, total_amount decimal(10,2) NOT NULL, status tinyint NOT NULL DEFAULT 0 COMMENT 0待付款 1已付款 2已發(fā)貨 3已完成 4已取消, receiver_name varchar(50), receiver_phone varchar(20), receiver_address varchar(255), create_time datetime DEFAULT CURRENT_TIMESTAMP, pay_time datetime ); CREATE TABLE order_item ( id bigint PRIMARY KEY AUTO_INCREMENT, order_id bigint NOT NULL, spu_id bigint, sku_id bigint, sku_snapshot varchar(500) COMMENT SKU信息快照(JSON), goods_name varchar(255), price decimal(10,2), quantity int );庫(kù)存扣減我選了下單時(shí)直接扣減的方案而不是支付時(shí)才扣。為什么因?yàn)橹Ц妒悄M的用戶很可能“下單后不付款”如果庫(kù)存不先鎖住就會(huì)出現(xiàn)超賣(mài)10 件庫(kù)存有 20 個(gè)人下單成功后面真正付款的人反而沒(méi)貨了。當(dāng)然只扣不減也不行所以訂單表里加了個(gè)超時(shí)狀態(tài)超過(guò) 30 分鐘未支付就把庫(kù)存加回去這樣既防止了超賣(mài)也避免了僵尸訂單占用庫(kù)存。2.3 用戶與權(quán)限RBAC 模型在公司項(xiàng)目里最穩(wěn)妥用戶體系我沒(méi)用復(fù)雜的方案就是標(biāo)準(zhǔn)的 RBAC用戶-角色-菜單三張表加兩張關(guān)聯(lián)表。一個(gè)用戶可以有多個(gè)角色一個(gè)角色可以訪問(wèn)多個(gè)菜單按鈕。商城場(chǎng)景里只需要兩種角色一個(gè)是ROLE_USER一個(gè)是ROLE_ADMIN但表結(jié)構(gòu)我依然按通用 RBAC 來(lái)做方便后續(xù)加運(yùn)營(yíng)、客服這類(lèi)角色。菜單表里直接存前端路由的path和組件路徑登錄后根據(jù)用戶角色動(dòng)態(tài)生成可訪問(wèn)的路由表前端配合路由守衛(wèi)做菜單渲染和頁(yè)面攔截。這樣后期要加權(quán)限只需要在數(shù)據(jù)庫(kù)里給角色掛菜單不用改代碼。3. 后端核心模塊實(shí)現(xiàn)要點(diǎn)3.1 JWT 登錄認(rèn)證與權(quán)限攔截?cái)r截器比框架更省心登錄接口的邏輯很直白接收用戶名密碼 → 查數(shù)據(jù)庫(kù)比對(duì)密碼MD5 加鹽 → 生成 JWT 返回給前端。前端把 token 存在 localStorage 里之后每次請(qǐng)求在 axios 攔截器里加到請(qǐng)求頭Authorization。后端我寫(xiě)了個(gè)AuthInterceptor實(shí)現(xiàn)HandlerInterceptor接口Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登錄、注冊(cè)等接口 String uri request.getRequestURI(); if (uri.contains(/api/auth/login) || uri.contains(/api/auth/register)) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登錄); } // 解析token把用戶ID放進(jìn)去 Long userId JwtUtils.parseToken(token.replace(Bearer , )); request.setAttribute(userId, userId); return true; }有同學(xué)會(huì)問(wèn)為什么不直接用 Spring Security說(shuō)實(shí)話如果只是做用戶認(rèn)證和角色判斷Spring Security 的配置成本遠(yuǎn)高于一個(gè)攔截器。Spring Security 適合權(quán)限規(guī)則很復(fù)雜的場(chǎng)景比如按鈕級(jí)細(xì)粒度權(quán)限、OAuth2 第三方登錄這個(gè)服裝商城的管理端就兩類(lèi)角色攔截器里判斷一下角色類(lèi)型完全夠了代碼還更直觀。如果以后要接入 Spring Security這兩套邏輯也可以平滑替換。3.2 商品管理與文件上傳OSS 和本地存儲(chǔ)怎么選后臺(tái)商品管理主要是商品的增刪改查。圖片上傳我重點(diǎn)說(shuō)一下因?yàn)檫@是最容易出 bug 的地方。文件上傳選擇有兩條路一種是傳到阿里云 OSS 這類(lèi)對(duì)象存儲(chǔ)適合部署在云服務(wù)器上的正式項(xiàng)目帶寬和存儲(chǔ)都有保障另一種是傳到項(xiàng)目本地目錄適合本地跑著玩或者部署在廉價(jià)服務(wù)器上的場(chǎng)景。我項(xiàng)目里做了一個(gè)折中圖片保存到服務(wù)器磁盤(pán)的指定路徑數(shù)據(jù)庫(kù)只存訪問(wèn) URL。配置文件里用upload.path指定存儲(chǔ)路徑再用一個(gè)WebMvcConfig把路徑映射成靜態(tài)資源訪問(wèn)registry.addResourceHandler(/images/**) .addResourceLocations(file: uploadPath /);這樣圖片就能通過(guò)http://localhost:8080/images/xxx.jpg直接訪問(wèn)了。部署到服務(wù)器的時(shí)候改一下配置路徑即可不用動(dòng)代碼。上傳接口最后會(huì)返回一個(gè)完整的圖片 URL前端el-upload組件拿到 URL 后直接塞進(jìn)表單字段里預(yù)覽回顯都很方便。3.3 下單流程與庫(kù)存扣減事務(wù)和鎖缺一不可下單是整個(gè)系統(tǒng)里最需要小心的環(huán)節(jié)。我的實(shí)現(xiàn)邏輯是這樣的校驗(yàn)購(gòu)物車(chē)?yán)锏?SKU 是否上架價(jià)格是否變化校驗(yàn)庫(kù)存是否充足計(jì)算訂單總金額創(chuàng)建訂單主表和明細(xì)扣減 SKU 庫(kù)存清空對(duì)應(yīng)購(gòu)物車(chē)記錄這幾步必須在一個(gè)事務(wù)里完成任何一步失敗都要全部回滾否則會(huì)出現(xiàn)“訂單建了但庫(kù)存沒(méi)扣”的臟數(shù)據(jù)。用Transactional注解包住整個(gè)方法另外在扣庫(kù)存的 SQL 上加了條件判斷UPDATE sku SET stock stock - #{quantity} WHERE id #{skuId} AND stock #{quantity}如果update影響行數(shù)為 0說(shuō)明庫(kù)存不足直接拋異常回滾這樣在高并發(fā)下也不會(huì)超賣(mài)。這個(gè)寫(xiě)法比先查后改多了一層保障——查詢和更新之間可能插入別的請(qǐng)求但帶條件的 UPDATE 語(yǔ)句本身是原子性的。對(duì)于這個(gè)量級(jí)的項(xiàng)目來(lái)說(shuō)它開(kāi)箱即用且足夠安全。3.4 統(tǒng)一返回結(jié)果與全局異常優(yōu)雅接口的第一步接口風(fēng)格統(tǒng)一是我一直強(qiáng)調(diào)的。我封裝了一個(gè)ResultT類(lèi)所有接口都返回統(tǒng)一的 JSON 結(jié)構(gòu){ code: 200, message: success, data: { } }同時(shí)用RestControllerAdvice做全局異常處理。業(yè)務(wù)異常返回對(duì)應(yīng)的錯(cuò)誤碼和提示比如庫(kù)存不足返回 5001未登錄返回 401參數(shù)校驗(yàn)失敗返回 400。這樣前端只需要在 axios 響應(yīng)攔截器里統(tǒng)一判斷 code彈錯(cuò)誤提示就行不需要每個(gè)接口單獨(dú)寫(xiě) try-catch。4. 前端 Vue3 落地實(shí)踐4.1 Vite 初始化項(xiàng)目與目錄規(guī)劃前端工程我是用 Vite 初始化創(chuàng)建的命令也很簡(jiǎn)單npm create vitelatest clothing-web -- --template vue然后安裝關(guān)鍵依賴npm install vue-router4 pinia axios element-plusVite 相比 Webpack 的啟動(dòng)速度確實(shí)快幾秒就能起服務(wù)熱更新也是毫秒級(jí)。有個(gè)要注意的地方是 Vite 的端口默認(rèn)是 5173而后端接口跑在 8080所以必須在vite.config.js里配開(kāi)發(fā)代理把/api前綴的請(qǐng)求轉(zhuǎn)發(fā)到后端地址順便解決跨域問(wèn)題export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })生產(chǎn)打包之后Nginx 里也配同樣的代理規(guī)則前后端部署在不同端口時(shí)就不會(huì)有跨域煩惱。4.2 axios 封裝與登錄態(tài)刷新機(jī)制前端請(qǐng)求封裝我習(xí)慣統(tǒng)一放在utils/request.js里。創(chuàng)建一個(gè) axios 實(shí)例設(shè)置 baseURL 為/api然后加請(qǐng)求攔截器和響應(yīng)攔截器const request axios.create({ baseURL: /api, timeout: 10000 }) // 請(qǐng)求攔截器自動(dòng)帶token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 響應(yīng)攔截器統(tǒng)一處理業(yè)務(wù)錯(cuò)誤和登錄過(guò)期 request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 請(qǐng)求失敗) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) localStorage.removeItem(userInfo) router.push(/login) ElMessage.warning(登錄已過(guò)期請(qǐng)重新登錄) } return Promise.reject(error) } )401 統(tǒng)一跳轉(zhuǎn)登錄頁(yè)的邏輯放在攔截器里能省掉每個(gè)頁(yè)面判斷 token 是否失效的重復(fù)代碼。登錄成功后把token和userInfo都存在 localStorage刷新瀏覽器也不會(huì)丟登錄態(tài)。4.3 購(gòu)物車(chē)與訂單狀態(tài)管理Pinia 比 localStorage 靠譜購(gòu)物車(chē)狀態(tài)我存在了 Pinia 里。為什么不直接用 localStorage兩個(gè)原因一是購(gòu)物車(chē)的狀態(tài)需要多頁(yè)面共享頁(yè)面組件里用useCartStore()就能拿到跨組件通信成本為零二是購(gòu)物車(chē)數(shù)量和選中狀態(tài)需要響應(yīng)式更新localStorage 沒(méi)有響應(yīng)式能力操作完還得手動(dòng)刷新視圖。購(gòu)物車(chē) store 的核心就是維護(hù)一個(gè)列表提供添加、刪除、修改數(shù)量、勾選的方法。每次變更之后調(diào)后端接口同步同時(shí)也把最新?tīng)顟B(tài)同步一份到 localStorage 做持久化頁(yè)面刷新后從 localStorage 恢復(fù)。這樣既不丟失數(shù)據(jù)也保留了響應(yīng)式的交互體驗(yàn)。export const useCartStore defineStore(cart, { state: () ({ items: JSON.parse(localStorage.getItem(cart_items) || []) }), actions: { addToCart(item) { const index this.items.findIndex(i i.skuId item.skuId) if (index -1) { this.items[index].quantity item.quantity } else { this.items.push(item) } this.save() }, removeItem(skuId) { this.items this.items.filter(i i.skuId ! skuId) this.save() }, save() { localStorage.setItem(cart_items, JSON.stringify(this.items)) } } })4.4 Element Plus 后臺(tái)管理界面搭建后臺(tái)管理頁(yè)面其實(shí)就是典型的“左側(cè)菜單 右側(cè)內(nèi)容區(qū)”布局。我用 Element Plus 的el-container、el-aside、el-menu搭框架商品管理用el-table展示數(shù)據(jù)配分頁(yè)、搜索、彈窗編輯三個(gè)基礎(chǔ)能力。訂單管理在此基礎(chǔ)上增加了篩選標(biāo)簽按狀態(tài)過(guò)濾和操作按鈕發(fā)貨、查看詳情。商品編輯表單里用到了el-upload上傳圖片:action指向后端的圖片上傳接口on-success回調(diào)里把返回的圖片 URL 賦值給表單字段。這里有個(gè)細(xì)節(jié)el-upload上傳組件走的是原生 XMLHttpRequest沒(méi)法帶上 axios 攔截器里的 Authorization 請(qǐng)求頭所以要在組件上顯式傳headers屬性el-upload :actionuploadUrl :headers{ Authorization: Bearer localStorage.getItem(token) } :on-successhandleUploadSuccess el-button上傳圖片/el-button /el-upload4.5 前端路由守衛(wèi)沒(méi)有登錄就看不了后臺(tái)動(dòng)態(tài)路由權(quán)限這塊我用的是最簡(jiǎn)單的方案在路由配置里給后臺(tái)頁(yè)面加meta: { requiresAuth: true, roles: [ROLE_ADMIN] }然后在全局前置守衛(wèi)里判斷router.beforeEach((to, from, next) { const token localStorage.getItem(token) const userInfo JSON.parse(localStorage.getItem(userInfo) || {}) if (to.meta.requiresAuth) { if (!token) { next(/login) } else if (to.meta.roles !to.meta.roles.includes(userInfo.role)) { next(/) } else { next() } } else { next() } })菜單渲染是在登錄后根據(jù)userInfo.role來(lái)判斷管理員顯示全部菜單普通用戶隱藏后臺(tái)菜單入口。這套方案雖然不像動(dòng)態(tài)路由那樣能在后端配置菜單但應(yīng)付兩個(gè)角色的商城系統(tǒng)完全足夠?qū)懫饋?lái)也直觀。5. 關(guān)鍵業(yè)務(wù)場(chǎng)景的實(shí)現(xiàn)細(xì)節(jié)5.1 多規(guī)格商品選擇聯(lián)動(dòng)顏色和尺碼怎么匹配 SKU服裝商城最典型的交互場(chǎng)景就是選顏色選尺碼。前端拿到商品詳情后把當(dāng)前 SPU 的所有 SKU 列表存在本地然后根據(jù)用戶選擇的顏色、尺碼組合去匹配 SKU。匹配到了就顯示價(jià)格和庫(kù)存匹配不到就提示“該規(guī)格暫時(shí)缺貨”。在 Vue3 里這個(gè)邏輯很適合放在computed里實(shí)現(xiàn)const selectedSku computed(() { return props.skus.find(s s.color selectedColor.value s.size selectedSize.value ) })下單時(shí)提交的是selectedSku.value.id而不是 SPU ID這個(gè)很關(guān)鍵。接口那邊通過(guò) SKU ID 才能查到準(zhǔn)確的庫(kù)存和價(jià)格否則就會(huì)出現(xiàn)“前端選了紅色M碼后端只收到了一個(gè)商品ID”這種尷尬情況。5.2 訂單狀態(tài)流轉(zhuǎn)從待付款到已完成的全鏈路訂單狀態(tài)我定義了 5 個(gè)值流轉(zhuǎn)關(guān)系是狀態(tài)數(shù)值操作者說(shuō)明待付款0用戶下單后默認(rèn)狀態(tài)超時(shí)30分鐘自動(dòng)取消已付款1系統(tǒng)用戶點(diǎn)擊“模擬支付”后觸發(fā)已發(fā)貨2管理員后臺(tái)訂單列表點(diǎn)擊“發(fā)貨”已完成3用戶/系統(tǒng)用戶點(diǎn)擊確認(rèn)收貨或發(fā)貨后15天自動(dòng)完成已取消4用戶/系統(tǒng)用戶主動(dòng)取消或超時(shí)未支付后端在訂單狀態(tài)變更的接口里做了狀態(tài)機(jī)校驗(yàn)比如不能從“待付款”直接跳到“已完成”只允許按順序流轉(zhuǎn)。這個(gè)校驗(yàn)放在 Service 層統(tǒng)一判斷前端雖然做了按鈕控制但必須防一手繞過(guò)前端的非法請(qǐng)求。5.3 銷(xiāo)售數(shù)據(jù)統(tǒng)計(jì)接口管理端的點(diǎn)睛之筆除了常規(guī) CRUD我給管理端加了一個(gè)數(shù)據(jù)統(tǒng)計(jì)面板首頁(yè)展示訂單總數(shù)、銷(xiāo)售總額、用戶總數(shù)、上架商品數(shù)四個(gè)指標(biāo)。查詢語(yǔ)句用 MySQL 的聚合函數(shù)寫(xiě)很簡(jiǎn)單// 今日銷(xiāo)售總額 SELECT IFNULL(SUM(total_amount), 0) FROM orders WHERE status IN (1, 2, 3) AND pay_time CURDATE()再用一個(gè)近七天每日銷(xiāo)售額的折線圖接口返回日期和金額兩個(gè)數(shù)組前端用 ECharts 渲染一下整個(gè)管理端的觀感立刻就不一樣了。這種統(tǒng)計(jì)功能技術(shù)上沒(méi)有難度但對(duì)于商戶來(lái)說(shuō)這往往比那些花哨的表格更有價(jià)值也給項(xiàng)目加分不少。5.4 定時(shí)任務(wù)處理超時(shí)訂單別讓庫(kù)存爛在池子里剛才提到訂單超時(shí)未支付要釋放庫(kù)存這個(gè)功能我用 SpringBoot 自帶的Scheduled定時(shí)任務(wù)來(lái)實(shí)現(xiàn)每 5 分鐘掃描一次超過(guò) 30 分鐘未支付的訂單批量把狀態(tài)改為已取消同時(shí)回補(bǔ)庫(kù)存Scheduled(cron 0 */5 * * * ?) public void cancelTimeoutOrders() { ListOrder orders orderMapper.selectList(new LambdaQueryWrapperOrder() .eq(Order::getStatus, 0) .lt(Order::getCreateTime, LocalDateTime.now().minusMinutes(30))); for (Order order : orders) { // 回補(bǔ)庫(kù)存、更新訂單狀態(tài) orderCancelService.cancel(order.getId()); } }定時(shí)任務(wù)放在項(xiàng)目里簡(jiǎn)單直接缺點(diǎn)是做不到實(shí)時(shí)性極端情況下庫(kù)存可能被鎖定 34 分鐘才釋放。如果要求準(zhǔn)確到秒級(jí)釋放庫(kù)存就得引入消息隊(duì)列做延遲消息比如 RocketMQ 的延遲消息或者 Redis 的過(guò)期監(jiān)聽(tīng)但那個(gè)復(fù)雜度就上去了。這個(gè)商城項(xiàng)目用定時(shí)任務(wù)已經(jīng)夠了我自己的體會(huì)是先滿足業(yè)務(wù)需求再考慮技術(shù)炫技。6. 部署上線與常見(jiàn)問(wèn)題排查6.1 本地聯(lián)調(diào)與打包部署全流程開(kāi)發(fā)完成后要跑通整套環(huán)境我先在本地起兩個(gè)服務(wù)前端的 Vite 開(kāi)發(fā)服務(wù)器5173和后端的 SpringBoot8080通過(guò)代理訪問(wèn)。聯(lián)調(diào)沒(méi)問(wèn)題后進(jìn)入生產(chǎn)模式后端打包mvn clean package -DskipTests java -jar clothing-server-1.0.0.jar前端打包npm run build打包產(chǎn)物在dist/目錄下把dist里的文件復(fù)制到服務(wù)器 Nginx 的 html 目錄然后配置 Nginxserver { listen 80; server_name your-domain.com; root /usr/share/nginx/html; index index.html; # 前端history路由 location / { try_files $uri $uri/ /index.html; } # 接口代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files $uri $uri/ /index.html;這行是 history 路由的關(guān)鍵不加的話刷新非首頁(yè)路由會(huì) 404。這個(gè)坑我第一次部署踩過(guò)排查了半天最后發(fā)現(xiàn)就是少了這一句。6.2 常見(jiàn)問(wèn)題速查表問(wèn)題 1跨域請(qǐng)求被攔截表現(xiàn)瀏覽器 Console 提示 CORS error。原因通常是前端請(qǐng)求地址和后端地址不一致。解決方案優(yōu)先用 Vite/Nginx 代理后端加CrossOrigin只是臨時(shí)手段生產(chǎn)環(huán)境還是得靠代理解決。問(wèn)題 2前端登錄后刷新頁(yè)面變回未登錄原因Vuex/Pinia 里的數(shù)據(jù)是內(nèi)存態(tài)的刷新就沒(méi)了。解決token 和 userInfo 存在 localStorage頁(yè)面啟動(dòng)時(shí)先從 localStorage 恢復(fù) store 狀態(tài)。問(wèn)題 3表單提交時(shí)間字段顯示一串?dāng)?shù)字原因MySQL 的 datetime 類(lèi)型沒(méi)有做時(shí)區(qū)轉(zhuǎn)換Java 接收時(shí)解析成了時(shí)間戳。解決在 application.yml 里配置spring.jackson.date-format: yyyy-MM-dd HH:mm:ss和spring.jackson.time-zone: GMT8。問(wèn)題 4商品圖片上傳成功但訪問(wèn) 404原因配置的upload.path不正確或者路徑?jīng)]映射到靜態(tài)資源。解決確認(rèn)磁盤(pán)絕對(duì)路徑存在檢查WebMvcConfig里的addResourceLocations必須file:前綴。問(wèn)題 5部署到服務(wù)器后接口可以訪問(wèn)但圖片加載失敗原因Nginx 配置沖突location /把靜態(tài)資源請(qǐng)求也接管了但找不到對(duì)應(yīng)文件就返回 index.html。解決單獨(dú)加一條圖片路徑的 locationlocation /images/ { alias /opt/clothing-upload/; }6.3 兩個(gè)值得記住的實(shí)戰(zhàn)經(jīng)驗(yàn)第一個(gè)訂單號(hào)別用自增 ID。訂單表雖然id是自增主鍵但那只能用于內(nèi)部關(guān)聯(lián)展示給用戶的訂單號(hào)必須單獨(dú)生成。網(wǎng)上很多教程直接用主鍵當(dāng)訂單號(hào)用戶看到自己的訂單一號(hào)二號(hào)三號(hào)很容易猜出平臺(tái)有多少訂單這在電商里是不專業(yè)的。我用的是“時(shí)間戳 隨機(jī)數(shù)”的格式比如20241103152012345616 位數(shù)字簡(jiǎn)潔還挺好用。第二個(gè)所有數(shù)據(jù)庫(kù)交互的金額字段必須用 decimal不能用 float 或 double。這是做電商系統(tǒng)的第一天就該養(yǎng)成的習(xí)慣。float 的二進(jìn)制浮點(diǎn)誤差在累計(jì)銷(xiāo)售總額、計(jì)算優(yōu)惠折扣時(shí)會(huì)放大到肉眼可見(jiàn)的錯(cuò)誤用decimal(10,2)才能保證財(cái)務(wù)金額精確計(jì)算。類(lèi)似地前端傳價(jià)格時(shí)用“分”為單位整數(shù)傳遞到顯示層再轉(zhuǎn)成“元”這是很多大廠電商項(xiàng)目的統(tǒng)一規(guī)范既避免浮點(diǎn)誤差也方便對(duì)接支付接口。7. 寫(xiě)在最后的個(gè)人體會(huì)這套服裝商城銷(xiāo)售管理系統(tǒng)做下來(lái)最大的收獲不是掌握了某個(gè)具體技術(shù)點(diǎn)而是把電商業(yè)務(wù)里互相咬合的模塊完整地理解了。比如訂單和庫(kù)存的關(guān)系、JWT 認(rèn)證在前后端分離項(xiàng)目中的完整鏈路、后端事務(wù)和前端狀態(tài)的配合這些知識(shí)單獨(dú)學(xué)任何一門(mén)課都很難有這種“全局觀”。對(duì)于想拿這個(gè)項(xiàng)目練手或者做畢設(shè)的同學(xué)我建議拿到代碼后不要只跑通就結(jié)束而是嘗試自己增加幾個(gè)模塊比如優(yōu)惠券功能下單時(shí)抵扣金額、商品評(píng)論功能用戶下單后評(píng)價(jià)曬圖、收貨地址管理多地址切換。這些擴(kuò)展點(diǎn)每個(gè)都能單獨(dú)寫(xiě)一套邏輯做完之后你對(duì)這套系統(tǒng)的理解會(huì)再上一個(gè)臺(tái)階。項(xiàng)目里最初的代碼風(fēng)格還有很多不規(guī)范的地方比如部分接口參數(shù)沒(méi)有做校驗(yàn)、定時(shí)任務(wù)沒(méi)有加分布式鎖兩臺(tái)服務(wù)器部署時(shí)會(huì)重復(fù)執(zhí)行、圖片上傳沒(méi)有限制文件類(lèi)型等等。我當(dāng)時(shí)是在滿足功能的前提下逐步優(yōu)化、迭代加固的。對(duì)于個(gè)人項(xiàng)目或者畢設(shè)來(lái)說(shuō)先把主鏈路跑通是第一優(yōu)先級(jí)然后在這個(gè)基礎(chǔ)上持續(xù)打磨項(xiàng)目的質(zhì)量是一版一版“練”出來(lái)的。 SpringBoot+Vue3前后端分離商城系統(tǒng)實(shí)戰(zhàn)：從數(shù)據(jù)庫(kù)設(shè)計(jì)到部署上線
去年接了一個(gè)服裝批發(fā)客戶的單子需求很直接要做一套商城系統(tǒng)前端能展示商品、加購(gòu)物車(chē)、下單后臺(tái)要管商品、訂單、庫(kù)存和會(huì)員還得留出以后接優(yōu)惠券、拼團(tuán)這些營(yíng)銷(xiāo)功能的余地。我最終選了SpringBoot Vue3這套組合來(lái)落地整套系統(tǒng)從前端頁(yè)面到后端接口全部自己搭前后花了差不多三周時(shí)間完成核心流程。這套“springbootvue3服裝商城銷(xiāo)售管理系統(tǒng)”做完之后無(wú)論是拿來(lái)接私活還是作為畢業(yè)設(shè)計(jì)都很值得復(fù)盤(pán)一遍。這個(gè)項(xiàng)目的價(jià)值不在于“商城”本身有多復(fù)雜而在于它把電商業(yè)務(wù)里最典型的幾個(gè)環(huán)節(jié)——商品中心、購(gòu)物車(chē)、訂單流轉(zhuǎn)、庫(kù)存扣減、權(quán)限控制——完整地串起來(lái)了。前端用 Vue3 的組合式 API 配合 Pinia 管理狀態(tài)后端用 SpringBoot 做 RESTful 接口安全認(rèn)證走 JWT RBAC數(shù)據(jù)層用 MyBatis-Plus 操作 MySQL。整套方案不吊高難度但每個(gè)模塊都是實(shí)實(shí)在在能跑的很適合想系統(tǒng)掌握前后端分離開(kāi)發(fā)流程的人拿來(lái)練手。1. 項(xiàng)目整體定位與方案拆解1.1 商城系統(tǒng)的核心需求到底有哪些做系統(tǒng)之前先別急著寫(xiě)代碼把需求拆清楚比什么技術(shù)選型都重要。服裝商城這類(lèi)銷(xiāo)售管理系統(tǒng)表面上是“賣(mài)衣服”實(shí)際上拆開(kāi)來(lái)看需求可以分成三條主線面向顧客的購(gòu)物流程、面向運(yùn)營(yíng)的商品管理、面向財(cái)務(wù)和管理層的訂單與數(shù)據(jù)統(tǒng)計(jì)。顧客端的完整鏈路是注冊(cè)登錄 → 瀏覽商品列表/詳情 → 搜索和篩選按品類(lèi)、價(jià)格、顏色、尺碼 → 加入購(gòu)物車(chē) → 提交訂單 → 模擬支付 → 查看訂單狀態(tài)。運(yùn)營(yíng)端的鏈路是維護(hù)商品分類(lèi) → 上架/下架商品 → 管理商品規(guī)格SKU價(jià)格和庫(kù)存 → 處理訂單發(fā)貨、備注 → 查看會(huì)員列表。管理層關(guān)心的則是銷(xiāo)售數(shù)據(jù)這部分我用了一個(gè)簡(jiǎn)單的統(tǒng)計(jì)接口來(lái)支撐比如按日/按月匯總銷(xiāo)售額、熱門(mén)商品排行等。這個(gè)項(xiàng)目里我把用戶端和管理端合并成了一個(gè)前端工程通過(guò)路由權(quán)限來(lái)區(qū)分角色。管理員登錄后能看到后臺(tái)菜單普通用戶只能看到商城頁(yè)面。這么做的好處是部署簡(jiǎn)單不用維護(hù)兩套前端應(yīng)用也方便統(tǒng)一處理登錄態(tài)。1.2 為什么是 SpringBoot Vue3而不是別的組合技術(shù)選型這件事我一直秉持“夠用、順手、好招人”的原則。SpringBoot 不用多說(shuō)Java 后端在電商這塊的生態(tài)太成熟了MyBatis-Plus 做單表 CRUD 幾乎零成本Spring Security 或者簡(jiǎn)單的攔截器都能搞定鑒權(quán)數(shù)據(jù)庫(kù)用 MySQL 也完全扛得住商城這個(gè)量級(jí)。前端選 Vue3 而不是 Vue2核心原因是組合式 API 在邏輯復(fù)用上太舒服了。商城這種業(yè)務(wù)購(gòu)物車(chē)邏輯、登錄態(tài)邏輯、商品篩選邏輯都是跨頁(yè)面復(fù)用的用 composable自定義組合函數(shù)可以把這些邏輯抽出來(lái)比 Vue2 時(shí)代寫(xiě) mixin 要清晰得多。配套的 Element Plus 組件庫(kù)在后臺(tái)管理界面上完全是量身定做表格、表單、彈窗、分頁(yè)全都現(xiàn)成。還有一個(gè)很實(shí)際的原因Vue3 的生態(tài)現(xiàn)在已經(jīng)很成熟了。Vite 的啟動(dòng)速度比 Webpack 快一個(gè)量級(jí)開(kāi)發(fā)體驗(yàn)好很多。Pinia 相比 Vuex 的樣板代碼少了一大截修改狀態(tài)不需要寫(xiě)一堆 mutation直接改 store 里的 state 就行這對(duì)商城這種狀態(tài)交互頻繁的場(chǎng)景特別友好。1.3 前后端分離的項(xiàng)目結(jié)構(gòu)這樣規(guī)劃整個(gè)工程我拆成了兩個(gè)目錄互不干擾clothing-server/ # SpringBoot 后端工程 ├── src/main/java/com/cshop │ ├── controller/ # 接口層 │ ├── service/ # 業(yè)務(wù)邏輯層 │ ├── mapper/ # MyBatis-Plus 數(shù)據(jù)訪問(wèn)層 │ ├── entity/ # 實(shí)體類(lèi) │ ├── dto/ # 前端傳參對(duì)象 │ ├── vo/ # 返回給前端的數(shù)據(jù)對(duì)象 │ ├── config/ # 配置類(lèi)跨域、攔截器、MyBatis-Plus │ ├── utils/ # JWT工具、統(tǒng)一返回結(jié)果封裝 │ └── CShopApplication.java └── src/main/resources/ ├── application.yml └── mapper/ # 復(fù)雜SQL的XML文件 clothing-web/ # Vue3 前端工程 ├── src/ │ ├── api/ # 接口請(qǐng)求封裝 │ ├── assets/ # 靜態(tài)資源 │ ├── components/ # 通用組件商品卡片、分頁(yè)等 │ ├── composables/ # 組合式函數(shù)購(gòu)物車(chē)、登錄態(tài) │ ├── router/ # 路由配置含權(quán)限守衛(wèi) │ ├── stores/ # Pinia 狀態(tài)管理 │ ├── views/ # 頁(yè)面商城首頁(yè)、商品詳情、后臺(tái)管理 │ └── utils/ # axios實(shí)例、工具函數(shù) └── vite.config.js后端按“Controller → Service → Mapper”三層去寫(xiě)Controller 只管參數(shù)接收和結(jié)果返回業(yè)務(wù)邏輯全在 Service 層。這樣后期如果要把某個(gè)接口拆成微服務(wù)或者引入消息隊(duì)列做訂單異步處理改動(dòng)成本都控制得住。前端按“頁(yè)面 → 組件 → API”分層所有請(qǐng)求都走src/api里封裝的函數(shù)不放裸 axios 調(diào)用在頁(yè)面里。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)與核心表建模2.1 商品表SPU 和 SKU 必須分開(kāi)建商品建模是商城系統(tǒng)的地基這塊設(shè)計(jì)錯(cuò)了后面全是坑。服裝類(lèi)商品有個(gè)典型特點(diǎn)一件衛(wèi)衣SPU會(huì)有多個(gè)顏色、多個(gè)尺碼每個(gè)顏色尺碼組合對(duì)應(yīng)一個(gè)價(jià)格和一份庫(kù)存這就是 SKUStock Keeping Unit。如果把顏色尺碼直接橫著寫(xiě)在商品表里加一個(gè)顏色就要改表結(jié)構(gòu)想想就頭大。我建了兩張表CREATE TABLE spu ( id bigint PRIMARY KEY AUTO_INCREMENT, name varchar(255) NOT NULL COMMENT 商品名稱, category_id bigint COMMENT 所屬類(lèi)目ID, main_image varchar(255) COMMENT 主圖URL, detail text COMMENT 商品詳情富文本, status tinyint DEFAULT 1 COMMENT 1上架 0下架, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE sku ( id bigint PRIMARY KEY AUTO_INCREMENT, spu_id bigint NOT NULL COMMENT 所屬SPU, color varchar(50) COMMENT 顏色, size varchar(20) COMMENT 尺碼, price decimal(10,2) NOT NULL COMMENT 售價(jià), stock int NOT NULL DEFAULT 0 COMMENT 庫(kù)存, image varchar(255) COMMENT SKU圖片, status tinyint DEFAULT 1 );查詢商品詳情的時(shí)候先查 SPU 基本信息再根據(jù) SPU ID 查 SKU 列表。前端展示的時(shí)候用color和size兩個(gè)維度做聯(lián)動(dòng)選擇。價(jià)格區(qū)間比如“199-299”可以直接用 SQLMIN(price)和MAX(price)聚合出來(lái)不用額外冗余字段。2.2 訂單與庫(kù)存表庫(kù)存扣減的兩種模式訂單這塊我用了電商最標(biāo)準(zhǔn)的“訂單主表 訂單明細(xì)表”結(jié)構(gòu)另外單拆了一張購(gòu)物車(chē)表。訂單主表存收貨人信息、訂單總金額、訂單狀態(tài)明細(xì)表存每個(gè) SKU 的購(gòu)買(mǎi)數(shù)量、成交單價(jià)、商品快照。商品快照這個(gè)字段很重要因?yàn)樯唐穬r(jià)格、名稱可能會(huì)變但歷史訂單里的信息必須保持下單那一刻的樣子。CREATE TABLE orders ( id bigint PRIMARY KEY AUTO_INCREMENT, order_no varchar(64) NOT NULL UNIQUE COMMENT 訂單號(hào), user_id bigint NOT NULL, total_amount decimal(10,2) NOT NULL, status tinyint NOT NULL DEFAULT 0 COMMENT 0待付款 1已付款 2已發(fā)貨 3已完成 4已取消, receiver_name varchar(50), receiver_phone varchar(20), receiver_address varchar(255), create_time datetime DEFAULT CURRENT_TIMESTAMP, pay_time datetime ); CREATE TABLE order_item ( id bigint PRIMARY KEY AUTO_INCREMENT, order_id bigint NOT NULL, spu_id bigint, sku_id bigint, sku_snapshot varchar(500) COMMENT SKU信息快照(JSON), goods_name varchar(255), price decimal(10,2), quantity int );庫(kù)存扣減我選了下單時(shí)直接扣減的方案而不是支付時(shí)才扣。為什么因?yàn)橹Ц妒悄M的用戶很可能“下單后不付款”如果庫(kù)存不先鎖住就會(huì)出現(xiàn)超賣(mài)10 件庫(kù)存有 20 個(gè)人下單成功后面真正付款的人反而沒(méi)貨了。當(dāng)然只扣不減也不行所以訂單表里加了個(gè)超時(shí)狀態(tài)超過(guò) 30 分鐘未支付就把庫(kù)存加回去這樣既防止了超賣(mài)也避免了僵尸訂單占用庫(kù)存。2.3 用戶與權(quán)限RBAC 模型在公司項(xiàng)目里最穩(wěn)妥用戶體系我沒(méi)用復(fù)雜的方案就是標(biāo)準(zhǔn)的 RBAC用戶-角色-菜單三張表加兩張關(guān)聯(lián)表。一個(gè)用戶可以有多個(gè)角色一個(gè)角色可以訪問(wèn)多個(gè)菜單按鈕。商城場(chǎng)景里只需要兩種角色一個(gè)是ROLE_USER一個(gè)是ROLE_ADMIN但表結(jié)構(gòu)我依然按通用 RBAC 來(lái)做方便后續(xù)加運(yùn)營(yíng)、客服這類(lèi)角色。菜單表里直接存前端路由的path和組件路徑登錄后根據(jù)用戶角色動(dòng)態(tài)生成可訪問(wèn)的路由表前端配合路由守衛(wèi)做菜單渲染和頁(yè)面攔截。這樣后期要加權(quán)限只需要在數(shù)據(jù)庫(kù)里給角色掛菜單不用改代碼。3. 后端核心模塊實(shí)現(xiàn)要點(diǎn)3.1 JWT 登錄認(rèn)證與權(quán)限攔截?cái)r截器比框架更省心登錄接口的邏輯很直白接收用戶名密碼 → 查數(shù)據(jù)庫(kù)比對(duì)密碼MD5 加鹽 → 生成 JWT 返回給前端。前端把 token 存在 localStorage 里之后每次請(qǐng)求在 axios 攔截器里加到請(qǐng)求頭Authorization。后端我寫(xiě)了個(gè)AuthInterceptor實(shí)現(xiàn)HandlerInterceptor接口Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登錄、注冊(cè)等接口 String uri request.getRequestURI(); if (uri.contains(/api/auth/login) || uri.contains(/api/auth/register)) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登錄); } // 解析token把用戶ID放進(jìn)去 Long userId JwtUtils.parseToken(token.replace(Bearer , )); request.setAttribute(userId, userId); return true; }有同學(xué)會(huì)問(wèn)為什么不直接用 Spring Security說(shuō)實(shí)話如果只是做用戶認(rèn)證和角色判斷Spring Security 的配置成本遠(yuǎn)高于一個(gè)攔截器。Spring Security 適合權(quán)限規(guī)則很復(fù)雜的場(chǎng)景比如按鈕級(jí)細(xì)粒度權(quán)限、OAuth2 第三方登錄這個(gè)服裝商城的管理端就兩類(lèi)角色攔截器里判斷一下角色類(lèi)型完全夠了代碼還更直觀。如果以后要接入 Spring Security這兩套邏輯也可以平滑替換。3.2 商品管理與文件上傳OSS 和本地存儲(chǔ)怎么選后臺(tái)商品管理主要是商品的增刪改查。圖片上傳我重點(diǎn)說(shuō)一下因?yàn)檫@是最容易出 bug 的地方。文件上傳選擇有兩條路一種是傳到阿里云 OSS 這類(lèi)對(duì)象存儲(chǔ)適合部署在云服務(wù)器上的正式項(xiàng)目帶寬和存儲(chǔ)都有保障另一種是傳到項(xiàng)目本地目錄適合本地跑著玩或者部署在廉價(jià)服務(wù)器上的場(chǎng)景。我項(xiàng)目里做了一個(gè)折中圖片保存到服務(wù)器磁盤(pán)的指定路徑數(shù)據(jù)庫(kù)只存訪問(wèn) URL。配置文件里用upload.path指定存儲(chǔ)路徑再用一個(gè)WebMvcConfig把路徑映射成靜態(tài)資源訪問(wèn)registry.addResourceHandler(/images/**) .addResourceLocations(file: uploadPath /);這樣圖片就能通過(guò)http://localhost:8080/images/xxx.jpg直接訪問(wèn)了。部署到服務(wù)器的時(shí)候改一下配置路徑即可不用動(dòng)代碼。上傳接口最后會(huì)返回一個(gè)完整的圖片 URL前端el-upload組件拿到 URL 后直接塞進(jìn)表單字段里預(yù)覽回顯都很方便。3.3 下單流程與庫(kù)存扣減事務(wù)和鎖缺一不可下單是整個(gè)系統(tǒng)里最需要小心的環(huán)節(jié)。我的實(shí)現(xiàn)邏輯是這樣的校驗(yàn)購(gòu)物車(chē)?yán)锏?SKU 是否上架價(jià)格是否變化校驗(yàn)庫(kù)存是否充足計(jì)算訂單總金額創(chuàng)建訂單主表和明細(xì)扣減 SKU 庫(kù)存清空對(duì)應(yīng)購(gòu)物車(chē)記錄這幾步必須在一個(gè)事務(wù)里完成任何一步失敗都要全部回滾否則會(huì)出現(xiàn)“訂單建了但庫(kù)存沒(méi)扣”的臟數(shù)據(jù)。用Transactional注解包住整個(gè)方法另外在扣庫(kù)存的 SQL 上加了條件判斷UPDATE sku SET stock stock - #{quantity} WHERE id #{skuId} AND stock #{quantity}如果update影響行數(shù)為 0說(shuō)明庫(kù)存不足直接拋異常回滾這樣在高并發(fā)下也不會(huì)超賣(mài)。這個(gè)寫(xiě)法比先查后改多了一層保障——查詢和更新之間可能插入別的請(qǐng)求但帶條件的 UPDATE 語(yǔ)句本身是原子性的。對(duì)于這個(gè)量級(jí)的項(xiàng)目來(lái)說(shuō)它開(kāi)箱即用且足夠安全。3.4 統(tǒng)一返回結(jié)果與全局異常優(yōu)雅接口的第一步接口風(fēng)格統(tǒng)一是我一直強(qiáng)調(diào)的。我封裝了一個(gè)ResultT類(lèi)所有接口都返回統(tǒng)一的 JSON 結(jié)構(gòu){ code: 200, message: success, data: { } }同時(shí)用RestControllerAdvice做全局異常處理。業(yè)務(wù)異常返回對(duì)應(yīng)的錯(cuò)誤碼和提示比如庫(kù)存不足返回 5001未登錄返回 401參數(shù)校驗(yàn)失敗返回 400。這樣前端只需要在 axios 響應(yīng)攔截器里統(tǒng)一判斷 code彈錯(cuò)誤提示就行不需要每個(gè)接口單獨(dú)寫(xiě) try-catch。4. 前端 Vue3 落地實(shí)踐4.1 Vite 初始化項(xiàng)目與目錄規(guī)劃前端工程我是用 Vite 初始化創(chuàng)建的命令也很簡(jiǎn)單npm create vitelatest clothing-web -- --template vue然后安裝關(guān)鍵依賴npm install vue-router4 pinia axios element-plusVite 相比 Webpack 的啟動(dòng)速度確實(shí)快幾秒就能起服務(wù)熱更新也是毫秒級(jí)。有個(gè)要注意的地方是 Vite 的端口默認(rèn)是 5173而后端接口跑在 8080所以必須在vite.config.js里配開(kāi)發(fā)代理把/api前綴的請(qǐng)求轉(zhuǎn)發(fā)到后端地址順便解決跨域問(wèn)題export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })生產(chǎn)打包之后Nginx 里也配同樣的代理規(guī)則前后端部署在不同端口時(shí)就不會(huì)有跨域煩惱。4.2 axios 封裝與登錄態(tài)刷新機(jī)制前端請(qǐng)求封裝我習(xí)慣統(tǒng)一放在utils/request.js里。創(chuàng)建一個(gè) axios 實(shí)例設(shè)置 baseURL 為/api然后加請(qǐng)求攔截器和響應(yīng)攔截器const request axios.create({ baseURL: /api, timeout: 10000 }) // 請(qǐng)求攔截器自動(dòng)帶token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 響應(yīng)攔截器統(tǒng)一處理業(yè)務(wù)錯(cuò)誤和登錄過(guò)期 request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 請(qǐng)求失敗) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) localStorage.removeItem(userInfo) router.push(/login) ElMessage.warning(登錄已過(guò)期請(qǐng)重新登錄) } return Promise.reject(error) } )401 統(tǒng)一跳轉(zhuǎn)登錄頁(yè)的邏輯放在攔截器里能省掉每個(gè)頁(yè)面判斷 token 是否失效的重復(fù)代碼。登錄成功后把token和userInfo都存在 localStorage刷新瀏覽器也不會(huì)丟登錄態(tài)。4.3 購(gòu)物車(chē)與訂單狀態(tài)管理Pinia 比 localStorage 靠譜購(gòu)物車(chē)狀態(tài)我存在了 Pinia 里。為什么不直接用 localStorage兩個(gè)原因一是購(gòu)物車(chē)的狀態(tài)需要多頁(yè)面共享頁(yè)面組件里用useCartStore()就能拿到跨組件通信成本為零二是購(gòu)物車(chē)數(shù)量和選中狀態(tài)需要響應(yīng)式更新localStorage 沒(méi)有響應(yīng)式能力操作完還得手動(dòng)刷新視圖。購(gòu)物車(chē) store 的核心就是維護(hù)一個(gè)列表提供添加、刪除、修改數(shù)量、勾選的方法。每次變更之后調(diào)后端接口同步同時(shí)也把最新?tīng)顟B(tài)同步一份到 localStorage 做持久化頁(yè)面刷新后從 localStorage 恢復(fù)。這樣既不丟失數(shù)據(jù)也保留了響應(yīng)式的交互體驗(yàn)。export const useCartStore defineStore(cart, { state: () ({ items: JSON.parse(localStorage.getItem(cart_items) || []) }), actions: { addToCart(item) { const index this.items.findIndex(i i.skuId item.skuId) if (index -1) { this.items[index].quantity item.quantity } else { this.items.push(item) } this.save() }, removeItem(skuId) { this.items this.items.filter(i i.skuId ! skuId) this.save() }, save() { localStorage.setItem(cart_items, JSON.stringify(this.items)) } } })4.4 Element Plus 后臺(tái)管理界面搭建后臺(tái)管理頁(yè)面其實(shí)就是典型的“左側(cè)菜單 右側(cè)內(nèi)容區(qū)”布局。我用 Element Plus 的el-container、el-aside、el-menu搭框架商品管理用el-table展示數(shù)據(jù)配分頁(yè)、搜索、彈窗編輯三個(gè)基礎(chǔ)能力。訂單管理在此基礎(chǔ)上增加了篩選標(biāo)簽按狀態(tài)過(guò)濾和操作按鈕發(fā)貨、查看詳情。商品編輯表單里用到了el-upload上傳圖片:action指向后端的圖片上傳接口on-success回調(diào)里把返回的圖片 URL 賦值給表單字段。這里有個(gè)細(xì)節(jié)el-upload上傳組件走的是原生 XMLHttpRequest沒(méi)法帶上 axios 攔截器里的 Authorization 請(qǐng)求頭所以要在組件上顯式傳headers屬性el-upload :actionuploadUrl :headers{ Authorization: Bearer localStorage.getItem(token) } :on-successhandleUploadSuccess el-button上傳圖片/el-button /el-upload4.5 前端路由守衛(wèi)沒(méi)有登錄就看不了后臺(tái)動(dòng)態(tài)路由權(quán)限這塊我用的是最簡(jiǎn)單的方案在路由配置里給后臺(tái)頁(yè)面加meta: { requiresAuth: true, roles: [ROLE_ADMIN] }然后在全局前置守衛(wèi)里判斷router.beforeEach((to, from, next) { const token localStorage.getItem(token) const userInfo JSON.parse(localStorage.getItem(userInfo) || {}) if (to.meta.requiresAuth) { if (!token) { next(/login) } else if (to.meta.roles !to.meta.roles.includes(userInfo.role)) { next(/) } else { next() } } else { next() } })菜單渲染是在登錄后根據(jù)userInfo.role來(lái)判斷管理員顯示全部菜單普通用戶隱藏后臺(tái)菜單入口。這套方案雖然不像動(dòng)態(tài)路由那樣能在后端配置菜單但應(yīng)付兩個(gè)角色的商城系統(tǒng)完全足夠?qū)懫饋?lái)也直觀。5. 關(guān)鍵業(yè)務(wù)場(chǎng)景的實(shí)現(xiàn)細(xì)節(jié)5.1 多規(guī)格商品選擇聯(lián)動(dòng)顏色和尺碼怎么匹配 SKU服裝商城最典型的交互場(chǎng)景就是選顏色選尺碼。前端拿到商品詳情后把當(dāng)前 SPU 的所有 SKU 列表存在本地然后根據(jù)用戶選擇的顏色、尺碼組合去匹配 SKU。匹配到了就顯示價(jià)格和庫(kù)存匹配不到就提示“該規(guī)格暫時(shí)缺貨”。在 Vue3 里這個(gè)邏輯很適合放在computed里實(shí)現(xiàn)const selectedSku computed(() { return props.skus.find(s s.color selectedColor.value s.size selectedSize.value ) })下單時(shí)提交的是selectedSku.value.id而不是 SPU ID這個(gè)很關(guān)鍵。接口那邊通過(guò) SKU ID 才能查到準(zhǔn)確的庫(kù)存和價(jià)格否則就會(huì)出現(xiàn)“前端選了紅色M碼后端只收到了一個(gè)商品ID”這種尷尬情況。5.2 訂單狀態(tài)流轉(zhuǎn)從待付款到已完成的全鏈路訂單狀態(tài)我定義了 5 個(gè)值流轉(zhuǎn)關(guān)系是狀態(tài)數(shù)值操作者說(shuō)明待付款0用戶下單后默認(rèn)狀態(tài)超時(shí)30分鐘自動(dòng)取消已付款1系統(tǒng)用戶點(diǎn)擊“模擬支付”后觸發(fā)已發(fā)貨2管理員后臺(tái)訂單列表點(diǎn)擊“發(fā)貨”已完成3用戶/系統(tǒng)用戶點(diǎn)擊確認(rèn)收貨或發(fā)貨后15天自動(dòng)完成已取消4用戶/系統(tǒng)用戶主動(dòng)取消或超時(shí)未支付后端在訂單狀態(tài)變更的接口里做了狀態(tài)機(jī)校驗(yàn)比如不能從“待付款”直接跳到“已完成”只允許按順序流轉(zhuǎn)。這個(gè)校驗(yàn)放在 Service 層統(tǒng)一判斷前端雖然做了按鈕控制但必須防一手繞過(guò)前端的非法請(qǐng)求。5.3 銷(xiāo)售數(shù)據(jù)統(tǒng)計(jì)接口管理端的點(diǎn)睛之筆除了常規(guī) CRUD我給管理端加了一個(gè)數(shù)據(jù)統(tǒng)計(jì)面板首頁(yè)展示訂單總數(shù)、銷(xiāo)售總額、用戶總數(shù)、上架商品數(shù)四個(gè)指標(biāo)。查詢語(yǔ)句用 MySQL 的聚合函數(shù)寫(xiě)很簡(jiǎn)單// 今日銷(xiāo)售總額 SELECT IFNULL(SUM(total_amount), 0) FROM orders WHERE status IN (1, 2, 3) AND pay_time CURDATE()再用一個(gè)近七天每日銷(xiāo)售額的折線圖接口返回日期和金額兩個(gè)數(shù)組前端用 ECharts 渲染一下整個(gè)管理端的觀感立刻就不一樣了。這種統(tǒng)計(jì)功能技術(shù)上沒(méi)有難度但對(duì)于商戶來(lái)說(shuō)這往往比那些花哨的表格更有價(jià)值也給項(xiàng)目加分不少。5.4 定時(shí)任務(wù)處理超時(shí)訂單別讓庫(kù)存爛在池子里剛才提到訂單超時(shí)未支付要釋放庫(kù)存這個(gè)功能我用 SpringBoot 自帶的Scheduled定時(shí)任務(wù)來(lái)實(shí)現(xiàn)每 5 分鐘掃描一次超過(guò) 30 分鐘未支付的訂單批量把狀態(tài)改為已取消同時(shí)回補(bǔ)庫(kù)存Scheduled(cron 0 */5 * * * ?) public void cancelTimeoutOrders() { ListOrder orders orderMapper.selectList(new LambdaQueryWrapperOrder() .eq(Order::getStatus, 0) .lt(Order::getCreateTime, LocalDateTime.now().minusMinutes(30))); for (Order order : orders) { // 回補(bǔ)庫(kù)存、更新訂單狀態(tài) orderCancelService.cancel(order.getId()); } }定時(shí)任務(wù)放在項(xiàng)目里簡(jiǎn)單直接缺點(diǎn)是做不到實(shí)時(shí)性極端情況下庫(kù)存可能被鎖定 34 分鐘才釋放。如果要求準(zhǔn)確到秒級(jí)釋放庫(kù)存就得引入消息隊(duì)列做延遲消息比如 RocketMQ 的延遲消息或者 Redis 的過(guò)期監(jiān)聽(tīng)但那個(gè)復(fù)雜度就上去了。這個(gè)商城項(xiàng)目用定時(shí)任務(wù)已經(jīng)夠了我自己的體會(huì)是先滿足業(yè)務(wù)需求再考慮技術(shù)炫技。6. 部署上線與常見(jiàn)問(wèn)題排查6.1 本地聯(lián)調(diào)與打包部署全流程開(kāi)發(fā)完成后要跑通整套環(huán)境我先在本地起兩個(gè)服務(wù)前端的 Vite 開(kāi)發(fā)服務(wù)器5173和后端的 SpringBoot8080通過(guò)代理訪問(wèn)。聯(lián)調(diào)沒(méi)問(wèn)題后進(jìn)入生產(chǎn)模式后端打包mvn clean package -DskipTests java -jar clothing-server-1.0.0.jar前端打包npm run build打包產(chǎn)物在dist/目錄下把dist里的文件復(fù)制到服務(wù)器 Nginx 的 html 目錄然后配置 Nginxserver { listen 80; server_name your-domain.com; root /usr/share/nginx/html; index index.html; # 前端history路由 location / { try_files $uri $uri/ /index.html; } # 接口代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files $uri $uri/ /index.html;這行是 history 路由的關(guān)鍵不加的話刷新非首頁(yè)路由會(huì) 404。這個(gè)坑我第一次部署踩過(guò)排查了半天最后發(fā)現(xiàn)就是少了這一句。6.2 常見(jiàn)問(wèn)題速查表問(wèn)題 1跨域請(qǐng)求被攔截表現(xiàn)瀏覽器 Console 提示 CORS error。原因通常是前端請(qǐng)求地址和后端地址不一致。解決方案優(yōu)先用 Vite/Nginx 代理后端加CrossOrigin只是臨時(shí)手段生產(chǎn)環(huán)境還是得靠代理解決。問(wèn)題 2前端登錄后刷新頁(yè)面變回未登錄原因Vuex/Pinia 里的數(shù)據(jù)是內(nèi)存態(tài)的刷新就沒(méi)了。解決token 和 userInfo 存在 localStorage頁(yè)面啟動(dòng)時(shí)先從 localStorage 恢復(fù) store 狀態(tài)。問(wèn)題 3表單提交時(shí)間字段顯示一串?dāng)?shù)字原因MySQL 的 datetime 類(lèi)型沒(méi)有做時(shí)區(qū)轉(zhuǎn)換Java 接收時(shí)解析成了時(shí)間戳。解決在 application.yml 里配置spring.jackson.date-format: yyyy-MM-dd HH:mm:ss和spring.jackson.time-zone: GMT8。問(wèn)題 4商品圖片上傳成功但訪問(wèn) 404原因配置的upload.path不正確或者路徑?jīng)]映射到靜態(tài)資源。解決確認(rèn)磁盤(pán)絕對(duì)路徑存在檢查WebMvcConfig里的addResourceLocations必須file:前綴。問(wèn)題 5部署到服務(wù)器后接口可以訪問(wèn)但圖片加載失敗原因Nginx 配置沖突location /把靜態(tài)資源請(qǐng)求也接管了但找不到對(duì)應(yīng)文件就返回 index.html。解決單獨(dú)加一條圖片路徑的 locationlocation /images/ { alias /opt/clothing-upload/; }6.3 兩個(gè)值得記住的實(shí)戰(zhàn)經(jīng)驗(yàn)第一個(gè)訂單號(hào)別用自增 ID。訂單表雖然id是自增主鍵但那只能用于內(nèi)部關(guān)聯(lián)展示給用戶的訂單號(hào)必須單獨(dú)生成。網(wǎng)上很多教程直接用主鍵當(dāng)訂單號(hào)用戶看到自己的訂單一號(hào)二號(hào)三號(hào)很容易猜出平臺(tái)有多少訂單這在電商里是不專業(yè)的。我用的是“時(shí)間戳 隨機(jī)數(shù)”的格式比如20241103152012345616 位數(shù)字簡(jiǎn)潔還挺好用。第二個(gè)所有數(shù)據(jù)庫(kù)交互的金額字段必須用 decimal不能用 float 或 double。這是做電商系統(tǒng)的第一天就該養(yǎng)成的習(xí)慣。float 的二進(jìn)制浮點(diǎn)誤差在累計(jì)銷(xiāo)售總額、計(jì)算優(yōu)惠折扣時(shí)會(huì)放大到肉眼可見(jiàn)的錯(cuò)誤用decimal(10,2)才能保證財(cái)務(wù)金額精確計(jì)算。類(lèi)似地前端傳價(jià)格時(shí)用“分”為單位整數(shù)傳遞到顯示層再轉(zhuǎn)成“元”這是很多大廠電商項(xiàng)目的統(tǒng)一規(guī)范既避免浮點(diǎn)誤差也方便對(duì)接支付接口。7. 寫(xiě)在最后的個(gè)人體會(huì)這套服裝商城銷(xiāo)售管理系統(tǒng)做下來(lái)最大的收獲不是掌握了某個(gè)具體技術(shù)點(diǎn)而是把電商業(yè)務(wù)里互相咬合的模塊完整地理解了。比如訂單和庫(kù)存的關(guān)系、JWT 認(rèn)證在前后端分離項(xiàng)目中的完整鏈路、后端事務(wù)和前端狀態(tài)的配合這些知識(shí)單獨(dú)學(xué)任何一門(mén)課都很難有這種“全局觀”。對(duì)于想拿這個(gè)項(xiàng)目練手或者做畢設(shè)的同學(xué)我建議拿到代碼后不要只跑通就結(jié)束而是嘗試自己增加幾個(gè)模塊比如優(yōu)惠券功能下單時(shí)抵扣金額、商品評(píng)論功能用戶下單后評(píng)價(jià)曬圖、收貨地址管理多地址切換。這些擴(kuò)展點(diǎn)每個(gè)都能單獨(dú)寫(xiě)一套邏輯做完之后你對(duì)這套系統(tǒng)的理解會(huì)再上一個(gè)臺(tái)階。項(xiàng)目里最初的代碼風(fēng)格還有很多不規(guī)范的地方比如部分接口參數(shù)沒(méi)有做校驗(yàn)、定時(shí)任務(wù)沒(méi)有加分布式鎖兩臺(tái)服務(wù)器部署時(shí)會(huì)重復(fù)執(zhí)行、圖片上傳沒(méi)有限制文件類(lèi)型等等。我當(dāng)時(shí)是在滿足功能的前提下逐步優(yōu)化、迭代加固的。對(duì)于個(gè)人項(xiàng)目或者畢設(shè)來(lái)說(shuō)先把主鏈路跑通是第一優(yōu)先級(jí)然后在這個(gè)基礎(chǔ)上持續(xù)打磨項(xiàng)目的質(zhì)量是一版一版“練”出來(lái)的。