簡(jiǎn)介一套基于 SpringBoot 與 Vue 的外賣管理系統(tǒng)源碼及配套數(shù)據(jù)庫(kù)目標(biāo)是幫助 Java 課程設(shè)計(jì)、期末大作業(yè)和畢業(yè)設(shè)計(jì)階段的學(xué)生以較低門檻完成一個(gè)前后端分離且能穩(wěn)定運(yùn)行的管理系統(tǒng)。壓縮包共 192 個(gè)文件整體 26.55MB內(nèi)部包含 73 個(gè) Java 源工程文件、20 個(gè) HTML 頁(yè)面、21 個(gè) JavaScript 腳本、17 個(gè) CSS 樣式表、SQL 數(shù)據(jù)庫(kù)腳本及常用配置文件后端業(yè)務(wù)邏輯與前端交互頁(yè)面一一對(duì)應(yīng)從建表腳本到接口訪問(wèn)再到頁(yè)面渲染形成閉環(huán)目錄結(jié)構(gòu)清晰便于定位用戶、菜品、訂單等模塊進(jìn)行學(xué)習(xí)或修改。資源目前已有 346 人學(xué)習(xí)下載適合參考已有完成度較高的課設(shè)項(xiàng)目來(lái)縮短開(kāi)發(fā)周期也適合在此基礎(chǔ)上深挖代碼細(xì)節(jié)準(zhǔn)備答辯。核心價(jià)值在于代碼完整、可直接運(yùn)行項(xiàng)目中實(shí)現(xiàn)了菜品分類、購(gòu)物下單、訂單管理等外賣場(chǎng)景注釋較詳細(xì)純手打原創(chuàng)結(jié)構(gòu)清晰導(dǎo)入數(shù)據(jù)庫(kù)、啟動(dòng)后端與前端即可在瀏覽器訪問(wèn)支持二次改造例如增加支付網(wǎng)關(guān)、數(shù)據(jù)統(tǒng)計(jì)、權(quán)限控制等功能滿足課程設(shè)計(jì)的驗(yàn)收要求。1. 這門課設(shè)到底在評(píng)什么SpringBootVue外賣系統(tǒng)的及格線如果你是在趕 Java 課程設(shè)計(jì)手里剛好拿到一份「外賣管理系統(tǒng)」的 SpringBootVue 源碼和數(shù)據(jù)庫(kù)先別急著解壓跑起來(lái)。課程設(shè)計(jì)和真實(shí)項(xiàng)目最大的區(qū)別是老師不關(guān)心你的系統(tǒng)能扛多少并發(fā)關(guān)心的是「技術(shù)棧全不全、業(yè)務(wù)流程通不通、答辯講不講得清」。SpringBoot 負(fù)責(zé)后端接口和業(yè)務(wù)邏輯Vue 負(fù)責(zé)前端頁(yè)面和數(shù)據(jù)展示MySQL 存業(yè)務(wù)數(shù)據(jù)這條線本身就是 Java 課設(shè)的標(biāo)準(zhǔn)高分組合。這套系統(tǒng)的核心價(jià)值在于它不是一個(gè) CRUD 堆砌的 demo而是覆蓋了用戶端下單、商家端接單、管理端維護(hù)菜品和訂單狀態(tài)的完整閉環(huán)。適合 Java 基礎(chǔ)語(yǔ)法學(xué)完、正在做課設(shè)或準(zhǔn)備 SpringBootVue 全棧入門的人拿來(lái)改造成自己的項(xiàng)目。拿到手第一件事不是看代碼而是先看它能不能跑通「用戶注冊(cè)登錄 → 瀏覽菜品 → 下單 → 商家接單 → 訂單狀態(tài)流轉(zhuǎn)」這條主線。2. 先立框架SpringBootVue外賣系統(tǒng)的技術(shù)版圖與三層選型2.1 前后端分離的劃分為什么 Controller 不寫業(yè)務(wù)外賣系統(tǒng)的代碼結(jié)構(gòu)通常分成三層Controller 只接收請(qǐng)求和返回結(jié)果Service 寫真正的業(yè)務(wù)邏輯Mapper 負(fù)責(zé)和數(shù)據(jù)庫(kù)打交道。很多課設(shè)代碼最大的問(wèn)題是把 SQL 拼在 Controller 里老師一問(wèn)「訂單金額怎么算的」就答不上來(lái)因?yàn)檫壿嬋ぴ诮涌趯印Ｎ夷玫揭惶自创a后會(huì)先看包結(jié)構(gòu)Controller、Service、Mapper 分得清不清是第一個(gè)評(píng)分點(diǎn)。Controller 里應(yīng)該是干凈的接收參數(shù)、調(diào)用 Service、封裝 Result 返回。Service 里才是下單、結(jié)算、狀態(tài)流轉(zhuǎn)這些核心邏輯。判斷代碼寫得好不好有一個(gè)土辦法——看一個(gè)下單接口的代碼量如果 Controller 里超過(guò)二十行還要自己拼 SQL這代碼基本不能給老師看。在真正動(dòng)手改代碼之前先確認(rèn) Maven 依賴?yán)镉袥](méi)有 lombok如果沒(méi)有實(shí)體類的 getter/setter 會(huì)寫到你懷疑人生。SpringBoot 版本一般 2.x 就夠配上 MyBatis-Plus 可以少寫很多 XML 映射。數(shù)據(jù)庫(kù)連接池用 Druid 還是 HikariCP 都行HikariCP 是 SpringBoot 默認(rèn)的不需要額外配置就能跑課設(shè)答辯時(shí)被問(wèn)到「連接池用的什么」可以直接答 HikariCP。2.2 數(shù)據(jù)庫(kù)之外的隱藏選型JWT、攔截器、跨域外賣系統(tǒng)繞不開(kāi)登錄鑒權(quán)。課程設(shè)計(jì)里最常見(jiàn)的方案是 JWT后端登錄成功后簽發(fā)一個(gè) token前端每次請(qǐng)求帶上這個(gè) token后端通過(guò)攔截器驗(yàn)證。比 Session 好講也比 Session 好演示——你可以在答辯現(xiàn)場(chǎng)打開(kāi)瀏覽器控制臺(tái)把 token 刪掉再刷新頁(yè)面頁(yè)面報(bào) 401 時(shí)老師能直觀看到鑒權(quán)確實(shí)生效了。攔截器要放行登錄接口、注冊(cè)接口和菜品瀏覽接口其他接口都要驗(yàn)證 token。有個(gè)很容易翻車的點(diǎn)Vue 的 devServer 默認(rèn)端口是 8080SpringBoot 默認(rèn)也是 8080不改端口必沖突前端要多配一個(gè)代理把 /api 開(kāi)頭的請(qǐng)求轉(zhuǎn)發(fā)到后端真實(shí)端口。另一個(gè)坑是跨域前端 8081 訪問(wèn)后端 8080 會(huì)觸發(fā) CORS 攔截解決方式是后端加一個(gè) WebMvcConfigurer 配置允許跨域或者在前端 devServer 里配 proxy。Vue 端還要留意路由和狀態(tài)管理。外賣系統(tǒng)的前端通常有用戶端和管理端兩套頁(yè)面路由守衛(wèi)需要根據(jù)登錄狀態(tài)和角色跳轉(zhuǎn)登錄頁(yè)。axios 攔截器統(tǒng)一處理 token 注入和 401 響應(yīng)這樣前端的請(qǐng)求代碼會(huì)干凈很多。拿到的源碼里如果有 vuex 或 pinia 的配置先看用戶信息存在哪——存在 localStorage 里刷新不會(huì)丟存在內(nèi)存里一刷新就沒(méi)了這個(gè)細(xì)節(jié)答辯時(shí)經(jīng)常被問(wèn)到。3. 數(shù)據(jù)庫(kù)設(shè)計(jì)把外賣業(yè)務(wù)的「關(guān)系」畫清楚3.1 核心表結(jié)構(gòu)用戶、商家、菜品、訂單外賣系統(tǒng)最核心的數(shù)據(jù)庫(kù)表是用戶表、商家表、菜品表、訂單表和訂單明細(xì)表。用戶表要區(qū)分普通用戶和管理員一般用 role 字段1 是用戶、2 是商家、3 是管理員。商家表直接做成用戶表的一個(gè)角色還是單獨(dú)建表取決于源碼的設(shè)計(jì)思路——獨(dú)立建表的好處是商家可以有自己的營(yíng)業(yè)時(shí)間、店鋪公告這些字段封裝成一個(gè) user 表加一個(gè) shop 表在答辯時(shí)更好講。菜品表要綁定商家 ID這樣商家登錄后只能查到自己店鋪的菜品。菜品字段里必有的是名稱、圖片、價(jià)格、分類、是否上架。圖片建議存相對(duì)路徑而不是完整 URL否則換一臺(tái)電腦跑項(xiàng)目時(shí)圖片全掛。訂單表是整張數(shù)據(jù)庫(kù)設(shè)計(jì)的核心需要包含下單用戶 ID、商家 ID、訂單金額、訂單狀態(tài)、下單時(shí)間、收貨地址和聯(lián)系電話。訂單明細(xì)表單獨(dú)建——?jiǎng)e把菜品快照塞在訂單表里因?yàn)橛唵卫锏膬r(jià)格是下單那一刻的價(jià)格菜品表的價(jià)格后續(xù)可能改。訂單明細(xì)表記錄菜品 ID、菜品名稱、單價(jià)、數(shù)量這樣訂單歷史里的金額永遠(yuǎn)是對(duì)的。數(shù)據(jù)庫(kù)文件里一般會(huì)帶一份初始化 SQL看建表語(yǔ)句時(shí)重點(diǎn)看外鍵和索引外鍵在課設(shè)里可以有但實(shí)際開(kāi)發(fā)基本不用MyBatis-Plus 刪數(shù)據(jù)時(shí)外鍵約束反而礙事。3.2 訂單狀態(tài)機(jī)的字段設(shè)計(jì)狀態(tài)字段與時(shí)間戳外賣訂單的狀態(tài)流轉(zhuǎn)是一條完整鏈路待支付 → 已支付/待接單 → 商家已接單 → 配送中 → 已完成另外還有已取消。源碼里一般用一個(gè)整數(shù)字段 status 表示0 待支付、1 已支付、2 已接單、3 配送中、4 已完成、5 已取消。答辯時(shí)把這張表講清楚老師就知道你不是只會(huì)增刪改查。設(shè)計(jì)上有一個(gè)常見(jiàn)的坑狀態(tài)字段只記錄了「當(dāng)前狀態(tài)」沒(méi)有記錄「狀態(tài)變更時(shí)間」導(dǎo)致演示時(shí)無(wú)法回答「這單是什么時(shí)候被商家接單的」。所以訂單表里要么加多個(gè)時(shí)間字段比如 pay_time、accept_time、finish_time要么建一張訂單狀態(tài)日志表每一步操作都插入一條記錄包含訂單 ID、原狀態(tài)、新?tīng)顟B(tài)、操作時(shí)間。后者設(shè)計(jì)上更工整課程設(shè)計(jì)用前者居多因?yàn)楹?jiǎn)單直接。另一個(gè)要提前想好的問(wèn)題是并發(fā)下的庫(kù)存扣減。如果訂單表和菜品表是分開(kāi)的下單時(shí)先查菜品庫(kù)存再扣減如果兩個(gè)用戶同時(shí)下同一道菜會(huì)出現(xiàn)超賣。課設(shè)里一般不會(huì)壓測(cè)并發(fā)但代碼里至少要用事務(wù)——下單方法上加 Transactional把扣庫(kù)存和生成訂單放在同一個(gè)事務(wù)里任何一步失敗就回滾。這個(gè)點(diǎn)在答辯現(xiàn)場(chǎng)一亮出來(lái)比單純演示功能得分高得多。3.3 初始化數(shù)據(jù)讓演示頁(yè)一打開(kāi)就有東西可看數(shù)據(jù)庫(kù)腳本里除了建表語(yǔ)句一定還要有 INSERT 語(yǔ)句。沒(méi)有初始化數(shù)據(jù)的外賣系統(tǒng)用戶登錄進(jìn)去看到的是空蕩蕩的頁(yè)面沒(méi)法演示。我檢查源碼時(shí)第一件事就是數(shù)初始化數(shù)據(jù)量用戶有幾個(gè)、商家有幾家、菜品有幾道、有沒(méi)有已完成的訂單。太少了不行太少?zèng)]法展示分頁(yè)太多了也不行幾百條垃圾數(shù)據(jù)會(huì)讓查詢變慢答辯時(shí)如果等列表加載觀感很差。初始化數(shù)據(jù)的質(zhì)量比數(shù)量重要。菜品圖片路徑要真實(shí)可訪問(wèn)價(jià)格要合理分類要覆蓋「熱銷」「主食」「飲品」等。密碼字段如果是 MD5 加密初始化數(shù)據(jù)里的密碼必須是加密后的值否則你登錄不進(jìn)去。還有一點(diǎn)容易漏外賣系統(tǒng)的用戶角色有三種初始化數(shù)據(jù)里三種角色都要有并且密碼要統(tǒng)一告訴答辯老師比如都是 123456省得現(xiàn)場(chǎng)登錄時(shí)試密碼浪費(fèi)時(shí)間。分頁(yè)查詢?cè)谡n設(shè)里是必考項(xiàng)。菜品列表、訂單列表都需要分頁(yè)MyBatis-Plus 自帶分頁(yè)插件配置一個(gè) MybatisPlusInterceptor 就行。數(shù)據(jù)庫(kù)設(shè)計(jì)階段就要想到分頁(yè)字段的設(shè)計(jì)——order by 排序字段要穩(wěn)定如果列表里有兩個(gè)訂單的下單時(shí)間完全相同不分頁(yè)時(shí)不會(huì)暴露問(wèn)題分頁(yè)后會(huì)出現(xiàn)重復(fù)數(shù)據(jù)。建議訂單表里加一個(gè)自增 ID 作為排序兜底字段下單時(shí)間相同就按 ID 倒序。4. 核心代碼落地從登錄鑒權(quán)到下單全鏈路4.1 登錄與 JWT 攔截器課程設(shè)計(jì)里最常見(jiàn)的翻車點(diǎn)先寫登錄接口這是外賣系統(tǒng)所有功能的前置。用戶輸入用戶名和密碼后端校驗(yàn)通過(guò)后簽發(fā) JWT 返回前端。JWT 生成的代碼一般用 jjwt 庫(kù)非常短// 生成 JWT有效期 2 小時(shí)攜帶用戶 ID 和角色 String token Jwts.builder() .setSubject(String.valueOf(user.getId())) // 主題存用戶 ID .claim(role, user.getRole()) // 自定義字段存角色 .setExpiration(new Date(System.currentTimeMillis() 7200000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) // 用同一個(gè)密鑰簽名 .compact();這段代碼里最容易翻車的是 SECRET_KEY 寫得太短jjwt 要求 HS256 的密鑰長(zhǎng)度至少 256 位隨便寫一個(gè)「abc」會(huì)直接拋 WeakKeyException。密鑰要單獨(dú)放在常量類里不要散落在各個(gè) Controller。另外簽發(fā) token 時(shí)把用戶 ID 放到 Subject 里后面攔截器解析時(shí)直接用這是貫穿全系統(tǒng)的通行證。攔截器驗(yàn)證 token 的邏輯要寫在 HandlerInterceptor 的 preHandle 里Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); } try { Claims claims Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token) .getBody(); request.setAttribute(userId, claims.getSubject()); return true; // 驗(yàn)證通過(guò)放行 } catch (Exception e) { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\未登錄或登錄已過(guò)期\}); return false; } }這個(gè)攔截器里有三個(gè)細(xì)節(jié)要講清楚。第一前端傳的 token 一般帶 Bearer 前綴后端切片時(shí)要先判斷再截取不判斷直接 substring 會(huì)越界報(bào)錯(cuò)。第二驗(yàn)證失敗返回 401 時(shí)一定要設(shè)置 ContentType 為 JSON不然前端收到的是 HTML 錯(cuò)誤頁(yè)axios 統(tǒng)一處理時(shí)拿不到錯(cuò)誤結(jié)構(gòu)。第三請(qǐng)求里設(shè)置 userId 屬性后Controller 里用 RequestAttribute 就能拿到當(dāng)前登錄用戶——比如下單接口就是拿這個(gè) userId 作為訂單的用戶 ID。攔截器還要注冊(cè)到 WebMvcConfigurer 里并且指定放行路徑Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(jwtInterceptor()) .addPathPatterns(/**) // 攔截所有請(qǐng)求 .excludePathPatterns(/api/user/login, /api/user/register, /api/shop/list, /api/dish/list); // 放行登錄注冊(cè)和瀏覽接口 }放行路徑寫少了登錄頁(yè)都打不開(kāi)放行路徑寫多了未登錄也能訪問(wèn)訂單接口鑒權(quán)形同虛設(shè)。我一般會(huì)在放行列表里把用戶端需要公開(kāi)訪問(wèn)的接口列全其余統(tǒng)統(tǒng)攔截然后用一個(gè)多小時(shí)把所有接口逐個(gè)點(diǎn)一遍確保沒(méi)有漏網(wǎng)之魚(yú)。檢查方法很簡(jiǎn)單登錄一個(gè)用戶把瀏覽器控制臺(tái)里的 token 手動(dòng)刪掉然后逐個(gè)點(diǎn)擊前端功能——所有需要登錄的請(qǐng)求都應(yīng)該返回 401。4.2 下單流程事務(wù)、庫(kù)存扣減與訂單明細(xì)下單是外賣系統(tǒng)的核心鏈路。前端的購(gòu)物車數(shù)據(jù)傳到后端后后端要做四件事校驗(yàn)菜品是否存在且已上架、計(jì)算訂單總金額、扣減菜品庫(kù)存、生成訂單主表和訂單明細(xì)表。這四步必須在一個(gè)事務(wù)里Transactional public Order createOrder(Long userId, CreateOrderRequest request) { // 1. 根據(jù)購(gòu)物車?yán)锏牟似?ID 批量查詢菜品 ListDish dishList dishMapper.selectBatchIds(request.getDishIds()); if (dishList.size() ! request.getDishIds().size()) { throw new BusinessException(部分菜品已下架請(qǐng)刷新購(gòu)物車); } // 2. 計(jì)算總金額并扣減庫(kù)存逐條操作方便定位問(wèn)題 BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : request.getItems()) { Dish dish dishMap.get(item.getDishId()); if (dish.getStock() item.getQuantity()) { throw new BusinessException(菜品[ dish.getName() ]庫(kù)存不足); } dish.setStock(dish.getStock() - item.getQuantity()); dishMapper.updateById(dish); // 生成訂單明細(xì) OrderDetail detail new OrderDetail(); detail.setOrderId(orderId); detail.setDishId(dish.getId()); detail.setDishName(dish.getName()); detail.setPrice(dish.getPrice()); detail.setQuantity(item.getQuantity()); orderDetailMapper.insert(detail); total total.add(dish.getPrice() .multiply(BigDecimal.valueOf(item.getQuantity()))); } // 3. 生成訂單主表 Order order new Order(); order.setUserId(userId); order.setShopId(request.getShopId()); order.setTotalAmount(total); order.setStatus(0); // 待支付 order.setCreateTime(new Date()); orderMapper.insert(order); return order; }這段代碼里最容易漏的是金額計(jì)算。數(shù)據(jù)庫(kù)里的金額字段我建議用 BigDecimal 而不是 doubledouble 算錢會(huì)出現(xiàn) 0.10.20.30000000000000004 這種問(wèn)題答辯時(shí)演示算錯(cuò)金額屬于硬傷。計(jì)算總價(jià)時(shí)用 BigDecimal 的 multiply 方法不要用 double 累加。庫(kù)存扣減有個(gè)隱藏問(wèn)題上面這段代碼是先查庫(kù)存再扣減在并發(fā)下會(huì)超賣。課程設(shè)計(jì)不會(huì)做并發(fā)壓測(cè)但你可以在代碼里用「樂(lè)觀鎖」的方式主動(dòng)展示給老師看——更新庫(kù)存的 SQL 加一個(gè) where stock quantity 條件影響行數(shù)為 0 就說(shuō)明庫(kù)存已被別的訂單扣完了。這個(gè)設(shè)計(jì)只需要改一條 SQL扣減的代碼不用動(dòng)。下單接口還有一個(gè)容易被忽略的點(diǎn)訂單 ID 的生成。自增 ID 雖然簡(jiǎn)單但訂單號(hào)如果直接返回給用戶演示時(shí)一眼就能看出系統(tǒng)一天的訂單量。課程設(shè)計(jì)階段用自增沒(méi)問(wèn)題但如果想讓訂單號(hào)更「像真的」可以用時(shí)間戳加隨機(jī)數(shù)生成一個(gè) 20 位以內(nèi)的訂單號(hào)。注意訂單號(hào)字段別設(shè)計(jì)成 int要用 varchar否則數(shù)字溢出直接報(bào)錯(cuò)。4.3 Vue 端路由與接口對(duì)接axios 封裝和動(dòng)態(tài)菜單前端從登錄頁(yè)接登錄接口開(kāi)始。axios 需要統(tǒng)一封裝否則每個(gè)頁(yè)面都要寫一遍 token 注入邏輯。先看 axios 實(shí)例的創(chuàng)建// src/utils/request.js import axios from axios import router from /router const request axios.create({ baseURL: /api, // 通過(guò) devServer 代理轉(zhuǎn)發(fā)避免跨域 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)一處理 401 和業(yè)務(wù)錯(cuò)誤碼 request.interceptors.response.use( response { const res response.data if (res.code 401) { localStorage.removeItem(token) router.push(/login) return Promise.reject(new Error(未登錄)) } return res }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } return Promise.reject(error) } ) export default requestbaseURL 寫成 /api 而不是直接寫后端地址是因?yàn)?Vue 的 devServer 可以把 /api 代理到 SpringBoot 的 8080 端口。這樣做的好處是前端代碼里不需要寫死后端地址將來(lái)部署時(shí)直接把 /api 指到不同的環(huán)境。devServer 配置在 vue.config.js 里// vue.config.js module.exports { devServer: { port: 8081, // 前端端口避免和后端沖突 proxy: { /api: { target: http://localhost:8080, // 后端 SpringBoot 地址 changeOrigin: true } } } }前端路由需要分成用戶端和管理端兩塊。用戶端有首頁(yè)、菜品列表、購(gòu)物車、訂單列表、個(gè)人中心管理端有菜品管理、訂單管理、數(shù)據(jù)統(tǒng)計(jì)。路由守衛(wèi)按角色控制訪問(wèn)// src/router/index.js router.beforeEach((to, from, next) { const token localStorage.getItem(token) const role localStorage.getItem(role) if (to.path /login) { next() // 登錄頁(yè)永遠(yuǎn)放行 } else if (!token) { next(/login) // 沒(méi)有 token 一律回登錄頁(yè) } else if (to.meta.requiresAdmin role ! 1) { next(/) // 訪問(wèn)管理端但沒(méi)有管理員角色打回首頁(yè) } else { next() } })動(dòng)態(tài)菜單的常見(jiàn)做法是登錄后根據(jù) role 字段渲染不同的菜單項(xiàng)。用戶端和管理端共用一套布局組件菜單數(shù)據(jù)從后端接口拉取前端根據(jù) role 過(guò)濾。這個(gè)方案比寫兩套頁(yè)面省事而且演示時(shí)切換賬號(hào)用同一個(gè)瀏覽器就能快速演示兩個(gè)身份。5. 課程設(shè)計(jì)避坑清單答辯前必須檢查的 5 個(gè)問(wèn)題5.1 端口沖突與數(shù)據(jù)庫(kù)版本不一致現(xiàn)象啟動(dòng) SpringBoot 后控制臺(tái)報(bào) Port already in use或者啟動(dòng)成功但頁(yè)面轉(zhuǎn)圈加載不出來(lái)。原因SpringBoot 默認(rèn) 8080如果本機(jī)裝了其他 Java 服務(wù)占用了 8080或者前端 Vue 和后端 SpringBoot 都用了 8080后端起不來(lái)前端請(qǐng)求也全失敗。數(shù)據(jù)庫(kù)版本不一致則表現(xiàn)為啟動(dòng)時(shí)報(bào) Unknown database 或 SQL 語(yǔ)法錯(cuò)誤比如本機(jī) MySQL 是 5.7源碼 SQL 里用了 8.0 的語(yǔ)法。解決先把 application.yml 里的端口改成一個(gè)不常用的比如 8088再在前端 devServer 的 proxy 里同步改成 8088。數(shù)據(jù)庫(kù)方面先查本機(jī) MySQL 版本如果源碼 SQL 運(yùn)行報(bào)錯(cuò)把報(bào)錯(cuò)語(yǔ)句單獨(dú)拎出來(lái)在 Navicat 里跑一遍能定位是語(yǔ)法問(wèn)題還是字段類型問(wèn)題。實(shí)在不兼容就重建表結(jié)構(gòu)用建表語(yǔ)句同步出的表結(jié)構(gòu)代替原有 SQL。5.2 菜品圖片加載不出來(lái)現(xiàn)象列表頁(yè)菜品名稱、價(jià)格都正常只有圖片區(qū)域是空的或裂圖。原因數(shù)據(jù)庫(kù)里存的圖片路徑是絕對(duì)路徑比如C:/Users/xxx/Pictures/或者作者本機(jī)的地址。換一臺(tái)電腦跑項(xiàng)目路徑就失效了。另一種情況是圖片來(lái)源用了外鏈網(wǎng)絡(luò)不穩(wěn)定時(shí)加載慢或被攔截。解決把所有圖片路徑改成相對(duì)路徑圖片文件放到 SpringBoot 的 src/main/resources/static 目錄下數(shù)據(jù)庫(kù)里只存/images/xxx.jpg這種相對(duì)路徑。前端拼接時(shí)用 window.location.origin 或者直接用 Vue 的 baseURL。檢查方法是打開(kāi)瀏覽器 F12 看圖片請(qǐng)求的完整 URL如果 URL 里包含 localhost:8080 以外的地址就要改。5.3 下單不扣庫(kù)存、金額對(duì)不上現(xiàn)象下單成功后訂單列表能看到訂單金額也和前端顯示一致但菜品表的庫(kù)存沒(méi)變?；蛘哂唵慰偨痤~比菜品單價(jià)乘以數(shù)量少了一部分。原因下單的事務(wù)沒(méi)生效或者扣庫(kù)存的代碼寫在了事務(wù)之外。金額對(duì)不上通常是前端計(jì)算總價(jià)傳給后端后端直接信任前端傳的 totalAmount 沒(méi)有自己重新計(jì)算。如果前端的計(jì)算邏輯有 bug或者有人用 Postman 直接調(diào)接口傳了個(gè)負(fù)數(shù)金額數(shù)據(jù)庫(kù)里就會(huì)留下臟數(shù)據(jù)。解決先檢查 Service 方法上有沒(méi)有 Transactional 注解沒(méi)加就加上加了還是不行檢查是不是同類內(nèi)部調(diào)用——同類里 A 方法調(diào)用 B 方法時(shí)事務(wù)注解不生效。金額必須后端重新計(jì)算前端傳的 totalAmount 直接丟棄。校驗(yàn)邏輯寫成遍歷訂單明細(xì)計(jì)算出總價(jià)和前端傳的值比對(duì)不一致直接拒絕下單并把提示返回給前端。5.4 打包部署后頁(yè)面白屏現(xiàn)象本地開(kāi)發(fā)環(huán)境 npm run serve 一切正常但是 npm run build 之后把 dist 目錄丟給老師打開(kāi) index.html 是白屏。原因Vue 打包后的靜態(tài)資源路徑默認(rèn)是絕對(duì)路徑/js/xxx.js在本地直接打開(kāi)文件時(shí)找不到。另外前端打包后訪問(wèn)后端接口的地址寫死了 localhost:8080老師換了電腦就請(qǐng)求不到。解決在 vue.config.js 里設(shè)置publicPath: ./讓打包后的資源相對(duì)當(dāng)前路徑加載。接口地址改成相對(duì)路徑 /api這樣前端和后端部署在同一個(gè)域名下就能直接工作不用關(guān)心對(duì)方在什么端口。交付課程設(shè)計(jì)時(shí)把前后端的啟動(dòng)說(shuō)明寫清楚MySQL 導(dǎo)入 SQL → 啟動(dòng) SpringBoot → 啟動(dòng) Vue三步做完就能看到完整系統(tǒng)。5.5 演示現(xiàn)場(chǎng)數(shù)據(jù)準(zhǔn)備不充分現(xiàn)象答辯演示時(shí)登錄頁(yè)進(jìn)去了但首頁(yè)空蕩蕩打開(kāi)訂單列表沒(méi)有數(shù)據(jù)可以點(diǎn)現(xiàn)場(chǎng)網(wǎng)絡(luò)不好圖片一直加載。原因初始化數(shù)據(jù)太少的鍋。設(shè)計(jì)數(shù)據(jù)庫(kù)時(shí)只保證了功能能跑沒(méi)有考慮演示效果。老師想看的是點(diǎn)開(kāi)每個(gè)頁(yè)面都有內(nèi)容可操作而不是看著空列表無(wú)語(yǔ)。解決演示前在系統(tǒng)里手動(dòng)補(bǔ)一套完整流程的數(shù)據(jù)注冊(cè)一個(gè)用戶 → 下一單 → 用商家賬號(hào)接單 → 用管理員賬號(hào)查看所有訂單。這套數(shù)據(jù)留在數(shù)據(jù)庫(kù)里不要?jiǎng)h。同時(shí)提前把菜品圖片準(zhǔn)備好把初始化 SQL 里所有菜品都配上圖片確保離線狀態(tài)也能正常展示。最后在演示電腦上完整走一遍「用戶下單選菜 → 提交訂單 → 商家接單 → 完成訂單」確認(rèn)每個(gè)按鈕都有響應(yīng)。6. 讓演示「說(shuō)人話」評(píng)分視角下的三個(gè)加分技巧第一個(gè)加分技巧是「講狀態(tài)流轉(zhuǎn)而不是講 CRUD」。外賣系統(tǒng)的訂單狀態(tài)從待支付到已完成要經(jīng)歷多個(gè)環(huán)節(jié)普通人的演示只是在頁(yè)面上點(diǎn)按鈕高分演示是先在黑板上畫出狀態(tài)流轉(zhuǎn)圖然后告訴老師「這一步操作對(duì)應(yīng) status 從 2 變成 3代碼在 OrderServiceImpl 的第幾行」——讓老師覺(jué)得你對(duì)業(yè)務(wù)鏈路有全局理解而不是會(huì)調(diào)用幾個(gè)現(xiàn)成接口。第二個(gè)技巧是「主動(dòng)暴露一個(gè)設(shè)計(jì)缺陷并給出改進(jìn)方案」。比如在答辯時(shí)主動(dòng)說(shuō)「這個(gè)系統(tǒng)的庫(kù)存扣減在高并發(fā)下可能超賣我目前用的是先查后扣如果產(chǎn)量化可以考慮用樂(lè)觀鎖加 version 字段SQL 改為 update dish set stock stock - 1 where id ? and stock 1」。這句話一出來(lái)比回答完所有提問(wèn)都加分因?yàn)樗故玖四銓?duì)代碼邊界和優(yōu)化方向的理解這是課程設(shè)計(jì)評(píng)分里「設(shè)計(jì)思想」那一檔的分?jǐn)?shù)。第三個(gè)技巧是「把數(shù)據(jù)庫(kù)設(shè)計(jì)講成業(yè)務(wù)故事」。講解訂單明細(xì)表時(shí)不要說(shuō)「這張表有 5 個(gè)字段」而是說(shuō)「訂單表只存總金額和狀態(tài)訂單明細(xì)表存的是下單那一刻的菜品快照因?yàn)椴似穬r(jià)格可能會(huì)調(diào)整但歷史訂單必須保持原價(jià)」。這種講法讓老師知道你不是抄的表結(jié)構(gòu)而是真的理解為什么訂單主表和明細(xì)表要拆分。這三個(gè)技巧本質(zhì)上都是把「你做了什么」轉(zhuǎn)成「你理解了為什么這么做」哪怕代碼是別人寫的只要你能把這個(gè)「為什么」講透這個(gè)系統(tǒng)在答辯語(yǔ)境下就是你的。我個(gè)人的習(xí)慣是答辯前一天把所有接口用 Postman 重新打一遍用 Excel 列一個(gè)「接口地址、參數(shù)、預(yù)期結(jié)果、實(shí)際情況」的對(duì)照表哪個(gè)接口返回異常當(dāng)場(chǎng)修不留到答辯現(xiàn)場(chǎng)翻車。課設(shè)這東西功能做出來(lái)只是及格把設(shè)計(jì)思路講得讓老師點(diǎn)頭才算真正做完。希望這些踩過(guò)的坑和總結(jié)的技巧能幫到你祝答辯順利。本文還有配套的精品資源點(diǎn)擊獲取