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