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