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