Spring Boot 做校園點(diǎn)餐系統(tǒng)不難但能不能做到被學(xué)校食堂、外賣店、學(xué)生三邊都夸“好用”就完全是另一回事了。這個(gè)“springboot123校內(nèi)校園點(diǎn)餐系統(tǒng)”標(biāo)題里藏著的信息量其實(shí)很大它既是一個(gè)典型的 Java 全棧練手項(xiàng)目也是一個(gè)能直接落地到真實(shí)生活場(chǎng)景的管理系統(tǒng)。今天我就以實(shí)際開發(fā)和部署的角度把這個(gè)項(xiàng)目的完整玩法、架構(gòu)思路、核心代碼設(shè)計(jì)、踩坑記錄全部拆給你看。先說一下這個(gè)系統(tǒng)到底能干什么。簡(jiǎn)單來(lái)說它就是把一個(gè)校內(nèi)校園點(diǎn)餐的全流程搬到線上學(xué)生登錄后能瀏覽食堂或商家的菜品加入購(gòu)物車下單支付再跟蹤訂單狀態(tài)商家端要處理接單、備餐、出餐管理員端負(fù)責(zé)菜品分類、商家審核、數(shù)據(jù)統(tǒng)計(jì)。技術(shù)上用的是 Spring Boot 作為后端框架搭配主流的關(guān)系型數(shù)據(jù)庫(kù)存數(shù)據(jù)前端可以用 Vue 或者 Thymeleaf 模板引擎整個(gè)系統(tǒng)就是一個(gè)典型的前后端分離或者半分離的架構(gòu)。適合誰(shuí)看如果你正在做畢業(yè)設(shè)計(jì)、課程項(xiàng)目或者剛學(xué)會(huì) Spring Boot 基礎(chǔ)想找一個(gè)完整的實(shí)戰(zhàn)項(xiàng)目練手這篇內(nèi)容能直接幫你跳過大量彎路。1. 整體設(shè)計(jì)思路一個(gè)校園點(diǎn)餐系統(tǒng)到底該怎么拆模塊很多人拿到這種系統(tǒng)需求第一反應(yīng)就是趕緊建表、趕緊寫接口。我的建議是反過來(lái)先把角色的使用路徑走一遍把“誰(shuí)在什么時(shí)間用什么功能”梳理清楚再去動(dòng)代碼。校園點(diǎn)餐系統(tǒng)的核心角色其實(shí)就三類學(xué)生C 端用戶、商家B 端商戶、管理員后臺(tái)運(yùn)營(yíng)方。每一類角色背后的功能訴求是完全不一樣的數(shù)據(jù)庫(kù)設(shè)計(jì)、權(quán)限設(shè)計(jì)、接口粒度都要跟著角色走。1.1 核心需求拆解三類角色三條主鏈路學(xué)生端最核心的鏈路是登錄 → 瀏覽菜品 → 加入購(gòu)物車 → 生成訂單 → 支付 → 等待出餐 → 確認(rèn)取餐。這條鏈路看起來(lái)簡(jiǎn)單但里面涉及了一個(gè)非常容易被學(xué)生項(xiàng)目忽視的點(diǎn)訂單狀態(tài)流轉(zhuǎn)。訂單狀態(tài)不能是一條死線它必須支持回退和異常處理。比如用戶下單后后悔了要有取消訂單的能力商家出餐超時(shí)了系統(tǒng)該有提醒機(jī)制如果用戶支付了但商家因?yàn)樵喜蛔憔軉瘟诉€得有自動(dòng)退款流程。我見過不少項(xiàng)目把訂單狀態(tài)設(shè)計(jì)成單純的一個(gè) int 字段0 未支付、1 已支付、2 已完成然后寫死在代碼里。這種方式應(yīng)付課設(shè)答辯沒問題但一旦進(jìn)入真實(shí)場(chǎng)景狀態(tài)機(jī)缺失會(huì)讓整個(gè)系統(tǒng)變得極其難維護(hù)。商家端的主鏈路是商家登錄 → 菜品管理 → 接收新訂單 → 確認(rèn)接單 → 出餐完成。商家最在意的不是界面的花哨程度而是操作夠不夠快、訂單信息夠不夠清晰。設(shè)計(jì)商家端時(shí)一個(gè)核心原則是減少點(diǎn)擊次數(shù)。比如新訂單推送消息里直接帶上“接單”和“拒單”兩個(gè)按鈕就比讓商家進(jìn)入訂單詳情頁(yè)再操作高效得多。管理員端的功能相對(duì)雜用戶管理、商家審核、菜品分類管理、訂單統(tǒng)計(jì)、營(yíng)業(yè)額報(bào)表。這里要注意的是很多新手會(huì)把管理員端和商家端混在一個(gè)角色體系里導(dǎo)致權(quán)限判斷到處是 if 嵌套。正確的做法是用 Spring Security 或自定義攔截器做角色分級(jí)把對(duì)接口的訪問權(quán)限精細(xì)到方法級(jí)別。1.2 技術(shù)選型為什么是這些Spring Boot 不是唯一答案但它是首選校園點(diǎn)餐系統(tǒng)這種場(chǎng)景備選方案其實(shí)不少Python 的 FastAPI、Go 的 Gin甚至直接用 Node.js 寫也不是不行。但 Spring Boot 在高校場(chǎng)景里的優(yōu)勢(shì)非常明顯。第一生態(tài)成熟。Spring Boot 本身就整合了 Spring MVC、Spring Security、MyBatis 或 JPA 的配置開發(fā)起來(lái)不用像傳統(tǒng) SSM 框架那樣手寫大量 XML。對(duì)于第二個(gè)部署運(yùn)維層面Spring Boot 內(nèi)嵌了 Tomcat一個(gè) java -jar 命令就能啟動(dòng)對(duì)服務(wù)器要求低租一臺(tái)小型云服務(wù)器就能跑起來(lái)完全夠一個(gè)學(xué)校內(nèi)部的點(diǎn)餐系統(tǒng)使用。第三資料和社區(qū)深度足夠。哪怕你卡在 Redis 緩存穿透這種細(xì)節(jié)上也能快速找到對(duì)應(yīng)的解決方案。數(shù)據(jù)庫(kù)選型上我用的是 MySQL 8.0搭配 MyBatis-Plus 做持久層框架。為什么不用 JPA因?yàn)辄c(diǎn)餐系統(tǒng)的查詢需求非常雜尤其是后臺(tái)的數(shù)據(jù)統(tǒng)計(jì)模塊各種分組聚合查詢、多表聯(lián)查MyBatis 寫 SQL 的控制力非常強(qiáng)更適合這種業(yè)務(wù)場(chǎng)景。緩存方面建議引入 Redis用來(lái)存放菜單列表、購(gòu)物車臨時(shí)數(shù)據(jù)、登錄 Token減少數(shù)據(jù)庫(kù)壓力。1.3 功能模塊地圖別漏掉這些“不起眼但很關(guān)鍵”的子功能很多課設(shè)項(xiàng)目做點(diǎn)餐系統(tǒng)把注意力全放在下單支付上結(jié)果到了驗(yàn)收的時(shí)候?qū)焼栆痪洹坝脩敉浢艽a怎么辦”就卡殼了。一個(gè)完整的校內(nèi)點(diǎn)餐系統(tǒng)功能地圖應(yīng)該是這樣的用戶側(cè)注冊(cè)登錄、找回密碼、瀏覽菜品分類、菜品搜索、購(gòu)物車管理、生成訂單、在線支付、訂單狀態(tài)跟蹤、歷史訂單查詢、個(gè)人資料修改、評(píng)價(jià)功能。商家側(cè)店鋪信息管理、菜品增刪改查、庫(kù)存設(shè)置、訂單管理接單/拒單/完成、營(yíng)業(yè)統(tǒng)計(jì)、評(píng)價(jià)管理。管理側(cè)用戶管理封禁/解封、商家入駐審核、菜品分類管理、公告管理、數(shù)據(jù)看板、訂單總覽。支付這一環(huán)如果是課設(shè)演示可以用模擬支付前端直接跳轉(zhuǎn)到“支付成功”頁(yè)面如果是要真實(shí)使用可以接入微信支付或支付寶沙箱環(huán)境。我的建議是兩套都做通過配置切換演示的時(shí)候用模擬支付上線的時(shí)候切換真實(shí)支付渠道。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)詳解訂單表的核心字段決定系統(tǒng)上限數(shù)據(jù)庫(kù)是整個(gè)系統(tǒng)的地基訂單表和菜品表的設(shè)計(jì)直接決定了系統(tǒng)的上限。我見過最糟糕的設(shè)計(jì)是把訂單的所有信息全塞進(jìn)一張大表里下單商品列表用逗號(hào)分隔的字符串存進(jìn)去。這樣寫起來(lái)確實(shí)快但后查數(shù)據(jù)、做統(tǒng)計(jì)時(shí)就得寫一堆奇葩的字符串處理代碼。正確的做法是采用主表和子表分離的設(shè)計(jì)訂單主表存核心信息訂單明細(xì)表存菜品快照。2.1 核心數(shù)據(jù)表結(jié)構(gòu)與字段解釋用戶表建議不要直接叫 user因?yàn)?user 在 MySQL 里本身是保留關(guān)鍵字?？梢杂?member 或 sys_user。必要字段包括id、username、password加密存儲(chǔ)、real_name、phone、avatar、rolestudent、merchant、admin、status正常/禁用、create_time。商家表可以獨(dú)立出來(lái)也可以和用戶表通過 role 區(qū)分。我建議獨(dú)立一張 shop 表id、merchant_id外鍵關(guān)聯(lián)用戶表、shop_name、shop_logo、notice、delivery_fee、起送價(jià) min_price、營(yíng)業(yè)狀態(tài) open_status、評(píng)分 score。訂單主表 ordersid、order_no訂單號(hào)唯一、user_id、shop_id、total_amount、pay_amount、discount_amount、status待支付/已支付/已接單/配送中/已完成/已取消/退款中、pay_time、finish_time、remark、create_time。訂單明細(xì)表 order_detailid、order_id、food_id、food_name冗余菜品名稱防止菜品被刪除后訂單顯示異常、food_image、price下單時(shí)的價(jià)格快照、quantity、sub_total。菜品表 foodid、shop_id、category_id、food_name、food_description、cover_image、price、stock、sales、status上架/下架、create_time。分類表 category 建議做成兩級(jí)一級(jí)分類比如“家常菜”“面食”“飲品”二級(jí)可以是具體菜品名但不要無(wú)限嵌套增加復(fù)雜度卻沒有實(shí)際收益。還要單獨(dú)說一個(gè)很容易被忽略的表購(gòu)物車表 cart。校園點(diǎn)餐的購(gòu)物車和電商購(gòu)物車不太一樣時(shí)效性非常強(qiáng)用戶可能中午下單前加購(gòu)吃完后購(gòu)物車就清空。所以設(shè)計(jì)上可以直接用 Redis 存用哈希結(jié)構(gòu) key 為 userIdfield 為 foodIdvalue 為數(shù)量。這樣性能好而且天然有過期時(shí)間省一張 MySQL 表。但如果你希望用戶在不同設(shè)備上購(gòu)物車同步那就得老老實(shí)實(shí)建一張 MySQL 表按 user_id 和 food_id 做唯一索引。2.2 一張表看懂訂單狀態(tài)流轉(zhuǎn)訂單狀態(tài)是整個(gè)點(diǎn)餐系統(tǒng)里最容易出錯(cuò)的地方先看下狀態(tài)機(jī)狀態(tài)碼狀態(tài)名稱觸發(fā)動(dòng)作下一狀態(tài)0待支付用戶下單成功支付成功 → 1超時(shí) → 61已支付/待接單用戶完成支付推送給商家商家接單 → 2商家拒單 → 72已接單/制作中商家確認(rèn)接單出餐完成 → 33待取餐/配送中商家出餐通知用戶用戶確認(rèn)取餐 → 44已完成用戶確認(rèn)取餐或超時(shí)自動(dòng)確認(rèn)終態(tài)5已取消用戶取消或系統(tǒng)自動(dòng)取消終態(tài)6退款中僅已支付狀態(tài)發(fā)起退款成功 → 77已退款/已關(guān)閉商家拒單/用戶退款終態(tài)這個(gè)狀態(tài)機(jī)要在代碼里嚴(yán)格約束每個(gè)狀態(tài)只允許特定動(dòng)作觸發(fā)轉(zhuǎn)移。比如已取消的訂單絕不能再次進(jìn)入“已支付”否則對(duì)賬的時(shí)候會(huì)亂成一團(tuán)。實(shí)現(xiàn)上可以在后端定義一個(gè)狀態(tài)流轉(zhuǎn)校驗(yàn)工具類把合法流轉(zhuǎn)關(guān)系配成 Map 或枚舉對(duì)照表每次更新訂單狀態(tài)前先校驗(yàn)。2.3 數(shù)據(jù)庫(kù)層的三個(gè)性能優(yōu)化細(xì)節(jié)校園點(diǎn)餐的并發(fā)量確實(shí)不會(huì)像電商大促那么夸張但中午飯點(diǎn)的峰值還是能到幾百甚至上千并發(fā)數(shù)據(jù)庫(kù)扛不住就完了。這三件事在開發(fā)時(shí)就應(yīng)該做好第一訂單號(hào)不要用自增 id要用雪花算法或時(shí)間戳加隨機(jī)數(shù)生成。因?yàn)樽栽?id 會(huì)暴露訂單量而且在高并發(fā)插入時(shí)會(huì)產(chǎn)生熱點(diǎn)寫競(jìng)爭(zhēng)。訂單號(hào)一般用 18 位左右前幾位是時(shí)間標(biāo)識(shí)后面是隨機(jī)數(shù)。第二菜品表要建立 (shop_id, status) 聯(lián)合索引這是菜單列表查詢最常用的查詢條件。訂單表要建立 (user_id, create_time) 聯(lián)合索引支撐用戶查歷史訂單同時(shí)建立 (shop_id, status) 支撐商家端查訂單。第三庫(kù)存字段的更新不能用先查再減的寫法要直接用 SQL 原子操作 UPDATE food SET stock stock - 1 WHERE id ? AND stock 0防止超賣。3. Spring Boot 后端核心實(shí)現(xiàn)從啟動(dòng)類到具體接口的完整拆解這一節(jié)直接上干貨梳理一下 Spring Boot 項(xiàng)目搭建的完整流程以及點(diǎn)餐系統(tǒng)里最核心的幾個(gè)接口的實(shí)現(xiàn)思路。項(xiàng)目整體結(jié)構(gòu)用的是標(biāo)準(zhǔn)的三層架構(gòu)Controller 層寫接口Service 層寫業(yè)務(wù)邏輯Mapper 層操作數(shù)據(jù)庫(kù)實(shí)體類對(duì)應(yīng)數(shù)據(jù)表。不要把所有邏輯都塞在 Controller 里否則后續(xù)想加權(quán)限、加緩存改動(dòng)量會(huì)非常大。3.1 項(xiàng)目初始化與依賴配置創(chuàng)建一個(gè) Spring Boot 項(xiàng)目版本選 2.7.x 或 3.x 都可以?？紤]到大部分高校環(huán)境用的 JDK 還是 8建議直接選 Spring Boot 2.7 系列JDK 8 兼容性最好。如果你對(duì)版本選擇沒有特別偏好又不確定 3.x 的依賴變化會(huì)不會(huì)給你帶來(lái)困擾2.7 是最穩(wěn)妥的選擇。pom.xml 里最關(guān)鍵的依賴就是這幾個(gè)dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version4.4.0/version /dependency /dependencies數(shù)據(jù)庫(kù)連接配置直接寫在 application.yml 里server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/campus_order?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto連接 MySQL 時(shí)serverTimezone 參數(shù)一定要配成 Asia/Shanghai否則日期字段和系統(tǒng)時(shí)區(qū)的偏差會(huì)在查訂單時(shí)間時(shí)把你坑死。map-underscore-to-camel-case 這個(gè)配置建議打開可以把數(shù)據(jù)庫(kù)里的 create_time 自動(dòng)映射成實(shí)體類的 createTime省去很多手寫映射代碼的麻煩。3.2 登錄鑒權(quán)與權(quán)限控制用 JWT 還是 Session登錄鑒權(quán)方案的選擇說簡(jiǎn)單也簡(jiǎn)單說復(fù)雜也復(fù)雜。傳統(tǒng)的校園課設(shè)項(xiàng)目最省事的方式是 Session Cookie因?yàn)?Spring Boot 內(nèi)置 Tomcat 支持不用額外引入組件。但如果你希望系統(tǒng)能支持前后端分離以后多端共用一套接口JWTJSON Web Token是更好的方案。JWT 的思路就是用戶登錄成功后服務(wù)端簽發(fā)一個(gè) Token把用戶 id、角色、過期時(shí)間加密到 Token 里面。客戶端后續(xù)請(qǐng)求在請(qǐng)求頭里帶上 Authorization: Bearer xxx后端通過攔截器解析 Token 獲取用戶身份。核心攔截器代碼可以這樣寫public class AuthInterceptor implements HandlerInterceptor { Autowired private StringRedisTemplate redisTemplate; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行預(yù)檢請(qǐng)求 if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); try { JWTVerifier verifier JWT.require(Algorithm.HMAC256(your-secret-key)).build(); DecodedJWT decodedJWT verifier.verify(token); Integer userId decodedJWT.getClaim(userId).asInt(); String role decodedJWT.getClaim(role).asString(); request.setAttribute(userId, userId); request.setAttribute(userRole, role); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; } }JWT 的密鑰千萬(wàn)不要硬編碼在代碼里建議配置在 application.yml 的配置項(xiàng)中后續(xù)上線可以通過環(huán)境變量覆蓋。Token 過期時(shí)間我一般設(shè)置為 24 小時(shí)對(duì)于校園點(diǎn)餐這種低頻系統(tǒng)足夠了。如果你希望用戶退出登錄后 Token 立即失效那就得在 Redis 里再加一層黑名單緩存否則 JWT 在過期前一直是有效的這是 JWT 方案天然的短板。角色權(quán)限這塊可以用 Spring Security也可以用攔截器自行判斷。如果不想引入 Spring Security 的一堆配置可以在攔截器里校驗(yàn)角色做一個(gè)手動(dòng)版本public class RoleInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String requiredRole (String) request.getAttribute(requiredRole); String userRole (String) request.getAttribute(userRole); if (!requiredRole.equals(userRole)) { response.setStatus(403); return false; } return true; } }通過 WebMvcConfigurer 注冊(cè)攔截器并給不同的接口路徑配置不同的權(quán)限要求。比如 /api/merchant/ 開頭的接口只允許 merchant 角色訪問/api/admin/ 開頭只允許 admin 訪問。3.3 點(diǎn)餐核心鏈路實(shí)現(xiàn)下單接口怎么設(shè)計(jì)才能不出事故點(diǎn)餐系統(tǒng)最核心的接口是下單。一個(gè)合格的下單接口必須做到事務(wù)性、防超賣、防重復(fù)提交三件事并行。事務(wù)性指的是生成訂單主表、生成訂單明細(xì)、扣減庫(kù)存、清空購(gòu)物車這幾步要么全成功要么全失敗。接口參數(shù)大概是這樣{ shopId: 1, items: [ { foodId: 12, quantity: 2 }, { foodId: 15, quantity: 1 } ], remark: 不要辣 }Service 層的實(shí)現(xiàn)思路Transactional(rollbackFor Exception.class) public OrderVO createOrder(Long userId, CreateOrderDTO dto) { // 1. 查詢商家是否存在且在營(yíng)業(yè) Shop shop shopMapper.selectById(dto.getShopId()); if (shop null || shop.getOpenStatus() ! 1) { throw new BusinessException(店鋪不存在或已打烊); } // 2. 遍歷菜品計(jì)算金額校驗(yàn)庫(kù)存 ListOrderDetail detailList new ArrayList(); BigDecimal totalAmount new BigDecimal(0); for (OrderItemDTO item : dto.getItems()) { Food food foodMapper.selectById(item.getFoodId()); if (food null || food.getStatus() ! 1) { throw new BusinessException(菜品已下架: item.getFoodId()); } // 原子扣減庫(kù)存 int updated foodMapper.decreaseStock(item.getFoodId(), item.getQuantity()); if (updated 0) { throw new BusinessException(庫(kù)存不足); } // 計(jì)算小計(jì) BigDecimal subTotal food.getPrice().multiply(new BigDecimal(item.getQuantity())); totalAmount totalAmount.add(subTotal); // 保存明細(xì)快照 OrderDetail detail new OrderDetail(); detail.setFoodId(food.getId()); detail.setFoodName(food.getFoodName()); detail.setFoodImage(food.getCoverImage()); detail.setPrice(food.getPrice()); detail.setQuantity(item.getQuantity()); detail.setSubTotal(subTotal); detailList.add(detail); } // 3. 校驗(yàn)起送價(jià) if (totalAmount.compareTo(shop.getMinPrice()) 0) { throw new BusinessException(未達(dá)到起送價(jià) shop.getMinPrice() 元); } // 4. 生成訂單號(hào) String orderNo generateOrderNo(); // 5. 保存訂單 Order order new Order(); order.setOrderNo(orderNo); order.setUserId(userId); order.setShopId(shop.getId()); order.setTotalAmount(totalAmount); order.setPayAmount(totalAmount); order.setStatus(0); // 待支付 orderMapper.insert(order); // 6. 保存訂單明細(xì) for (OrderDetail detail : detailList) { detail.setOrderId(order.getId()); orderDetailMapper.insert(detail); } return convertToVO(order); }注意Transactional 注解的 rollbackFor 屬性一定要設(shè)為 Exception.class。因?yàn)?Spring 默認(rèn)只在 RuntimeException 回滾如果你拋的是自定義的檢查異常不加這個(gè)屬性事務(wù)不會(huì)回滾訂單可能只生成了一半就卡住了。防重復(fù)提交可以用 Redis 的 setnx 命令用一個(gè)以 userId 加 shopId 為 key 的鎖下單前嘗試加鎖下單后釋放鎖并設(shè)置短時(shí)間過期。這樣即使用戶瘋狂點(diǎn)擊提交按鈕系統(tǒng)也能保證同一用戶同一時(shí)間只有一個(gè)訂單在創(chuàng)建。3.4 支付回調(diào)與訂單狀態(tài)更新的安全落地真實(shí)支付渠道接入后支付結(jié)果是通過異步回調(diào)通知后端的。這一步非常容易踩坑因?yàn)橹Ц镀脚_(tái)的回調(diào)可能因?yàn)榫W(wǎng)絡(luò)原因重復(fù)推送如果后端不去重訂單狀態(tài)就會(huì)被重復(fù)更新。支付回調(diào)接口的正確寫法是收到回調(diào)后先根據(jù)訂單號(hào)查訂單狀態(tài)如果訂單已經(jīng)是“已支付”直接返回成功響應(yīng)不再做任何更新。然后把回調(diào)數(shù)據(jù)落一條日志表方便對(duì)賬排查。模擬支付的話更簡(jiǎn)單直接提供一個(gè)接口把訂單從待支付狀態(tài)改為已支付并且觸發(fā)后續(xù)的商家通知邏輯。不過要注意模擬支付接口一定只能在校內(nèi)測(cè)試環(huán)境開啟上線前必須關(guān)閉否則任何人都可以把自己訂單改成已支付狀態(tài)。3.5 商家端與用戶端的消息通知機(jī)制校內(nèi)點(diǎn)餐系統(tǒng)里的消息通知不需要做到像即時(shí)通訊那樣實(shí)時(shí)推送用輪詢就能解決。商家端有新訂單時(shí)前端每 10 秒拉一次待接單列表用戶端下單后每 10 秒查一次訂單狀態(tài)。這個(gè)方案在用戶量不大的校園場(chǎng)景下非常穩(wěn)定實(shí)現(xiàn)簡(jiǎn)單也不用引入消息推送組件。另外在 Redis 里可以做一個(gè)簡(jiǎn)單的提醒渠道。下單成功后把 shopId 作為 key往一個(gè) List 里 push 一條消息商家端的接口從 List 里 pop 消息。這樣比前端直接輪詢數(shù)據(jù)庫(kù)壓力小得多而且響應(yīng)時(shí)間幾乎是即時(shí)的。4. Redis 在點(diǎn)餐系統(tǒng)里的實(shí)際應(yīng)用緩存、購(gòu)物車與防重Redis 在點(diǎn)餐系統(tǒng)里是性價(jià)比很高的一環(huán)。它的應(yīng)用點(diǎn)主要集中在三個(gè)地方菜品列表緩存、登錄 Token 存儲(chǔ)、購(gòu)物車臨時(shí)數(shù)據(jù)。不要一開始就把 MySQL 的數(shù)據(jù)全部塞進(jìn)緩存而是針對(duì)熱點(diǎn)數(shù)據(jù)做緩存。4.1 菜品列表緩存減少數(shù)據(jù)庫(kù)壓力最直接的手段中午飯點(diǎn)的時(shí)候大量用戶同時(shí)打開同一個(gè)商家的菜單數(shù)據(jù)庫(kù)查詢壓力集中在一個(gè)點(diǎn)?？梢栽诓樵儾似妨斜淼?Service 層加一層 Redis 緩存。key 設(shè)計(jì)成 menu:shopId:categoryIdvalue 是 JSON 字符串過期時(shí)間 30 分鐘。緩存更新策略用最簡(jiǎn)單的 Cache Aside 模式查詢菜品時(shí)先讀緩存緩存沒命中再查數(shù)據(jù)庫(kù)并回填商家修改菜品、上下架菜品時(shí)主動(dòng)刪除對(duì)應(yīng)商家的緩存 key。這里要注意刪除緩存和更新數(shù)據(jù)庫(kù)的順序一定要先更新數(shù)據(jù)庫(kù)成功再刪除緩存避免緩存先刪了、數(shù)據(jù)庫(kù)還沒更新完成用戶讀到舊數(shù)據(jù)的情況。4.2 購(gòu)物車用 Redis 還是 MySQL購(gòu)物車我建議直接采用 Redis 的 Hash 結(jié)構(gòu)key 是 cart:userIdfield 是 foodIdvalue 是數(shù)量。核心操作代碼public void addToCart(Long userId, Long foodId, Integer quantity) { String key cart: userId; redisTemplate.opsForHash().increment(key, foodId.toString(), quantity); }讀取購(gòu)物車時(shí)需要把 foodId 列表查一遍數(shù)據(jù)庫(kù)拿到菜品詳情再拼接成完整購(gòu)物車對(duì)象。這里有一個(gè)性能點(diǎn)如果購(gòu)物車?yán)锊似窋?shù)量很多不要一個(gè)菜一個(gè)菜查數(shù)據(jù)庫(kù)直接把所有 foodId 收集起來(lái)用 in 查詢一次拿回所有菜品數(shù)據(jù)。4.3 分布式鎖防重復(fù)提交和數(shù)據(jù)一致性下單接口的防重我用的是 Redis 分布式鎖public boolean tryLock(String key, String requestId, long expireTime) { return redisTemplate.opsForValue().setIfAbsent(key, requestId, Duration.ofSeconds(expireTime)); }鎖的 key 用 userId 加 shopId。同一用戶在同一個(gè)店鋪同時(shí)只能有一個(gè)訂單在創(chuàng)建中鎖過期時(shí)間設(shè)置 5 秒就夠了。如果用戶提交訂單后支付頁(yè)面卡住超過 5 秒理論上可以再次提交但這屬于極端場(chǎng)景對(duì)于校園系統(tǒng)來(lái)說影響不大。Redis 在支付回調(diào)去重里也能派上用場(chǎng)。用 SETNX 把 orderNo 作為 key 存一個(gè)標(biāo)識(shí)回調(diào)處理前嘗試加鎖如果加鎖失敗說明已經(jīng)處理過直接返回成功。這個(gè)方法比查數(shù)據(jù)庫(kù)判斷狀態(tài)更高效還能有效防止并發(fā)回調(diào)時(shí)的臟寫。5. 前端設(shè)計(jì)與接口聯(lián)調(diào)分層渲染還是前后端分離前端這塊有兩種主流做法一種是用 Thymeleaf 模板引擎做服務(wù)端渲染另一種是 Vue Element UI 做前后端分離。對(duì)于校園點(diǎn)餐這種管理系統(tǒng)我個(gè)人的建議是如果目標(biāo)是快速出成果、應(yīng)付答辯直接用 Thymeleaf 最省事Spring Boot 內(nèi)置支持不用另起前端服務(wù)如果目標(biāo)是做出一個(gè)像樣的多端系統(tǒng)以后還想擴(kuò)展到小程序端那就用 Vue 寫?yīng)毩⑶岸隧?xiàng)目后端只出 JSON 接口。5.1 基于 Vue 的前端架構(gòu)與核心頁(yè)面結(jié)構(gòu)前端項(xiàng)目用 Vue 2 還是 Vue 3取決于你熟悉的程度。Vue 3 是當(dāng)下主流組合式 API 開發(fā)起來(lái)更清爽。項(xiàng)目初始化用 Vite配代理解決接口跨域問題// vite.config.js export default defineConfig({ plugins: [vue()], server: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })頁(yè)面大概需要這些用戶端登錄注冊(cè)頁(yè)、首頁(yè)店鋪列表/輪播、菜單頁(yè)分類菜品列表、購(gòu)物車頁(yè)、訂單結(jié)算頁(yè)、支付頁(yè)、訂單列表頁(yè)、訂單詳情頁(yè)、個(gè)人中心頁(yè)。商家端工作臺(tái)新訂單提醒、菜品管理頁(yè)表格彈窗編輯、訂單管理頁(yè)、營(yíng)業(yè)統(tǒng)計(jì)頁(yè)。管理端用戶列表頁(yè)、商家審核頁(yè)、菜品分類頁(yè)、訂單總覽頁(yè)。路由配置里要注意權(quán)限控制前端路由守衛(wèi)根據(jù)本地存儲(chǔ)的 token 和角色做基礎(chǔ)的頁(yè)面跳轉(zhuǎn)攔截。后端接口的權(quán)限校驗(yàn)才是真正的安全防線前端攔截只是優(yōu)化體驗(yàn)。5.2 接口返回格式統(tǒng)一前端聯(lián)調(diào)不吵架的關(guān)鍵接口格式統(tǒng)一是開發(fā)效率的關(guān)鍵。我習(xí)慣用統(tǒng)一的響應(yīng)結(jié)構(gòu){ code: 200, message: success, data: {} }用全局異常處理器把業(yè)務(wù)異常轉(zhuǎn)成標(biāo)準(zhǔn)格式。定義好公共返回對(duì)象之后前端可以封裝統(tǒng)一的 axios 攔截器code 非 200 時(shí)直接彈出錯(cuò)誤提示不用每個(gè)接口單獨(dú)處理錯(cuò)誤邏輯。5.3 分頁(yè)查詢與搜索交互列表頁(yè)性能優(yōu)化菜品列表和訂單列表離不開分頁(yè)。MyBatis-Plus 內(nèi)置分頁(yè)插件配置很簡(jiǎn)單Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }查詢訂單列表時(shí)建議只查主表字段不要關(guān)聯(lián)商家表和用戶表。需要展示商家名稱或用戶昵稱時(shí)一次性收集對(duì)應(yīng)的 id 再批量查或者直接在訂單表冗余一個(gè)商家名稱字段和用戶昵稱字段。冗余雖然聽起來(lái)不夠“范式規(guī)范”但在這種業(yè)務(wù)場(chǎng)景里減少聯(lián)查對(duì)查詢性能的提升是立竿見影的。6. 項(xiàng)目部署上線從本地跑通到校內(nèi)公網(wǎng)可訪問很多學(xué)生的項(xiàng)目最后都卡在部署環(huán)節(jié)代碼寫得再漂亮跑不起來(lái)等于零。Spring Boot 項(xiàng)目的部署方式特別多我推薦最樸素且最穩(wěn)定的方式打成 jar 包用 systemd 或 nohup 跑在服務(wù)器上配合 Nginx 做反向代理。6.1 環(huán)境準(zhǔn)備與打包構(gòu)建打包之前要先把 application.yml 里的數(shù)據(jù)庫(kù)地址改成生產(chǎn)環(huán)境的地址。用 Maven 打包執(zhí)行命令mvn clean package -DskipTests打包完成后target 目錄下會(huì)生成一個(gè)可執(zhí)行 jar 包。啟動(dòng)命令nohup java -jar campus-order-system.jar --spring.profiles.activeprod app.log 21 這里建議配置文件做多環(huán)境區(qū)分application-dev.yml 用于本地開發(fā)application-prod.yml 用于生產(chǎn)。如果數(shù)據(jù)庫(kù)地址、Redis 地址這些信息不想硬編碼在配置文件里可以加上環(huán)境變量引用用 ${DB_HOST} 這種占位符部署時(shí)通過 export 設(shè)置環(huán)境變量。6.2 Nginx 反向代理配置與前后端分離部署Nginx 在這里的核心作用有兩個(gè)一是靜態(tài)文件托管二是 API 反向代理。前端 Vue 項(xiàng)目打包成靜態(tài)文件后直接交給 Nginx 托管server { listen 80; server_name your-domain; # 前端靜態(tài)文件 root /var/www/campus-order-front; index index.html; location / { try_files $uri $uri/ /index.html; } # 后端 API 反向代理 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; } }注意 try_files 這行的作用。Vue Router 默認(rèn)用的是 History 模式刷新頁(yè)面時(shí) Nginx 會(huì)在文件系統(tǒng)里找對(duì)應(yīng)的路徑找不到就會(huì)返回 404所以必須讓所有未知路由都重寫到 index.html由前端路由接管。6.3 部署后的例行檢查與數(shù)據(jù)備份項(xiàng)目上線不是終點(diǎn)持續(xù)穩(wěn)定運(yùn)行才是目標(biāo)。建議定期做這幾件事每天凌晨自動(dòng)備份 MySQL 數(shù)據(jù)庫(kù)備份命令用 mysqldump 就好備份文件保留最近 7 天定期查看 app.log 和 Nginx 的 error.log排查后臺(tái)異常每周檢查一次磁盤空間防止日志文件把服務(wù)器空間占滿。給服務(wù)器配一個(gè)簡(jiǎn)單的定時(shí)任務(wù)比如每天凌晨 3 點(diǎn)執(zhí)行數(shù)據(jù)庫(kù)備份的 shell 腳本就能省下大量手工運(yùn)維的時(shí)間。7. 常見問題與排查技巧實(shí)錄這個(gè)系統(tǒng)開發(fā)過程中踩過的坑、幫人排查過的問題確保已經(jīng)記錄在案。下面這些情況你在做類似項(xiàng)目時(shí)大概率也會(huì)碰到提前給你打個(gè)預(yù)防針。7.1 接口報(bào) 500 錯(cuò)誤的排查思路All bills are looked up step by step先看后端的啟動(dòng)日志定位是哪一行代碼拋出異常。比如常見的數(shù)據(jù)庫(kù)連接失敗檢查 MySQL 服務(wù)是否啟動(dòng)用戶名密碼是否正確遠(yuǎn)程連接權(quán)限是否開啟。再比如 mybatis-plus 查詢時(shí)報(bào) invalid bound statement多半是 Mapper 接口和 XML 文件的命名空間不匹配。遇到這種錯(cuò)誤別慌先看控制臺(tái)最前面的幾行堆棧信息十有八九能定位到問題。7.2 前端請(qǐng)求跨域報(bào)錯(cuò)的解決記錄前后端分離開發(fā)時(shí)Vite 代理配置正確一般不會(huì)出現(xiàn)跨域問題。但如果后端直接暴露接口調(diào)試就會(huì)報(bào) Access-Control-Allow-Origin 錯(cuò)誤。解決辦法是后端加一個(gè) CORS 配置類Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(Registry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }這種方式只能用于開發(fā)環(huán)境上線后必須由 Nginx 反向代理接管關(guān)掉后端的跨域配置。注意 allowCredentials(true) 時(shí)allowedOriginPatterns 不能用 *否則某些瀏覽器版本下會(huì)直接拒絕響應(yīng)。7.3 應(yīng)用啟動(dòng)慢與內(nèi)存吃緊的問題排查Spring Boot 項(xiàng)目?jī)?nèi)嵌 Tomcat本身啟動(dòng)就比傳統(tǒng) Servlet 容器慢。如果服務(wù)器內(nèi)存只有 1G可以在啟動(dòng)命令里加上 JVM 參數(shù)限制內(nèi)存java -Xms256m -Xmx512m -jar campus-order-system.jar如果啟動(dòng)還是很慢檢查是不是把 Redis 的序列化器配置錯(cuò)了導(dǎo)致每個(gè)緩存對(duì)象序列化傳輸特別慢。Redis 的 key 和 value 序列化方式建議統(tǒng)一用 StringRedisSerializer 或 GenericJackson2JsonRedisSerializer避免默認(rèn) JDK 序列化產(chǎn)生亂七八糟的亂碼前綴。7.4 訂單狀態(tài)不一致問題排查點(diǎn)餐系統(tǒng)最常見的故障就是訂單狀態(tài)和數(shù)據(jù)對(duì)不上。排查第一步查 Redis 或數(shù)據(jù)庫(kù)中是否存在臟數(shù)據(jù)比如訂單狀態(tài)已顯示“已完成”但支付時(shí)間字段為空。第二步看回調(diào)接口有沒有做冪等性校驗(yàn)。第三步看前端有沒有做競(jìng)態(tài)處理。一個(gè)非常經(jīng)典的坑是用戶在支付成功后立刻刷新頁(yè)面前端用初始的訂單狀態(tài)把后端更新的新狀態(tài)覆蓋了。解決辦法是在前端路由跳轉(zhuǎn)后用最新接口刷新訂單狀態(tài)不要依賴本地緩存的狀態(tài)值。7.5 測(cè)試與驗(yàn)收課設(shè)答辯時(shí)怎么展示項(xiàng)目測(cè)試階段建議造一批真實(shí)的測(cè)試數(shù)據(jù)5 個(gè)商家、每個(gè)商家 20 個(gè)菜品、10 個(gè)測(cè)試學(xué)生賬號(hào)、50 條不同狀態(tài)的訂單。這樣演示的時(shí)候打開商家端能看到琳瑯滿目的菜品列表打開管理端能看到各種統(tǒng)計(jì)報(bào)表評(píng)委瀏覽體驗(yàn)會(huì)好很多。答辯時(shí)先展示項(xiàng)目結(jié)構(gòu)再演示核心流程重點(diǎn)演示用戶登錄 → 瀏覽商家 → 加購(gòu)物車 → 結(jié)算 → 支付 → 商家接單 → 出餐 → 完成訂單。整套流程走完整個(gè)系統(tǒng)的完整性就立住了。8. 經(jīng)驗(yàn)總結(jié)與后續(xù)擴(kuò)展方向這個(gè)系統(tǒng)我自己做下來(lái)最深的體會(huì)是把基礎(chǔ)功能做扎實(shí)遠(yuǎn)比堆砌花哨功能有價(jià)值。校園點(diǎn)餐系統(tǒng)的核心就在訂單狀態(tài)的準(zhǔn)確流轉(zhuǎn)、并發(fā)場(chǎng)景下的穩(wěn)定性、角色權(quán)限的清晰控制這三個(gè)點(diǎn)上把它們打磨透了項(xiàng)目就能拿得出手。技術(shù)擴(kuò)展上后續(xù)可以加的方向很多。比如接入導(dǎo)航地圖把餐品配送軌跡做出來(lái)引入 WebSocket讓商家新訂單提醒和用戶訂單狀態(tài)更新更加實(shí)時(shí)加一個(gè)用戶積分體系通過消費(fèi)次數(shù)發(fā)放優(yōu)惠券做一個(gè)小程序端學(xué)生從小程序直接下單使用體驗(yàn)比 H5 頁(yè)面更順暢。數(shù)據(jù)庫(kù)層面如果真的要支撐全校幾千人同時(shí)用可以考慮讀寫分離但這不是必須的先把單機(jī)性能優(yōu)化到極致再說。最后再分享一個(gè)小細(xì)節(jié)我在項(xiàng)目里通過 AOP 做了統(tǒng)一的操作日志記錄。任何一個(gè)管理員或者商家執(zhí)行了關(guān)鍵操作比如審核商家、上下架菜品、手動(dòng)改訂單狀態(tài)都會(huì)在日志表里留一條記錄。上線一段時(shí)間之后回頭看這些日志是排查問題、追溯責(zé)任的最好材料。很多新手項(xiàng)目不做這一塊等真正上線出了問題查半天都不知道是誰(shuí)在什么時(shí)候改了什么數(shù)據(jù)。這個(gè)習(xí)慣一定要從第一個(gè)項(xiàng)目就養(yǎng)成。寫到這里整個(gè)校園點(diǎn)餐系統(tǒng)從設(shè)計(jì)、編碼到部署、排查的完整鏈路已經(jīng)打通了。如果你正在開發(fā)同類項(xiàng)目希望能照著這個(gè)思路一步一步落地。代碼不在多關(guān)鍵業(yè)務(wù)鏈路寫穩(wěn)了你從中獲得的經(jīng)驗(yàn)比項(xiàng)目的“完成度”更有價(jià)值。