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