作為一個(gè)常年混跡各類項(xiàng)目、也幫不少人救過火的開發(fā)者我看到“網(wǎng)上點(diǎn)餐系統(tǒng)”這類題目還是挺有感觸的。它幾乎是畢業(yè)設(shè)計(jì)里最典型的“麻雀雖小五臟俱全”涉及用戶端、商家端、訂單流程、支付模擬還得把前后端分離、權(quán)限控制、數(shù)據(jù)庫設(shè)計(jì)這些點(diǎn)都串起來。如果你正打算做這個(gè)題目或者已經(jīng)被它折磨了一陣子這篇文章應(yīng)該能幫你把整個(gè)技術(shù)路線徹底理順。我會(huì)從選題拆解、技術(shù)選型、數(shù)據(jù)庫設(shè)計(jì)、后端實(shí)現(xiàn)、前端實(shí)現(xiàn)、聯(lián)調(diào)部署一直到答辯避坑按我實(shí)際做項(xiàng)目時(shí)的順序完整講一遍。先說結(jié)論這個(gè)題目非常適合作為前后端分離的練手項(xiàng)目因?yàn)樗炔粫?huì)像純后臺(tái)管理系統(tǒng)那樣單調(diào)又不會(huì)像電商平臺(tái)那樣復(fù)雜到失控。一個(gè)點(diǎn)餐系統(tǒng)的核心閉環(huán)是“瀏覽菜品—加入購物車—下單—接單—結(jié)算”圍繞這個(gè)閉環(huán)把一對(duì)多、多對(duì)多關(guān)系理清楚你的畢業(yè)設(shè)計(jì)就已經(jīng)贏了一大半。下面直接進(jìn)入干活模式。1. 選題定位與核心需求拆解1.1 這個(gè)題目到底在考什么很多同學(xué)誤以為畢業(yè)設(shè)計(jì)就是要做得“高大上”于是加一堆用不上的功能。實(shí)際上評(píng)審老師關(guān)注的永遠(yuǎn)是三件事數(shù)據(jù)模型合不合理、業(yè)務(wù)流程通不通、技術(shù)點(diǎn)有沒有真正掌握。網(wǎng)上點(diǎn)餐系統(tǒng)恰好能把這三件事一次性覆蓋?！熬W(wǎng)上點(diǎn)餐”的業(yè)務(wù)核心是訂單。訂單離不開菜品、用戶、門店這幾個(gè)基本實(shí)體。訂單本身又要拆成主表和明細(xì)表因?yàn)橐粋€(gè)訂單包含多個(gè)菜品每個(gè)菜品又有下單時(shí)的快照價(jià)格。你把這幾張表建清楚CURD怎么擴(kuò)展都只是體力活。反過來如果一上來就堆功能、堆頁面最后數(shù)據(jù)庫字段亂成一團(tuán)聯(lián)調(diào)時(shí)就會(huì)出現(xiàn)“購物車數(shù)量同步不了”“訂單狀態(tài)改不動(dòng)”這種抓瞎問題。我建議你把題目拆成兩個(gè)層面來理解一是面向消費(fèi)者的前臺(tái)微信風(fēng)格的長(zhǎng)列表、菜品分類、購物車角標(biāo)、下單流程二是面向管理員/商家的后臺(tái)菜品上下架、訂單處理、銷量統(tǒng)計(jì)。這兩個(gè)層面共用一套后端接口但權(quán)限不同這正好是前后端分離和權(quán)限控制的絕佳應(yīng)用場(chǎng)景。1.2 前后端分離到底是不是必須的放在幾年前用 Thymeleaf 寫服務(wù)端渲染也能交差但放在現(xiàn)在如果你為了省事放棄前后端分離答辯時(shí)基本會(huì)被問倒。原因不是“現(xiàn)在流行”而是業(yè)務(wù)場(chǎng)景確實(shí)需要分離用戶端和管理端是兩套完全不同的界面節(jié)奏用戶端要輕快、交互多管理端要表格密集、操作批量。前后端分離的開發(fā)模式會(huì)讓你把“接口設(shè)計(jì)”當(dāng)成一件正經(jīng)事來對(duì)待。比如下訂單接口是 POST /api/order更新菜品庫存是 PUT /api/dish/status我不需要在后端方法里返回一堆 HTML 片段只需要定義清晰的 JSON 結(jié)構(gòu)。前端拿到數(shù)據(jù)后自己渲染調(diào)樣式、改組件都不影響后端邏輯。從部署角度講分離還意味著后端可以被多個(gè)前端復(fù)用。將來你想加一個(gè)小程序端只要復(fù)用同一套接口前端重新開發(fā)就行。這本身也是畢業(yè)設(shè)計(jì)里一個(gè)值得寫進(jìn)“項(xiàng)目展望”的亮點(diǎn)。1.3 目標(biāo)用戶與功能清單做任何項(xiàng)目之前先定義清楚誰在用。我推薦把用戶分成三類普通用戶、商家管理員、超級(jí)管理員可選。普通用戶能注冊(cè)登錄、瀏覽菜品、加購物車、下單、查看訂單狀態(tài)商家管理員能維護(hù)菜品分類和菜品信息、處理訂單接單、完成超級(jí)管理員可以管理用戶和基礎(chǔ)數(shù)據(jù)。你不需要做支付網(wǎng)關(guān)對(duì)接那樣會(huì)把復(fù)雜度和安全要求提得太高。做個(gè)模擬支付即可下單后訂單狀態(tài)變?yōu)椤按Ц丁鼻岸藦棾鲆粋€(gè)模擬收銀臺(tái)點(diǎn)擊“確認(rèn)支付”就把狀態(tài)置為“已支付待商家接單”。這里只需要一個(gè)事務(wù)操作既講得清楚又符合安全邊界。核心功能清單如下用戶注冊(cè)登錄用戶名密碼、JWT 令牌。菜品分類與菜品展示分類樹、分頁、關(guān)鍵字搜索。購物車單選加購、數(shù)量增減、角標(biāo)聯(lián)動(dòng)。訂單流程購物車生成訂單、訂單狀態(tài)流轉(zhuǎn)、訂單明細(xì)。商家后臺(tái)菜品管理、分類管理、訂單處理。數(shù)據(jù)統(tǒng)計(jì)訂單數(shù)量趨勢(shì)、銷量排行。這些功能全部做完不會(huì)超過兩周卻能覆蓋一個(gè)完整信息系統(tǒng)的所有核心面。后續(xù)如果你想加積分、優(yōu)惠券、配送地址都是在訂單主表上延伸字段和關(guān)聯(lián)表不會(huì)傷筋動(dòng)骨。2. 技術(shù)選型與開發(fā)環(huán)境搭建2.1 后端技術(shù)棧版本怎么選后端我建議用 Spring Boot 2.7.x 而不是 3.x。原因很現(xiàn)實(shí)2.7 的生態(tài)最成熟網(wǎng)上資料最多遇到的依賴兼容問題最少。嗯畢業(yè)設(shè)計(jì)的重點(diǎn)是跑通邏輯不是當(dāng)新版本小白鼠。Spring Boot 3 必須用 Java 17而很多學(xué)校機(jī)器上的 JDK 還是 8一旦版本對(duì)不上環(huán)境問題就能耗掉你一周。持久層我推薦 MyBatis-Plus。它比原生 MyBatis 少寫大量 XML單表 CRUD 直接用 BaseMapper 就能搞定多表查詢用 LambdaQueryWrapper 也夠。另一個(gè)選擇是 Spring Data JPA但對(duì)于新手JPA 的懶加載和級(jí)聯(lián)操作很容易把人繞暈不如 MyBatis-Plus 來得直觀。數(shù)據(jù)庫用 MySQL 8.0默認(rèn)字符集設(shè)置為 utf8mb4這樣才能存 emoji 以及生僻字。如果你不想在本地安裝 MySQL用 Docker 拉一個(gè) mysql:8.0 鏡像也很方便但要注意掛載數(shù)據(jù)目錄別把數(shù)據(jù)存在容器里否則容器一刪全沒了。2.2 前端技術(shù)棧的取舍前端基礎(chǔ)框架我用 Vue 3 Vite。很多教程還在講 Vue 2 Vue CLI但新項(xiàng)目沒必要給自己埋坑。Vue 3 的組合式 API 寫業(yè)務(wù)代碼更順手Vite 的開發(fā)服務(wù)器冷啟動(dòng)快得多整體體驗(yàn)比 Webpack 時(shí)代舒服好幾個(gè)檔次。你還需要這三樣?xùn)|西路由用 Vue Router 4狀態(tài)管理用 PiniaUI 組件庫用 Element Plus。如果目標(biāo)是做一個(gè)更像真實(shí)點(diǎn)餐 App 的界面可以再用 UnoCSS 或 Tailwind 自定義樣式但核心業(yè)務(wù)部分用 Element Plus 快速搭框架是最可靠的。移動(dòng)端適配問題我后面會(huì)單獨(dú)講這里先記住Element Plus 的柵格布局能省你很多事。構(gòu)建工具上Vite 默認(rèn)配置已經(jīng)足夠。開發(fā)環(huán)境下用 proxy 把 /api 請(qǐng)求轉(zhuǎn)發(fā)到 localhost:8080避免前后端端口不一致帶來的跨域問題。生產(chǎn)環(huán)境則用 Nginx 反向代理把 /api 路徑轉(zhuǎn)發(fā)到后端服務(wù)同時(shí)把前端靜態(tài)文件托管在 /usr/share/nginx/html這一套方案在畢業(yè)設(shè)計(jì)答辯現(xiàn)場(chǎng)非常常見也最容易講清楚。2.3 開發(fā)環(huán)境逐步配置清單我提供一個(gè)可以直接照抄的初始化步驟省去你到處翻坑的時(shí)間。安裝 JDK 8 或 11配置 JAVA_HOME 環(huán)境變量。安裝 Maven 3.8修改 settings.xml 里的鏡像源。你懂的國外源經(jīng)常抽風(fēng)用阿里云的鏡像倉能讓你不至于卡在下載依賴這一步。安裝 MySQL 8.0創(chuàng)建數(shù)據(jù)庫點(diǎn)餐系統(tǒng)庫比如 takeout_db字符集選 utf8mb4。安裝 Node.js 16 或 18npm 源可以設(shè)置為國內(nèi)鏡像否則 npm install 可能慢到懷疑人生。使用 Spring Initializr 生成后端骨架依賴選 Spring Web、MySQL Driver、Lombok后面手動(dòng)加入 MyBatis-Plus 和 JJWT。使用 Vite 創(chuàng)建前端骨架npm create vitelatest takeout-web模板選 vue。安裝前端依賴vue-router、pinia、axios、element-plus。這里有幾個(gè)特別容易踩的細(xì)節(jié)。第一Maven 鏡像和 npm 鏡像別弄混云效、阿里云認(rèn)準(zhǔn)一個(gè)就行。第二MySQL 8 的驅(qū)動(dòng)名是 com.mysql.cj.jdbc.Driver不是舊版的 com.mysql.jdbc.DriverURL 里別忘了加 serverTimezoneAsia/Shanghai不然時(shí)間全偏。第三Lombok 和你 IDE 的版本要匹配新版 IDEA 一般沒事但老版本社區(qū)版如果沒裝 Lombok 插件編譯能過但運(yùn)行報(bào)找不到方法很玄學(xué)。3. 數(shù)據(jù)庫設(shè)計(jì)與權(quán)限模型詳解3.1 核心表結(jié)構(gòu)設(shè)計(jì)網(wǎng)上點(diǎn)餐系統(tǒng)的核心表我建議六張用戶表、菜品分類表、菜品表、購物車表、訂單表、訂單明細(xì)表。再加一張可選的輪播圖表或地址表但核心永遠(yuǎn)是那六張?jiān)O(shè)計(jì)原則是避免字段冗余。用戶表字段id, username, password, nickname, phone, avatar, role, status, create_time。密碼存放的是 BCrypt 哈希值不是明文。role 用字符串存 USER 和 ADMIN 就好不需要建用戶角色關(guān)聯(lián)表因?yàn)橄到y(tǒng)只有兩種角色加一張表反而顯得過度設(shè)計(jì)。status 是狀態(tài)開關(guān)可以用來做賬號(hào)禁用。菜品分類表字段id, name, sort。sort 用于排序比如飲品放前面還是后面。菜品表字段id, category_id, name, description, image_url, price, stock, status, create_time。注意 price 我用 decimal(10,2)不要用 double涉及金額的類型必須精確。購物車表字段id, user_id, dish_id, quantity, selected。selected 字段表示是否勾選前端購物車?yán)锏膹?fù)選框就是對(duì)應(yīng)這個(gè)字段。如果只支持整單提交這個(gè)字段可以去掉但如果你想讓用戶勾選部分菜品結(jié)算就必須有這個(gè)字段。訂單表字段id, order_no, user_id, total_amount, status, remark, create_time, pay_time。重點(diǎn)是這個(gè) status需要定義一組狀態(tài)碼0 待支付、1 待接單已支付、2 已接單/制作中、3 已完成、4 已取消。訂單明細(xì)表字段id, order_id, dish_id, dish_name, dish_image, price, quantity其中 dish_name 和 price 是從下單時(shí)刻的商品數(shù)據(jù)快照而來防止商家后來改價(jià)導(dǎo)致歷史訂單金額變掉。3.2 為什么我不用數(shù)據(jù)庫外鍵這是很多數(shù)據(jù)庫課程里的“標(biāo)準(zhǔn)答案”和真實(shí)開發(fā)之間的差異點(diǎn)。課程里講外鍵約束但真實(shí)項(xiàng)目里我?guī)缀醪挥梦锢硗怄I。外鍵會(huì)帶來什么問題第一刪除菜品時(shí)如果被訂單明細(xì)引用會(huì)被約束擋住你得先處理關(guān)聯(lián)數(shù)據(jù)很麻煩第二高并發(fā)插入訂單時(shí)外鍵校驗(yàn)會(huì)帶來不必要的鎖競(jìng)爭(zhēng)第三一旦需要做分庫分表物理外鍵完全不可用。我推薦用邏輯外鍵在訂單明細(xì)表里保存 dish_id通過應(yīng)用層保證數(shù)據(jù)的引用完整性。比如刪除菜品前先查一下訂單明細(xì)表有沒有引用如果有就做假刪除把菜品的 status 置為下架而不是 DELETE。這樣既保留了數(shù)據(jù)可追溯性又不會(huì)因?yàn)榧s束把業(yè)務(wù)卡死。答辯時(shí)可以主動(dòng)向老師解釋“為什么不用外鍵”這往往是一個(gè)加分項(xiàng)因?yàn)檎f明你思考過真實(shí)場(chǎng)景。3.3 登錄態(tài)與權(quán)限控制設(shè)計(jì)登錄態(tài)我用 JWT而不是 Session。原因很簡(jiǎn)單前后端分離之后后端不能依賴 Cookie 里的 Session ID 來識(shí)別用戶因?yàn)榭缬蚯闆r下 Cookie 要么被瀏覽器攔截要么需要復(fù)雜的跨域配置。JWT 本身是無狀態(tài)的后端簽發(fā) Token 給前端前端后續(xù)請(qǐng)求時(shí)在 HTTP 頭里帶上 Authorization: Bearer 。JWT 里我存三個(gè)信息userId、username、role。不存密碼不存敏感信息因?yàn)?JWT 只是 Base64Url 編碼并不是加密任何人都能解碼看到 payload。簽名由后端密鑰掌控防的是篡改不是防窺視。后端拿到 Token 后解析出 role用攔截器做兩級(jí)校驗(yàn)。第一級(jí)校驗(yàn) Token 是否有效第二級(jí)校驗(yàn)接口需要的角色。對(duì)于管理端接口我會(huì)在 Controller 方法上寫一個(gè)自定義注解 RequireAdmin攔截器發(fā)現(xiàn)當(dāng)前角色的不是 ADMIN 就返回 403。這樣權(quán)限邏輯集中在一處而不是散落在每個(gè)業(yè)務(wù)方法里代碼可維護(hù)性高很多。4. 后端核心模塊實(shí)現(xiàn)Spring Boot 實(shí)操4.1 統(tǒng)一響應(yīng)體與全局異常處理后端接口如果每個(gè)方法各返各的格式前端解析起來就是災(zāi)難。我定義一個(gè)統(tǒng)一的 Result Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.setCode(200); r.setMessage(success); r.setData(data); return r; } public static T ResultT error(String message) { ResultT r new Result(); r.setCode(500); r.setMessage(message); return r; } }這個(gè)類看起來簡(jiǎn)單但它決定了整個(gè)前后端協(xié)作的基礎(chǔ)。前端 axios 攔截器看到 code 為 200 就直接用 data否則彈 message。別小看這個(gè)機(jī)制它能讓你在聯(lián)調(diào)時(shí)迅速區(qū)分“后端報(bào)錯(cuò)”和“前端邏輯問題”。全局異常處理用 RestControllerAdvice。我把業(yè)務(wù)異常和系統(tǒng)異常分開處理業(yè)務(wù)異常返回 code 比如 400系統(tǒng)異常記錄到日志文件里返回給前端的 message 則是“系統(tǒng)繁忙請(qǐng)稍后重試”。日志打印用 Lombok 的 Slf4j關(guān)鍵請(qǐng)求參數(shù)也要打日志否則出問題你連復(fù)現(xiàn)都無從下手。4.2 JWT 登錄與攔截器寫法登錄接口的流程根據(jù)用戶名查用戶比對(duì) BCrypt 密碼比對(duì)成功生成 JWT返回給前端。生成方式和校驗(yàn)方式我都單獨(dú)封裝成 JwtUtil 工具類不要在 Controller 里寫 JWT 構(gòu)建邏輯。Component public class JwtUtil { Value(${jwt.secret}) private String secret; Value(${jwt.expire}) private Long expire; public String generateToken(Long userId, String username, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(username, username) .claim(role, role) .setExpiration(new Date(System.currentTimeMillis() expire)) .signWith(SignatureAlgorithm.HS256, secret.getBytes(StandardCharsets.UTF_8)) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secret.getBytes(StandardCharsets.UTF_8)) .parseClaimsJws(token) .getBody(); } }這里有一個(gè)重要坑點(diǎn)。JWT 的 signWith 方法在高版本 jjwt 庫里的簽名要求傳入 Key 對(duì)象而不是字符串。如果你用 0.9.x 版本那按字符串傳沒問題如果你用 0.11.x必須用 Keys.hmacShaKeyFor(secret.getBytes())。這個(gè)版本差異導(dǎo)致了大量“能生成不能解析”的古怪報(bào)錯(cuò)我在本地就踩過一次查了好久才發(fā)現(xiàn)是 API 變更。攔截器繼承 HandlerInterceptorAdapter 重寫 preHandlepublic class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); try { Claims claims jwtUtil.parseToken(token); request.setAttribute(userId, Long.valueOf(claims.getSubject())); request.setAttribute(userRole, claims.get(role)); return true; } catch (Exception e) { // 解析失敗說明 token 過期或偽造 } } response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write(JSON.toJSONString(Result.error(未登錄或登錄過期))); return false; } }注冊(cè)攔截器時(shí)要注意靜態(tài)資源放行。后端一般沒有靜態(tài)資源但如果接入了文件上傳圖片預(yù)覽要把 /upload/** 這類路徑放行否則圖片都加載不出來。4.3 點(diǎn)餐下單的核心事務(wù)邏輯下單是系統(tǒng)里最核心的方法也是評(píng)委會(huì)專門盯著問的地方。絕不能寫一個(gè) INSERT 訂單、再循環(huán)插入明細(xì)就完事必須考慮完整的事務(wù)一致性。我推薦把下單和模擬支付拆成兩個(gè)方法下單時(shí)生成成功即凍結(jié)庫存支付時(shí)才扣減。下單的核心邏輯校驗(yàn)購物車選中項(xiàng)取出菜品 ID 和數(shù)量。用 FOR UPDATE 鎖住商品行或者樂觀鎖控制庫存。畢業(yè)設(shè)計(jì)用樂觀鎖就可以UPDATE dish SET stock stock - #{quantity} WHERE id #{dishId} AND stock #{quantity}返回受影響行數(shù)來判斷是否超賣。生成訂單主表狀態(tài)為 0 待支付。批量插入訂單明細(xì)。清空對(duì)應(yīng)購物車項(xiàng)。整個(gè)方法上用 Transactional(rollbackFor Exception.class)確保任何一個(gè)環(huán)節(jié)拋異常前面插入的訂單和扣減的庫存全部回滾。注意 rollbackFor 必須寫成 rollbackFor Exception.class只寫 Transactional 時(shí)默認(rèn)只回滾 RuntimeException普通異常拋出來不會(huì)回滾這是新手最容易犯的錯(cuò)誤。模擬支付接口更簡(jiǎn)單把訂單狀態(tài)從 0 改成 1同時(shí)記錄支付時(shí)間。這里同樣要校驗(yàn)訂單歸屬防止用戶把別人的訂單支付了。接口里必須帶上 userId下單接口保存訂單表時(shí)要記錄 user_id支付時(shí)先查訂單的 user_id 是否等于當(dāng)前登錄用戶。4.4 統(tǒng)計(jì)報(bào)表的 SQL 優(yōu)化思路后臺(tái)管理端要展示銷量排行和訂單數(shù)趨勢(shì)。很多同學(xué)直接用 groupBy 把全表查出來數(shù)據(jù)量少時(shí)還好量一大數(shù)據(jù)庫立刻卡頓。其實(shí)這類報(bào)表查詢的核心不是寫復(fù)雜 SQL而是要讓索引命中。訂單表按 create_time 建索引統(tǒng)計(jì)某天訂單數(shù)時(shí)SQL 寫成SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS day, COUNT(*) AS cnt FROM orders WHERE create_time 2024-01-01 AND create_time 2024-02-01 GROUP BY DATE_FORMAT(create_time, %Y-%m-%d);如果不加時(shí)間范圍限制MySQL 會(huì)掃描全表。你可以在開發(fā)時(shí)用 EXPLAIN 看一眼理論上應(yīng)該走 range 而不是 ALL這一點(diǎn)要能主動(dòng)在答辯時(shí)說清楚。銷量排行則會(huì) join 菜品表按菜品分組求和數(shù)據(jù)量大時(shí)同樣要先限定時(shí)間范圍。統(tǒng)計(jì)查詢一般不加載到內(nèi)存超過幾百行因?yàn)榫S度只有天和菜品不會(huì)膨脹。如果你想做得更漂亮可以引入定時(shí)任務(wù)每天凌晨統(tǒng)計(jì)一次把結(jié)果寫入統(tǒng)計(jì)表查詢時(shí)直接查結(jié)果表。這種方式叫做“空間換時(shí)間”在功能演示時(shí)性能提升非常明顯也是答辯里很好講的優(yōu)化點(diǎn)。5. 前端核心模塊實(shí)現(xiàn)Vue 實(shí)操5.1 Axios 封裝與請(qǐng)求攔截前端如果每個(gè)頁面里直接寫 axios.get將來改接口前綴或者加 Token 就非常痛苦。我習(xí)慣在 src/utils/request.js 里封裝一個(gè) axios 實(shí)例import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) 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) router.push(/login) } ElMessage.error(網(wǎng)絡(luò)請(qǐng)求失敗) return Promise.reject(error) } ) export default request注意我返回的是 res.data 而不是 res這樣調(diào)用方不需要每次解一層包裝業(yè)務(wù)代碼清爽很多。401 時(shí)自動(dòng)跳登錄頁也算把之前后端攔截器設(shè)計(jì)了一次閉環(huán)。5.2 購物車與訂單確認(rèn)的交互設(shè)計(jì)前端“加購”這個(gè)動(dòng)作看上去簡(jiǎn)單但實(shí)際上要處理好三個(gè)地方購物車圖標(biāo)角標(biāo)、商品卡片按鈕狀態(tài)、購物車頁面的數(shù)量修改。我推薦用 Pinia 管理購物車列表和總數(shù)量組件之間不做 event bus 傳遞避免數(shù)據(jù)不同步。購物車 state 里維護(hù)一個(gè) items 數(shù)組每個(gè)元素包含 dishId、name、price、quantity、selected。加購操作去重有兩種選擇后端把購物車表當(dāng)持久化數(shù)據(jù)或者前端純本地存儲(chǔ)。我建議采用后端持久化因?yàn)檫@樣才能做到“換個(gè)設(shè)備購物車還在”這也讓購物車表的設(shè)計(jì)有了真實(shí)意義。前端加購時(shí)調(diào)用后端接口返回最新數(shù)量后更新 Pinia。購物車頁面的加減按鈕不能每點(diǎn)一下都等后端響應(yīng)再做本地更新那樣體驗(yàn)會(huì)很卡。正確做法是樂觀更新點(diǎn)擊加號(hào)立刻更新本地?cái)?shù)量和總價(jià)同時(shí)向后臺(tái)發(fā)請(qǐng)求。如果請(qǐng)求失敗再回滾本地狀態(tài)并提示錯(cuò)誤。這種交互細(xì)節(jié)寫進(jìn)“項(xiàng)目心得體會(huì)”里老師會(huì)覺得你真懂前端。下單確認(rèn)頁要展示商品列表、總金額和用戶備注。備注字段要限制長(zhǎng)度防止惡意用戶塞超長(zhǎng)字符串。提交訂單時(shí)把 quantity 和 dishId 做成數(shù)組傳給后端后端用訂單明細(xì)表接收。前端收到訂單號(hào)后跳轉(zhuǎn)到“訂單列表/訂單詳情頁”而不是停留在購物車頁這樣用戶的認(rèn)知路徑是完整的。5.3 路由守衛(wèi)與不同角色的首頁區(qū)分前端路由需要區(qū)分用戶端和管理端。用戶端的頁面包括首頁、菜品列表、購物車、我的訂單管理端的頁面包括后臺(tái)布局、菜品管理、分類管理、訂單管理、數(shù)據(jù)統(tǒng)計(jì)。兩者不能互相串訪。我配置路由時(shí)給管理端加一個(gè) meta.requiresAdmin。全局前置守衛(wèi)里同時(shí)判斷登錄態(tài)和角色router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) return } const role localStorage.getItem(role) if (to.meta.requiresAdmin role ! ADMIN) { next(/) return } next() })這里有一個(gè)小細(xì)節(jié)用戶登錄后把基本信息存到 localStorage但不要存密碼等敏感信息。只存 userId、username、role、token。頁面刷新時(shí) Pinia 里的用戶信息會(huì)清空這時(shí)候需要從 localStorage 恢復(fù)。我封裝了一個(gè) init 方法在 App.vue 的 created 里調(diào)用保證刷新頁面不丟登錄狀態(tài)。管理端的側(cè)邊菜單我也根據(jù)角色動(dòng)態(tài)生成不是寫死。游客看不到管理入口管理員進(jìn)系統(tǒng)后默認(rèn)落在數(shù)據(jù)統(tǒng)計(jì)頁。這個(gè)“動(dòng)態(tài)菜單”功能用 Vue Router 的 addRoute 實(shí)現(xiàn)比較高級(jí)但如果你時(shí)間緊張暫時(shí)固定菜單再配合路由守衛(wèi)攔截也能交差功能上并無硬傷。6. 聯(lián)調(diào)部署與源碼組織建議6.1 前后端聯(lián)調(diào)最容易崩的三個(gè)點(diǎn)前后端各自跑得通合在一起就掛這事太常見了。我聯(lián)調(diào)時(shí)遇到過三個(gè)高頻問題先列出來你遇到的時(shí)候能少走彎路。第一個(gè)是跨域配置。如果你用 Vite 的 proxy前端頁面代碼里的請(qǐng)求路徑必須以 /api 開頭后端 Context Path 不要重復(fù)配置成 /api。也就是說前端請(qǐng)求 /api/auth/login后端 Controller 的 RequestMapping 是 /auth/login。如果后端又配了 context-path/api那么實(shí)際接口路徑會(huì)變成 /api/auth/login而前端又加了一層 /api最后變成 /api/api/auth/login404 沒跑。第二個(gè)是時(shí)間格式串臺(tái)。后端返回 LocalDateTime 時(shí)默認(rèn)序列化格式是數(shù)組或帶 T 的 ISO 字符串前端顯示出來很奇怪。統(tǒng)一在 application.yml 里配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8第三個(gè)是字段命名不一致。后端數(shù)據(jù)庫字段用下劃線 user_id實(shí)體類用駝峰 userId如果 MyBatis-Plus 沒開啟 map-underscore-to-camel-case 全局配置查詢結(jié)果里 user_id 就映射不到 userId返回的 JSON 缺失字段前端數(shù)據(jù)全是 undefined。這個(gè)配置通常默認(rèn)開啟但最好主動(dòng)確認(rèn)一次。6.2 生產(chǎn)環(huán)境構(gòu)建與 Nginx 配置演示的時(shí)候你大概率不會(huì)用生產(chǎn)模式Vite dev server 跑起來就夠了。但畢業(yè)設(shè)計(jì)說明書里大概率要寫“部署方案”而且答辯現(xiàn)場(chǎng)如果網(wǎng)絡(luò)抽風(fēng)本地開發(fā)服務(wù)器掛了會(huì)很尷尬。所以我還是建議把生產(chǎn)構(gòu)建流程跑通一遍。前端執(zhí)行 npm run build生成 dist 目錄。后端正用 Maven 打包mvn clean package -DskipTests生成 jar 包。本地測(cè)試可以直接 java -jar target/takeout-backend.jar前提是 MySQL 已啟動(dòng)。Nginx 配置模板我給出最小可用的版本server { listen 80; server_name localhost; root /opt/takeout-web/dist; index index.html; 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; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }這里最容易出錯(cuò)的是 proxy_pass 的結(jié)尾斜杠。location /api/ 配上 proxy_pass http://127.0.0.1:8080; 沒有斜杠等價(jià)于把 /api 前綴保留放在一起轉(zhuǎn)發(fā)如果有斜杠路徑會(huì)被替換為 /api 之后的部分。兩種寫法對(duì)應(yīng)不同后端接口設(shè)計(jì)我建議統(tǒng)一用沒有斜杠的形式然后后端接口路徑不要帶 /api 前綴讓 Nginx 統(tǒng)一處理前綴結(jié)構(gòu)最清晰。6.3 源碼目錄結(jié)構(gòu)與說明書章節(jié)對(duì)應(yīng)源碼結(jié)構(gòu)清晰與否直接影響評(píng)閱老師對(duì)你的第一印象。后端我用標(biāo)準(zhǔn)的包結(jié)構(gòu)controller、service、mapper、entity、dto、config、common。前端按功能模塊分目錄views/user、views/admin、api、utils、stores、router、components。所有配置項(xiàng)都要放進(jìn)配置文件變量禁止在代碼里寫死。數(shù)據(jù)庫密碼尤其不能寫在業(yè)務(wù)代碼里要寫在 application.yml 里然后通過 Value 注入到數(shù)據(jù)源配置。就算項(xiàng)目是本地 demo也要養(yǎng)成這種習(xí)慣答辯時(shí)提起“配置與代碼分離”是一個(gè)能加印象分的點(diǎn)。畢業(yè)設(shè)計(jì)說明書的大綱可以直接對(duì)照源碼結(jié)構(gòu)來寫第一章緒論對(duì)應(yīng)項(xiàng)目背景和意義第二章技術(shù)選型對(duì)應(yīng)項(xiàng)目開發(fā)環(huán)境第三章系統(tǒng)設(shè)計(jì)對(duì)應(yīng)數(shù)據(jù)庫表和接口設(shè)計(jì)第四章系統(tǒng)實(shí)現(xiàn)對(duì)應(yīng)前后端核心代碼講解第五章測(cè)試對(duì)應(yīng)功能測(cè)試和聯(lián)調(diào)結(jié)果。你的源碼里每個(gè) service 類的方法名盡量對(duì)應(yīng)說明書里的小節(jié)標(biāo)題這樣寫論文時(shí)不用來回映射。7. 常見問題排查與答辯避坑實(shí)錄7.1 高頻故障速查表現(xiàn)象可能原因解決辦法前端控制臺(tái) 404代理路徑或后端 Context Path 重復(fù)檢查 /api 前綴是否只加了一次登錄接口報(bào) 500數(shù)據(jù)庫密碼或 URL 配錯(cuò)了檢查 application.yml 的 url/username/password查詢數(shù)據(jù)中文亂碼MySQL 字符集不是 utf8mb4建庫時(shí)指定 utf8mb4連接串加 characterEncodingutf8提交訂單后庫存沒變事務(wù)沒生效或方法間調(diào)用被代理攔截確認(rèn) Controller 調(diào)用的是 Service 代理而非同類內(nèi)部方法Token 生成成功但解析失敗jjwt 版本 API 變更統(tǒng)一用 Keys.hmacShaKeyFor 構(gòu)建 Key前端訪問后端接口跨域未配置代理或跨域過濾器Vite proxy 優(yōu)先CORS 配置只是后端兜底圖片上傳無法訪問靜態(tài)資源路徑未放行映射本地 upload 目錄并放行對(duì)應(yīng)路徑打包后前端刷新 404History 路由未配置回退Nginx 里配置 try_files 到 index.html以上每一條我都實(shí)際踩過不是從文檔里順手抄的。尤其是中間兩條事務(wù)不生效和 Token 解析失敗卡了我最長(zhǎng)的時(shí)間。你如果開發(fā)到一半突然遇到這些魔幻問題先按表里檢查別急著懷疑人生。7.2 答辯時(shí)老師常抓的三個(gè)軟肋很多同學(xué)的代碼能跑但被老師一問就漏氣。我見過的高頻追問有三個(gè)。第一個(gè)是“購物車為什么不直接存 Redis”。老師想考察的是你對(duì)緩存的理解。你可以回答Redis 適合臨時(shí)性高并發(fā)場(chǎng)景但這個(gè)項(xiàng)目為了降低架構(gòu)復(fù)雜度、保證數(shù)據(jù)不丟失把購物車持久化到 MySQL后續(xù)如果要做大規(guī)模并發(fā)再引入 Redis 做緩存層。這樣回答既表達(dá)了你了解 Redis又說明你的方案是有針對(duì)性的不是不會(huì)。第二個(gè)是“訂單并發(fā)超賣怎么辦”。這個(gè)問得最多。你可以把扣庫存的 SQL 寫法展示出來UPDATE dish SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}并解釋為什么這條語句天然保證不會(huì)扣成負(fù)數(shù)。如果他想聽鎖機(jī)制你再繼續(xù)說悲觀鎖和樂觀鎖的區(qū)別以及在這個(gè)量級(jí)里樂觀鎖足夠。第三個(gè)是“JWT 和 Session 有什么區(qū)別”。標(biāo)準(zhǔn)答法是Session 存儲(chǔ)在服務(wù)端需要共享存儲(chǔ)才能支撐多實(shí)例部署JWT 自包含服務(wù)端無狀態(tài)直接靠簽名驗(yàn)簽天然適合前后端分離和分布式環(huán)境。但要承認(rèn) JWT 的缺點(diǎn)是難以主動(dòng)注銷所以通常配合短期過期和前端登出清 Token。這種“既講優(yōu)點(diǎn)也講局限”的回答比單純吹捧 JWT 可信得多。7.3 我在實(shí)際動(dòng)手中的幾個(gè)獨(dú)家體會(huì)第一別等項(xiàng)目做完再寫文檔。我建議每做一個(gè)模塊就在說明文檔里同步貼一張截圖和一段核心代碼否則臨到答辯前三天熬夜補(bǔ)文檔質(zhì)量差到離譜。我的習(xí)慣是每天收工前花十五分鐘記錄“今天完成了什么、踩了什么坑”答辯時(shí)直接把這些一手資料加工成“項(xiàng)目難點(diǎn)”章節(jié)真實(shí)又具體。第二演示數(shù)據(jù)要提前準(zhǔn)備好而且要有邏輯。不要用“菜品1”“菜品2”這種傻瓜數(shù)據(jù)菜品名稱、價(jià)格、分類要按真實(shí)場(chǎng)景配好比如“招牌紅燒肉 28 元”“冰鎮(zhèn)酸梅湯 6 元”。訂單數(shù)據(jù)里要有不同狀態(tài)和不同日期的多條記錄這樣打開數(shù)據(jù)統(tǒng)計(jì)頁時(shí)趨勢(shì)圖才有起伏演示效果完全不一樣。第三做一點(diǎn)“超出預(yù)期”的小功能但不要多。比如菜品搜索的關(guān)鍵字高亮、訂單列表的分頁、圖片上傳后實(shí)時(shí)預(yù)覽。選擇一個(gè)跟你核心業(yè)務(wù)有結(jié)合的小亮點(diǎn)做精比堆砌五個(gè)半成品功能有用得多。我當(dāng)時(shí)做了一個(gè)“訂單狀態(tài)時(shí)間線”用戶在訂單詳情頁能看到從下單到完成的每一步時(shí)間戳老師當(dāng)場(chǎng)就問了這個(gè)數(shù)據(jù)是怎么組織和展示的成了整場(chǎng)答辯互動(dòng)最多的一個(gè)點(diǎn)。最后再分享一個(gè)小技巧。這個(gè)項(xiàng)目做完之后不要急著刪開發(fā)記錄。把數(shù)據(jù)庫初始化腳本、啟動(dòng)說明、常見問題說明寫進(jìn)項(xiàng)目的 README并且把 README 掛在倉庫首頁。不僅是自己以后回看方便而且如果指導(dǎo)老師或者評(píng)審想跑一下你的項(xiàng)目照著 README 就能十分鐘內(nèi)啟動(dòng)成功這會(huì)大大降低溝通成本也側(cè)面證明你的工程化意識(shí)。不要小看這一個(gè)小動(dòng)作很多同學(xué)的項(xiàng)目在老師手里根本跑不起來就是差一份像樣的啟動(dòng)說明。你可以按我的經(jīng)驗(yàn)在項(xiàng)目根目錄建一個(gè) docs 文件夾把 SQL 腳本、環(huán)境變量示例、接口文檔表格全放進(jìn)去答辯的時(shí)候直接把這份文檔展示出來效果不比你半小時(shí)的代碼演示差。