項(xiàng)目實(shí)踐：從前后端分離架構(gòu)到部署落地)
做這種“基于Vue的電商購物平臺(tái)”項(xiàng)目我的第一反應(yīng)是這大概率不是一個(gè)人閑著沒事寫的玩具而是畢業(yè)設(shè)計(jì)或者課程設(shè)計(jì)的標(biāo)配需求。用戶要的不是一堆概念而是一個(gè)能真正跑起來、能講清楚、能寫進(jìn)論文的完整閉環(huán)系統(tǒng)。我前前后后幫人做過好幾個(gè)類似的項(xiàng)目從零搭建到交付源碼、再到陪跑答辯踩過的坑比很多人寫過的代碼都多。這篇就把我實(shí)際做這個(gè)項(xiàng)目時(shí)的完整思路、技術(shù)選型、數(shù)據(jù)庫設(shè)計(jì)、前端交互邏輯、以及最后聯(lián)調(diào)部署時(shí)最容易翻車的幾個(gè)點(diǎn)一次性講透。這個(gè)項(xiàng)目的東西不難但東西多。前端Vue、后端JavaSpring Boot那一套、MySQL數(shù)據(jù)庫再加上商品瀏覽、購物車、訂單、支付模擬、后臺(tái)管理這幾個(gè)核心模塊串起來就是一個(gè)標(biāo)準(zhǔn)的前后端分離電商系統(tǒng)。適合正在準(zhǔn)備畢業(yè)設(shè)計(jì)、簡歷上缺一個(gè)像樣全棧項(xiàng)目的同學(xué)也適合想搞懂“電商網(wǎng)站背后到底怎么運(yùn)轉(zhuǎn)”的初學(xué)者直接照著抄作業(yè)。1. 項(xiàng)目整體設(shè)計(jì)與技術(shù)選型1.1 核心需求與系統(tǒng)邊界在動(dòng)手寫代碼之前我習(xí)慣先把用戶需求和系統(tǒng)邊界畫清楚。電商購物平臺(tái)聽起來很大但作為一個(gè)可交付的畢設(shè)項(xiàng)目核心業(yè)務(wù)其實(shí)就那么幾條線用戶注冊登錄、瀏覽商品、加入購物車、提交訂單、模擬支付、后臺(tái)管理商品和訂單。這里我要多說一句很多同學(xué)一上來就想做秒殺、拼團(tuán)、優(yōu)惠券、積分商城這些功能不是不能加但如果你連最基礎(chǔ)的“下單減庫存”都還沒理清楚加再多花活都是給自己埋雷。畢設(shè)項(xiàng)目講究的是業(yè)務(wù)閉環(huán)完整而不是功能數(shù)量多。一個(gè)能從注冊走到支付完成、后臺(tái)能看到訂單狀態(tài)的系統(tǒng)已經(jīng)足夠說明你理解了電商的核心流程。我做的這個(gè)版本用戶端包含注冊登錄、商品列表、商品詳情、購物車、訂單確認(rèn)、支付成功頁、個(gè)人訂單列表管理端包含商品管理、分類管理、訂單管理、用戶管理、數(shù)據(jù)統(tǒng)計(jì)看板。數(shù)據(jù)統(tǒng)計(jì)看板是后來加的需求用ECharts做了簡單的柱狀圖和折線圖展示銷售額趨勢和商品銷量排行這正好也符合很多題目里寫的“數(shù)據(jù)可視化”。1.2 前端技術(shù)棧為什么是Vue題目里直接寫了“基于Vue”所以前端框架基本是鎖定的。但Vue也分Vue2和Vue3還有一個(gè)Element UI和Element Plus的選擇問題。我實(shí)際開發(fā)中用的是Vue2 Element UI Vuex Vue Router Axios的組合原因有兩點(diǎn)。第一Vue2生態(tài)成熟穩(wěn)定網(wǎng)上資料最多遇到問題基本都能搜到答案。雖然Vue3是趨勢但很多高校的課程和企業(yè)舊項(xiàng)目還是以Vue2為主答辯時(shí)老師也更熟悉這套東西。第二Element UI的組件風(fēng)格非常適合后臺(tái)管理系統(tǒng)和電商前臺(tái)頁面表格、表單、分頁、彈窗這些現(xiàn)成組件拿來即用能把大量時(shí)間省下來投入到業(yè)務(wù)邏輯上。當(dāng)然如果你是從零開始學(xué)也可以直接用Vue3 Element Plus Pinia代碼寫起來更現(xiàn)代一點(diǎn)。項(xiàng)目核心是業(yè)務(wù)閉環(huán)不是框架版本這個(gè)道理要搞清楚。前端項(xiàng)目的目錄結(jié)構(gòu)我習(xí)慣這樣安排src/ api/ // 接口請求封裝 assets/ // 靜態(tài)資源 components/ // 公共組件頂部導(dǎo)航、商品卡片等 router/ // 路由配置 store/ // Vuex狀態(tài)管理 views/ // 頁面視圖 home/ // 首頁 goods/ // 商品列表與詳情 cart/ // 購物車 order/ // 訂單確認(rèn)與列表 user/ // 個(gè)人中心 admin/ // 后臺(tái)管理 utils/ // 工具函數(shù)request封裝、格式化等1.3 后端技術(shù)選型Java Spring Boot后端我選的是Spring Boot MyBatis Plus MySQL。為什么不用PHP、Python、C#不是它們不好而是對于這種“業(yè)務(wù)閉環(huán)型”項(xiàng)目Spring Boot有幾點(diǎn)天然優(yōu)勢Maven管理依賴方便MyBatis Plus的代碼生成器能省掉大量重復(fù)的CRUD代碼Spring Security或者攔截器做登錄鑒權(quán)也成熟。還有一個(gè)很現(xiàn)實(shí)的理由畢業(yè)設(shè)計(jì)答辯老師最熟悉的技術(shù)棧就是Java你拿Java寫的東西老師起碼挑不出“技術(shù)棧太偏”的毛病。用Python寫Django或者Flask也可以但用Java的人更多、參考代碼更多遇到問題更好解決。后端項(xiàng)目結(jié)構(gòu)就是經(jīng)典的三層架構(gòu)controller/ // 接收請求返回結(jié)果 service/ // 業(yè)務(wù)邏輯層 mapper/ // 數(shù)據(jù)訪問層MyBatis Plus entity/ // 數(shù)據(jù)庫實(shí)體 config/ // 攔截器、跨域配置等 common/ // 統(tǒng)一返回結(jié)果、異常處理這里的核心思路是讓每層各司其職比如下單這個(gè)操作Controller只負(fù)責(zé)接收參數(shù)和返回結(jié)果真正“檢查庫存、扣減庫存、生成訂單號、創(chuàng)建訂單、清空購物車”這一串動(dòng)作全部放在Service里完成。這樣代碼邏輯清晰寫論文的時(shí)候畫個(gè)架構(gòu)圖也順理成章。1.4 為什么堅(jiān)持前后端分離現(xiàn)在做項(xiàng)目第一反應(yīng)就應(yīng)該是前后端分離。前端Vue跑在8080端口后端Spring Boot跑在8081端口通過接口交互前端通過Axios發(fā)起請求后端返回JSON數(shù)據(jù)。前后端分離的好處是開發(fā)時(shí)兩邊可以并行前端用模擬數(shù)據(jù)也能先跑起來部署時(shí)前端打包成靜態(tài)文件扔到Nginx后端單獨(dú)啟動(dòng)答辯演示時(shí)前端頁面掛了也不影響后端邏輯的講解。這個(gè)架構(gòu)寫進(jìn)論文里也是加分項(xiàng)因?yàn)樗悄壳捌髽I(yè)開發(fā)的主流方式。開發(fā)階段我用Vue CLI的代理解決跨域問題配置在vue.config.js里module.exports { devServer: { proxy: { /api: { target: http://localhost:8081, changeOrigin: true } } } }這樣前端請求的/api/user/login會(huì)自動(dòng)轉(zhuǎn)發(fā)到后端的http://localhost:8081/api/user/login不用在后端單獨(dú)配CORS省了很多事。2. 環(huán)境準(zhǔn)備與項(xiàng)目啟動(dòng)2.1 本地開發(fā)環(huán)境清單標(biāo)準(zhǔn)的一套環(huán)境配置如下版本不需要特別新穩(wěn)定即可軟件版本建議說明JDK1.8大多數(shù)學(xué)校和企業(yè)還在用8別盲目上17MySQL5.7或8.08.0注意驅(qū)動(dòng)配置Node.js14.x或16.xVue2項(xiàng)目建議14以上IDEA任意版本社區(qū)版也能用VSCode任意版本寫前端用Navicat可選可視化數(shù)據(jù)庫管理這里有個(gè)我實(shí)際踩過的坑Node版本不能太新。之前某同學(xué)直接用Node 18跑Vue2項(xiàng)目結(jié)果node-sass安裝失敗報(bào)一堆紅字錯(cuò)誤。這不是你的代碼問題是node-sass對新版Node支持不到位。解決方案有兩個(gè)一是把Node版本降到16二是把node-sass換成sassdart-sass。我后來統(tǒng)一用dart-sass干凈利落。2.2 數(shù)據(jù)庫初始化數(shù)據(jù)庫不需要手動(dòng)建表。項(xiàng)目自帶的sql目錄下有一個(gè)mall.sql腳本用Navicat或者命令行直接執(zhí)行就能把所有表結(jié)構(gòu)、初始數(shù)據(jù)一次性導(dǎo)入。執(zhí)行完以后數(shù)據(jù)庫名是mall里面包含用戶表、商品表、訂單表、購物車表、分類表這些核心表初始數(shù)據(jù)里有測試賬號管理員和普通用戶以及一批商品數(shù)據(jù)方便演示。這種“自帶腳本直接跑”的方式對交付非常重要。你想想如果別人拿到你的源碼還要對著幾十行SQL到處找哪里有缺失體驗(yàn)會(huì)非常差。所以我做項(xiàng)目的時(shí)候SQL腳本一定會(huì)寫全表結(jié)構(gòu)、測試數(shù)據(jù)、索引全部包含在一個(gè)文件里。2.3 啟動(dòng)順序和驗(yàn)證啟動(dòng)是整個(gè)流程里最容易出問題的環(huán)節(jié)我寫一個(gè)標(biāo)準(zhǔn)順序啟動(dòng)MySQL確認(rèn)3306端口正常監(jiān)聽用IDEA打開后端項(xiàng)目修改application.yml里的數(shù)據(jù)庫賬號密碼啟動(dòng)Spring Boot命令行進(jìn)入前端項(xiàng)目目錄執(zhí)行npm install安裝依賴執(zhí)行npm run serve啟動(dòng)前端開發(fā)服務(wù)瀏覽器訪問http://localhost:8080看到首頁說明啟動(dòng)成功驗(yàn)證后端是否正?？梢灾苯釉跒g覽器訪問http://localhost:8081/api/goods/list如果返回了商品列表的JSON數(shù)據(jù)說明后端、數(shù)據(jù)庫、接口鏈路全是通的。啟動(dòng)過程中如果發(fā)現(xiàn)端口被占用用下面命令查netstat -ano | findstr 8081查到PID之后去任務(wù)管理器結(jié)束對應(yīng)進(jìn)程就行。這是最常用的一招。3. 數(shù)據(jù)庫設(shè)計(jì)表結(jié)構(gòu)與字段規(guī)劃3.1 用戶表設(shè)計(jì)用戶表是系統(tǒng)的基座登錄、注冊、管理員身份全都靠它。CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 用戶名, password varchar(100) NOT NULL COMMENT 密碼BCrypt加密, nickname varchar(50) DEFAULT NULL COMMENT 昵稱, role tinyint(1) NOT NULL DEFAULT 0 COMMENT 角色0-普通用戶1-管理員, phone varchar(20) DEFAULT NULL COMMENT 手機(jī)號, avatar varchar(255) DEFAULT NULL COMMENT 頭像地址, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;這里有兩個(gè)關(guān)鍵細(xì)節(jié)。第一密碼一定要加密存儲(chǔ)我用的BCryptSpring Security自帶的加密工具安全且答辯時(shí)能講出所以然。第二用戶名加了唯一索引防止重復(fù)注冊。就這么一個(gè)簡單的字段設(shè)計(jì)當(dāng)時(shí)答辯時(shí)老師問“你這個(gè)用戶表怎么保證數(shù)據(jù)一致性”直接用唯一索引回答就可以了。3.2 商品表與分類表商品表是系統(tǒng)的門面首頁和列表頁展示的信息都來自這張表。CREATE TABLE category ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(50) NOT NULL COMMENT 分類名, sort int(11) DEFAULT 0 COMMENT 排序權(quán)重, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE goods ( id int(11) NOT NULL AUTO_INCREMENT, category_id int(11) NOT NULL COMMENT 所屬分類, name varchar(200) NOT NULL COMMENT 商品名稱, subtitle varchar(255) DEFAULT NULL COMMENT 副標(biāo)題, main_image varchar(500) DEFAULT NULL COMMENT 主圖地址, price decimal(10,2) NOT NULL COMMENT 價(jià)格單位元, stock int(11) NOT NULL DEFAULT 0 COMMENT 庫存, sales int(11) NOT NULL DEFAULT 0 COMMENT 銷量, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 狀態(tài)1-上架0-下架, detail text COMMENT 商品詳情, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;價(jià)格字段我用的decimal(10,2)而不是float這是個(gè)非常容易被忽略的坑。float存在精度丟失問題兩個(gè)浮點(diǎn)數(shù)做加減運(yùn)算結(jié)果會(huì)有偏差電商場景下算錯(cuò)一毛錢都受不了。decimal是定點(diǎn)數(shù)精度由你自己定義10,2表示總共10位數(shù)、小數(shù)2位百萬級的商品價(jià)格足夠用了。3.3 購物車表與訂單相關(guān)表購物車表的關(guān)鍵設(shè)計(jì)在于狀態(tài)位CREATE TABLE cart_item ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, goods_id int(11) NOT NULL, quantity int(11) NOT NULL DEFAULT 1, checked tinyint(1) NOT NULL DEFAULT 1 COMMENT 是否選中1-選中0-未選中, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_goods (user_id,goods_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;uk_user_goods這個(gè)聯(lián)合唯一索引特別重要。它保證了同一個(gè)用戶對同一個(gè)商品只會(huì)存在一條購物車記錄用戶反復(fù)點(diǎn)擊“加入購物車”后端要做的是把quantity加1而不是插入一條新記錄。很多初學(xué)者做購物車沒有加這個(gè)唯一約束結(jié)果用戶點(diǎn)一次加購就多一條記錄購物車變成流水賬后面改起來非常費(fèi)勁。訂單相關(guān)表拆成主表order和明細(xì)表order_item。主表存訂單編號、用戶ID、訂單總價(jià)、訂單狀態(tài)、收貨地址、創(chuàng)建時(shí)間明細(xì)表存訂單里每個(gè)商品的信息商品ID、商品名稱冗余存儲(chǔ)、單價(jià)、數(shù)量。為什么要拆兩張表因?yàn)橐粋€(gè)訂單包含多個(gè)商品一張表存不下。如果只存一個(gè)合并的商品字符串比如“蘋果x2,香蕉x1”之后想做訂單統(tǒng)計(jì)、銷量分析就完全沒法查了。下單時(shí)的庫存扣減邏輯是這樣的校驗(yàn)庫存充足 - 扣減庫存 - 生成訂單 - 返回訂單號?？蹘齑婧蜕捎唵伪仨毞旁谕粋€(gè)事務(wù)里否則會(huì)出現(xiàn)庫存扣了但訂單沒生成、或者訂單生成了但庫存沒扣的情況。事務(wù)我用Transactional注解Spring管理一句話的事。3.4 表關(guān)系與查詢思路用戶、訂單、購物車、商品之間的關(guān)系一句話總結(jié)用戶1對多訂單訂單1對多訂單明細(xì)訂單明細(xì)多對1商品購物車是用戶和商品的多對多關(guān)系表。理解了這條關(guān)系鏈寫SQL基本不會(huì)迷路。后臺(tái)管理端查“某用戶的訂單詳情”這種SQL核心就是join兩三次表SELECT o.id, o.order_no, o.payment, o.status, oi.goods_name, oi.goods_price, oi.quantity FROM order o LEFT JOIN order_item oi ON o.id oi.order_id WHERE o.user_id #{userId} ORDER BY o.create_time DESC4. 功能模塊實(shí)現(xiàn)前端核心交互與后端業(yè)務(wù)閉環(huán)4.1 注冊登錄與權(quán)限控制登錄功能的實(shí)現(xiàn)分三步前端表單校驗(yàn) - 后端驗(yàn)證用戶名密碼 - 簽發(fā)Token返回 - 前端存儲(chǔ)Token并跳轉(zhuǎn)首頁。Token我用的是JWT一段由頭部、載荷、簽名組成的字符串。用戶在登錄成功后拿到Token之后每次請求都帶上后端通過攔截器校驗(yàn)Token的合法性再從Token中解析出用戶ID和角色。攔截器是實(shí)現(xiàn)權(quán)限控制的關(guān)鍵核心思路是放行登錄、注冊、商品列表這些公開接口攔截需要登錄才能訪問的接口如下單、查看購物車、后臺(tái)管理接口。public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); // 解析token失敗則返回401提示未登錄 // 解析成功則將用戶信息放入request上下文供后續(xù)Service使用 }前端配合這位使用Axios攔截器所有請求自動(dòng)從localStorage取Token并放進(jìn)請求頭service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config })前端路由還需要做權(quán)限守衛(wèi)未登錄用戶訪問“我的訂單”頁面時(shí)直接重定向到登錄頁router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path.startsWith(/order) !token) { next(/login) } else { next() } })4.2 商品列表與詳情展示商品列表用的是Element UI的el-card組件加自定義商品卡片每張卡片顯示商品圖、名稱、價(jià)格點(diǎn)擊跳轉(zhuǎn)到詳情頁。列表數(shù)據(jù)是后端接口返回的分頁參數(shù)pageNum和pageSize通過GET請求傳給后端。商品詳情頁除了基本信息展示還有一個(gè)“加入購物車”和一個(gè)“立即購買”按鈕。加入購物車就是調(diào)用后端接口傳入goodsId和quantity立即購買則先判斷是否登錄未登錄跳登錄頁已登錄把這件商品作為選中狀態(tài)跳轉(zhuǎn)到訂單確認(rèn)頁。針對商品圖片很多畢設(shè)項(xiàng)目用的是本地圖片地址比如/upload/xxx.jpg。我建議直接存一個(gè)圖片URL或者把圖片放到后端的resources/static/upload下通過Spring Boot的靜態(tài)資源映射來訪問。不要存base64到數(shù)據(jù)庫里那會(huì)讓表體量暴漲且查詢極慢。4.3 購物車業(yè)務(wù)邏輯購物車頁面的核心操作是勾選商品、修改數(shù)量、刪除商品、全選、計(jì)算總價(jià)?？們r(jià)的計(jì)算前端做還是后端做我建議展示用前端實(shí)時(shí)算下單時(shí)以后端重新計(jì)算為準(zhǔn)。后端計(jì)算訂單金額是一個(gè)很關(guān)鍵的信任邊界。用戶在前端看到的金額只是“預(yù)估”真正下單時(shí)后端要重新從數(shù)據(jù)庫讀取商品的價(jià)格乘以數(shù)量累加出總價(jià)。如果直接從頁面?zhèn)饕粋€(gè)總價(jià)給后端那用戶完全可以改接口參數(shù)把訂單金額改成0.01元下單這是嚴(yán)重的邏輯漏洞。所以“后端為準(zhǔn)”是必須堅(jiān)持的原則。購物車接口設(shè)計(jì)大概有五個(gè)添加購物車POST /api/cart/add購物車列表GET /api/cart/list更新購物車數(shù)量PUT /api/cart/update刪除購物車項(xiàng)DELETE /api/cart/delete/{id}選擇購物車項(xiàng)PUT /api/cart/check每個(gè)接口都必須校驗(yàn)user_id是不是當(dāng)前登錄用戶的ID防止越權(quán)操作。之前我見過有的項(xiàng)目傳一個(gè)購物車ID刪除后端不加校驗(yàn)直接把對應(yīng)記錄刪了結(jié)果用戶A能刪用戶B的購物車數(shù)據(jù)。這就是典型的水平越權(quán)漏洞答辯時(shí)被老師追問會(huì)非常難看。4.4 下單與模擬支付下單流程是業(yè)務(wù)閉環(huán)的核心環(huán)節(jié)。用戶從購物車勾選商品點(diǎn)擊“去結(jié)算”進(jìn)入訂單確認(rèn)頁填寫收貨人、手機(jī)號、地址點(diǎn)擊“提交訂單”。后端下單接口內(nèi)部做了這么幾件事從請求中取出購物車ID列表選中的那些購物車項(xiàng)查出購物車數(shù)據(jù)和對應(yīng)商品逐條校驗(yàn)庫存計(jì)算總價(jià)生成唯一訂單號扣減庫存并累加商品銷量創(chuàng)建訂單主記錄和訂單明細(xì)清空已下單的購物車記錄返回訂單號和訂單金額每一步都在同一個(gè)事務(wù)方法里完成任何一步失敗全部回滾。這里有一個(gè)理論支撐點(diǎn)叫“分布式事務(wù)的本地事務(wù)簡化”單體應(yīng)用用Transactional就足夠了不需要引入消息隊(duì)列。模擬支付的實(shí)現(xiàn)很簡單創(chuàng)建訂單后訂單狀態(tài)為“待支付”前端跳轉(zhuǎn)到支付頁點(diǎn)擊“立即支付”調(diào)用POST /api/order/pay/{orderNo}。后端把這個(gè)接口模擬成支付成功把訂單狀態(tài)改成“已支付”。因?yàn)楫呍O(shè)不需要對接真實(shí)支付寶、微信支付所以這一步用一個(gè)模擬接口講清楚整個(gè)狀態(tài)流轉(zhuǎn)即可。訂單狀態(tài)的枚舉我建議設(shè)計(jì)成0-待支付1-已支付待發(fā)貨2-已發(fā)貨3-已完成4-已取消。后臺(tái)管理員可以對訂單進(jìn)行發(fā)貨操作把狀態(tài)從1改為2。5. 接口聯(lián)調(diào)與狀態(tài)管理5.1 統(tǒng)一返回結(jié)果封裝接口聯(lián)調(diào)最怕前后端各寫各的、對齊困難。我一開始就定了一套統(tǒng)一的返回格式{ code: 200, message: success, data: { } }code代表業(yè)務(wù)狀態(tài)碼200成功、400參數(shù)錯(cuò)誤、401未登錄、403無權(quán)限、500服務(wù)器異常。前端Axios響應(yīng)攔截器拿到響應(yīng)后先看code非200的話彈錯(cuò)誤提示并中斷操作。這樣一套規(guī)范寫下來不管接口有多少前后端永遠(yuǎn)不會(huì)因?yàn)榉祷馗袷絾栴}吵架。5.2 Vuex狀態(tài)管理前端我用Vuex管理全局狀態(tài)主要存儲(chǔ)用戶信息和購物車數(shù)量。用戶登錄成功后dispatch一個(gè)login的action把用戶信息寫進(jìn)store同時(shí)同步到localStorage。刷新頁面時(shí)在main.js里重新從localStorage讀取用戶信息調(diào)store.commit(setUser)避免刷新后頁面變成未登錄狀態(tài)。購物車數(shù)量是頂欄右上角的小紅點(diǎn)數(shù)字登錄后拉取購物車列表取所有item的quantity求和這個(gè)數(shù)字變化及時(shí)更新到Vuex里。Vuex的好處是組件間共享狀態(tài)不用一層層傳props缺點(diǎn)是刷新后狀態(tài)丟失所以配合localStorage做持久化這兩個(gè)結(jié)合起來用是前端狀態(tài)管理的標(biāo)準(zhǔn)姿勢。5.3 Axios封裝與接口統(tǒng)一管理我把所有后端接口按照模塊統(tǒng)一封裝到src/api目錄下例如// api/goods.js import request from /utils/request export function getGoodsList(params) { return request({ url: /api/goods/list, method: get, params }) }這樣頁面里調(diào)用時(shí)一行代碼搞定const res await getGoodsList({ pageNum: 1 })。接口統(tǒng)一收口的好處是后端接口路徑變了只需要改一個(gè)文件不用全局搜索到處改。5.4 后臺(tái)管理端實(shí)現(xiàn)后臺(tái)管理端和前臺(tái)的代碼在同一個(gè)Vue項(xiàng)目里通過路由前綴區(qū)分/admin開頭的都是管理頁面。權(quán)限上用路由守衛(wèi)判斷當(dāng)前用戶role是否為1非管理員直接踢回首頁。商品管理頁用el-table展示商品列表支持新增、編輯、刪除、上下架操作。新增商品時(shí)彈出一個(gè)el-dialog表單包含商品名稱、分類、價(jià)格、庫存、主圖、詳情等信息提交后調(diào)用后端接口寫入數(shù)據(jù)庫。訂單管理頁展示所有訂單支持按訂單號和狀態(tài)篩選。管理員可以點(diǎn)擊“發(fā)貨”按鈕把訂單狀態(tài)從待發(fā)貨變成已發(fā)貨。用戶管理頁就相對簡單查看用戶列表、啟用禁用賬號。數(shù)據(jù)統(tǒng)計(jì)頁用ECharts畫三個(gè)圖近七天銷售額折線圖、商品分類銷售占比餅圖、商品銷量排行條形圖。數(shù)據(jù)來源是后端統(tǒng)計(jì)接口返回的聚合數(shù)據(jù)。這一段代碼不復(fù)雜但視覺效果好答辯演示的時(shí)候老師看到圖表基本都會(huì)覺得項(xiàng)目很完整。6. 常見坑與排查心得6.1 跨域請求被攔截這個(gè)是前后端分離項(xiàng)目出現(xiàn)頻率最高的報(bào)錯(cuò)。現(xiàn)象是前端控制臺(tái)報(bào)No Access-Control-Allow-Origin header is present請求發(fā)出去了但一直拋錯(cuò)。實(shí)際排查要區(qū)分開發(fā)環(huán)境和部署環(huán)境。開發(fā)環(huán)境我用的是Vue CLI的proxy代理后端不用處理跨域部署環(huán)境如果前端Nginx和后端域名不同需要在Nginx配置反向代理或者后端配置CORS。為什么開發(fā)時(shí)proxy能解決因?yàn)榇硎峭吹臑g覽器看到的是前端服務(wù)轉(zhuǎn)發(fā)出去的請求不存在跨域。這一點(diǎn)在答辯時(shí)要能講清楚屬于架構(gòu)層面的理解題。6.2 數(shù)據(jù)庫時(shí)間字段差8小時(shí)MySQL連接串如果沒設(shè)置serverTimezone會(huì)在時(shí)區(qū)上出問題。我一開始后端返回的創(chuàng)建時(shí)間比實(shí)際時(shí)間少了8個(gè)小時(shí)排查時(shí)發(fā)現(xiàn)是數(shù)據(jù)庫連接沒指定時(shí)區(qū)。在application.yml里加一行就解決spring: datasource: url: jdbc:mysql://localhost:3306/mall?useUnicodetruecharacterEncodingutf-8serverTimezoneAsia/Shanghai這種問題寫論文時(shí)幾乎不會(huì)被提到但實(shí)際開發(fā)時(shí)非常典型真遇到了很磨人。6.3 npm install頻繁報(bào)錯(cuò)前端依賴安裝是另一大坑。npm install報(bào)錯(cuò)時(shí)我的處理路徑是清緩存npm cache clean --force刪掉node_modules和package-lock.json重新裝如果node-sass導(dǎo)致報(bào)錯(cuò)把sass相關(guān)的包換成dart-sass直接安裝node-sassnpm:dart-sass或者改用sass實(shí)在不行換鏡像源很多時(shí)候不是代碼問題而是網(wǎng)絡(luò)源或者Node版本和依賴不兼容。這些坑第一次遇到會(huì)覺得莫名其妙記錄到筆記里下次三分鐘就能解決。6.4 常見問題速查表現(xiàn)象可能原因解決辦法前端請求一直pending后端沒啟動(dòng)或端口不對先訪問后端接口確認(rèn)返回?cái)?shù)據(jù)登錄后刷新頁面狀態(tài)丟失用戶信息只存了Vuex沒存localStorage持久化用戶信息刷新時(shí)重新讀取加入購物車重復(fù)插入記錄數(shù)據(jù)表缺少聯(lián)合唯一索引加uk_user_goods唯一索引用插入時(shí)ON DUPLICATE KEY UPDATE下單不扣庫存事務(wù)沒生效或庫存扣減邏輯錯(cuò)誤檢查方法上有沒有Transactional檢查庫存校驗(yàn)是否在事務(wù)內(nèi)管理員頁面普通用戶也能訪問前端路由守衛(wèi)沒檢查角色在beforeEach里增加role 1判斷圖片不顯示圖片路徑是絕對路徑后端沒映射在Spring Boot中配置靜態(tài)資源映射或改用相對路徑分頁數(shù)據(jù)不對前端傳的參數(shù)名和后端接收的參數(shù)名不一致統(tǒng)一用pageNum/pageSize記得大小寫一致7. 部署上線與后續(xù)擴(kuò)展7.1 打包部署前端的部署方式很簡單執(zhí)行npm run build后dist目錄下就是打包好的靜態(tài)文件。把它扔到Nginx的html目錄配置一個(gè)server塊就能通過80端口訪問。這里有個(gè)關(guān)鍵點(diǎn)直接雙擊index.html使用file協(xié)議打開會(huì)一片空白因?yàn)槁酚捎玫氖荋istory模式file協(xié)議不支持。要么改用hash模式要么配置Nginx的try_files。我在交付項(xiàng)目時(shí)會(huì)附帶一份啟動(dòng)文檔詳細(xì)到每一步怎么操作、訪問什么地址、初始賬號是什么拿到的同學(xué)照著文檔走一遍就能跑起來。這種項(xiàng)目如果說還有什么無形的價(jià)值就是這套標(biāo)準(zhǔn)化交付的習(xí)慣。7.2 功能的擴(kuò)展方向項(xiàng)目運(yùn)行起來之后如果還有余力可以往幾個(gè)方向擴(kuò)展接入Redis做驗(yàn)證碼存儲(chǔ)和Session共享加ElasticSearch做商品搜索用RabbitMQ做訂單超時(shí)取消。這些技術(shù)點(diǎn)每一個(gè)都能單獨(dú)寫進(jìn)論文的“系統(tǒng)優(yōu)化”章節(jié)也都能在答辯時(shí)展示你對系統(tǒng)的深入理解。但我的建議是先把現(xiàn)有閉環(huán)打磨好別急著加。有一個(gè)完整可運(yùn)行的項(xiàng)目比一個(gè)半成品但堆了十種技術(shù)的項(xiàng)目更有說服力。7.3 文檔與答辯材料的整理很多同學(xué)源代碼跑通了就感覺自己完事了但實(shí)際上交付一個(gè)畢設(shè)/課設(shè)項(xiàng)目文檔是占大頭價(jià)值的。我常見做法是整理四份材料需求分析文檔含用例圖、數(shù)據(jù)庫設(shè)計(jì)文檔含ER圖和表結(jié)構(gòu)說明、接口文檔用Swagger或者Word表格、操作手冊含截圖和啟動(dòng)步驟。再加上一個(gè)PPT流程就是“研究背景 - 技術(shù)棧選型 - 系統(tǒng)架構(gòu)圖 - 核心功能展示 - 數(shù)據(jù)庫設(shè)計(jì) - 總結(jié)”。答辯的時(shí)候照著這個(gè)順序講重點(diǎn)放在“前后端分離架構(gòu) 完整業(yè)務(wù)閉環(huán) 安全校驗(yàn)”這幾個(gè)點(diǎn)上比背代碼效果好得多。我個(gè)人在實(shí)際操作中的體會(huì)是這類項(xiàng)目最怕的就是“什么都想要但什么都不完整”。能跑通全流程、代碼結(jié)構(gòu)清晰、每一步能講出設(shè)計(jì)理由就是一套成功的交付。把這個(gè)項(xiàng)目完整做下來收獲的不只是幾千行代碼而是一套“從業(yè)務(wù)到架構(gòu)再到細(xì)節(jié)”的完整思考方式。后面不管是找工作面試還是繼續(xù)深造這套思路都能直接復(fù)用。 基于Vue的電商購物平臺(tái)項(xiàng)目實(shí)踐：從前后端分離架構(gòu)到部署落地
做這種“基于Vue的電商購物平臺(tái)”項(xiàng)目我的第一反應(yīng)是這大概率不是一個(gè)人閑著沒事寫的玩具而是畢業(yè)設(shè)計(jì)或者課程設(shè)計(jì)的標(biāo)配需求。用戶要的不是一堆概念而是一個(gè)能真正跑起來、能講清楚、能寫進(jìn)論文的完整閉環(huán)系統(tǒng)。我前前后后幫人做過好幾個(gè)類似的項(xiàng)目從零搭建到交付源碼、再到陪跑答辯踩過的坑比很多人寫過的代碼都多。這篇就把我實(shí)際做這個(gè)項(xiàng)目時(shí)的完整思路、技術(shù)選型、數(shù)據(jù)庫設(shè)計(jì)、前端交互邏輯、以及最后聯(lián)調(diào)部署時(shí)最容易翻車的幾個(gè)點(diǎn)一次性講透。這個(gè)項(xiàng)目的東西不難但東西多。前端Vue、后端JavaSpring Boot那一套、MySQL數(shù)據(jù)庫再加上商品瀏覽、購物車、訂單、支付模擬、后臺(tái)管理這幾個(gè)核心模塊串起來就是一個(gè)標(biāo)準(zhǔn)的前后端分離電商系統(tǒng)。適合正在準(zhǔn)備畢業(yè)設(shè)計(jì)、簡歷上缺一個(gè)像樣全棧項(xiàng)目的同學(xué)也適合想搞懂“電商網(wǎng)站背后到底怎么運(yùn)轉(zhuǎn)”的初學(xué)者直接照著抄作業(yè)。1. 項(xiàng)目整體設(shè)計(jì)與技術(shù)選型1.1 核心需求與系統(tǒng)邊界在動(dòng)手寫代碼之前我習(xí)慣先把用戶需求和系統(tǒng)邊界畫清楚。電商購物平臺(tái)聽起來很大但作為一個(gè)可交付的畢設(shè)項(xiàng)目核心業(yè)務(wù)其實(shí)就那么幾條線用戶注冊登錄、瀏覽商品、加入購物車、提交訂單、模擬支付、后臺(tái)管理商品和訂單。這里我要多說一句很多同學(xué)一上來就想做秒殺、拼團(tuán)、優(yōu)惠券、積分商城這些功能不是不能加但如果你連最基礎(chǔ)的“下單減庫存”都還沒理清楚加再多花活都是給自己埋雷。畢設(shè)項(xiàng)目講究的是業(yè)務(wù)閉環(huán)完整而不是功能數(shù)量多。一個(gè)能從注冊走到支付完成、后臺(tái)能看到訂單狀態(tài)的系統(tǒng)已經(jīng)足夠說明你理解了電商的核心流程。我做的這個(gè)版本用戶端包含注冊登錄、商品列表、商品詳情、購物車、訂單確認(rèn)、支付成功頁、個(gè)人訂單列表管理端包含商品管理、分類管理、訂單管理、用戶管理、數(shù)據(jù)統(tǒng)計(jì)看板。數(shù)據(jù)統(tǒng)計(jì)看板是后來加的需求用ECharts做了簡單的柱狀圖和折線圖展示銷售額趨勢和商品銷量排行這正好也符合很多題目里寫的“數(shù)據(jù)可視化”。1.2 前端技術(shù)棧為什么是Vue題目里直接寫了“基于Vue”所以前端框架基本是鎖定的。但Vue也分Vue2和Vue3還有一個(gè)Element UI和Element Plus的選擇問題。我實(shí)際開發(fā)中用的是Vue2 Element UI Vuex Vue Router Axios的組合原因有兩點(diǎn)。第一Vue2生態(tài)成熟穩(wěn)定網(wǎng)上資料最多遇到問題基本都能搜到答案。雖然Vue3是趨勢但很多高校的課程和企業(yè)舊項(xiàng)目還是以Vue2為主答辯時(shí)老師也更熟悉這套東西。第二Element UI的組件風(fēng)格非常適合后臺(tái)管理系統(tǒng)和電商前臺(tái)頁面表格、表單、分頁、彈窗這些現(xiàn)成組件拿來即用能把大量時(shí)間省下來投入到業(yè)務(wù)邏輯上。當(dāng)然如果你是從零開始學(xué)也可以直接用Vue3 Element Plus Pinia代碼寫起來更現(xiàn)代一點(diǎn)。項(xiàng)目核心是業(yè)務(wù)閉環(huán)不是框架版本這個(gè)道理要搞清楚。前端項(xiàng)目的目錄結(jié)構(gòu)我習(xí)慣這樣安排src/ api/ // 接口請求封裝 assets/ // 靜態(tài)資源 components/ // 公共組件頂部導(dǎo)航、商品卡片等 router/ // 路由配置 store/ // Vuex狀態(tài)管理 views/ // 頁面視圖 home/ // 首頁 goods/ // 商品列表與詳情 cart/ // 購物車 order/ // 訂單確認(rèn)與列表 user/ // 個(gè)人中心 admin/ // 后臺(tái)管理 utils/ // 工具函數(shù)request封裝、格式化等1.3 后端技術(shù)選型Java Spring Boot后端我選的是Spring Boot MyBatis Plus MySQL。為什么不用PHP、Python、C#不是它們不好而是對于這種“業(yè)務(wù)閉環(huán)型”項(xiàng)目Spring Boot有幾點(diǎn)天然優(yōu)勢Maven管理依賴方便MyBatis Plus的代碼生成器能省掉大量重復(fù)的CRUD代碼Spring Security或者攔截器做登錄鑒權(quán)也成熟。還有一個(gè)很現(xiàn)實(shí)的理由畢業(yè)設(shè)計(jì)答辯老師最熟悉的技術(shù)棧就是Java你拿Java寫的東西老師起碼挑不出“技術(shù)棧太偏”的毛病。用Python寫Django或者Flask也可以但用Java的人更多、參考代碼更多遇到問題更好解決。后端項(xiàng)目結(jié)構(gòu)就是經(jīng)典的三層架構(gòu)controller/ // 接收請求返回結(jié)果 service/ // 業(yè)務(wù)邏輯層 mapper/ // 數(shù)據(jù)訪問層MyBatis Plus entity/ // 數(shù)據(jù)庫實(shí)體 config/ // 攔截器、跨域配置等 common/ // 統(tǒng)一返回結(jié)果、異常處理這里的核心思路是讓每層各司其職比如下單這個(gè)操作Controller只負(fù)責(zé)接收參數(shù)和返回結(jié)果真正“檢查庫存、扣減庫存、生成訂單號、創(chuàng)建訂單、清空購物車”這一串動(dòng)作全部放在Service里完成。這樣代碼邏輯清晰寫論文的時(shí)候畫個(gè)架構(gòu)圖也順理成章。1.4 為什么堅(jiān)持前后端分離現(xiàn)在做項(xiàng)目第一反應(yīng)就應(yīng)該是前后端分離。前端Vue跑在8080端口后端Spring Boot跑在8081端口通過接口交互前端通過Axios發(fā)起請求后端返回JSON數(shù)據(jù)。前后端分離的好處是開發(fā)時(shí)兩邊可以并行前端用模擬數(shù)據(jù)也能先跑起來部署時(shí)前端打包成靜態(tài)文件扔到Nginx后端單獨(dú)啟動(dòng)答辯演示時(shí)前端頁面掛了也不影響后端邏輯的講解。這個(gè)架構(gòu)寫進(jìn)論文里也是加分項(xiàng)因?yàn)樗悄壳捌髽I(yè)開發(fā)的主流方式。開發(fā)階段我用Vue CLI的代理解決跨域問題配置在vue.config.js里module.exports { devServer: { proxy: { /api: { target: http://localhost:8081, changeOrigin: true } } } }這樣前端請求的/api/user/login會(huì)自動(dòng)轉(zhuǎn)發(fā)到后端的http://localhost:8081/api/user/login不用在后端單獨(dú)配CORS省了很多事。2. 環(huán)境準(zhǔn)備與項(xiàng)目啟動(dòng)2.1 本地開發(fā)環(huán)境清單標(biāo)準(zhǔn)的一套環(huán)境配置如下版本不需要特別新穩(wěn)定即可軟件版本建議說明JDK1.8大多數(shù)學(xué)校和企業(yè)還在用8別盲目上17MySQL5.7或8.08.0注意驅(qū)動(dòng)配置Node.js14.x或16.xVue2項(xiàng)目建議14以上IDEA任意版本社區(qū)版也能用VSCode任意版本寫前端用Navicat可選可視化數(shù)據(jù)庫管理這里有個(gè)我實(shí)際踩過的坑Node版本不能太新。之前某同學(xué)直接用Node 18跑Vue2項(xiàng)目結(jié)果node-sass安裝失敗報(bào)一堆紅字錯(cuò)誤。這不是你的代碼問題是node-sass對新版Node支持不到位。解決方案有兩個(gè)一是把Node版本降到16二是把node-sass換成sassdart-sass。我后來統(tǒng)一用dart-sass干凈利落。2.2 數(shù)據(jù)庫初始化數(shù)據(jù)庫不需要手動(dòng)建表。項(xiàng)目自帶的sql目錄下有一個(gè)mall.sql腳本用Navicat或者命令行直接執(zhí)行就能把所有表結(jié)構(gòu)、初始數(shù)據(jù)一次性導(dǎo)入。執(zhí)行完以后數(shù)據(jù)庫名是mall里面包含用戶表、商品表、訂單表、購物車表、分類表這些核心表初始數(shù)據(jù)里有測試賬號管理員和普通用戶以及一批商品數(shù)據(jù)方便演示。這種“自帶腳本直接跑”的方式對交付非常重要。你想想如果別人拿到你的源碼還要對著幾十行SQL到處找哪里有缺失體驗(yàn)會(huì)非常差。所以我做項(xiàng)目的時(shí)候SQL腳本一定會(huì)寫全表結(jié)構(gòu)、測試數(shù)據(jù)、索引全部包含在一個(gè)文件里。2.3 啟動(dòng)順序和驗(yàn)證啟動(dòng)是整個(gè)流程里最容易出問題的環(huán)節(jié)我寫一個(gè)標(biāo)準(zhǔn)順序啟動(dòng)MySQL確認(rèn)3306端口正常監(jiān)聽用IDEA打開后端項(xiàng)目修改application.yml里的數(shù)據(jù)庫賬號密碼啟動(dòng)Spring Boot命令行進(jìn)入前端項(xiàng)目目錄執(zhí)行npm install安裝依賴執(zhí)行npm run serve啟動(dòng)前端開發(fā)服務(wù)瀏覽器訪問http://localhost:8080看到首頁說明啟動(dòng)成功驗(yàn)證后端是否正?？梢灾苯釉跒g覽器訪問http://localhost:8081/api/goods/list如果返回了商品列表的JSON數(shù)據(jù)說明后端、數(shù)據(jù)庫、接口鏈路全是通的。啟動(dòng)過程中如果發(fā)現(xiàn)端口被占用用下面命令查netstat -ano | findstr 8081查到PID之后去任務(wù)管理器結(jié)束對應(yīng)進(jìn)程就行。這是最常用的一招。3. 數(shù)據(jù)庫設(shè)計(jì)表結(jié)構(gòu)與字段規(guī)劃3.1 用戶表設(shè)計(jì)用戶表是系統(tǒng)的基座登錄、注冊、管理員身份全都靠它。CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 用戶名, password varchar(100) NOT NULL COMMENT 密碼BCrypt加密, nickname varchar(50) DEFAULT NULL COMMENT 昵稱, role tinyint(1) NOT NULL DEFAULT 0 COMMENT 角色0-普通用戶1-管理員, phone varchar(20) DEFAULT NULL COMMENT 手機(jī)號, avatar varchar(255) DEFAULT NULL COMMENT 頭像地址, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;這里有兩個(gè)關(guān)鍵細(xì)節(jié)。第一密碼一定要加密存儲(chǔ)我用的BCryptSpring Security自帶的加密工具安全且答辯時(shí)能講出所以然。第二用戶名加了唯一索引防止重復(fù)注冊。就這么一個(gè)簡單的字段設(shè)計(jì)當(dāng)時(shí)答辯時(shí)老師問“你這個(gè)用戶表怎么保證數(shù)據(jù)一致性”直接用唯一索引回答就可以了。3.2 商品表與分類表商品表是系統(tǒng)的門面首頁和列表頁展示的信息都來自這張表。CREATE TABLE category ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(50) NOT NULL COMMENT 分類名, sort int(11) DEFAULT 0 COMMENT 排序權(quán)重, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE goods ( id int(11) NOT NULL AUTO_INCREMENT, category_id int(11) NOT NULL COMMENT 所屬分類, name varchar(200) NOT NULL COMMENT 商品名稱, subtitle varchar(255) DEFAULT NULL COMMENT 副標(biāo)題, main_image varchar(500) DEFAULT NULL COMMENT 主圖地址, price decimal(10,2) NOT NULL COMMENT 價(jià)格單位元, stock int(11) NOT NULL DEFAULT 0 COMMENT 庫存, sales int(11) NOT NULL DEFAULT 0 COMMENT 銷量, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 狀態(tài)1-上架0-下架, detail text COMMENT 商品詳情, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;價(jià)格字段我用的decimal(10,2)而不是float這是個(gè)非常容易被忽略的坑。float存在精度丟失問題兩個(gè)浮點(diǎn)數(shù)做加減運(yùn)算結(jié)果會(huì)有偏差電商場景下算錯(cuò)一毛錢都受不了。decimal是定點(diǎn)數(shù)精度由你自己定義10,2表示總共10位數(shù)、小數(shù)2位百萬級的商品價(jià)格足夠用了。3.3 購物車表與訂單相關(guān)表購物車表的關(guān)鍵設(shè)計(jì)在于狀態(tài)位CREATE TABLE cart_item ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, goods_id int(11) NOT NULL, quantity int(11) NOT NULL DEFAULT 1, checked tinyint(1) NOT NULL DEFAULT 1 COMMENT 是否選中1-選中0-未選中, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_goods (user_id,goods_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;uk_user_goods這個(gè)聯(lián)合唯一索引特別重要。它保證了同一個(gè)用戶對同一個(gè)商品只會(huì)存在一條購物車記錄用戶反復(fù)點(diǎn)擊“加入購物車”后端要做的是把quantity加1而不是插入一條新記錄。很多初學(xué)者做購物車沒有加這個(gè)唯一約束結(jié)果用戶點(diǎn)一次加購就多一條記錄購物車變成流水賬后面改起來非常費(fèi)勁。訂單相關(guān)表拆成主表order和明細(xì)表order_item。主表存訂單編號、用戶ID、訂單總價(jià)、訂單狀態(tài)、收貨地址、創(chuàng)建時(shí)間明細(xì)表存訂單里每個(gè)商品的信息商品ID、商品名稱冗余存儲(chǔ)、單價(jià)、數(shù)量。為什么要拆兩張表因?yàn)橐粋€(gè)訂單包含多個(gè)商品一張表存不下。如果只存一個(gè)合并的商品字符串比如“蘋果x2,香蕉x1”之后想做訂單統(tǒng)計(jì)、銷量分析就完全沒法查了。下單時(shí)的庫存扣減邏輯是這樣的校驗(yàn)庫存充足 - 扣減庫存 - 生成訂單 - 返回訂單號?？蹘齑婧蜕捎唵伪仨毞旁谕粋€(gè)事務(wù)里否則會(huì)出現(xiàn)庫存扣了但訂單沒生成、或者訂單生成了但庫存沒扣的情況。事務(wù)我用Transactional注解Spring管理一句話的事。3.4 表關(guān)系與查詢思路用戶、訂單、購物車、商品之間的關(guān)系一句話總結(jié)用戶1對多訂單訂單1對多訂單明細(xì)訂單明細(xì)多對1商品購物車是用戶和商品的多對多關(guān)系表。理解了這條關(guān)系鏈寫SQL基本不會(huì)迷路。后臺(tái)管理端查“某用戶的訂單詳情”這種SQL核心就是join兩三次表SELECT o.id, o.order_no, o.payment, o.status, oi.goods_name, oi.goods_price, oi.quantity FROM order o LEFT JOIN order_item oi ON o.id oi.order_id WHERE o.user_id #{userId} ORDER BY o.create_time DESC4. 功能模塊實(shí)現(xiàn)前端核心交互與后端業(yè)務(wù)閉環(huán)4.1 注冊登錄與權(quán)限控制登錄功能的實(shí)現(xiàn)分三步前端表單校驗(yàn) - 后端驗(yàn)證用戶名密碼 - 簽發(fā)Token返回 - 前端存儲(chǔ)Token并跳轉(zhuǎn)首頁。Token我用的是JWT一段由頭部、載荷、簽名組成的字符串。用戶在登錄成功后拿到Token之后每次請求都帶上后端通過攔截器校驗(yàn)Token的合法性再從Token中解析出用戶ID和角色。攔截器是實(shí)現(xiàn)權(quán)限控制的關(guān)鍵核心思路是放行登錄、注冊、商品列表這些公開接口攔截需要登錄才能訪問的接口如下單、查看購物車、后臺(tái)管理接口。public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); // 解析token失敗則返回401提示未登錄 // 解析成功則將用戶信息放入request上下文供后續(xù)Service使用 }前端配合這位使用Axios攔截器所有請求自動(dòng)從localStorage取Token并放進(jìn)請求頭service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config })前端路由還需要做權(quán)限守衛(wèi)未登錄用戶訪問“我的訂單”頁面時(shí)直接重定向到登錄頁router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path.startsWith(/order) !token) { next(/login) } else { next() } })4.2 商品列表與詳情展示商品列表用的是Element UI的el-card組件加自定義商品卡片每張卡片顯示商品圖、名稱、價(jià)格點(diǎn)擊跳轉(zhuǎn)到詳情頁。列表數(shù)據(jù)是后端接口返回的分頁參數(shù)pageNum和pageSize通過GET請求傳給后端。商品詳情頁除了基本信息展示還有一個(gè)“加入購物車”和一個(gè)“立即購買”按鈕。加入購物車就是調(diào)用后端接口傳入goodsId和quantity立即購買則先判斷是否登錄未登錄跳登錄頁已登錄把這件商品作為選中狀態(tài)跳轉(zhuǎn)到訂單確認(rèn)頁。針對商品圖片很多畢設(shè)項(xiàng)目用的是本地圖片地址比如/upload/xxx.jpg。我建議直接存一個(gè)圖片URL或者把圖片放到后端的resources/static/upload下通過Spring Boot的靜態(tài)資源映射來訪問。不要存base64到數(shù)據(jù)庫里那會(huì)讓表體量暴漲且查詢極慢。4.3 購物車業(yè)務(wù)邏輯購物車頁面的核心操作是勾選商品、修改數(shù)量、刪除商品、全選、計(jì)算總價(jià)?？們r(jià)的計(jì)算前端做還是后端做我建議展示用前端實(shí)時(shí)算下單時(shí)以后端重新計(jì)算為準(zhǔn)。后端計(jì)算訂單金額是一個(gè)很關(guān)鍵的信任邊界。用戶在前端看到的金額只是“預(yù)估”真正下單時(shí)后端要重新從數(shù)據(jù)庫讀取商品的價(jià)格乘以數(shù)量累加出總價(jià)。如果直接從頁面?zhèn)饕粋€(gè)總價(jià)給后端那用戶完全可以改接口參數(shù)把訂單金額改成0.01元下單這是嚴(yán)重的邏輯漏洞。所以“后端為準(zhǔn)”是必須堅(jiān)持的原則。購物車接口設(shè)計(jì)大概有五個(gè)添加購物車POST /api/cart/add購物車列表GET /api/cart/list更新購物車數(shù)量PUT /api/cart/update刪除購物車項(xiàng)DELETE /api/cart/delete/{id}選擇購物車項(xiàng)PUT /api/cart/check每個(gè)接口都必須校驗(yàn)user_id是不是當(dāng)前登錄用戶的ID防止越權(quán)操作。之前我見過有的項(xiàng)目傳一個(gè)購物車ID刪除后端不加校驗(yàn)直接把對應(yīng)記錄刪了結(jié)果用戶A能刪用戶B的購物車數(shù)據(jù)。這就是典型的水平越權(quán)漏洞答辯時(shí)被老師追問會(huì)非常難看。4.4 下單與模擬支付下單流程是業(yè)務(wù)閉環(huán)的核心環(huán)節(jié)。用戶從購物車勾選商品點(diǎn)擊“去結(jié)算”進(jìn)入訂單確認(rèn)頁填寫收貨人、手機(jī)號、地址點(diǎn)擊“提交訂單”。后端下單接口內(nèi)部做了這么幾件事從請求中取出購物車ID列表選中的那些購物車項(xiàng)查出購物車數(shù)據(jù)和對應(yīng)商品逐條校驗(yàn)庫存計(jì)算總價(jià)生成唯一訂單號扣減庫存并累加商品銷量創(chuàng)建訂單主記錄和訂單明細(xì)清空已下單的購物車記錄返回訂單號和訂單金額每一步都在同一個(gè)事務(wù)方法里完成任何一步失敗全部回滾。這里有一個(gè)理論支撐點(diǎn)叫“分布式事務(wù)的本地事務(wù)簡化”單體應(yīng)用用Transactional就足夠了不需要引入消息隊(duì)列。模擬支付的實(shí)現(xiàn)很簡單創(chuàng)建訂單后訂單狀態(tài)為“待支付”前端跳轉(zhuǎn)到支付頁點(diǎn)擊“立即支付”調(diào)用POST /api/order/pay/{orderNo}。后端把這個(gè)接口模擬成支付成功把訂單狀態(tài)改成“已支付”。因?yàn)楫呍O(shè)不需要對接真實(shí)支付寶、微信支付所以這一步用一個(gè)模擬接口講清楚整個(gè)狀態(tài)流轉(zhuǎn)即可。訂單狀態(tài)的枚舉我建議設(shè)計(jì)成0-待支付1-已支付待發(fā)貨2-已發(fā)貨3-已完成4-已取消。后臺(tái)管理員可以對訂單進(jìn)行發(fā)貨操作把狀態(tài)從1改為2。5. 接口聯(lián)調(diào)與狀態(tài)管理5.1 統(tǒng)一返回結(jié)果封裝接口聯(lián)調(diào)最怕前后端各寫各的、對齊困難。我一開始就定了一套統(tǒng)一的返回格式{ code: 200, message: success, data: { } }code代表業(yè)務(wù)狀態(tài)碼200成功、400參數(shù)錯(cuò)誤、401未登錄、403無權(quán)限、500服務(wù)器異常。前端Axios響應(yīng)攔截器拿到響應(yīng)后先看code非200的話彈錯(cuò)誤提示并中斷操作。這樣一套規(guī)范寫下來不管接口有多少前后端永遠(yuǎn)不會(huì)因?yàn)榉祷馗袷絾栴}吵架。5.2 Vuex狀態(tài)管理前端我用Vuex管理全局狀態(tài)主要存儲(chǔ)用戶信息和購物車數(shù)量。用戶登錄成功后dispatch一個(gè)login的action把用戶信息寫進(jìn)store同時(shí)同步到localStorage。刷新頁面時(shí)在main.js里重新從localStorage讀取用戶信息調(diào)store.commit(setUser)避免刷新后頁面變成未登錄狀態(tài)。購物車數(shù)量是頂欄右上角的小紅點(diǎn)數(shù)字登錄后拉取購物車列表取所有item的quantity求和這個(gè)數(shù)字變化及時(shí)更新到Vuex里。Vuex的好處是組件間共享狀態(tài)不用一層層傳props缺點(diǎn)是刷新后狀態(tài)丟失所以配合localStorage做持久化這兩個(gè)結(jié)合起來用是前端狀態(tài)管理的標(biāo)準(zhǔn)姿勢。5.3 Axios封裝與接口統(tǒng)一管理我把所有后端接口按照模塊統(tǒng)一封裝到src/api目錄下例如// api/goods.js import request from /utils/request export function getGoodsList(params) { return request({ url: /api/goods/list, method: get, params }) }這樣頁面里調(diào)用時(shí)一行代碼搞定const res await getGoodsList({ pageNum: 1 })。接口統(tǒng)一收口的好處是后端接口路徑變了只需要改一個(gè)文件不用全局搜索到處改。5.4 后臺(tái)管理端實(shí)現(xiàn)后臺(tái)管理端和前臺(tái)的代碼在同一個(gè)Vue項(xiàng)目里通過路由前綴區(qū)分/admin開頭的都是管理頁面。權(quán)限上用路由守衛(wèi)判斷當(dāng)前用戶role是否為1非管理員直接踢回首頁。商品管理頁用el-table展示商品列表支持新增、編輯、刪除、上下架操作。新增商品時(shí)彈出一個(gè)el-dialog表單包含商品名稱、分類、價(jià)格、庫存、主圖、詳情等信息提交后調(diào)用后端接口寫入數(shù)據(jù)庫。訂單管理頁展示所有訂單支持按訂單號和狀態(tài)篩選。管理員可以點(diǎn)擊“發(fā)貨”按鈕把訂單狀態(tài)從待發(fā)貨變成已發(fā)貨。用戶管理頁就相對簡單查看用戶列表、啟用禁用賬號。數(shù)據(jù)統(tǒng)計(jì)頁用ECharts畫三個(gè)圖近七天銷售額折線圖、商品分類銷售占比餅圖、商品銷量排行條形圖。數(shù)據(jù)來源是后端統(tǒng)計(jì)接口返回的聚合數(shù)據(jù)。這一段代碼不復(fù)雜但視覺效果好答辯演示的時(shí)候老師看到圖表基本都會(huì)覺得項(xiàng)目很完整。6. 常見坑與排查心得6.1 跨域請求被攔截這個(gè)是前后端分離項(xiàng)目出現(xiàn)頻率最高的報(bào)錯(cuò)。現(xiàn)象是前端控制臺(tái)報(bào)No Access-Control-Allow-Origin header is present請求發(fā)出去了但一直拋錯(cuò)。實(shí)際排查要區(qū)分開發(fā)環(huán)境和部署環(huán)境。開發(fā)環(huán)境我用的是Vue CLI的proxy代理后端不用處理跨域部署環(huán)境如果前端Nginx和后端域名不同需要在Nginx配置反向代理或者后端配置CORS。為什么開發(fā)時(shí)proxy能解決因?yàn)榇硎峭吹臑g覽器看到的是前端服務(wù)轉(zhuǎn)發(fā)出去的請求不存在跨域。這一點(diǎn)在答辯時(shí)要能講清楚屬于架構(gòu)層面的理解題。6.2 數(shù)據(jù)庫時(shí)間字段差8小時(shí)MySQL連接串如果沒設(shè)置serverTimezone會(huì)在時(shí)區(qū)上出問題。我一開始后端返回的創(chuàng)建時(shí)間比實(shí)際時(shí)間少了8個(gè)小時(shí)排查時(shí)發(fā)現(xiàn)是數(shù)據(jù)庫連接沒指定時(shí)區(qū)。在application.yml里加一行就解決spring: datasource: url: jdbc:mysql://localhost:3306/mall?useUnicodetruecharacterEncodingutf-8serverTimezoneAsia/Shanghai這種問題寫論文時(shí)幾乎不會(huì)被提到但實(shí)際開發(fā)時(shí)非常典型真遇到了很磨人。6.3 npm install頻繁報(bào)錯(cuò)前端依賴安裝是另一大坑。npm install報(bào)錯(cuò)時(shí)我的處理路徑是清緩存npm cache clean --force刪掉node_modules和package-lock.json重新裝如果node-sass導(dǎo)致報(bào)錯(cuò)把sass相關(guān)的包換成dart-sass直接安裝node-sassnpm:dart-sass或者改用sass實(shí)在不行換鏡像源很多時(shí)候不是代碼問題而是網(wǎng)絡(luò)源或者Node版本和依賴不兼容。這些坑第一次遇到會(huì)覺得莫名其妙記錄到筆記里下次三分鐘就能解決。6.4 常見問題速查表現(xiàn)象可能原因解決辦法前端請求一直pending后端沒啟動(dòng)或端口不對先訪問后端接口確認(rèn)返回?cái)?shù)據(jù)登錄后刷新頁面狀態(tài)丟失用戶信息只存了Vuex沒存localStorage持久化用戶信息刷新時(shí)重新讀取加入購物車重復(fù)插入記錄數(shù)據(jù)表缺少聯(lián)合唯一索引加uk_user_goods唯一索引用插入時(shí)ON DUPLICATE KEY UPDATE下單不扣庫存事務(wù)沒生效或庫存扣減邏輯錯(cuò)誤檢查方法上有沒有Transactional檢查庫存校驗(yàn)是否在事務(wù)內(nèi)管理員頁面普通用戶也能訪問前端路由守衛(wèi)沒檢查角色在beforeEach里增加role 1判斷圖片不顯示圖片路徑是絕對路徑后端沒映射在Spring Boot中配置靜態(tài)資源映射或改用相對路徑分頁數(shù)據(jù)不對前端傳的參數(shù)名和后端接收的參數(shù)名不一致統(tǒng)一用pageNum/pageSize記得大小寫一致7. 部署上線與后續(xù)擴(kuò)展7.1 打包部署前端的部署方式很簡單執(zhí)行npm run build后dist目錄下就是打包好的靜態(tài)文件。把它扔到Nginx的html目錄配置一個(gè)server塊就能通過80端口訪問。這里有個(gè)關(guān)鍵點(diǎn)直接雙擊index.html使用file協(xié)議打開會(huì)一片空白因?yàn)槁酚捎玫氖荋istory模式file協(xié)議不支持。要么改用hash模式要么配置Nginx的try_files。我在交付項(xiàng)目時(shí)會(huì)附帶一份啟動(dòng)文檔詳細(xì)到每一步怎么操作、訪問什么地址、初始賬號是什么拿到的同學(xué)照著文檔走一遍就能跑起來。這種項(xiàng)目如果說還有什么無形的價(jià)值就是這套標(biāo)準(zhǔn)化交付的習(xí)慣。7.2 功能的擴(kuò)展方向項(xiàng)目運(yùn)行起來之后如果還有余力可以往幾個(gè)方向擴(kuò)展接入Redis做驗(yàn)證碼存儲(chǔ)和Session共享加ElasticSearch做商品搜索用RabbitMQ做訂單超時(shí)取消。這些技術(shù)點(diǎn)每一個(gè)都能單獨(dú)寫進(jìn)論文的“系統(tǒng)優(yōu)化”章節(jié)也都能在答辯時(shí)展示你對系統(tǒng)的深入理解。但我的建議是先把現(xiàn)有閉環(huán)打磨好別急著加。有一個(gè)完整可運(yùn)行的項(xiàng)目比一個(gè)半成品但堆了十種技術(shù)的項(xiàng)目更有說服力。7.3 文檔與答辯材料的整理很多同學(xué)源代碼跑通了就感覺自己完事了但實(shí)際上交付一個(gè)畢設(shè)/課設(shè)項(xiàng)目文檔是占大頭價(jià)值的。我常見做法是整理四份材料需求分析文檔含用例圖、數(shù)據(jù)庫設(shè)計(jì)文檔含ER圖和表結(jié)構(gòu)說明、接口文檔用Swagger或者Word表格、操作手冊含截圖和啟動(dòng)步驟。再加上一個(gè)PPT流程就是“研究背景 - 技術(shù)棧選型 - 系統(tǒng)架構(gòu)圖 - 核心功能展示 - 數(shù)據(jù)庫設(shè)計(jì) - 總結(jié)”。答辯的時(shí)候照著這個(gè)順序講重點(diǎn)放在“前后端分離架構(gòu) 完整業(yè)務(wù)閉環(huán) 安全校驗(yàn)”這幾個(gè)點(diǎn)上比背代碼效果好得多。我個(gè)人在實(shí)際操作中的體會(huì)是這類項(xiàng)目最怕的就是“什么都想要但什么都不完整”。能跑通全流程、代碼結(jié)構(gòu)清晰、每一步能講出設(shè)計(jì)理由就是一套成功的交付。把這個(gè)項(xiàng)目完整做下來收獲的不只是幾千行代碼而是一套“從業(yè)務(wù)到架構(gòu)再到細(xì)節(jié)”的完整思考方式。后面不管是找工作面試還是繼續(xù)深造這套思路都能直接復(fù)用。