“舊時(shí)光”這三個(gè)字聽(tīng)起來(lái)就很適合做項(xiàng)目背景——一家主打懷舊復(fù)古風(fēng)的咖啡廳既有堂食、外帶也有會(huì)員儲(chǔ)值、積分兌換這些餐飲老玩法。技術(shù)棧選了Java Spring Boot做后端前端用Vue這套組合在學(xué)校畢設(shè)、個(gè)人全棧作品、甚至小型創(chuàng)業(yè)項(xiàng)目里都非常成熟資料多、社區(qū)活躍遇到問(wèn)題基本搜得到答案。這篇文章我不會(huì)給你貼一層皮式的“項(xiàng)目展示”而是按我實(shí)際做這類(lèi)點(diǎn)餐收銀系統(tǒng)的思路從需求分析、表結(jié)構(gòu)、后端接口、前端頁(yè)面、懷舊主題落地到上線(xiàn)前容易踩的坑完整走一遍。適合正準(zhǔn)備做類(lèi)似管理系統(tǒng)的同學(xué)參考也適合已經(jīng)寫(xiě)完業(yè)務(wù)、想優(yōu)化代碼細(xì)節(jié)的朋友當(dāng)個(gè)檢查清單。1. 動(dòng)手之前先給咖啡廳管理系統(tǒng)“畫(huà)像”很多人做管理系統(tǒng)有個(gè)通病拿到需求就建表表建完就寫(xiě)增刪改查結(jié)果做到一半發(fā)現(xiàn)業(yè)務(wù)流程對(duì)不上返工成本極高?！芭f時(shí)光咖啡廳”這種項(xiàng)目核心是運(yùn)營(yíng)閉環(huán)第一步應(yīng)該先把角色、場(chǎng)景和流程定死。1.1 角色與使用場(chǎng)景咖啡廳管理系統(tǒng)絕不是只有管理員一個(gè)角色的“單機(jī)軟件”我按照現(xiàn)場(chǎng)動(dòng)線(xiàn)設(shè)計(jì)了四類(lèi)使用者分別對(duì)應(yīng)不同的終端和界面角色主要終端職責(zé)核心操作管理員PC后臺(tái)門(mén)店全局管理商品上下架、訂單查詢(xún)、數(shù)據(jù)報(bào)表、員工賬號(hào)管理收銀員PC收銀臺(tái)/平板堂食點(diǎn)單、結(jié)賬、退款快速開(kāi)單、折扣、接單、打印小票吧臺(tái)/后廚后廚顯示屏制作出品查看待制作訂單、標(biāo)記完成顧客手機(jī)瀏覽器掃碼自助點(diǎn)餐掃碼看菜單、下單、查看訂單進(jìn)度這里有個(gè)特別容易忽略的點(diǎn)顧客端必須移動(dòng)端優(yōu)先收銀臺(tái)要適應(yīng)平板觸屏操作而后廚屏是大屏展示。一套 Vue 響應(yīng)式布局在桌面上做“寬度斷點(diǎn) 觸控按鈕加大”就能覆蓋沒(méi)必要像有些項(xiàng)目一樣拆好幾個(gè)獨(dú)立前端工程。1.2 核心業(yè)務(wù)流程梳理我從“顧客進(jìn)店到離店”這條主線(xiàn)倒推系統(tǒng)功能顧客到店掃描桌臺(tái)二維碼手機(jī)端瀏覽菜單、加購(gòu)、提交訂單訂單進(jìn)入后臺(tái)待支付狀態(tài)顧客在線(xiàn)支付或到收銀臺(tái)結(jié)賬后廚屏顯示新訂單按順序制作點(diǎn)擊完成收銀臺(tái)打印小票顧客取餐或服務(wù)員送餐結(jié)賬后會(huì)員積分自動(dòng)累計(jì)餐后顧客可查看歷史訂單。這一套流程對(duì)應(yīng)到后端就是桌臺(tái)模塊、菜品模塊、購(gòu)物車(chē)模塊、訂單模塊、支付模塊、后廚狀態(tài)流轉(zhuǎn)模塊、會(huì)員模塊。你的“管理后臺(tái)”其實(shí)只服務(wù)其中三分之一的需求另外三分之二都在給顧客和后廚做工具。當(dāng)時(shí)我畫(huà)完流程有個(gè)很關(guān)鍵的體會(huì)不要把一個(gè)需求的每一步都做成頁(yè)面。比如“后廚屏”根本沒(méi)有復(fù)雜表單就是一張輪詢(xún)更新的列表加一個(gè)完成按鈕真正重的邏輯都在訂單狀態(tài)的流轉(zhuǎn)和并發(fā)控制上。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)“舊時(shí)光”的家底怎么盤(pán)表結(jié)構(gòu)設(shè)計(jì)是這類(lèi)系統(tǒng)的地基。地基歪了后端的業(yè)務(wù)代碼寫(xiě)得再漂亮也是空中樓閣。2.1 核心表清單我按業(yè)務(wù)域拆成六大模塊自認(rèn)為這是咖啡廳管理系統(tǒng)性?xún)r(jià)比最高的建模方式用戶(hù)與權(quán)限user員工/管理員、role、permission或者直接用更簡(jiǎn)單的 user role 兩張表 前端按鈕級(jí)權(quán)限判斷。多數(shù)校園項(xiàng)目用 JWT 攔截器判斷角色就夠不需要引入復(fù)雜的權(quán)限框架。菜品域category菜品分類(lèi)、product菜品、product_spec規(guī)格比如大杯/中杯、常溫/加冰還有 product_image 處理多圖切換。桌臺(tái)域table包含桌號(hào)、座位數(shù)、當(dāng)前狀態(tài)空閑/占用/待清理、綁定的二維碼。訂單域orders主表、order_item明細(xì)表、order_status_log狀態(tài)流轉(zhuǎn)記錄。會(huì)員域member會(huì)員檔案、member_balance_log儲(chǔ)值流水、member_points_log積分流水、coupon優(yōu)惠券和 user_coupon領(lǐng)券記錄。倉(cāng)儲(chǔ)域material原材料、purchase進(jìn)貨單、stock_record庫(kù)存流水。咖啡廳也是要算物料成本的這一塊做好了管報(bào)表時(shí)才有東西可看。有些同學(xué)對(duì)“狀態(tài)機(jī)日志表”不重視覺(jué)得多寫(xiě)一張表很麻煩。真上線(xiàn)后你會(huì)發(fā)現(xiàn)顧客說(shuō)“我明明支付了但顯示未支付”或者后廚說(shuō)“這單怎么重復(fù)出現(xiàn)了”查訂單狀態(tài)歷史時(shí)沒(méi)有日志你只能跟用戶(hù)來(lái)回拉扯。加一張 status_log每次狀態(tài)變更記一下誰(shuí)改的、從哪改到哪、為什么改排查問(wèn)題效率翻倍。2.2 建表時(shí)的幾個(gè)細(xì)節(jié)訂單主表我建議長(zhǎng)這樣省略部分字段CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 訂單號(hào), table_id BIGINT COMMENT 桌臺(tái)ID自取可空, member_id BIGINT COMMENT 會(huì)員ID非會(huì)員可空, total_amount DECIMAL(10,2) NOT NULL COMMENT 應(yīng)收金額, discount_amount DECIMAL(10,2) DEFAULT 0.00 COMMENT 優(yōu)惠金額, pay_amount DECIMAL(10,2) NOT NULL COMMENT 實(shí)付金額, pay_type TINYINT COMMENT 1微信 2支付寶 3現(xiàn)金 4儲(chǔ)值卡, status TINYINT NOT NULL COMMENT 訂單狀態(tài), remark VARCHAR(255) COMMENT 顧客備注, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, KEY idx_order_no (order_no), KEY idx_table_status (table_id, status), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT訂單主表;幾個(gè)容易踩的點(diǎn)金額一律DECIMAL(10,2)Java 里對(duì)應(yīng)BigDecimal絕不用double?？Х葐蝺r(jià)看似是 18 元、28 元這種整數(shù)但折扣、滿(mǎn)減、積分抵扣算下來(lái)浮點(diǎn)數(shù)誤差積累幾萬(wàn)單之后會(huì)很惡心。訂單號(hào)order_no我習(xí)慣由后端生成用時(shí)間戳 隨機(jī)序列 門(mén)店前綴比如2025031215301001。不要用自增 ID 當(dāng)訂單號(hào)漏給顧客既不安全也難辨識(shí)。所有跟“狀態(tài)”有關(guān)的字段建議用TINYINT數(shù)字而不是字符串表里注釋寫(xiě)明每個(gè)數(shù)字的含義。Java 側(cè)用枚舉類(lèi)映射前后端統(tǒng)一狀態(tài)碼字典。凡是需要列表查詢(xún)的表都給 create_time 和狀態(tài)字段建索引。管理端“查今天的訂單”“查某桌待支付訂單”是最常見(jiàn)的高頻查詢(xún)沒(méi)索引的話(huà)數(shù)據(jù)量過(guò)萬(wàn)就會(huì)開(kāi)始卡。2.3 索引與查詢(xún)優(yōu)化后臺(tái)報(bào)表頁(yè)經(jīng)常出現(xiàn)“時(shí)間范圍 狀態(tài) 門(mén)店”組合查詢(xún)這種場(chǎng)景別想著一個(gè)復(fù)合索引通吃。我當(dāng)時(shí)的做法是訂單主表給(status, create_time)建聯(lián)合索引因?yàn)樽畛３霈F(xiàn)的篩選是“某狀態(tài) 最近時(shí)間”桌臺(tái)表按(store_id, status)走訂單明細(xì)表則完全靠order_id查詢(xún)只建單列索引。運(yùn)行時(shí)如果發(fā)現(xiàn)某個(gè)報(bào)表接口慢用EXPLAIN看一下是否走了索引別盲目加索引——咖啡廳系統(tǒng)寫(xiě)入頻率遠(yuǎn)高于讀取索引過(guò)多會(huì)導(dǎo)致插入和更新變慢得不償失。3. Spring Boot 后端把“重復(fù)勞動(dòng)”砍到最低后端我用的版本組合是 Spring Boot 3.2.x JDK 17 MyBatis-Plus MySQL 8。選這個(gè)組合的理由很簡(jiǎn)單Spring Boot 3 已經(jīng)非常穩(wěn)定JDK 17 是長(zhǎng)期支持版MyBatis-Plus 做單表 CRUD 幾乎不用寫(xiě) SQL可以把精力集中在真正復(fù)雜的訂單流轉(zhuǎn)和報(bào)表聚合上。3.1 工程結(jié)構(gòu)不要過(guò)度設(shè)計(jì)現(xiàn)在網(wǎng)上很多項(xiàng)目一上來(lái)就拆 Maven 多模塊common、system、order、member……對(duì)于一個(gè)單體就能扛住的咖啡廳管理系統(tǒng)我強(qiáng)烈建議用單模塊按包名分域目錄長(zhǎng)這樣com.oldtime.cafe ├── config # 全局配置CORS、MyBatisPlus、Jackson ├── common # 統(tǒng)一返回體、異常、工具類(lèi) ├── security # JWT 認(rèn)證與攔截器 ├── controller # 接口層 ├── service # 業(yè)務(wù)層 ├── mapper # MyBatis-Plus Mapper ├── entity # 數(shù)據(jù)庫(kù)實(shí)體 ├── dto # 請(qǐng)求/響應(yīng)對(duì)象 └── vo # 前端視圖對(duì)象只要你的代碼不是爛到完全不可維護(hù)這種包結(jié)構(gòu)足夠支撐到幾千家門(mén)店的規(guī)模。多模塊真正的收益是在團(tuán)隊(duì)協(xié)作和強(qiáng)制依賴(lài)邊界上一個(gè)人開(kāi)發(fā)的項(xiàng)目用多模塊純屬給自己找編譯麻煩。3.2 認(rèn)證方案JWT 攔截器咖啡廳的角色不多用 Spring Security 也綽綽有余但我實(shí)際用的是輕量方案登錄接口發(fā)放 JWT前端每次請(qǐng)求帶上 Token后端寫(xiě)一個(gè)攔截器解析 Token、校驗(yàn)角色、放行請(qǐng)求。JWT 的“無(wú)狀態(tài)”特性在這個(gè)場(chǎng)景很合適顧客手機(jī)端、收銀臺(tái) PC、后廚屏三個(gè)終端共享同一套認(rèn)證不需要服務(wù)端維護(hù) Session。但要注意 JWT 過(guò)期時(shí)間的設(shè)置——顧客點(diǎn)餐可能長(zhǎng)時(shí)間不退出我設(shè)置的是 7 天員工后臺(tái)則設(shè)置 2 小時(shí)過(guò)期后重新登錄。登錄接口的核心邏輯大致如下Override public LoginResult login(String username, String password) { User user userMapper.selectOne( new LambdaQueryWrapperUser() .eq(User::getUsername, username) ); if (user null) { throw new BusinessException(用戶(hù)名或密碼錯(cuò)誤); } if (!passwordEncoder.matches(password, user.getPassword())) { throw new BusinessException(用戶(hù)名或密碼錯(cuò)誤); } if (user.getStatus() ! 1) { throw new BusinessException(賬號(hào)已被禁用); } String token jwtUtil.generateToken(user.getId(), user.getRole(), user.getNickname()); return new LoginResult(token, user.getRole(), user.getNickname()); }有一件事必須單獨(dú)提醒顧客掃碼點(diǎn)餐本質(zhì)上也是登錄。不要讓顧客去注冊(cè)賬號(hào)注冊(cè)門(mén)檻會(huì)把手機(jī)點(diǎn)餐轉(zhuǎn)化率砍掉一半。顧客端用“微信授權(quán) 手機(jī)號(hào)”方式或者干脆生成一個(gè)臨時(shí)游客身份結(jié)賬時(shí)才引導(dǎo)綁定會(huì)員。我在表設(shè)計(jì)里的 member 就是可空字段原因就在這里。3.3 訂單提交接口與并發(fā)思考點(diǎn)餐系統(tǒng)最容易出事故的就是“提交訂單”這個(gè)動(dòng)作。顧客瞬間提交、多次點(diǎn)擊、庫(kù)存修改、余額扣減任何一個(gè)環(huán)節(jié)不加控制都會(huì)出問(wèn)題。我的訂單提交流程分四步冪等校驗(yàn)前端生成“請(qǐng)求唯一標(biāo)識(shí)”比如 UUID提交時(shí)帶上。后端用 Redis 的 SETNX 緩存這個(gè)標(biāo)識(shí)如果 3 秒內(nèi)重復(fù)提交直接返回“訂單處理中”。這一步能擋住 90% 的重復(fù)點(diǎn)擊問(wèn)題。庫(kù)存預(yù)扣讀取商品庫(kù)存預(yù)扣除購(gòu)買(mǎi)數(shù)量而不是等到支付完成才扣。如果顧客 15 分鐘未支付庫(kù)存自動(dòng)回補(bǔ)。計(jì)算金額加購(gòu)項(xiàng)單價(jià) × 數(shù)量減去優(yōu)惠券金額再算會(huì)員折扣全程用BigDecimal。事務(wù)落庫(kù)在事務(wù)里寫(xiě)入訂單主表、明細(xì)表、庫(kù)存流水、優(yōu)惠券核銷(xiāo)記錄。用Transactional(rollbackFor Exception.class)明確指定回滾條件。我當(dāng)時(shí)踩過(guò)一個(gè)大坑訂單超時(shí)未支付回補(bǔ)庫(kù)存用的是定時(shí)任務(wù)掃表結(jié)果高峰期定時(shí)任務(wù) 3 分鐘跑一次顧客看到“還有 5 件”點(diǎn)進(jìn)去卻發(fā)現(xiàn)沒(méi)有了。后來(lái)改成 Redis 延遲隊(duì)列 訂單狀態(tài)掃描雙保險(xiǎn)體驗(yàn)才真正達(dá)標(biāo)。3.4 后端基建統(tǒng)一返回、全局異常、日志接口返回格式一定要統(tǒng)一這是前后端協(xié)作的底線(xiàn){ code: 200, message: success, data: {} }為了少寫(xiě)重復(fù)代碼我做了一個(gè)ApiResponseT泛型工具類(lèi)配合全局異常處理器RestControllerAdvice這樣業(yè)務(wù)里想報(bào)錯(cuò)時(shí)直接throw new BusinessException(庫(kù)存不足)前端拿到的永遠(yuǎn)是同一個(gè)結(jié)構(gòu)。日志方面用 Slf4j 在關(guān)鍵節(jié)點(diǎn)打日志登錄、下單、支付回調(diào)、退款、庫(kù)存變更。上線(xiàn)后顧客來(lái)反饋問(wèn)題你只需要搜訂單號(hào)就能串起整個(gè)過(guò)程。4. Vue 前端從路由守衛(wèi)到掃碼點(diǎn)餐前端我用的是 Vue 3 Vite Element Plus Pinia Axios這套組合是目前 Vue 生態(tài)的主流答案。Vite 比 Webpack 快的不是一點(diǎn)點(diǎn)開(kāi)發(fā)體驗(yàn)舒服太多了。4.1 工程目錄與 API 封裝Vue 前端單倉(cāng)庫(kù)多頁(yè)面即可按“后臺(tái)管理”和“顧客端 H5”拆成兩個(gè)路由空間但共用一套請(qǐng)求封裝和組件src ├── api # 所有接口定義按模塊拆分 ├── assets # 靜態(tài)資源、懷舊主題圖片 ├── components # 通用組件 ├── layout # 后臺(tái)布局 ├── router # 路由配置 ├── store # Pinia 狀態(tài) ├── views │ ├── admin # 管理后臺(tái)頁(yè)面 │ └── mobile # 顧客掃碼點(diǎn)餐頁(yè)面 └── utils # axios、工具函數(shù)Axios 封裝里最核心的是攔截器。請(qǐng)求攔截器從 Pinia 的 token 狀態(tài)里取 JWT 塞進(jìn) Header響應(yīng)攔截器統(tǒng)一處理業(yè)務(wù)錯(cuò)誤碼401 跳登錄500 彈出錯(cuò)誤提示。這段代碼每個(gè)項(xiàng)目都得寫(xiě)一遍但寫(xiě)好之后所有頁(yè)面調(diào)用接口就是一行await api.order.submit(params)干凈利落。4.2 路由守衛(wèi)與角色控制管理后臺(tái)的訪(fǎng)問(wèn)控制說(shuō)復(fù)雜也復(fù)雜說(shuō)簡(jiǎn)單也簡(jiǎn)單。我用的是“路由 meta 全局前置守衛(wèi)”router.beforeEach((to, from, next) { const store useUserStore(); if (to.meta.public) { next(); return; } if (!store.token) { next(/login); return; } if (to.meta.roles !to.meta.roles.includes(store.role)) { next(/403); return; } next(); });把“哪些頁(yè)面哪些角色能進(jìn)”寫(xiě)在路由表的 meta 里加頁(yè)面時(shí)順手聲明權(quán)限維護(hù)成本非常低。管理員能看到報(bào)表和員工管理收銀員看不到這些入口后廚屏甚至不需要登錄——它是獨(dú)立路由走的是店內(nèi)局域網(wǎng)接口。4.3 掃碼點(diǎn)餐的實(shí)現(xiàn)思路顧客端最核心的交互是“掃碼 → 看菜單 → 加購(gòu) → 下單”。二維碼不是技術(shù)難點(diǎn)但有幾個(gè)體驗(yàn)細(xì)節(jié)值得說(shuō)二維碼內(nèi)容用一個(gè)短標(biāo)識(shí)符比如cafe://table/12而不是完整 URL。這樣換個(gè)域名二維碼不用重新生成。掃碼后先調(diào)接口查詢(xún)桌臺(tái)狀態(tài)如果已占用則提示“本桌已開(kāi)臺(tái)”避免重復(fù)開(kāi)臺(tái)。加購(gòu)按鈕要大觸控區(qū)域不小于 44px菜單分類(lèi)左右布局右側(cè)菜品列表可滾動(dòng)。購(gòu)物車(chē)做成懸浮底部欄點(diǎn)擊展開(kāi)明細(xì)整個(gè)交互參考外賣(mài) App 但比外賣(mài)更簡(jiǎn)單——不需要配送地址省掉一大塊表單。購(gòu)物車(chē)狀態(tài)我用 Pinia 管理刷新頁(yè)面會(huì)丟失所以下單前用戶(hù)看到的購(gòu)物車(chē)是前端本地狀態(tài)。這里有個(gè)小優(yōu)化把未提交的購(gòu)物車(chē)持久化到 localStorage顧客手滑刷新頁(yè)面購(gòu)物車(chē)還在體驗(yàn)會(huì)好很多。4.4 后廚屏最簡(jiǎn)單的界面最需要注意的刷新策略后廚屏不是一個(gè) CRUD 頁(yè)面而是一個(gè)“實(shí)時(shí)看板”。我用了兩種刷新方式組合頁(yè)面加載時(shí)拉一次全量待制作訂單之后通過(guò) WebSocket 推送新訂單事件收到事件后再拉增量列表。用原生 WebSocket 就行不需要引入 Socket.IO。這里有個(gè)小坑如果咖啡館網(wǎng)絡(luò)不穩(wěn)定WebSocket 掉線(xiàn)期間新訂單會(huì)堆積。解決方案是前端加一個(gè) 30 秒的輪詢(xún)兜底發(fā)現(xiàn) WebSocket 狀態(tài)異常就自動(dòng)切換到輪詢(xún)模式頁(yè)面頂部顯示“連接已降級(jí)每 30 秒自動(dòng)刷新”。5. “舊時(shí)光”視覺(jué)主題懷舊不是放幾張老照片這個(gè)項(xiàng)目的名字本身就是最大賣(mài)點(diǎn)界面風(fēng)格如果做成默認(rèn)藍(lán)白后臺(tái)那“舊時(shí)光”三個(gè)字就白起了。5.1 設(shè)計(jì)關(guān)鍵詞拆解我把“舊時(shí)光”拆成三個(gè)視覺(jué)關(guān)鍵詞暖木色、紙張質(zhì)感、復(fù)古字體。主色調(diào)不用多定一個(gè)深咖色#4A3426作為品牌主色輔以奶油底色#F5EFE0和點(diǎn)綴的懷舊紅#A65B3C。Element Plus 的主題變量可以自定義把這個(gè)幾個(gè)顏色替換進(jìn)去整個(gè)后臺(tái)的按鈕、輸入框、卡片會(huì)自動(dòng)全部換膚比手工改 CSS 劃算得多。5.2 幾個(gè)低成本高質(zhì)感的落地技巧菜單卡片模擬老菜單紙張背景用奶油色漸變加極淡的噪點(diǎn)紋理字體用手寫(xiě)風(fēng)格的標(biāo)題字體中文可以找免費(fèi)商用字庫(kù)價(jià)格用等寬數(shù)字字體。收銀臺(tái)界面做“膠片感”頁(yè)面切換用平滑淡入而不是生硬的跳轉(zhuǎn)小圖標(biāo)統(tǒng)一使用線(xiàn)性風(fēng)格整體降低飽和度和對(duì)比度。首頁(yè)放“記憶墻”顧客端 H5 的首頁(yè)不是上來(lái)就逼你下單而是先放一組品牌故事照片和新品海報(bào)往下滑才是菜單。這個(gè)設(shè)計(jì)讓顧客愿意在頁(yè)面上多停留一會(huì)兒間接提升點(diǎn)單概率。小票樣式復(fù)古化訂單完成后的“電子小票”做成帶鋸齒邊緣的卡片字體用像素感和圓角感兼顧的中文字體顧客截圖分享本身就是免費(fèi)宣傳。懷舊不等于放棄現(xiàn)代體驗(yàn)。所有按鈕至少 44px 高字號(hào)不小于 14px關(guān)鍵操作有明確的按下反饋。視覺(jué)風(fēng)格再舊交互邏輯必須新。5.3 響應(yīng)式打印適配收銀小票是 Java Vue 項(xiàng)目里容易被忽略的環(huán)節(jié)。小票打印一般走瀏覽器打印但頁(yè)面寬度、字體大小要單獨(dú)適配 58mm/80mm 熱敏紙。我的方案是專(zhuān)門(mén)做一個(gè)打印組件生成純表格樣式的小票頁(yè)面再用media print隱藏導(dǎo)航和按鈕只保留小票區(qū)域。這里有個(gè)實(shí)用技巧小票寬度設(shè)成 58mmpage { size: 58mm auto; margin: 0; }打印時(shí)選擇“實(shí)際大小”不要“適應(yīng)頁(yè)面”否則字體會(huì)被壓縮到看不清。6. 從開(kāi)發(fā)到上線(xiàn)實(shí)測(cè)中我反復(fù)踩的坑功能寫(xiě)完只是第一步能穩(wěn)定跑起來(lái)才是真本事。整理幾個(gè)我在這個(gè)項(xiàng)目里反復(fù)踩、也幫別人排查過(guò)的問(wèn)題。6.1 金額和時(shí)間兩個(gè)“差之毫厘謬以千里”的細(xì)節(jié)金額精度問(wèn)題前面提過(guò)這里再說(shuō)一個(gè)隱蔽場(chǎng)景訂單金額在數(shù)據(jù)庫(kù)是DECIMAL(10,2)MyBatis-Plus 映射到 Java 會(huì)給你BigDecimal沒(méi)問(wèn)題。但前端 JavaScript 計(jì)算金額時(shí)0.1 0.2 這種浮點(diǎn)誤差會(huì)直接爆出來(lái)。前端只負(fù)責(zé)展示金額計(jì)算一律以后端返回為準(zhǔn)前端不要做任何加減乘除。購(gòu)物車(chē)頁(yè)面的“合計(jì)”必須是后端在加購(gòu)時(shí)就算好返回的而不是前端把單價(jià)相加。時(shí)間問(wèn)題則是時(shí)區(qū)加格式的組合拳。后端用LocalDateTime統(tǒng)一存數(shù)據(jù)庫(kù)接口返回格式統(tǒng)一成yyyy-MM-dd HH:mm:ss。Jackson 配置里要顯式設(shè)置日期格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8不然前端拿到的是數(shù)組或者帶 T 的 ISO 格式解析起來(lái)一臉懵。另外數(shù)據(jù)庫(kù)連接串記得加serverTimezoneAsia/Shanghai這個(gè)坑在部署到云服務(wù)器后最容易出現(xiàn)——本地好好的服務(wù)器一跑時(shí)間全錯(cuò)。6.2 商品圖片上傳本地存儲(chǔ)還是對(duì)象存儲(chǔ)如果只是校園項(xiàng)目或者單店部署最穩(wěn)妥的方案是本機(jī)磁盤(pán)存儲(chǔ) Nginx 映射靜態(tài)資源。圖片上傳接口把文件存到服務(wù)器某個(gè)目錄返回給前端一個(gè)/images/products/xxx.jpg路徑由 Nginx 直接服務(wù)后端完全不用管讀取。但如果你打算做成可商用、支持多門(mén)店的系統(tǒng)就得上 MinIO——它是一種兼容 S3 協(xié)議的開(kāi)源對(duì)象存儲(chǔ)。商品圖片、品牌素材全部打到 MinIO 桶里加個(gè)桶權(quán)限策略圖片鏈接走 Nginx 代理緩存會(huì)比自己管理磁盤(pán)干凈很多。不管是本機(jī)存儲(chǔ)還是 MinIO上傳接口統(tǒng)一返回相對(duì)路徑不要返回完整 URL這樣以后換域名、換 HTTPS 都不用改數(shù)據(jù)庫(kù)里的舊數(shù)據(jù)。6.3 商品上下架與緩存一致性菜單是高頻讀取、低頻修改的數(shù)據(jù)。顧客端每次打開(kāi)都查 MySQL 顯然不劃算我在 Redis 里存了一份“在售商品列表”key 為menu:store:{storeId}30 分鐘過(guò)期。這里真正要注意的是緩存更新時(shí)機(jī)商品上架/下架、改價(jià)格、改庫(kù)存這些操作發(fā)生時(shí)必須主動(dòng)刪除緩存而不是依賴(lài)過(guò)期。因?yàn)槲矣玫氖恰氨粍?dòng)失效 主動(dòng)刪除”策略管理員修改商品后立刻刪緩存下一次查詢(xún)重新從數(shù)據(jù)庫(kù)加載。極端情況下緩存和數(shù)據(jù)庫(kù)最多有幾秒不一致這點(diǎn)延遲對(duì)咖啡廳場(chǎng)景完全可接受。6.4 報(bào)表導(dǎo)出Java POI 的真實(shí)邊際管理后臺(tái)通常會(huì)有“營(yíng)業(yè)報(bào)表導(dǎo)出”需求常見(jiàn)實(shí)現(xiàn)是 Apache POI 生成 Excel。很多同學(xué)一聽(tīng)說(shuō) POI 就頭疼其實(shí)餐廳報(bào)表用最基本的XSSFWorkbook就夠了做一個(gè)訂單匯總表try (XSSFWorkbook workbook new XSSFWorkbook()) { Sheet sheet workbook.createSheet(營(yíng)業(yè)報(bào)表); Row header sheet.createRow(0); header.createCell(0).setCellValue(日期); header.createCell(1).setCellValue(訂單數(shù)); header.createCell(2).setCellValue(營(yíng)業(yè)額); // 遍歷訂單數(shù)據(jù)填充... ByteArrayOutputStream out new ByteArrayOutputStream(); workbook.write(out); return out.toByteArray(); }POI 完全支持在 Excel 里生成圖表比如月度營(yíng)業(yè)額柱狀圖。如果你只是導(dǎo)出報(bào)表不需要整那些花活老老實(shí)實(shí)把數(shù)據(jù)鋪出來(lái)就行圖表展示交給前端用 ECharts 渲染性能和美觀(guān)度都遠(yuǎn)超 Excel 自帶圖。6.5 Spring Boot 版本與依賴(lài)沖突用 Spring Boot 3 記得 JDK 必須是 17 及以上MyBatis-Plus 也要用適配 Spring Boot 3 的版本mybatis-plus-spring-boot3-starter。很多同學(xué)項(xiàng)目啟動(dòng)報(bào)一堆錯(cuò)十有八九是 Spring Boot 2 的依賴(lài)習(xí)慣性復(fù)制到了 3 里。還有 Lombok 插件版本也要同步升級(jí)舊版 Lombok 和 JDK 17 組合經(jīng)常出現(xiàn)java.lang.ClassFormatError。我的建議是新項(xiàng)目直接 Spring Boot 3 JDK 17不要猶豫。網(wǎng)上雖然 Spring Boot 2 教程多但類(lèi)名和方法基本一致遇到差異時(shí)翻官方文檔比查舊博客靠譜得多。7. 我想額外說(shuō)給“做畢設(shè)”的人聽(tīng)的幾句話(huà)這套系統(tǒng)作為畢業(yè)設(shè)計(jì)技術(shù)棧非常合適因?yàn)樗募夹g(shù)覆蓋面廣Spring Boot 的接口開(kāi)發(fā)、MyBatis-Plus 的數(shù)據(jù)操作、JWT 認(rèn)證、Vue 的組件化和路由權(quán)限、數(shù)據(jù)庫(kù)設(shè)計(jì)、甚至桌臺(tái)二維碼這種 IoT 邊緣場(chǎng)景都能講出東西來(lái)。但切記——不要堆砌沒(méi)有業(yè)務(wù)邏輯的 CRUD 頁(yè)面。提升項(xiàng)目含金量的方向不是增加頁(yè)面數(shù)量而是把幾個(gè)核心場(chǎng)景做深訂單并發(fā)控制做了沒(méi)有金額計(jì)算是否全程可靠狀態(tài)機(jī)流轉(zhuǎn)是否清晰可追蹤前端交互是否有思考過(guò)真實(shí)用戶(hù)的使用感受有沒(méi)有報(bào)表分析、緩存優(yōu)化這些“非必選但加分”的能力答辯時(shí)能把這幾個(gè)問(wèn)題說(shuō)到位比列十個(gè)“增刪改查模塊”管用得多?？Х葟d管理系統(tǒng)這類(lèi)項(xiàng)目最迷人的地方在于它離真實(shí)生活很近。你把代碼寫(xiě)完、部署上線(xiàn)看著顧客用手機(jī)掃碼下單、收銀臺(tái)打出復(fù)古小票、后廚屏彈出新訂單那種“技術(shù)真的在服務(wù)具體的人”的感覺(jué)會(huì)讓人覺(jué)得這段代碼寫(xiě)得值。如果這個(gè)項(xiàng)目能幫到你哪怕只是其中一個(gè)建表思路、一個(gè)排查方向我就覺(jué)得這篇分享沒(méi)白寫(xiě)。祝你開(kāi)發(fā)順利記得給自己留一杯咖啡的時(shí)間。