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