設(shè)計與實現(xiàn)——從需求到答辯全流程指南)
做畢設(shè)選“Java餐飲管理系統(tǒng)”的人一直不少這個題目幾乎每年都出現(xiàn)在各大高校的選題榜前幾名。原因很直白業(yè)務場景足夠貼近生活點餐、購物車、訂單、支付、報表這一整套流程和真實商業(yè)系統(tǒng)幾乎沒有差別但技術(shù)復雜度又剛好控制在本科生能駕馭的范圍內(nèi)。往淺了做用 JSPServlet 也能交出完整頁面往深了做SpringBoot、Redis、JWT、并發(fā)控制、事務一致性這些點全都塞得進去屬于典型的“下限低、上限高”題目。這篇文章我就用最近幫一個學弟完成“基于Java的餐廳運營與點餐服務平臺/Java驅(qū)動的智慧食堂數(shù)字化管理系統(tǒng)”的過程作為主線從需求分析、技術(shù)選型、表結(jié)構(gòu)設(shè)計、核心功能實現(xiàn)到真正開發(fā)時踩過的一堆坑再到答辯和求職面試怎么把這個項目講出亮點完整捋一遍。適合正在定題、想用 SpringBoot 把老題目重新包裝、或者想拿一個高完成度項目去找實習的同學參考。下面全是實操經(jīng)驗不繞彎子。1. 需求分析與模塊拆分先想清楚再做碼很多人拿到題目第一反應是打開 IDEA 直接建工程這是畢設(shè)翻車的第一大原因。餐飲管理系統(tǒng)表面上是“點餐”兩個字實際牽扯到角色權(quán)限、桌臺狀態(tài)、菜品上下架、訂單狀態(tài)流轉(zhuǎn)、庫存變動、財務統(tǒng)計任何一個環(huán)節(jié)想得不清楚后面寫代碼就是反復返工。我勸學弟先花一周時間把需求理成一張功能清單再談技術(shù)。1.1 用戶角色與業(yè)務場景我習慣把餐飲系統(tǒng)的使用者拆成三類每一類對應獨立的業(yè)務場景顧客端瀏覽菜品、按分類篩選、搜索、加入購物車、下單、模擬支付、查看歷史訂單、評價菜品。如果做的是掃碼點餐還需要考慮桌臺綁定。前臺/服務員端開臺、換臺、點菜、催菜、收銀結(jié)賬、訂單狀態(tài)更新。服務員是操作最頻繁的角色所有高頻操作都要控制在兩步以內(nèi)這個體驗原則也可以寫進答辯PPT里。管理員端菜品分類管理、菜品上下架、圖片上傳、庫存管理、員工賬號管理、會員管理、銷售報表查看。管理員關(guān)心的是經(jīng)營數(shù)據(jù)不是點餐細節(jié)。這里有個非常重要的取舍畢設(shè)不要輕易把“外賣配送”“多門店連鎖”“騎手調(diào)度”加進來因為那會把業(yè)務范圍撐得很大最后每一項都做得淺。我的建議是做“堂食自提”的輕量模式把點餐下單這條主鏈路做透再把并發(fā)扣庫存、訂單事務這兩個點做深答辯的時候反而更好講。這也正是“餐廳運營與點餐服務平臺”這個定位的精髓——核心是運營數(shù)據(jù)的閉環(huán)不是功能的堆砌。1.2 功能清單與工作量預估功能模塊具體內(nèi)容預計工作量優(yōu)先級用戶與權(quán)限用戶注冊登錄、JWT會話、后臺員工權(quán)限1-2天高菜品管理分類維護、菜品CRUD、圖片上傳、上下架2天高桌臺管理桌號維護、桌臺狀態(tài)流轉(zhuǎn)0.5天中購物車加購、改數(shù)量、刪除、清空、庫存預校驗1-2天高訂單模塊下單事務、訂單狀態(tài)機、模擬支付、退單3天高庫存管理菜品庫存、扣減、預警1天中會員積分積分累計、消費抵用1天低統(tǒng)計報表日/周銷售曲線、菜品銷量排行2天中系統(tǒng)輔助全局異常、日志、統(tǒng)一返回結(jié)構(gòu)1天高我估算工作量是按一個熟悉 SpringBoot 基本語法的大學生每天寫6小時算的。為什么購物車和訂單要預留那么多時間因為這兩個模塊涉及的數(shù)據(jù)狀態(tài)最多購物車要聯(lián)動庫存和菜品上下架狀態(tài)訂單要處理事務回滾和并發(fā)問題這些不是靠復制粘貼能快速搞定的。很多學弟喜歡在選題后直接找網(wǎng)上的老項目改但如果連功能清單都沒列清楚改了半個月還是不知道哪些代碼該刪、哪些該留。1.3 為什么不建議一上來就做微服務你們在技術(shù)選型時很容易被網(wǎng)上文章帶偏看到“高并發(fā)”“分布式”“微服務”就興奮。餐飲管理系統(tǒng)這種業(yè)務用戶量級就是一個小型食堂、一個小餐廳單體應用完全扛得住。微服務要拆分成服務注冊、配置中心、網(wǎng)關(guān)、鏈路追蹤一套下來光環(huán)境搭建就夠折騰兩星期最后查詢報表還要跨服務調(diào)用事務一致性更難保證。我的原則是畢設(shè)的技術(shù)難度要匹配業(yè)務復雜度把單體寫扎實比硬上微服務拿個半成品強得多。如果面試被問“為什么不用微服務”你就說“當前業(yè)務規(guī)模下單體架構(gòu)足夠過度設(shè)計會增加維護成本”這本身就是一種架構(gòu)思維的體現(xiàn)。2. 技術(shù)選型與項目骨架搭建SSM還是SpringBoot這一步直接決定后面開發(fā)的效率。我?guī)蛯W弟定下的技術(shù)棧是SpringBoot MyBatis-Plus MySQL Redis Vue。如果你對前端不太熟也可以把 Vue 換成 Thymeleaf 模板引擎服務端渲染代碼量更少答辯演示更穩(wěn)定。下面把選型理由說清楚這些都是面試時可以講的點。2.1 主流方案對比方案技術(shù)組合優(yōu)點缺點適用場景AJSP Servlet JDBC簡單直接專業(yè)課熟悉代碼冗余連接管理混亂難以擴展課程設(shè)計不建議畢設(shè)BSSM經(jīng)典框架組合分層清晰XML配置繁瑣整合門檻高想鞏固框架原理的同學CSpringBoot MyBatis-Plus配置少、開發(fā)快、生態(tài)成熟封裝太多原理要額外補當前最推薦的畢設(shè)方案DSpringBoot Redis MQ性能強、可講亮點學習成本高容易爛尾基礎(chǔ)很好的同學我給學弟選 C 方案理由有三條。第一SpringBoot 的自動配置把 SpringMVC、事務管理、JSON 轉(zhuǎn)換這些繁瑣配置全部簡化了能把精力集中在業(yè)務邏輯上。第二MyBatis-Plus 對單表 CRUD 做了極強的封裝BaseMapper 直接提供 insert、selectPage、updateById再也不用像 MyBatis 那樣為每個簡單查詢寫 XML。第三社區(qū)資料極多遇到問題搜一下就有答案適合畢設(shè)周期。前端用 Vue Element-UI后端只提供 JSON 接口這種前后端分離模式更貼近公司真實開發(fā)也便于講解“統(tǒng)一返回結(jié)構(gòu)”和“跨域處理”。如果怕環(huán)境配置麻煩用 Thymeleaf 也可以但沒有前后端分離那樣容易擴展成小程序端。2.2 工程結(jié)構(gòu)與分層思想項目包名我建議用 com.example.restaurant下面按職責分包看起目錄就懂架構(gòu)com.example.restaurant ├── config # 配置類跨域、MyBatis-Plus分頁、JWT攔截器 ├── controller # 接口層只做參數(shù)接收和結(jié)果返回 ├── service # 業(yè)務層業(yè)務規(guī)則、事務控制 │ └── impl ├── mapper # 數(shù)據(jù)訪問層繼承BaseMapper ├── entity # 數(shù)據(jù)庫實體 ├── dto # 入?yún)ο?├── vo # 出參對象 ├── common # 統(tǒng)一返回Result、常量、枚舉 └── exception # 自定義異常與全局異常處理器這個分層不是隨便分的每一層都有明確職責。Controller 層不要寫任何業(yè)務代碼它只做三件事接收參數(shù)、調(diào)用 Service、返回 Result。Service 層承載業(yè)務規(guī)則比如下單時要校驗庫存、生成訂單號、扣減庫存、清空購物車這些操作必須在一個事務方法里完成。Mapper 層就是數(shù)據(jù)庫操作MyBatis-Plus 讓單表操作幾乎不用寫 SQL。這樣分層帶來的好處是面試官問你“訂單模塊怎么設(shè)計的”你能清晰地講出數(shù)據(jù)走向 request → controller → service → mapper → DB而不是含糊地說“就寫在那個類里了”。統(tǒng)一返回結(jié)構(gòu)是我要求學弟必須做的一件事。定義一個 ResultT包含 code、msg、data 三個字段所有接口都返回這個對象。這樣做的好處有三個前端處理邏輯統(tǒng)一不必為每個接口單獨判斷數(shù)據(jù)結(jié)構(gòu)全局異常處理器可以把異常統(tǒng)一包裝成 Result 返回前端不會突然收到一堆看不懂的報錯答辯時講接口設(shè)計規(guī)范也有話說。2.3 編碼環(huán)境與JDK版本問題環(huán)境這塊我多說幾句因為每年都有人卡在第一步。JDK 我推薦用 8 或 11不是越新越好而是很多老項目、教學視頻都是基于 JDK8 寫的你遇到問題去搜答案匹配度最高。如果你機器上裝了 JDK17一定要檢查 IDEA 的 Project Structure 里 Project SDK 和 Maven 的 Java Compiler 版本是不是一致否則就會出現(xiàn)“警告: 源發(fā)行版 17 需要目標發(fā)行版 17”這類編譯錯誤這個我后面在坑里細說。環(huán)境變量配置也是新手常踩的點。安裝 JDK 后要配置 JAVA_HOME 和 PATHIDEA 內(nèi)部其實可以自動識別但如果你在命令行里 mvn 打包環(huán)境變量配不對就會報“mvn不是內(nèi)部或外部命令”。最穩(wěn)的辦法是在命令行執(zhí)行 java -version 和 mvn -version確認版本一致再繼續(xù)。我不建議在 CLASSPATH 上花太多心思現(xiàn)代 Java 開發(fā)很少手動配 CLASSPATH把 JAVA_HOME 和 PATH 弄對就夠用了。3. 數(shù)據(jù)庫設(shè)計與核心表結(jié)構(gòu)表設(shè)計決定系統(tǒng)上限很多畢設(shè)項目死在第二階段代碼寫了一堆數(shù)據(jù)庫就三四張表點餐記錄和菜品信息全塞在一起查個銷量報表要嵌套三層子查詢。數(shù)據(jù)庫是系統(tǒng)的地基表設(shè)計不合理后面每個功能都會變扭。我用了一晚上幫學弟把表結(jié)構(gòu)重新梳理了一遍下面直接說核心。3.1 核心表清單與字段設(shè)計表名用途關(guān)鍵字段sys_user后臺管理員/員工id, username, password, real_name, roleuserC端顧客id, openid, nickname, phone, pointscategory菜品分類id, name, sort, statusdish菜品id, category_id, name, price, image, description, stock, version, statustable_info桌臺id, table_no, capacity, statuscart購物車id, user_id, dish_id, quantity, checkedorders訂單主表id, order_no, user_id, table_id, total_amount, pay_amount, status, pay_status, create_timeorder_detail訂單明細id, order_id, dish_id, dish_name, price, quantity, subtotalmember會員信息id, user_id, level, points, total_consumeoperation_log操作日志id, user_id, action, detail, create_time為什么需要這兩張訂單表因為訂單主表和訂單明細表是一對多關(guān)系。一張訂單里可能點了五個菜如果把菜品信息直接冗余在主表里改價格、統(tǒng)計銷量都會亂套。主表記錄訂單整體狀態(tài)和金額明細表記錄每一道菜的快照信息——注意這里存的是 dish_name 和 price 快照不是只存 dish_id。為什么因為菜品價格后來可能調(diào)整但歷史訂單必須保持當時的下單價格這是財務報表和退款糾紛的依據(jù)。3.2 關(guān)鍵字段的設(shè)計原因有幾個字段設(shè)計是必須要能講出道理的寫文檔和答辯都用得上。金額字段一律用 DECIMAL(10,2)不能使用 FLOAT/DOUBLE。這是經(jīng)典面試題“Java中浮點數(shù)精度丟失”的數(shù)據(jù)庫版本。FLOAT 是二進制浮點0.1 0.2 會得到 0.30000000000000004而金額計算差一分錢都是事故。DECIMAL 是定點數(shù)MySQL 內(nèi)部按字符串存儲計算精確。Java 側(cè)對應使用 BigDecimal不要用 Double 接收金額參數(shù)。狀態(tài)字段我用 TINYINT 加常量類而不是直接存中文。比如訂單狀態(tài) order_status0待支付、1已支付、2制作中、3已完成、4已取消、5退款中。用數(shù)字的好處是存儲空間小、查詢快、方便擴展狀態(tài)機但代碼里不能到處寫魔法數(shù)字必須定義 OrderStatus 常量類。這不僅是代碼規(guī)范問題也是面試官常問的“如何避免魔法值”。邏輯刪除字段 deleted 我基本每張表都加了。為什么不物理刪除因為餐飲系統(tǒng)的訂單、菜品、用戶數(shù)據(jù)都有統(tǒng)計價值物理刪了之后日報表、銷量排行都對不上。但邏輯刪會帶來一個坑如果菜品名有唯一索引刪除后再添加同名菜品會報唯一鍵沖突。解決辦法是把唯一索引改成 (name, deleted) 聯(lián)合索引或者干脆不設(shè)唯一索引、靠代碼判斷。這個細節(jié)我在第5章還會提到。version 樂觀鎖字段是給庫存表、訂單表用的。它的存在是為了應對兩個人同時下單搶最后一份菜的場景詳細原理見第4章。你可以在答辯時說“這個字段是我專門用來解決并發(fā)超賣問題的”這句話本身就是加分項。3.3 核心建表SQL參考下面給出三張核心表的建表 SQL其他表照著這個思路寫就行。注意字符集、存儲引擎和時間字段默認值。CREATE TABLE dish ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 菜品ID, category_id BIGINT NOT NULL COMMENT 分類ID, name VARCHAR(50) NOT NULL COMMENT 菜品名稱, price DECIMAL(10,2) NOT NULL COMMENT 單價, image VARCHAR(255) DEFAULT NULL COMMENT 圖片地址, stock INT NOT NULL DEFAULT 0 COMMENT 庫存, version INT NOT NULL DEFAULT 0 COMMENT 樂觀鎖版本號, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 邏輯刪除 0正常 1刪除, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT菜品表; CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 訂單號, user_id BIGINT DEFAULT NULL, table_id BIGINT DEFAULT NULL, total_amount DECIMAL(10,2) NOT NULL COMMENT 總金額, order_status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付..., pay_status TINYINT NOT NULL DEFAULT 0, pay_time DATETIME DEFAULT NULL, deleted TINYINT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT訂單主表; CREATE TABLE order_detail ( id BIGINT NOT NULL AUTO_INCREMENT, order_id BIGINT NOT NULL, dish_id BIGINT NOT NULL, dish_name VARCHAR(50) NOT NULL COMMENT 菜品快照名, price DECIMAL(10,2) NOT NULL COMMENT 下單時單價快照, quantity INT NOT NULL, subtotal DECIMAL(10,2) NOT NULL, PRIMARY KEY (id), KEY idx_order (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT訂單明細表;為什么 order_no 要單獨建唯一索引因為訂單號要面向用戶展示、客服查單必須保證全局唯一且高效率查詢。生成訂單號我用的是“yyyyMMddHHmmss 用戶ID后四位 隨機數(shù)”簡單可靠不需要引入雪花算法。雪花算法適合分布式系統(tǒng)生成全局唯一ID但單體 MySQL 下時間戳隨機數(shù)配合唯一索引已經(jīng)足夠。真要考慮高并發(fā)可以談“Snowflake”的原理但不一定非要寫進代碼。4. 核心功能模塊實現(xiàn)從點餐到報表的閉環(huán)技術(shù)棧和表結(jié)構(gòu)定了開發(fā)就按模塊推進。下面挑我最想讓讀者抄作業(yè)的四個核心環(huán)節(jié)展開分別是登錄認證、購物車與菜品、下單事務與防超賣、報表統(tǒng)計。這些代碼不是完整源碼但把核心邏輯寫透了你照著搭腳手架就能跑通。4.1 登錄認證與權(quán)限控制C 端用戶可以用簡單的手機號驗證碼也可以做微信授權(quán)登錄需要小程序。后臺員工用賬號密碼登錄。我這里采用 JWT 做前后端分離的會話管理不用 Session。為什么不用 Session因為 Session 依賴服務端內(nèi)存前后端分離部署時可能有多臺實例Session 同步麻煩JWT 是無狀態(tài)的token 本身攜帶用戶信息適合接口化開發(fā)。核心流程是用戶登錄成功后后端簽發(fā)一個 JWT token前端每次請求在 Header 里帶Authorization: Bearer token后端攔截器解析 token把 userId 和 role 放到 ThreadLocal 里供 Service 層取用。Component public class JwtInterceptor implements HandlerInterceptor { private final JwtUtil jwtUtil; public JwtInterceptor(JwtUtil jwtUtil) { this.jwtUtil jwtUtil; } Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登錄接口 if (request.getRequestURI().contains(/login)) { return true; } String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); if (jwtUtil.validateToken(token)) { Long userId jwtUtil.getUserId(token); String role jwtUtil.getRole(token); UserContext.set(userId, role); return true; } } response.setStatus(401); return false; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }注意兩個細節(jié)一是密碼絕對不能明文存數(shù)據(jù)庫我用 BCrypt 加密每次登錄把用戶輸入的密碼 BCrypt 哈希后和庫里比對即使數(shù)據(jù)庫泄露攻擊者也拿不到明文密碼。二是 ThreadLocal 用完必須清除否則 Tomcat 線程池復用線程會把上一個用戶的身份帶到下一次請求這是很嚴重的安全漏洞也是 Spring 源碼里 RequestContextHolder 也在做同樣事情的原因。4.2 菜品管理、購物車與分頁菜品列表是系統(tǒng)最常用的接口支撐菜單頁。用 MyBatis-Plus 的分頁插件非常省事Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }Service 里只需要public PageResultDishVO pageDish(DishQueryDTO dto) { LambdaQueryWrapperDish wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.hasText(dto.getCategory()), Dish::getCategoryId, dto.getCategory()) .eq(Dish::getStatus, 1) .eq(Dish::getDeleted, 0) .orderByDesc(Dish::getCreateTime); PageDish page dishMapper.selectPage(new Page(dto.getPageNum(), dto.getPageSize()), wrapper); // 轉(zhuǎn)VO返回分頁結(jié)果 }購物車我強烈建議做后端表而不是存前端 localStorage。后端表的好處換設(shè)備數(shù)據(jù)不丟、菜品庫存和上架狀態(tài)可以實時校驗、結(jié)賬時直接讀購物車表生成訂單更可靠。代價是每次改數(shù)量都要請求后端但并發(fā)量低完全不是問題。加購物車的一個核心校驗是如果菜品已經(jīng)下架或庫存為0要直接拋出業(yè)務異常不能把無效菜品加進購物車。這個判斷放在 Service 層而不是 Controller屬于“業(yè)務規(guī)則要下沉”。4.3 下單事務與庫存防超賣這是整個系統(tǒng)最核心、也是最值得在答辯時全力展開的模塊。用戶點完菜點“結(jié)賬”后端要做的事情包括校驗桌臺和購物車、生成訂單主表、批量生成訂單明細、扣減庫存、清空購物車、標記待支付。這五個操作必須是一個原子操作任何一個失敗都不能留下半截數(shù)據(jù)。實現(xiàn)方式就是 Transactional。Service public class OrderServiceImpl implements OrderService { Override Transactional(rollbackFor Exception.class) public OrderCreateVO createOrder(OrderCreateDTO dto) { // 1. 校驗桌臺狀態(tài) TableInfo table tableInfoMapper.selectById(dto.getTableId()); if (table null || !TableStatus.FREE.equals(table.getStatus())) { throw new BizException(桌臺不可用); } // 2. 查詢購物車列表 ListCart cartList cartMapper.selectList( new LambdaQueryWrapperCart().eq(Cart::getUserId, dto.getUserId())); if (cartList.isEmpty()) { throw new BizException(購物車為空); } // 3. 計算總金額同時校驗菜品狀態(tài)與庫存 BigDecimal totalAmount BigDecimal.ZERO; ListOrderDetail detailList new ArrayList(); for (Cart cart : cartList) { Dish dish dishMapper.selectById(cart.getDishId()); if (dish null || dish.getStatus() ! 1 || dish.getDeleted() ! 0) { throw new BizException(菜品不存在或已下架 cart.getDishId()); } // 樂觀鎖扣減庫存stock 數(shù)量才更新成功 int rows dishMapper.deductStock(cart.getDishId(), cart.getQuantity()); if (rows 0) { throw new BizException(菜品庫存不足 dish.getName()); } BigDecimal subtotal dish.getPrice().multiply(BigDecimal.valueOf(cart.getQuantity())); totalAmount totalAmount.add(subtotal); detailList.add(buildDetail(dish, cart.getQuantity(), subtotal)); } // 4. 生成訂單號并插入訂單主表 String orderNo OrderNoGenerator.generate(dto.getUserId()); Order order new Order(); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setTableId(dto.getTableId()); order.setTotalAmount(totalAmount); order.setOrderStatus(OrderStatus.UNPAID); orderMapper.insert(order); // 5. 批量插入明細 detailList.forEach(d - { d.setOrderId(order.getId()); orderDetailMapper.insert(d); }); // 6. 清空購物車 cartMapper.delete( new LambdaQueryWrapperCart().eq(Cart::getUserId, dto.getUserId())); return new OrderCreateVO(order.getId(), orderNo, totalAmount); } }對應 Mapper 里的樂觀鎖扣減 SQL 長這樣UPDATE dish SET stock stock - #{quantity}, version version 1 WHERE id #{dishId} AND stock #{quantity} AND status 1這個 SQL 妙在把條件放在 WHERE 里。如果庫存不足WHERE 匹配不到行影響行數(shù)為 0業(yè)務就能感知到并拋異常。如果兩個用戶同時搶最后一份菜數(shù)據(jù)庫的行鎖保證只有一個更新成功另一個影響行數(shù)為 0進入“庫存不足”分支。這種方案不需要 SELECT ... FOR UPDATE也不需要分布式鎖最適合單體項目。關(guān)于 Transactional 有幾個坑必須提醒事務默認只對 RuntimeException 回滾如果代碼里拋出的是檢查異常事務不會回滾所以我在注解里寫了 rollbackFor Exception.class。還有一個經(jīng)典失效場景是同類內(nèi)部調(diào)用比如 Controller 調(diào) Service 的 A 方法A 方法內(nèi)部又調(diào)同一個類的 B 方法B 上的 Transactional 不會生效因為 Spring 的事務是通過代理類實現(xiàn)的內(nèi)部調(diào)用走的是 this不是代理對象。解決辦法是把 B 拆到另一個 Service 類或者把事務邊界放在 A 方法上。4.4 報表統(tǒng)計與分析報表模塊是餐飲系統(tǒng)的門面也是很多老師愛看的功能。我用 ECharts 做前端展示后端只需要提供兩個核心接口按日銷售額統(tǒng)計、菜品銷量排行。按日銷售額統(tǒng)計的核心 SQLSELECT DATE(create_time) AS day, SUM(total_amount) AS amount FROM orders WHERE order_status 3 AND create_time DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE(create_time) ORDER BY day菜品銷量排行SELECT d.id, d.name, SUM(od.quantity) AS total_sales FROM order_detail od LEFT JOIN dish d ON od.dish_id d.id LEFT JOIN orders o ON od.order_id o.id WHERE o.order_status 3 GROUP BY d.id, d.name ORDER BY total_sales DESC LIMIT 10只統(tǒng)計已完成訂單order_status3因為待支付訂單還沒有產(chǎn)生實際收入。這個過濾條件是學弟容易漏掉的漏掉之后報表數(shù)字會虛高。查詢量上來之后記得在 create_time、order_status 上建聯(lián)合索引否則全表掃描會把數(shù)據(jù)庫拖慢。報表這類接口讀多寫少如果以后數(shù)據(jù)量大可以把統(tǒng)計結(jié)果用定時任務匯總到一張報表表中或者加 Redis 緩存當日數(shù)據(jù)但畢設(shè)階段做好 SQL 就夠了。5. 開發(fā)中常見的坑與解決實錄把這些寫進項目總結(jié)里這部分全是真金白銀。學弟在開發(fā)過程里踩過的坑我?guī)缀醵寂闼挪榱艘槐橄旅嫣糇钣写硇缘奈鍌€寫出來每個都可以直接抄進項目文檔的“疑難問題”章節(jié)。5.1 BigDecimal、日期與JSON序列化問題第一個坑后端返回的金額 BigDecimal 傳到前端有時會變成長長的科學計數(shù)法或者直接丟精度。根因是 Jackson 默認把 BigDecimal 序列化為數(shù)字較大的小數(shù)可能被轉(zhuǎn)成科學計數(shù)法。解決辦法是全局配置 BigDecimal 的序列化器讓它輸出字符串Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder - { builder.serializerByType(BigDecimal.class, ToStringSerializer.instance); builder.serializerByType(LocalDateTime.class, new LocalDateTimeSerializer( DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); }; }第二個坑LocalDateTime 默認序列化成數(shù)組格式[2025,1,1,12,0,0]前端根本沒法用。所以要單獨定義 LocalDateTime 的序列化器和反序列化器統(tǒng)一日期格式。這些配置看起來小但直接影響前端聯(lián)調(diào)效率建議項目第一天就配上。5.2 并發(fā)超賣與事務失效的排查測試庫存防超賣時我用 JMeter 開 20 個線程同時點最后一份菜結(jié)果發(fā)現(xiàn)庫存變成負數(shù)了。排查過程很有代表性先檢查 SQL發(fā)現(xiàn) UPDATE 語句沒有加 stock #{quantity} 條件等于無條件扣減修好后再測數(shù)據(jù)庫層面正常了。之后又發(fā)現(xiàn)一個問題扣庫存和插入訂單明細不在同一個事務里扣庫存成功、插入明細失敗時庫存被白白扣掉。解決方式就是上面第4章那套把所有寫操作包在同一個事務方法里并且扣減失敗要拋 RuntimeException 觸發(fā)回滾。如果你在答辯時被問到“怎么保證數(shù)據(jù)一致性”不要只背 ACID要結(jié)合這個項目講我用事務保證訂單明細和庫存操作的原子性用樂觀鎖防止庫存超賣用數(shù)據(jù)庫唯一索引保證訂單號不重復。這一套組合拳講下來比干巴巴背“原子性一致性隔離性持久性”有力得多。5.3 數(shù)據(jù)庫亂碼、時區(qū)與連接池問題學弟第一次啟動項目數(shù)據(jù)庫中文全部亂碼排查半天發(fā)現(xiàn)是連接 URL 少了編碼參數(shù)?，F(xiàn)在 MySQL 8 的全套連接參數(shù)建議這樣寫jdbc:mysql://localhost:3306/restaurant?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltruecharacterEncodingutf8 控制中文不亂碼serverTimezone 解決數(shù)據(jù)庫和服務器時區(qū)不對導致的 8 小時時間差。allowPublicKeyRetrievaltrue 是 MySQL 8 用 caching_sha2_password 認證時需要的參數(shù)。這些參數(shù)在答辯時不用講得太深但能解決啟動失敗問題。如果啟動時報HikariPool-1 - Exception during pool initialization先檢查 MySQL 服務有沒有啟動、賬號密碼是否正確、驅(qū)動依賴版本是否匹配。最常見的是 pom 里引入了 MySQL 5 的驅(qū)動而連接的是 MySQL 8或者反過來驅(qū)動版本和數(shù)據(jù)庫版本不匹配。5.4 Maven編譯版本不匹配與Java環(huán)境變量熱詞里那條“java: 警告: 源發(fā)行版 17 需要目標發(fā)行版 17”我太熟悉了。這種報錯的本質(zhì)是 IDEA 的 Project SDK 是 JDK17但 Maven 的 compiler 插件還按 JDK8 編譯或者 Maven 用的 JDK 和 Project SDK 版本不一致。最簡單粗暴的解決辦法是在 pom.xml 里顯式指定編譯版本properties maven.compiler.source11/maven.compiler.source maven.compiler.target11/maven.compiler.target /properties如果是在命令行打包還要保證java -version和mvn -version指向同一個 JDK。很多同學電腦里既裝了 JRE 又裝了多個 JDK環(huán)境變量 PATH 指到舊的 JRE命令行和 IDEA 里看到的版本不一樣就會出現(xiàn)各種詭異問題。這也是我反復強調(diào)“統(tǒng)一 JDK 版本”的原因。5.5 跨域、404與打包部署問題前后端分離項目聯(lián)調(diào)時第一個報錯就是跨域。我在后端寫一個 WebMvcConfigurer 配置類允許本機前端地址訪問并放行 OPTIONS 預檢請求。否則前端瀏覽器發(fā)出預檢請求會被攔截器當成正常請求攔截導致“CORS 請求未通過”的詭異報錯。如果前端用 Vue Router 的 history 模式部署上線后刷新頁面會 404因為 nginx 找不到對應的靜態(tài)資源路徑。解決辦法是 nginx 里配置 try_files 把所有路由回退到 index.html或者干脆改用 hash 模式URL 會帶個 #不美觀但省心。畢設(shè)演示一般用 hash 模式就夠了因為我吃過 history 模式的虧現(xiàn)場演示時刷新就白屏很尷尬。打包部署我推薦 SpringBoot 的可執(zhí)行 jar用mvn clean package打出來服務器上java -jar restaurant.jar一條命令啟動。數(shù)據(jù)庫腳本作為 init.sql 保存服務器上手動執(zhí)行一次。端口的話8080 很容易被占用啟動失敗時就netstat -ano | findstr 8080查占用進程。6. 畢設(shè)答辯與面試怎么講這個項目讓代碼變成你的加分項項目寫完只是完成了一半另一半是讓別人看到它的價值。我?guī)W弟準備了答題思路和面試問題梳理發(fā)現(xiàn)只要把項目里的幾個核心決策講透面試官就不會揪著八股文窮追猛打。這一章直接給可復用的素材。6.1 五分鐘演示腳本與項目亮點整理演示順序建議固定登錄系統(tǒng) → 管理員維護菜品 → 顧客掃碼點餐 → 加購物車 → 下單 → 模擬支付 → 查看訂單狀態(tài) → 后臺看銷售報表。整個過程控制在五分鐘內(nèi)重點是下單和支付環(huán)節(jié)因為這里有事務回滾和狀態(tài)流轉(zhuǎn)最能體現(xiàn)業(yè)務完整性。講解項目時用 STAR 法則背景是學校食堂需要一套數(shù)字化點餐系統(tǒng)你的角色是獨立完成前后端開發(fā)和數(shù)據(jù)庫設(shè)計難點是并發(fā)減庫存、訂單狀態(tài)一致性、報表統(tǒng)計方案是事務樂觀鎖統(tǒng)一狀態(tài)機結(jié)果是系統(tǒng)可以穩(wěn)定支撐日訂單數(shù)百單模擬量。這樣講面試官立刻就能抓住重點。被問“項目最大的亮點是什么”時不要回答“我用了SpringBoot、Redis”這種技術(shù)名詞堆砌。我建議的答案是“細節(jié)上我設(shè)計了訂單主表和明細表隔離、菜品金額快照機制保證歷史訂單財務數(shù)據(jù)準確并發(fā)上我用數(shù)據(jù)庫樂觀鎖解決了超賣問題工程上我做了全局異常處理和統(tǒng)一返回結(jié)構(gòu)前后端聯(lián)調(diào)效率很高?！边@三個點既有業(yè)務思考又有技術(shù)深度比單純背框架名強得多。6.2 高頻Java面試題與項目的掛鉤方式很多同學背了一堆八股文面試時卻不會結(jié)合項目講。我整理了五類高頻題目和對應的話術(shù)。面向?qū)ο笕匦栽陧椖恐械捏w現(xiàn)。封裝用戶、訂單、菜品都封裝成實體類外部只能通過 Service 方法訪問繼承基礎(chǔ)實體 BaseEntity 包含 id、createTime、updateTime所有實體繼承它多態(tài)支付方式設(shè)計成 PayStrategy 接口微信支付、余額支付各自實現(xiàn)下單時根據(jù)支付類型動態(tài)調(diào)用。這樣答完面試官就相信你真的在項目里用過面向?qū)ο蠖皇侵粫瑢懚x。HashMap 與數(shù)據(jù)結(jié)構(gòu)題。可以結(jié)合項目里“菜單熱點數(shù)據(jù)緩存”來說我說過不用 HashMap 做全局緩存因為它是線程不安全的并發(fā)讀寫會丟數(shù)據(jù)單機可以用 ConcurrentHashMap生產(chǎn)環(huán)境更適合 Caffeine。如果被追問 HashMap 底層原理就講數(shù)組鏈表/紅黑樹、put 流程、擴容機制、為什么 HashMap 非線程安全。這個題幾乎是 Java 面試必問一定要準備。String、StringBuilder、StringBuffer 的區(qū)別。結(jié)合項目訂單明細數(shù)量多時批量拼接 SQL 或日志千萬不能在循環(huán)里用String 因為 String 不可變每次拼接都創(chuàng)建新對象O(n2) 性能問題。用 StringBuilder 做局部字符串拼接StringBuffer 因為方法加了 synchronized不需要多線程拼接時沒必要用它。這題簡單但答得接地氣反而加分。如何保證數(shù)據(jù)一致性。這個題我用項目里的下單流程完整回答步驟是校驗庫存、生成訂單、扣庫存、清購物車全部包在同一個事務里任何一個步驟失敗整體回滾庫存扣減用樂觀鎖條件更新防止超賣訂單號用唯一索引兜底。然后再補一句“如果以后拆微服務訂單和庫存分庫就需要引入分布式事務方案比如 Seata 或者本地消息表”這句話證明你有架構(gòu)視野但當前項目規(guī)模單體事務足夠。排序算法題。菜品銷量排序用到過 Collections.sort 配合 Comparator 對 ListDishSalesVO 按銷量排序面試如果讓你手寫至少能寫出冒泡和快排。冒泡排序雖然不高效但容易講清楚快排的核心是選定 pivot 分區(qū)遞歸。我建議項目答辯前把這兩個排序的代碼過一遍因為“java排序”是高頻搜索詞很容易被問到。Java 基礎(chǔ)與學習路線的建議。如果面試官問“Java學習怎么規(guī)劃”你可以說先搞清數(shù)據(jù)類型、集合、面向?qū)ο笕缓髮W并發(fā)和 JVM接著上手 SpringBoot最后通過餐飲系統(tǒng)這個項目把知識串起來。這個回答既展示技術(shù)深度也讓對方看到你有明確的學習路徑。6.3 功能擴展思路項目做完之后學弟問我還能加什么。我給的擴展方向按投入產(chǎn)出比排序第一接入支付寶沙箱支付體驗真實支付回調(diào)流程支付回調(diào)的冪等性又是一個亮點第二增加優(yōu)惠券模塊涉及滿減規(guī)則、有效期、庫存擴展業(yè)務廣度第三基于歷史訂單做“猜你喜歡”最簡單的實現(xiàn)是用關(guān)聯(lián)規(guī)則或者協(xié)同過濾的 ItemCF講起來很高端第四如果非要往架構(gòu)方向談可以把訂單服務和庫存服務拆開用 Redis 中間件解耦但我不建議在畢設(shè)階段真的做。這些擴展點不一定要全部實現(xiàn)哪怕只實現(xiàn)一個支付沙箱項目完成度和面試談資都會提升一大截。關(guān)鍵在于每個擴展都能對應到一個明確的技術(shù)問題支付回調(diào)怎么保證冪等優(yōu)惠券超發(fā)怎么防止推薦算法怎么冷啟動帶著問題去實現(xiàn)比瞎加功能有用得多。最后說點個人體會。這個項目從我接手幫學弟到最后跑通前后大概四周投入最大的是表結(jié)構(gòu)設(shè)計和下單事務那一塊。學弟后來拿著這個項目去面試暑期實習面試官問到“怎么解決超賣”時他把 optimistic lock 和事務回滾講得清清楚楚當場就被夸“項目思路很完整”。我覺得畢設(shè)項目的價值從來不在技術(shù)多新而在于每個設(shè)計點你都能講出“為什么”。你在文檔里把表字段為什么用 DECIMAL、訂單為什么要主表明細分離、狀態(tài)為什么用常量類、扣庫存為什么要帶條件更新寫清楚答辯老師想不給高分都難。再分享一個小技巧寫項目文檔時專門留一個“設(shè)計決策記錄”章節(jié)每做一個關(guān)鍵選擇就把當時考慮的兩三個備選方案和最終理由記下來。比如“購物車為什么用后端表而不是localStorage”記錄完你就會發(fā)現(xiàn)自己的項目比那些只說“我實現(xiàn)了什么功能”的同學高出一個檔次。如果時間緊張優(yōu)先把下單、支付、報表這條主鏈路跑得毫無破綻再去加其他花活這是我最想提醒各位的一句話。 基于SpringBoot的餐飲管理系統(tǒng)設(shè)計與實現(xiàn)——從需求到答辯全流程指南
做畢設(shè)選“Java餐飲管理系統(tǒng)”的人一直不少這個題目幾乎每年都出現(xiàn)在各大高校的選題榜前幾名。原因很直白業(yè)務場景足夠貼近生活點餐、購物車、訂單、支付、報表這一整套流程和真實商業(yè)系統(tǒng)幾乎沒有差別但技術(shù)復雜度又剛好控制在本科生能駕馭的范圍內(nèi)。往淺了做用 JSPServlet 也能交出完整頁面往深了做SpringBoot、Redis、JWT、并發(fā)控制、事務一致性這些點全都塞得進去屬于典型的“下限低、上限高”題目。這篇文章我就用最近幫一個學弟完成“基于Java的餐廳運營與點餐服務平臺/Java驅(qū)動的智慧食堂數(shù)字化管理系統(tǒng)”的過程作為主線從需求分析、技術(shù)選型、表結(jié)構(gòu)設(shè)計、核心功能實現(xiàn)到真正開發(fā)時踩過的一堆坑再到答辯和求職面試怎么把這個項目講出亮點完整捋一遍。適合正在定題、想用 SpringBoot 把老題目重新包裝、或者想拿一個高完成度項目去找實習的同學參考。下面全是實操經(jīng)驗不繞彎子。1. 需求分析與模塊拆分先想清楚再做碼很多人拿到題目第一反應是打開 IDEA 直接建工程這是畢設(shè)翻車的第一大原因。餐飲管理系統(tǒng)表面上是“點餐”兩個字實際牽扯到角色權(quán)限、桌臺狀態(tài)、菜品上下架、訂單狀態(tài)流轉(zhuǎn)、庫存變動、財務統(tǒng)計任何一個環(huán)節(jié)想得不清楚后面寫代碼就是反復返工。我勸學弟先花一周時間把需求理成一張功能清單再談技術(shù)。1.1 用戶角色與業(yè)務場景我習慣把餐飲系統(tǒng)的使用者拆成三類每一類對應獨立的業(yè)務場景顧客端瀏覽菜品、按分類篩選、搜索、加入購物車、下單、模擬支付、查看歷史訂單、評價菜品。如果做的是掃碼點餐還需要考慮桌臺綁定。前臺/服務員端開臺、換臺、點菜、催菜、收銀結(jié)賬、訂單狀態(tài)更新。服務員是操作最頻繁的角色所有高頻操作都要控制在兩步以內(nèi)這個體驗原則也可以寫進答辯PPT里。管理員端菜品分類管理、菜品上下架、圖片上傳、庫存管理、員工賬號管理、會員管理、銷售報表查看。管理員關(guān)心的是經(jīng)營數(shù)據(jù)不是點餐細節(jié)。這里有個非常重要的取舍畢設(shè)不要輕易把“外賣配送”“多門店連鎖”“騎手調(diào)度”加進來因為那會把業(yè)務范圍撐得很大最后每一項都做得淺。我的建議是做“堂食自提”的輕量模式把點餐下單這條主鏈路做透再把并發(fā)扣庫存、訂單事務這兩個點做深答辯的時候反而更好講。這也正是“餐廳運營與點餐服務平臺”這個定位的精髓——核心是運營數(shù)據(jù)的閉環(huán)不是功能的堆砌。1.2 功能清單與工作量預估功能模塊具體內(nèi)容預計工作量優(yōu)先級用戶與權(quán)限用戶注冊登錄、JWT會話、后臺員工權(quán)限1-2天高菜品管理分類維護、菜品CRUD、圖片上傳、上下架2天高桌臺管理桌號維護、桌臺狀態(tài)流轉(zhuǎn)0.5天中購物車加購、改數(shù)量、刪除、清空、庫存預校驗1-2天高訂單模塊下單事務、訂單狀態(tài)機、模擬支付、退單3天高庫存管理菜品庫存、扣減、預警1天中會員積分積分累計、消費抵用1天低統(tǒng)計報表日/周銷售曲線、菜品銷量排行2天中系統(tǒng)輔助全局異常、日志、統(tǒng)一返回結(jié)構(gòu)1天高我估算工作量是按一個熟悉 SpringBoot 基本語法的大學生每天寫6小時算的。為什么購物車和訂單要預留那么多時間因為這兩個模塊涉及的數(shù)據(jù)狀態(tài)最多購物車要聯(lián)動庫存和菜品上下架狀態(tài)訂單要處理事務回滾和并發(fā)問題這些不是靠復制粘貼能快速搞定的。很多學弟喜歡在選題后直接找網(wǎng)上的老項目改但如果連功能清單都沒列清楚改了半個月還是不知道哪些代碼該刪、哪些該留。1.3 為什么不建議一上來就做微服務你們在技術(shù)選型時很容易被網(wǎng)上文章帶偏看到“高并發(fā)”“分布式”“微服務”就興奮。餐飲管理系統(tǒng)這種業(yè)務用戶量級就是一個小型食堂、一個小餐廳單體應用完全扛得住。微服務要拆分成服務注冊、配置中心、網(wǎng)關(guān)、鏈路追蹤一套下來光環(huán)境搭建就夠折騰兩星期最后查詢報表還要跨服務調(diào)用事務一致性更難保證。我的原則是畢設(shè)的技術(shù)難度要匹配業(yè)務復雜度把單體寫扎實比硬上微服務拿個半成品強得多。如果面試被問“為什么不用微服務”你就說“當前業(yè)務規(guī)模下單體架構(gòu)足夠過度設(shè)計會增加維護成本”這本身就是一種架構(gòu)思維的體現(xiàn)。2. 技術(shù)選型與項目骨架搭建SSM還是SpringBoot這一步直接決定后面開發(fā)的效率。我?guī)蛯W弟定下的技術(shù)棧是SpringBoot MyBatis-Plus MySQL Redis Vue。如果你對前端不太熟也可以把 Vue 換成 Thymeleaf 模板引擎服務端渲染代碼量更少答辯演示更穩(wěn)定。下面把選型理由說清楚這些都是面試時可以講的點。2.1 主流方案對比方案技術(shù)組合優(yōu)點缺點適用場景AJSP Servlet JDBC簡單直接專業(yè)課熟悉代碼冗余連接管理混亂難以擴展課程設(shè)計不建議畢設(shè)BSSM經(jīng)典框架組合分層清晰XML配置繁瑣整合門檻高想鞏固框架原理的同學CSpringBoot MyBatis-Plus配置少、開發(fā)快、生態(tài)成熟封裝太多原理要額外補當前最推薦的畢設(shè)方案DSpringBoot Redis MQ性能強、可講亮點學習成本高容易爛尾基礎(chǔ)很好的同學我給學弟選 C 方案理由有三條。第一SpringBoot 的自動配置把 SpringMVC、事務管理、JSON 轉(zhuǎn)換這些繁瑣配置全部簡化了能把精力集中在業(yè)務邏輯上。第二MyBatis-Plus 對單表 CRUD 做了極強的封裝BaseMapper 直接提供 insert、selectPage、updateById再也不用像 MyBatis 那樣為每個簡單查詢寫 XML。第三社區(qū)資料極多遇到問題搜一下就有答案適合畢設(shè)周期。前端用 Vue Element-UI后端只提供 JSON 接口這種前后端分離模式更貼近公司真實開發(fā)也便于講解“統(tǒng)一返回結(jié)構(gòu)”和“跨域處理”。如果怕環(huán)境配置麻煩用 Thymeleaf 也可以但沒有前后端分離那樣容易擴展成小程序端。2.2 工程結(jié)構(gòu)與分層思想項目包名我建議用 com.example.restaurant下面按職責分包看起目錄就懂架構(gòu)com.example.restaurant ├── config # 配置類跨域、MyBatis-Plus分頁、JWT攔截器 ├── controller # 接口層只做參數(shù)接收和結(jié)果返回 ├── service # 業(yè)務層業(yè)務規(guī)則、事務控制 │ └── impl ├── mapper # 數(shù)據(jù)訪問層繼承BaseMapper ├── entity # 數(shù)據(jù)庫實體 ├── dto # 入?yún)ο?├── vo # 出參對象 ├── common # 統(tǒng)一返回Result、常量、枚舉 └── exception # 自定義異常與全局異常處理器這個分層不是隨便分的每一層都有明確職責。Controller 層不要寫任何業(yè)務代碼它只做三件事接收參數(shù)、調(diào)用 Service、返回 Result。Service 層承載業(yè)務規(guī)則比如下單時要校驗庫存、生成訂單號、扣減庫存、清空購物車這些操作必須在一個事務方法里完成。Mapper 層就是數(shù)據(jù)庫操作MyBatis-Plus 讓單表操作幾乎不用寫 SQL。這樣分層帶來的好處是面試官問你“訂單模塊怎么設(shè)計的”你能清晰地講出數(shù)據(jù)走向 request → controller → service → mapper → DB而不是含糊地說“就寫在那個類里了”。統(tǒng)一返回結(jié)構(gòu)是我要求學弟必須做的一件事。定義一個 ResultT包含 code、msg、data 三個字段所有接口都返回這個對象。這樣做的好處有三個前端處理邏輯統(tǒng)一不必為每個接口單獨判斷數(shù)據(jù)結(jié)構(gòu)全局異常處理器可以把異常統(tǒng)一包裝成 Result 返回前端不會突然收到一堆看不懂的報錯答辯時講接口設(shè)計規(guī)范也有話說。2.3 編碼環(huán)境與JDK版本問題環(huán)境這塊我多說幾句因為每年都有人卡在第一步。JDK 我推薦用 8 或 11不是越新越好而是很多老項目、教學視頻都是基于 JDK8 寫的你遇到問題去搜答案匹配度最高。如果你機器上裝了 JDK17一定要檢查 IDEA 的 Project Structure 里 Project SDK 和 Maven 的 Java Compiler 版本是不是一致否則就會出現(xiàn)“警告: 源發(fā)行版 17 需要目標發(fā)行版 17”這類編譯錯誤這個我后面在坑里細說。環(huán)境變量配置也是新手常踩的點。安裝 JDK 后要配置 JAVA_HOME 和 PATHIDEA 內(nèi)部其實可以自動識別但如果你在命令行里 mvn 打包環(huán)境變量配不對就會報“mvn不是內(nèi)部或外部命令”。最穩(wěn)的辦法是在命令行執(zhí)行 java -version 和 mvn -version確認版本一致再繼續(xù)。我不建議在 CLASSPATH 上花太多心思現(xiàn)代 Java 開發(fā)很少手動配 CLASSPATH把 JAVA_HOME 和 PATH 弄對就夠用了。3. 數(shù)據(jù)庫設(shè)計與核心表結(jié)構(gòu)表設(shè)計決定系統(tǒng)上限很多畢設(shè)項目死在第二階段代碼寫了一堆數(shù)據(jù)庫就三四張表點餐記錄和菜品信息全塞在一起查個銷量報表要嵌套三層子查詢。數(shù)據(jù)庫是系統(tǒng)的地基表設(shè)計不合理后面每個功能都會變扭。我用了一晚上幫學弟把表結(jié)構(gòu)重新梳理了一遍下面直接說核心。3.1 核心表清單與字段設(shè)計表名用途關(guān)鍵字段sys_user后臺管理員/員工id, username, password, real_name, roleuserC端顧客id, openid, nickname, phone, pointscategory菜品分類id, name, sort, statusdish菜品id, category_id, name, price, image, description, stock, version, statustable_info桌臺id, table_no, capacity, statuscart購物車id, user_id, dish_id, quantity, checkedorders訂單主表id, order_no, user_id, table_id, total_amount, pay_amount, status, pay_status, create_timeorder_detail訂單明細id, order_id, dish_id, dish_name, price, quantity, subtotalmember會員信息id, user_id, level, points, total_consumeoperation_log操作日志id, user_id, action, detail, create_time為什么需要這兩張訂單表因為訂單主表和訂單明細表是一對多關(guān)系。一張訂單里可能點了五個菜如果把菜品信息直接冗余在主表里改價格、統(tǒng)計銷量都會亂套。主表記錄訂單整體狀態(tài)和金額明細表記錄每一道菜的快照信息——注意這里存的是 dish_name 和 price 快照不是只存 dish_id。為什么因為菜品價格后來可能調(diào)整但歷史訂單必須保持當時的下單價格這是財務報表和退款糾紛的依據(jù)。3.2 關(guān)鍵字段的設(shè)計原因有幾個字段設(shè)計是必須要能講出道理的寫文檔和答辯都用得上。金額字段一律用 DECIMAL(10,2)不能使用 FLOAT/DOUBLE。這是經(jīng)典面試題“Java中浮點數(shù)精度丟失”的數(shù)據(jù)庫版本。FLOAT 是二進制浮點0.1 0.2 會得到 0.30000000000000004而金額計算差一分錢都是事故。DECIMAL 是定點數(shù)MySQL 內(nèi)部按字符串存儲計算精確。Java 側(cè)對應使用 BigDecimal不要用 Double 接收金額參數(shù)。狀態(tài)字段我用 TINYINT 加常量類而不是直接存中文。比如訂單狀態(tài) order_status0待支付、1已支付、2制作中、3已完成、4已取消、5退款中。用數(shù)字的好處是存儲空間小、查詢快、方便擴展狀態(tài)機但代碼里不能到處寫魔法數(shù)字必須定義 OrderStatus 常量類。這不僅是代碼規(guī)范問題也是面試官常問的“如何避免魔法值”。邏輯刪除字段 deleted 我基本每張表都加了。為什么不物理刪除因為餐飲系統(tǒng)的訂單、菜品、用戶數(shù)據(jù)都有統(tǒng)計價值物理刪了之后日報表、銷量排行都對不上。但邏輯刪會帶來一個坑如果菜品名有唯一索引刪除后再添加同名菜品會報唯一鍵沖突。解決辦法是把唯一索引改成 (name, deleted) 聯(lián)合索引或者干脆不設(shè)唯一索引、靠代碼判斷。這個細節(jié)我在第5章還會提到。version 樂觀鎖字段是給庫存表、訂單表用的。它的存在是為了應對兩個人同時下單搶最后一份菜的場景詳細原理見第4章。你可以在答辯時說“這個字段是我專門用來解決并發(fā)超賣問題的”這句話本身就是加分項。3.3 核心建表SQL參考下面給出三張核心表的建表 SQL其他表照著這個思路寫就行。注意字符集、存儲引擎和時間字段默認值。CREATE TABLE dish ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 菜品ID, category_id BIGINT NOT NULL COMMENT 分類ID, name VARCHAR(50) NOT NULL COMMENT 菜品名稱, price DECIMAL(10,2) NOT NULL COMMENT 單價, image VARCHAR(255) DEFAULT NULL COMMENT 圖片地址, stock INT NOT NULL DEFAULT 0 COMMENT 庫存, version INT NOT NULL DEFAULT 0 COMMENT 樂觀鎖版本號, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 邏輯刪除 0正常 1刪除, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT菜品表; CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 訂單號, user_id BIGINT DEFAULT NULL, table_id BIGINT DEFAULT NULL, total_amount DECIMAL(10,2) NOT NULL COMMENT 總金額, order_status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付..., pay_status TINYINT NOT NULL DEFAULT 0, pay_time DATETIME DEFAULT NULL, deleted TINYINT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT訂單主表; CREATE TABLE order_detail ( id BIGINT NOT NULL AUTO_INCREMENT, order_id BIGINT NOT NULL, dish_id BIGINT NOT NULL, dish_name VARCHAR(50) NOT NULL COMMENT 菜品快照名, price DECIMAL(10,2) NOT NULL COMMENT 下單時單價快照, quantity INT NOT NULL, subtotal DECIMAL(10,2) NOT NULL, PRIMARY KEY (id), KEY idx_order (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT訂單明細表;為什么 order_no 要單獨建唯一索引因為訂單號要面向用戶展示、客服查單必須保證全局唯一且高效率查詢。生成訂單號我用的是“yyyyMMddHHmmss 用戶ID后四位 隨機數(shù)”簡單可靠不需要引入雪花算法。雪花算法適合分布式系統(tǒng)生成全局唯一ID但單體 MySQL 下時間戳隨機數(shù)配合唯一索引已經(jīng)足夠。真要考慮高并發(fā)可以談“Snowflake”的原理但不一定非要寫進代碼。4. 核心功能模塊實現(xiàn)從點餐到報表的閉環(huán)技術(shù)棧和表結(jié)構(gòu)定了開發(fā)就按模塊推進。下面挑我最想讓讀者抄作業(yè)的四個核心環(huán)節(jié)展開分別是登錄認證、購物車與菜品、下單事務與防超賣、報表統(tǒng)計。這些代碼不是完整源碼但把核心邏輯寫透了你照著搭腳手架就能跑通。4.1 登錄認證與權(quán)限控制C 端用戶可以用簡單的手機號驗證碼也可以做微信授權(quán)登錄需要小程序。后臺員工用賬號密碼登錄。我這里采用 JWT 做前后端分離的會話管理不用 Session。為什么不用 Session因為 Session 依賴服務端內(nèi)存前后端分離部署時可能有多臺實例Session 同步麻煩JWT 是無狀態(tài)的token 本身攜帶用戶信息適合接口化開發(fā)。核心流程是用戶登錄成功后后端簽發(fā)一個 JWT token前端每次請求在 Header 里帶Authorization: Bearer token后端攔截器解析 token把 userId 和 role 放到 ThreadLocal 里供 Service 層取用。Component public class JwtInterceptor implements HandlerInterceptor { private final JwtUtil jwtUtil; public JwtInterceptor(JwtUtil jwtUtil) { this.jwtUtil jwtUtil; } Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登錄接口 if (request.getRequestURI().contains(/login)) { return true; } String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); if (jwtUtil.validateToken(token)) { Long userId jwtUtil.getUserId(token); String role jwtUtil.getRole(token); UserContext.set(userId, role); return true; } } response.setStatus(401); return false; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }注意兩個細節(jié)一是密碼絕對不能明文存數(shù)據(jù)庫我用 BCrypt 加密每次登錄把用戶輸入的密碼 BCrypt 哈希后和庫里比對即使數(shù)據(jù)庫泄露攻擊者也拿不到明文密碼。二是 ThreadLocal 用完必須清除否則 Tomcat 線程池復用線程會把上一個用戶的身份帶到下一次請求這是很嚴重的安全漏洞也是 Spring 源碼里 RequestContextHolder 也在做同樣事情的原因。4.2 菜品管理、購物車與分頁菜品列表是系統(tǒng)最常用的接口支撐菜單頁。用 MyBatis-Plus 的分頁插件非常省事Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }Service 里只需要public PageResultDishVO pageDish(DishQueryDTO dto) { LambdaQueryWrapperDish wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.hasText(dto.getCategory()), Dish::getCategoryId, dto.getCategory()) .eq(Dish::getStatus, 1) .eq(Dish::getDeleted, 0) .orderByDesc(Dish::getCreateTime); PageDish page dishMapper.selectPage(new Page(dto.getPageNum(), dto.getPageSize()), wrapper); // 轉(zhuǎn)VO返回分頁結(jié)果 }購物車我強烈建議做后端表而不是存前端 localStorage。后端表的好處換設(shè)備數(shù)據(jù)不丟、菜品庫存和上架狀態(tài)可以實時校驗、結(jié)賬時直接讀購物車表生成訂單更可靠。代價是每次改數(shù)量都要請求后端但并發(fā)量低完全不是問題。加購物車的一個核心校驗是如果菜品已經(jīng)下架或庫存為0要直接拋出業(yè)務異常不能把無效菜品加進購物車。這個判斷放在 Service 層而不是 Controller屬于“業(yè)務規(guī)則要下沉”。4.3 下單事務與庫存防超賣這是整個系統(tǒng)最核心、也是最值得在答辯時全力展開的模塊。用戶點完菜點“結(jié)賬”后端要做的事情包括校驗桌臺和購物車、生成訂單主表、批量生成訂單明細、扣減庫存、清空購物車、標記待支付。這五個操作必須是一個原子操作任何一個失敗都不能留下半截數(shù)據(jù)。實現(xiàn)方式就是 Transactional。Service public class OrderServiceImpl implements OrderService { Override Transactional(rollbackFor Exception.class) public OrderCreateVO createOrder(OrderCreateDTO dto) { // 1. 校驗桌臺狀態(tài) TableInfo table tableInfoMapper.selectById(dto.getTableId()); if (table null || !TableStatus.FREE.equals(table.getStatus())) { throw new BizException(桌臺不可用); } // 2. 查詢購物車列表 ListCart cartList cartMapper.selectList( new LambdaQueryWrapperCart().eq(Cart::getUserId, dto.getUserId())); if (cartList.isEmpty()) { throw new BizException(購物車為空); } // 3. 計算總金額同時校驗菜品狀態(tài)與庫存 BigDecimal totalAmount BigDecimal.ZERO; ListOrderDetail detailList new ArrayList(); for (Cart cart : cartList) { Dish dish dishMapper.selectById(cart.getDishId()); if (dish null || dish.getStatus() ! 1 || dish.getDeleted() ! 0) { throw new BizException(菜品不存在或已下架 cart.getDishId()); } // 樂觀鎖扣減庫存stock 數(shù)量才更新成功 int rows dishMapper.deductStock(cart.getDishId(), cart.getQuantity()); if (rows 0) { throw new BizException(菜品庫存不足 dish.getName()); } BigDecimal subtotal dish.getPrice().multiply(BigDecimal.valueOf(cart.getQuantity())); totalAmount totalAmount.add(subtotal); detailList.add(buildDetail(dish, cart.getQuantity(), subtotal)); } // 4. 生成訂單號并插入訂單主表 String orderNo OrderNoGenerator.generate(dto.getUserId()); Order order new Order(); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setTableId(dto.getTableId()); order.setTotalAmount(totalAmount); order.setOrderStatus(OrderStatus.UNPAID); orderMapper.insert(order); // 5. 批量插入明細 detailList.forEach(d - { d.setOrderId(order.getId()); orderDetailMapper.insert(d); }); // 6. 清空購物車 cartMapper.delete( new LambdaQueryWrapperCart().eq(Cart::getUserId, dto.getUserId())); return new OrderCreateVO(order.getId(), orderNo, totalAmount); } }對應 Mapper 里的樂觀鎖扣減 SQL 長這樣UPDATE dish SET stock stock - #{quantity}, version version 1 WHERE id #{dishId} AND stock #{quantity} AND status 1這個 SQL 妙在把條件放在 WHERE 里。如果庫存不足WHERE 匹配不到行影響行數(shù)為 0業(yè)務就能感知到并拋異常。如果兩個用戶同時搶最后一份菜數(shù)據(jù)庫的行鎖保證只有一個更新成功另一個影響行數(shù)為 0進入“庫存不足”分支。這種方案不需要 SELECT ... FOR UPDATE也不需要分布式鎖最適合單體項目。關(guān)于 Transactional 有幾個坑必須提醒事務默認只對 RuntimeException 回滾如果代碼里拋出的是檢查異常事務不會回滾所以我在注解里寫了 rollbackFor Exception.class。還有一個經(jīng)典失效場景是同類內(nèi)部調(diào)用比如 Controller 調(diào) Service 的 A 方法A 方法內(nèi)部又調(diào)同一個類的 B 方法B 上的 Transactional 不會生效因為 Spring 的事務是通過代理類實現(xiàn)的內(nèi)部調(diào)用走的是 this不是代理對象。解決辦法是把 B 拆到另一個 Service 類或者把事務邊界放在 A 方法上。4.4 報表統(tǒng)計與分析報表模塊是餐飲系統(tǒng)的門面也是很多老師愛看的功能。我用 ECharts 做前端展示后端只需要提供兩個核心接口按日銷售額統(tǒng)計、菜品銷量排行。按日銷售額統(tǒng)計的核心 SQLSELECT DATE(create_time) AS day, SUM(total_amount) AS amount FROM orders WHERE order_status 3 AND create_time DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE(create_time) ORDER BY day菜品銷量排行SELECT d.id, d.name, SUM(od.quantity) AS total_sales FROM order_detail od LEFT JOIN dish d ON od.dish_id d.id LEFT JOIN orders o ON od.order_id o.id WHERE o.order_status 3 GROUP BY d.id, d.name ORDER BY total_sales DESC LIMIT 10只統(tǒng)計已完成訂單order_status3因為待支付訂單還沒有產(chǎn)生實際收入。這個過濾條件是學弟容易漏掉的漏掉之后報表數(shù)字會虛高。查詢量上來之后記得在 create_time、order_status 上建聯(lián)合索引否則全表掃描會把數(shù)據(jù)庫拖慢。報表這類接口讀多寫少如果以后數(shù)據(jù)量大可以把統(tǒng)計結(jié)果用定時任務匯總到一張報表表中或者加 Redis 緩存當日數(shù)據(jù)但畢設(shè)階段做好 SQL 就夠了。5. 開發(fā)中常見的坑與解決實錄把這些寫進項目總結(jié)里這部分全是真金白銀。學弟在開發(fā)過程里踩過的坑我?guī)缀醵寂闼挪榱艘槐橄旅嫣糇钣写硇缘奈鍌€寫出來每個都可以直接抄進項目文檔的“疑難問題”章節(jié)。5.1 BigDecimal、日期與JSON序列化問題第一個坑后端返回的金額 BigDecimal 傳到前端有時會變成長長的科學計數(shù)法或者直接丟精度。根因是 Jackson 默認把 BigDecimal 序列化為數(shù)字較大的小數(shù)可能被轉(zhuǎn)成科學計數(shù)法。解決辦法是全局配置 BigDecimal 的序列化器讓它輸出字符串Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder - { builder.serializerByType(BigDecimal.class, ToStringSerializer.instance); builder.serializerByType(LocalDateTime.class, new LocalDateTimeSerializer( DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); }; }第二個坑LocalDateTime 默認序列化成數(shù)組格式[2025,1,1,12,0,0]前端根本沒法用。所以要單獨定義 LocalDateTime 的序列化器和反序列化器統(tǒng)一日期格式。這些配置看起來小但直接影響前端聯(lián)調(diào)效率建議項目第一天就配上。5.2 并發(fā)超賣與事務失效的排查測試庫存防超賣時我用 JMeter 開 20 個線程同時點最后一份菜結(jié)果發(fā)現(xiàn)庫存變成負數(shù)了。排查過程很有代表性先檢查 SQL發(fā)現(xiàn) UPDATE 語句沒有加 stock #{quantity} 條件等于無條件扣減修好后再測數(shù)據(jù)庫層面正常了。之后又發(fā)現(xiàn)一個問題扣庫存和插入訂單明細不在同一個事務里扣庫存成功、插入明細失敗時庫存被白白扣掉。解決方式就是上面第4章那套把所有寫操作包在同一個事務方法里并且扣減失敗要拋 RuntimeException 觸發(fā)回滾。如果你在答辯時被問到“怎么保證數(shù)據(jù)一致性”不要只背 ACID要結(jié)合這個項目講我用事務保證訂單明細和庫存操作的原子性用樂觀鎖防止庫存超賣用數(shù)據(jù)庫唯一索引保證訂單號不重復。這一套組合拳講下來比干巴巴背“原子性一致性隔離性持久性”有力得多。5.3 數(shù)據(jù)庫亂碼、時區(qū)與連接池問題學弟第一次啟動項目數(shù)據(jù)庫中文全部亂碼排查半天發(fā)現(xiàn)是連接 URL 少了編碼參數(shù)?，F(xiàn)在 MySQL 8 的全套連接參數(shù)建議這樣寫jdbc:mysql://localhost:3306/restaurant?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltruecharacterEncodingutf8 控制中文不亂碼serverTimezone 解決數(shù)據(jù)庫和服務器時區(qū)不對導致的 8 小時時間差。allowPublicKeyRetrievaltrue 是 MySQL 8 用 caching_sha2_password 認證時需要的參數(shù)。這些參數(shù)在答辯時不用講得太深但能解決啟動失敗問題。如果啟動時報HikariPool-1 - Exception during pool initialization先檢查 MySQL 服務有沒有啟動、賬號密碼是否正確、驅(qū)動依賴版本是否匹配。最常見的是 pom 里引入了 MySQL 5 的驅(qū)動而連接的是 MySQL 8或者反過來驅(qū)動版本和數(shù)據(jù)庫版本不匹配。5.4 Maven編譯版本不匹配與Java環(huán)境變量熱詞里那條“java: 警告: 源發(fā)行版 17 需要目標發(fā)行版 17”我太熟悉了。這種報錯的本質(zhì)是 IDEA 的 Project SDK 是 JDK17但 Maven 的 compiler 插件還按 JDK8 編譯或者 Maven 用的 JDK 和 Project SDK 版本不一致。最簡單粗暴的解決辦法是在 pom.xml 里顯式指定編譯版本properties maven.compiler.source11/maven.compiler.source maven.compiler.target11/maven.compiler.target /properties如果是在命令行打包還要保證java -version和mvn -version指向同一個 JDK。很多同學電腦里既裝了 JRE 又裝了多個 JDK環(huán)境變量 PATH 指到舊的 JRE命令行和 IDEA 里看到的版本不一樣就會出現(xiàn)各種詭異問題。這也是我反復強調(diào)“統(tǒng)一 JDK 版本”的原因。5.5 跨域、404與打包部署問題前后端分離項目聯(lián)調(diào)時第一個報錯就是跨域。我在后端寫一個 WebMvcConfigurer 配置類允許本機前端地址訪問并放行 OPTIONS 預檢請求。否則前端瀏覽器發(fā)出預檢請求會被攔截器當成正常請求攔截導致“CORS 請求未通過”的詭異報錯。如果前端用 Vue Router 的 history 模式部署上線后刷新頁面會 404因為 nginx 找不到對應的靜態(tài)資源路徑。解決辦法是 nginx 里配置 try_files 把所有路由回退到 index.html或者干脆改用 hash 模式URL 會帶個 #不美觀但省心。畢設(shè)演示一般用 hash 模式就夠了因為我吃過 history 模式的虧現(xiàn)場演示時刷新就白屏很尷尬。打包部署我推薦 SpringBoot 的可執(zhí)行 jar用mvn clean package打出來服務器上java -jar restaurant.jar一條命令啟動。數(shù)據(jù)庫腳本作為 init.sql 保存服務器上手動執(zhí)行一次。端口的話8080 很容易被占用啟動失敗時就netstat -ano | findstr 8080查占用進程。6. 畢設(shè)答辯與面試怎么講這個項目讓代碼變成你的加分項項目寫完只是完成了一半另一半是讓別人看到它的價值。我?guī)W弟準備了答題思路和面試問題梳理發(fā)現(xiàn)只要把項目里的幾個核心決策講透面試官就不會揪著八股文窮追猛打。這一章直接給可復用的素材。6.1 五分鐘演示腳本與項目亮點整理演示順序建議固定登錄系統(tǒng) → 管理員維護菜品 → 顧客掃碼點餐 → 加購物車 → 下單 → 模擬支付 → 查看訂單狀態(tài) → 后臺看銷售報表。整個過程控制在五分鐘內(nèi)重點是下單和支付環(huán)節(jié)因為這里有事務回滾和狀態(tài)流轉(zhuǎn)最能體現(xiàn)業(yè)務完整性。講解項目時用 STAR 法則背景是學校食堂需要一套數(shù)字化點餐系統(tǒng)你的角色是獨立完成前后端開發(fā)和數(shù)據(jù)庫設(shè)計難點是并發(fā)減庫存、訂單狀態(tài)一致性、報表統(tǒng)計方案是事務樂觀鎖統(tǒng)一狀態(tài)機結(jié)果是系統(tǒng)可以穩(wěn)定支撐日訂單數(shù)百單模擬量。這樣講面試官立刻就能抓住重點。被問“項目最大的亮點是什么”時不要回答“我用了SpringBoot、Redis”這種技術(shù)名詞堆砌。我建議的答案是“細節(jié)上我設(shè)計了訂單主表和明細表隔離、菜品金額快照機制保證歷史訂單財務數(shù)據(jù)準確并發(fā)上我用數(shù)據(jù)庫樂觀鎖解決了超賣問題工程上我做了全局異常處理和統(tǒng)一返回結(jié)構(gòu)前后端聯(lián)調(diào)效率很高?！边@三個點既有業(yè)務思考又有技術(shù)深度比單純背框架名強得多。6.2 高頻Java面試題與項目的掛鉤方式很多同學背了一堆八股文面試時卻不會結(jié)合項目講。我整理了五類高頻題目和對應的話術(shù)。面向?qū)ο笕匦栽陧椖恐械捏w現(xiàn)。封裝用戶、訂單、菜品都封裝成實體類外部只能通過 Service 方法訪問繼承基礎(chǔ)實體 BaseEntity 包含 id、createTime、updateTime所有實體繼承它多態(tài)支付方式設(shè)計成 PayStrategy 接口微信支付、余額支付各自實現(xiàn)下單時根據(jù)支付類型動態(tài)調(diào)用。這樣答完面試官就相信你真的在項目里用過面向?qū)ο蠖皇侵粫瑢懚x。HashMap 與數(shù)據(jù)結(jié)構(gòu)題。可以結(jié)合項目里“菜單熱點數(shù)據(jù)緩存”來說我說過不用 HashMap 做全局緩存因為它是線程不安全的并發(fā)讀寫會丟數(shù)據(jù)單機可以用 ConcurrentHashMap生產(chǎn)環(huán)境更適合 Caffeine。如果被追問 HashMap 底層原理就講數(shù)組鏈表/紅黑樹、put 流程、擴容機制、為什么 HashMap 非線程安全。這個題幾乎是 Java 面試必問一定要準備。String、StringBuilder、StringBuffer 的區(qū)別。結(jié)合項目訂單明細數(shù)量多時批量拼接 SQL 或日志千萬不能在循環(huán)里用String 因為 String 不可變每次拼接都創(chuàng)建新對象O(n2) 性能問題。用 StringBuilder 做局部字符串拼接StringBuffer 因為方法加了 synchronized不需要多線程拼接時沒必要用它。這題簡單但答得接地氣反而加分。如何保證數(shù)據(jù)一致性。這個題我用項目里的下單流程完整回答步驟是校驗庫存、生成訂單、扣庫存、清購物車全部包在同一個事務里任何一個步驟失敗整體回滾庫存扣減用樂觀鎖條件更新防止超賣訂單號用唯一索引兜底。然后再補一句“如果以后拆微服務訂單和庫存分庫就需要引入分布式事務方案比如 Seata 或者本地消息表”這句話證明你有架構(gòu)視野但當前項目規(guī)模單體事務足夠。排序算法題。菜品銷量排序用到過 Collections.sort 配合 Comparator 對 ListDishSalesVO 按銷量排序面試如果讓你手寫至少能寫出冒泡和快排。冒泡排序雖然不高效但容易講清楚快排的核心是選定 pivot 分區(qū)遞歸。我建議項目答辯前把這兩個排序的代碼過一遍因為“java排序”是高頻搜索詞很容易被問到。Java 基礎(chǔ)與學習路線的建議。如果面試官問“Java學習怎么規(guī)劃”你可以說先搞清數(shù)據(jù)類型、集合、面向?qū)ο笕缓髮W并發(fā)和 JVM接著上手 SpringBoot最后通過餐飲系統(tǒng)這個項目把知識串起來。這個回答既展示技術(shù)深度也讓對方看到你有明確的學習路徑。6.3 功能擴展思路項目做完之后學弟問我還能加什么。我給的擴展方向按投入產(chǎn)出比排序第一接入支付寶沙箱支付體驗真實支付回調(diào)流程支付回調(diào)的冪等性又是一個亮點第二增加優(yōu)惠券模塊涉及滿減規(guī)則、有效期、庫存擴展業(yè)務廣度第三基于歷史訂單做“猜你喜歡”最簡單的實現(xiàn)是用關(guān)聯(lián)規(guī)則或者協(xié)同過濾的 ItemCF講起來很高端第四如果非要往架構(gòu)方向談可以把訂單服務和庫存服務拆開用 Redis 中間件解耦但我不建議在畢設(shè)階段真的做。這些擴展點不一定要全部實現(xiàn)哪怕只實現(xiàn)一個支付沙箱項目完成度和面試談資都會提升一大截。關(guān)鍵在于每個擴展都能對應到一個明確的技術(shù)問題支付回調(diào)怎么保證冪等優(yōu)惠券超發(fā)怎么防止推薦算法怎么冷啟動帶著問題去實現(xiàn)比瞎加功能有用得多。最后說點個人體會。這個項目從我接手幫學弟到最后跑通前后大概四周投入最大的是表結(jié)構(gòu)設(shè)計和下單事務那一塊。學弟后來拿著這個項目去面試暑期實習面試官問到“怎么解決超賣”時他把 optimistic lock 和事務回滾講得清清楚楚當場就被夸“項目思路很完整”。我覺得畢設(shè)項目的價值從來不在技術(shù)多新而在于每個設(shè)計點你都能講出“為什么”。你在文檔里把表字段為什么用 DECIMAL、訂單為什么要主表明細分離、狀態(tài)為什么用常量類、扣庫存為什么要帶條件更新寫清楚答辯老師想不給高分都難。再分享一個小技巧寫項目文檔時專門留一個“設(shè)計決策記錄”章節(jié)每做一個關(guān)鍵選擇就把當時考慮的兩三個備選方案和最終理由記下來。比如“購物車為什么用后端表而不是localStorage”記錄完你就會發(fā)現(xiàn)自己的項目比那些只說“我實現(xiàn)了什么功能”的同學高出一個檔次。如果時間緊張優(yōu)先把下單、支付、報表這條主鏈路跑得毫無破綻再去加其他花活這是我最想提醒各位的一句話。