簡介本資源是一套基于Spring Boot Vue3 UniApp全棧技術(shù)實(shí)現(xiàn)的點(diǎn)餐小程序完整源碼工程面向Java后端開發(fā)者、前端工程師及跨端小程序?qū)W習(xí)者解決餐飲場景下多端統(tǒng)一交付、前后端分離開發(fā)與快速迭代的實(shí)際需求。壓縮包共499個(gè)文件涵蓋78個(gè)Java后端類含SysGoodsController、UserOrderServiceImpl等核心業(yè)務(wù)控制器與服務(wù)、127個(gè)Vue組件支撐小程序頁面邏輯與交互、58個(gè)JS/40個(gè)TS腳本含API封裝與狀態(tài)管理、40個(gè)PNG圖標(biāo)資源及配置類yml、json、xml等整體19.16MB結(jié)構(gòu)規(guī)范模塊劃分清晰便于二次開發(fā)與教學(xué)分析。已有832人學(xué)習(xí)下載提供可直接運(yùn)行的前后端協(xié)同方案Spring Boot構(gòu)建RESTful接口并集成安全與數(shù)據(jù)庫支持Vue3通過Composition API實(shí)現(xiàn)響應(yīng)式界面UniApp保障微信小程序、H5、App三端一鍵編譯附帶完整訂單、商品、用戶、評論等業(yè)務(wù)閉環(huán)代碼是理解現(xiàn)代全棧開發(fā)協(xié)作模式的優(yōu)質(zhì)實(shí)踐樣本。1. 項(xiàng)目概述與整體設(shè)計(jì)思路做點(diǎn)餐小程序這個(gè)項(xiàng)目最早是因?yàn)榕笥验_了一家小餐廳堂食點(diǎn)單全靠服務(wù)員手寫高峰期經(jīng)常出錯(cuò)后廚出餐順序也亂。他問能不能做一個(gè)客人掃碼就能自己點(diǎn)餐的小程序后廚和前臺能實(shí)時(shí)看到訂單。我盤了一下需求決定用 SpringBoot Vue3 Uniapp 這套組合來做。這套方案選型不是拍腦袋而是基于幾個(gè)現(xiàn)實(shí)約束后端要穩(wěn)定、能扛住并發(fā)Java 系 SpringBoot 是當(dāng)前最成熟的選擇管理端需要做菜單管理、訂單管理、數(shù)據(jù)統(tǒng)計(jì)Vue3 生態(tài)完善、組件豐富非常適合做這類后臺系統(tǒng)用戶端要同時(shí)兼容微信小程序和 H5Uniapp 一套代碼多端發(fā)布省去了重復(fù)開發(fā)的成本。整個(gè)項(xiàng)目本質(zhì)上是一個(gè)典型的前后端分離架構(gòu)。后端只負(fù)責(zé)提供 RESTful API不關(guān)心頁面長什么樣前端分成兩個(gè)獨(dú)立的工程管理端是 Vue3 Element Plus 的 Web 應(yīng)用給餐廳管理員用用戶端是 Uniapp 項(xiàng)目編譯成微信小程序給顧客用。三者之間通過 HTTP/HTTPS 通信數(shù)據(jù)格式統(tǒng)一用 JSON。我畫過一張簡單的架構(gòu)圖在心里小程序端 → Nginx → SpringBoot 服務(wù) → MySQL / Redis管理端同樣走這條路。這樣分層的好處是職責(zé)清晰任何一個(gè)環(huán)節(jié)出問題都能快速定位不至于像老式 JSP 項(xiàng)目那樣前后端代碼揉在一起改個(gè)樣式都要重啟服務(wù)。這套方案的適用人群很明確有一定 Java 基礎(chǔ)、想完整走一遍全棧流程的開發(fā)者或者接私活時(shí)需要快速交付點(diǎn)餐類項(xiàng)目的朋友。項(xiàng)目做完之后可以延伸出很多變體比如奶茶店點(diǎn)單、食堂預(yù)訂、火鍋店叫號等核心流程都是相通的。下面我會按模塊把關(guān)鍵實(shí)現(xiàn)拆開講包括后端接口設(shè)計(jì)、管理端頁面開發(fā)、小程序端核心功能以及實(shí)際部署中踩過的坑盡可能做到看完就能照著做。2. 后端 SpringBoot 核心模塊設(shè)計(jì)與接口實(shí)現(xiàn)2.1 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計(jì)與訂單狀態(tài)機(jī)點(diǎn)餐系統(tǒng)的核心數(shù)據(jù)模型其實(shí)不復(fù)雜但表設(shè)計(jì)直接決定了后面能不能撐住業(yè)務(wù)擴(kuò)展。我最初設(shè)計(jì)時(shí)規(guī)劃了這幾張核心表category分類表、dish菜品表、setmeal套餐表、user用戶表、orders訂單主表、order_detail訂單明細(xì)表、shopping_cart購物車表以及address_book地址簿表。訂單表是整個(gè)系統(tǒng)的核心我重點(diǎn)說一下狀態(tài)字段的設(shè)計(jì)。我用一個(gè)status整數(shù)字段表示訂單狀態(tài)1 待付款、2 待接單、3 已接單制作中、4 派送中/待取餐、5 已完成、6 已取消。這里有個(gè)容易踩坑的地方——很多人喜歡用字符串存狀態(tài)比如PENDING、PAID雖然可讀性高但在數(shù)據(jù)庫層面排序、索引、統(tǒng)計(jì)都不如整數(shù)方便而且接口傳給前端后還得做一層映射轉(zhuǎn)換。我最終選擇了整數(shù) 枚舉類雙向映射的方式Java 代碼里定義枚舉類通過EnumValue注解映射到數(shù)據(jù)庫既能保證代碼可讀性又不犧牲查詢效率。訂單號生成也是個(gè)細(xì)節(jié)活。直接用數(shù)據(jù)庫自增 ID 當(dāng)訂單號暴露給用戶很容易被猜到今天有多少訂單而且多表合并查詢時(shí)不方便。我采用時(shí)間戳 隨機(jī)數(shù)的方案yyyyMMddHHmmss 4位隨機(jī)數(shù)雖然并發(fā)極高時(shí)有極小概率重復(fù)但在加唯一索引的保障下沖突會直接報(bào)錯(cuò)重試實(shí)際跑下來沒出過問題。如果你追求更嚴(yán)格的唯一性可以引入雪花算法但中小型餐廳的并發(fā)量完全沒必要上這么重的方案。2.2 菜品管理接口與文件上傳菜品管理是后端最基礎(chǔ)也最繁瑣的部分。菜品表dish需要關(guān)聯(lián)分類表一個(gè)分類下有多個(gè)菜品菜品有名稱、圖片、價(jià)格、描述、口味標(biāo)簽、起售/停售狀態(tài)等字段。這里我強(qiáng)調(diào)一點(diǎn)status字段一定要加索引因?yàn)榍岸诵〕绦蚴醉撝粫閟tatus 1的起售菜品高頻查詢場景下沒有索引會非常吃虧。菜品圖片上傳我用的方案是本地存儲 Nginx 靜態(tài)映射沒有引入 OSS 對象存儲。原因很簡單個(gè)人項(xiàng)目或小餐廳的量級OSS 的維護(hù)成本和費(fèi)用完全不劃算。實(shí)現(xiàn)方式是后端提供一個(gè)/common/upload接口接收MultipartFile重命名文件避免中文亂碼按日期分目錄存儲然后把可訪問的 URL 返回給前端。重命名規(guī)則我用的是UUID.randomUUID()拼接原始文件擴(kuò)展名這樣能最大程度避免文件名沖突也能防止用戶上傳惡意文件名。靜態(tài)資源映射在 SpringBoot 里只需要在WebMvcConfigurer中加一行registry.addResourceHandler(/upload/**).addResourceLocation(file: uploadPath)非常簡單。菜品的新增和修改往往需要同時(shí)處理口味數(shù)據(jù)。一個(gè)菜品可能有多個(gè)口味比如“辣度微辣/中辣/特辣”如果每次都是先刪后插在高并發(fā)下會出現(xiàn)短暫的“查不到口味”的中間狀態(tài)。我改用事務(wù)方式處理先保存菜品主表拿到主鍵 ID然后遍歷口味列表逐個(gè)插入整個(gè)過程包在Transactional里任何一個(gè)環(huán)節(jié)失敗就整體回滾。之前有朋友問我為什么不用 MyBatis-Plus 的saveBatch批量插入——我當(dāng)時(shí)確實(shí)是逐條插入的原因是口味數(shù)量通常很少最多三五個(gè)逐條插入的性能損耗完全可以忽略但代碼的清晰度會高很多。2.3 微信小程序登錄與 JWT 鑒權(quán)體系小程序端用戶最頭疼的就是登錄鑒權(quán)。傳統(tǒng)的 session 方案在小程序場景下不太好用因?yàn)樾〕绦虻恼埱筇烊粠в锌缬蚝筒l(fā)特性服務(wù)端 session 不一定能保持。我選擇了 JWTJSON Web Token方案服務(wù)端無狀態(tài)、天然支持橫向擴(kuò)展。登錄流程是這樣的小程序端調(diào)用wx.login()獲取臨時(shí) code傳給后端/user/login接口后端拿著 code 調(diào)用微信的jscode2session接口換取 openid查數(shù)據(jù)庫看用戶是否已存在不存在就自動注冊一個(gè)然后把 user 對象的核心信息userId、openid放進(jìn) JWT 的 claims 里簽名后返回 token 給前端。同時(shí)我把用戶第一次登錄的昵稱和頭像也做了一次更新這樣用戶資料會自動同步到最新狀態(tài)。這里有個(gè)容易踩的坑jscode2session接口的 appid 和 secret 一定不能寫在前端代碼里必須放在后端配置文件中否則等于把微信支付等敏感能力暴露給了任何人。我剛開始開發(fā)時(shí)為了方便把 secret 寫死在代碼里后來發(fā)現(xiàn)自己用抓包工具都能看到請求參數(shù)里有 secret嚇出一身冷汗趕緊改成配置項(xiàng)并通過環(huán)境變量注入。JWT 的攔截器實(shí)現(xiàn)用了 SpringBoot 的HandlerInterceptor在preHandle里從請求頭Authorization字段取出 token解析并校驗(yàn)簽名把 userId 放入ThreadLocal中方便后續(xù)業(yè)務(wù)代碼直接獲取。ThreadLocal用完一定要remove()否則線程池復(fù)用會導(dǎo)致數(shù)據(jù)串號這是非常隱蔽的 bug排查起來很痛苦。還有一個(gè)需要注意的點(diǎn)/user/login、/common/upload這類匿名接口要記得在攔截器配置中放行否則前端一進(jìn)來就被攔截連登錄頁都打不開。注意JWT 有個(gè)先天缺陷是無法主動失效。如果用戶需要“退出登錄”功能只能靠前端刪除 token服務(wù)端沒法強(qiáng)制下線。在點(diǎn)餐系統(tǒng)里通常不需要嚴(yán)格處理這個(gè)問題但如果你在做后臺管理系統(tǒng)的鑒權(quán)建議引入 Redis 做 token 黑名單機(jī)制或者干脆用 Redis Token 替代純 JWT。2.4 購物車與訂單提交的事務(wù)處理購物車的 API 相對簡單無非是添加、查看、清空、減少數(shù)量四個(gè)接口本質(zhì)上是對shopping_cart表做增刪改查。但我發(fā)現(xiàn)一個(gè)大多數(shù)人會忽略的點(diǎn)購物車內(nèi)同一菜品添加兩次是插入兩條記錄還是合并數(shù)量我在實(shí)現(xiàn)時(shí)采用了“同一用戶、同一菜品、相同口味則數(shù)量疊加”的策略用查詢條件先去數(shù)據(jù)庫找找到了就setNumber(number 1)找不到才插入新記錄。這種做法的好處是前端購物車列表清爽不會出現(xiàn)同一個(gè)菜品刷屏的情況。訂單提交是整個(gè)系統(tǒng)事務(wù)最重的地方。用戶點(diǎn)擊“提交訂單”后后端需要做一串操作創(chuàng)建訂單主表記錄狀態(tài)為待付款→ 批量插入訂單明細(xì) → 清空購物車 → 如果是“到店自取”還需要通知商家。這一串操作必須全部成功或全部失敗所以我用Transactional(rollbackFor Exception.class)包裹整個(gè)方法。這里rollbackFor必須顯式指定否則默認(rèn)只在運(yùn)行時(shí)異常時(shí)回滾而 Spring 聲明式事務(wù)遇到Exception的檢查型異常是不會自動回滾的很多人踩過這個(gè)坑。訂單金額計(jì)算我建議以后端為準(zhǔn)前端傳的價(jià)格只能作為參考。具體做法是后端根據(jù)購物車?yán)锏牟似?ID 重新查一遍數(shù)據(jù)庫拿到最新單價(jià)乘以數(shù)量計(jì)算總價(jià)防止前端篡改價(jià)格。有些開發(fā)者圖省事直接信任前端傳來的 totalAmount這在真實(shí)項(xiàng)目里是不可接受的——點(diǎn)餐小程序直接跟錢掛鉤任何漏洞都可能造成真金白銀的損失。3. Vue3 管理端從零搭建到核心頁面實(shí)現(xiàn)3.1 腳手架選型與工程結(jié)構(gòu)規(guī)范管理端是一個(gè)典型的單頁應(yīng)用我選用 Vue3 Vite Element Plus Pinia 的組合。Vite 相比 Webpack 在開發(fā)體驗(yàn)上強(qiáng)太多冷啟動基本秒開熱更新也是毫秒級對于整天改 UI 的后臺項(xiàng)目來說能省下大量等待時(shí)間。Vue3 的組合式 APIComposition API配合setup語法糖代碼邏輯聚合度高同一個(gè)功能的變量和方法放在一起不用像 Options API 那樣在data、methods、computed之間反復(fù)橫跳。工程結(jié)構(gòu)我按功能模塊分包而不是簡單按文件類型分src/views放頁面組件src/api放接口請求封裝src/router放路由配置src/store放 Pinia 狀態(tài)管理src/utils放工具函數(shù)如request.js的請求封裝。有一點(diǎn)很關(guān)鍵接口請求必須統(tǒng)一封裝不要在頁面里直接寫axios.get。我在utils/request.js中創(chuàng)建了一個(gè) axios 實(shí)例統(tǒng)一設(shè)置基礎(chǔ) URL 和超時(shí)時(shí)間然后在請求攔截器里加上 token在響應(yīng)攔截器里統(tǒng)一處理后端返回的code/message格式。這樣做的好處是后端接口格式一旦有變化只需要改一個(gè)文件而不用滿項(xiàng)目搜索修改。管理端的接口統(tǒng)一返回{ code: 200, message: 操作成功, data: {...} }結(jié)構(gòu)code 非 200 時(shí)前端彈錯(cuò)誤提示并中斷流程。3.2 動態(tài)菜單與權(quán)限控制方案管理端的用戶分為超級管理員和普通操作員。普通操作員可能只能操作菜品和訂單不能查看營收統(tǒng)計(jì)超級管理員則全部開放。這個(gè)權(quán)限模型在路由層面用“動態(tài)路由”實(shí)現(xiàn)用戶登錄后后端根據(jù)其角色返回可訪問的菜單列表前端拿到后動態(tài)添加路由同時(shí)根據(jù)菜單列表渲染側(cè)邊欄。我在具體實(shí)現(xiàn)中用的是“前端路由表 后端權(quán)限碼”配合的方式。靜態(tài)路由基礎(chǔ)框架包括登錄頁、404 頁動態(tài)路由按模塊配置好 meta 信息如{ title: 菜品管理, icon: Dish, roles: [admin, operator] }。用戶登錄后前端通過store里的generateRoutes方法過濾出當(dāng)前角色可訪問的路由用router.addRoute動態(tài)注冊。這里有幾個(gè)坑一是在頁面刷新后Pinia 的狀態(tài)會丟失需要重新從后端獲取權(quán)限并再次注冊路由否則刷新后白屏二是在router.beforeEach守衛(wèi)中要處理好“已登錄 訪問登錄頁 → 跳轉(zhuǎn)首頁”和“未登錄 → 跳轉(zhuǎn)登錄頁”這兩種情況三是 addRoute 添加的路由如果又刪又要再添加會存在重名警告記得先通過router.removeRoute移除。我實(shí)際測試下來這套方案能解決絕大多數(shù)點(diǎn)餐管理端的權(quán)限需求。如果你在做一個(gè)高度定制化的 SaaS 后臺可能要引入更細(xì)粒度的按鈕級權(quán)限控制但那個(gè)復(fù)雜度會成倍增加個(gè)人項(xiàng)目沒必要一上來就上。3.3 菜品管理頁面的增刪改查與圖片回顯菜品管理頁面是管理端用得最多的功能。我用了一個(gè)“表格 搜索 彈窗表單”的組合列表頁頂部放分類篩選和菜品名稱關(guān)鍵字搜索表格顯示菜品圖片、名稱、分類、價(jià)格、狀態(tài)、操作列新增和編輯共用一個(gè)彈窗組件里面是表單校驗(yàn)、圖片上傳、口味設(shè)置。這里我重點(diǎn)說一下圖片上傳組件的封裝。Element Plus 的el-upload組件功能全面但直接用在表單里有兩個(gè)問題一是el-upload自帶一套 action URL不方便統(tǒng)一走我們封裝的 axios 實(shí)例因?yàn)橐獛?token 頭二是回顯時(shí)需要手動把 URL 轉(zhuǎn)成文件列表格式這個(gè)轉(zhuǎn)換邏輯在不同頁面會重復(fù)。我封裝出一個(gè)ImageUpload.vue組件內(nèi)部用http-request自定義上傳方法走統(tǒng)一的 axios 實(shí)例上傳成功后把返回的 URL 通過v-model暴露給父組件回顯時(shí)在on-change里做處理。這樣菜品、套餐、分類都直接用同一個(gè)上傳組件一行代碼搞定省了無數(shù)重復(fù)工?？谖对O(shè)置是一個(gè)動態(tài)表單點(diǎn)擊“添加口味”會追加一行表單控件每行包括口味名稱如“辣度”和可選值如“微辣/中辣/特辣”。這里我用了 Vue3 的v-for結(jié)合reactive數(shù)組增刪行就是 push 和 splice。在提交前要注意把所有空行過濾掉否則用戶點(diǎn)擊了“添加口味”又沒填內(nèi)容就提交會有空數(shù)據(jù)入庫。這個(gè)小問題曾經(jīng)困擾了我一個(gè)下午后來在過濾邏輯中統(tǒng)一處理才解決。3.4 訂單管理與數(shù)據(jù)統(tǒng)計(jì)的兩個(gè)關(guān)鍵頁訂單管理頁面相對簡單核心是列表篩選詳情。篩選條件包括訂單號關(guān)鍵字、訂單狀態(tài)、下單時(shí)間段。訂單號我用了模糊查詢狀態(tài)用精確匹配時(shí)間段用BETWEEN查詢。這里涉及一個(gè) MyBatis-Plus 的LambdaQueryWrapper使用技巧多個(gè)篩選條件要判斷非空再拼接否則用戶不選時(shí)間段的默認(rèn)查詢會出問題。訂單詳情彈窗是查看某個(gè)訂單的菜品明細(xì)、金額明細(xì)、用戶信息和配送信息。這里涉及多表聯(lián)合查詢我在后端寫了一個(gè)getOrderDetailWithDish方法先查訂單主表再查訂單明細(xì)表再把每個(gè)明細(xì)里對應(yīng)的菜品名稱和圖片查出來。出于性能優(yōu)化考慮我在這里用了一次FOR循環(huán) 批量查詢的方式而不是逐條查詢——即使這樣在實(shí)際場景中一個(gè)訂單最多也就十來個(gè)菜品性能壓力基本可以忽略。數(shù)據(jù)統(tǒng)計(jì)頁面我用了 ECharts 做可視化。兩個(gè)核心圖表近 7 天營業(yè)額折線圖、分類銷售占比餅圖。后端提供兩個(gè)統(tǒng)計(jì)接口一個(gè)是按日期分組求和另一個(gè)是按分類分組求和。SQL 寫法上日期分組用DATE_FORMAT(order_time, %Y-%m-%d)做分組條件分類匯總用JOIN order_detail和JOIN dish做關(guān)聯(lián)。這里有個(gè)需要處理好的細(xì)節(jié)用戶選的日期范圍可能跨月直接用%Y-%m-%d分組沒問題但如果跨年后續(xù)前端顯示時(shí)最好連年份一起展示。4. Uniapp 小程序端的核心功能實(shí)現(xiàn)與適配4.1 頁面結(jié)構(gòu)與 tabBar 配置用戶端小程序的功能相對集中我設(shè)計(jì)了四個(gè)底部 tab 頁首頁點(diǎn)餐、訂單、購物車、我的。這個(gè)結(jié)構(gòu)經(jīng)過多次調(diào)整——最初我還加了“收藏”頁后來發(fā)現(xiàn)使用率極低果斷下線?？彻δ芤彩情_發(fā)的一部分忍住加功能的沖動往往比實(shí)現(xiàn)功能更重要。頁面結(jié)構(gòu)確定后需要在pages.json里配置 tabBar。tabBar 的圖標(biāo)我直接用 PNG 格式尺寸要求 81px 81px不能超過 40KB否則真機(jī)預(yù)覽時(shí)圖標(biāo)會不顯示。這個(gè)坑是微信小程序的老規(guī)矩很多新手第一次配 tabBar 就栽在圖標(biāo)尺寸上。還有一個(gè)細(xì)節(jié)tabBar 頁面不能使用uni.navigateTo跳轉(zhuǎn)必須用uni.switchTab否則會報(bào)錯(cuò)說頁面不存在。我剛開始不知道這個(gè)限制寫接口時(shí)跳轉(zhuǎn)總失敗查了半天才發(fā)現(xiàn)是跳轉(zhuǎn)方法用錯(cuò)了。小程序的頁面結(jié)構(gòu)還有一點(diǎn)要注意pages數(shù)組中的第一項(xiàng)是啟動頁也就是冷啟動時(shí)默認(rèn)加載的頁面。我把首頁放在第一位確保用戶打開小程序就能看到點(diǎn)餐界面而不是先進(jìn)登錄頁。登錄邏輯我放在“進(jìn)入首頁后靜默登錄”的流程中用戶無感知體驗(yàn)會好很多。4.2 點(diǎn)餐首頁與分類聯(lián)動實(shí)現(xiàn)點(diǎn)餐首頁是整個(gè)小程序最核心也最復(fù)雜的頁面。布局采用“左分類、右菜品”的雙欄滾動結(jié)構(gòu)左側(cè)是豎向滾動的一級分類列表右側(cè)是分類下菜品列表。這個(gè)結(jié)構(gòu)有兩個(gè)實(shí)現(xiàn)方案一是左側(cè)點(diǎn)擊分類時(shí)右側(cè)列表跳轉(zhuǎn)到對應(yīng)位置二是左右兩側(cè)獨(dú)立滾動右側(cè)滾動經(jīng)過某個(gè)分類時(shí)左側(cè)高亮自動切換。我選擇了第二種因?yàn)樗咏缊F(tuán)、餓了么的主交互。實(shí)現(xiàn)方案需要分別給左側(cè)和右側(cè)設(shè)置scroll-view右側(cè)監(jiān)聽scroll事件獲取滾動的 scrollTop與各分類的 offsetTop 做對比判斷當(dāng)前應(yīng)該高亮哪個(gè)分類。能觸發(fā)scroll-view滾動事件的屬性是scroll取滾動距離用event.detail.scrollTop。這里有個(gè)行業(yè)通用的坑兩個(gè)scroll-view嵌套時(shí)內(nèi)層滾動會與外層滾動沖突解決方案是給內(nèi)層設(shè)置scroll-y并確保外層沒有滾動或者用 flex 布局把高度撐滿。我經(jīng)過多次試驗(yàn)最終用flex: 1 固定高度的方式解決了滾動沖突效果很穩(wěn)定。菜品的加購操作我加了一個(gè)“SKU 選擇彈窗”。部分菜品有口味和規(guī)格用戶點(diǎn)擊加購時(shí)不能立刻加入購物車而是彈出選擇窗口選完規(guī)格后確認(rèn)。這個(gè)彈窗的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)為每個(gè)菜品包含specs數(shù)組如[{ name: 規(guī)格, values: [小份, 大份], priceDelta: [0, 8] }]總價(jià)等于基礎(chǔ)價(jià)加上所有priceDelta的累加值。由于涉及價(jià)格計(jì)算我在computed里做了動態(tài)求和確保任何規(guī)格變化都會自動刷新展示價(jià)格。4.3 購物車邏輯與本地狀態(tài)管理購物車頁面的狀態(tài)管理我選擇了 Pinia因?yàn)樾〕绦蚨撕?Web 端的共享邏輯幾乎一致Pinia 在 Uniapp 中配合 Vue3 使用非常自然。購物車的狀態(tài)包括cartList數(shù)組每個(gè)元素是菜品 ID、名稱、圖片、單價(jià)、數(shù)量、規(guī)格組合。所有增刪改操作都封裝成 action在頁面中只需調(diào)用store.addToCart(dish)或store.removeFromCart(dishId)。購物車有一個(gè)兩個(gè)頁面需要同步的數(shù)據(jù)問題首頁的購物車圖標(biāo)右上角要顯示數(shù)量角標(biāo)而角標(biāo)數(shù)據(jù)存在 store 里。小程序中 store 是內(nèi)存級共享頁面切換不會丟失但小程序冷啟動時(shí)會重新加載初始狀態(tài)如果用戶上次沒提交訂單購物車數(shù)據(jù)就丟了。我在實(shí)現(xiàn)時(shí)用了uni.setStorageSync做了持久化購物車每次變更時(shí)同步寫入本地存儲應(yīng)用啟動時(shí)讀取本地存儲初始化 store。這樣即使用戶殺掉小程序重進(jìn)購物車也能恢復(fù)不過要記得在訂單提交成功后清除對應(yīng)存儲。還有個(gè)細(xì)節(jié)購物車的選中狀態(tài)和結(jié)算邏輯分開設(shè)計(jì)。比如購物車中有 A、B 兩個(gè)菜品用戶勾選了 A結(jié)算時(shí)只計(jì)算 A 的價(jià)格。這個(gè)實(shí)現(xiàn)其實(shí)不復(fù)雜在cartList每項(xiàng)加一個(gè)checked布爾值結(jié)算按鈕的金額通過computed計(jì)算出“所有 checked 為 true 的項(xiàng)的價(jià)格總和”。這里很多人會忘記處理“勾選了但商品已下架”的邊界情況我在每次拉取菜品狀態(tài)時(shí)做了比對如果下架則自動置灰且不可勾選避免用戶付了錢發(fā)現(xiàn)商品沒了。4.4 微信支付與訂單狀態(tài)更新流支付環(huán)節(jié)是整個(gè)小程序端最繞不開的坎。微信小程序支付必須走統(tǒng)一下單流程前端調(diào)用后端/order/pay接口后端接收訂單號后調(diào)用微信支付 API 生成預(yù)支付交易單拿到prepay_id后返回給前端wx.requestPayment所需的參數(shù)timeStamp、nonceStr、package、signType、paySign。這里最關(guān)鍵的一點(diǎn)是小程序端的 appid 必須和微信支付商戶號綁定否則會報(bào)錯(cuò)appid and mch_id not match這個(gè)綁定關(guān)系需要在微信支付商戶平臺設(shè)置不是代碼能解決的。我最初在這個(gè)問題上卡了整整一天反復(fù)檢查代碼都找不出問題后來才想起檢查商戶平臺的綁定關(guān)系。支付成功后的狀態(tài)更新我采用“支付回調(diào) 前端輪詢確認(rèn)”的雙保險(xiǎn)方案。微信支付成功后微信服務(wù)器會向商戶后臺配置的notify_url發(fā)送異步通知后端接收后校驗(yàn)簽名、更新訂單狀態(tài)為“待接單”。由于回調(diào)是異步的前端在wx.requestPayment的success回調(diào)里不能立刻認(rèn)為訂單已完成支付而應(yīng)該跳轉(zhuǎn)到訂單詳情頁后通過輪詢或setInterval定時(shí)請求訂單狀態(tài)接口確認(rèn)結(jié)果為已支付后再渲染結(jié)果頁。這個(gè)細(xì)節(jié)很多人會忽略導(dǎo)致用戶付款成功后看到的狀態(tài)還是“待付款”體驗(yàn)極差。注意微信支付異步通知的地址必須是 HTTPS 公網(wǎng)地址而且回調(diào)處理要滿足冪等性——同一筆訂單的通知可能重復(fù)發(fā)送多次后端拿到通知要先查訂單狀態(tài)已支付就直接返回成功不要再做重復(fù)更新。4.5 uniapp 跨端適配與真機(jī)調(diào)試一個(gè) Uniapp 項(xiàng)目除了微信小程序通常還要兼顧 H5 打包所以我在開發(fā)時(shí)盡量使用uni.開頭的 API 而不是直接調(diào)用wx.系列 API。例如跳轉(zhuǎn)頁面用uni.navigateTo、彈出提示用uni.showToast、本地存儲用uni.setStorageSync。如果必須要用某個(gè)平臺的特定 API我會用條件編譯#ifdef MP-WEIXIN包裹確保 H5 端不會因缺失 API 而報(bào)錯(cuò)。真機(jī)調(diào)試中我遇到的最典型的適配問題有兩個(gè)一是 iPhone 底部安全區(qū)在page.json中設(shè)置app-plus的safeArea配置或者使用 CSS 的env(safe-area-inset-bottom)來適配底部操作欄否則購物車結(jié)算按鈕會被 Home 指示條遮擋二是頁面滾動穿透彈窗打開時(shí)底層的頁面仍然可以滾動解決方法是給彈窗層的touchmove.stop.prevent阻止事件冒泡。另外在所有涉及到圖片的頁面要設(shè)置modeaspectFill否則不同分辨率下手機(jī)會出現(xiàn)圖片拉伸變形這個(gè)問題在菜品列表和輪播圖中尤其明顯。5. 前后端聯(lián)調(diào)部署與常見問題排查5.1 開發(fā)環(huán)境跨域配置與本地聯(lián)調(diào)前后端分離開發(fā)最大的攔路虎就是跨域。前端開發(fā)服務(wù)器跑在localhost:5173后端接口在localhost:8080瀏覽器默認(rèn)會攔截跨域請求。我在 SpringBoot 后端配置了一個(gè)全局 CORS 過濾器允許所有來源訪問但在生產(chǎn)環(huán)境會限制為具體域名。這里有個(gè)容易迷惑的地方小程序端請求后端接口其實(shí)不涉及跨域限制因?yàn)樾〕绦虻恼埱蟛辉跒g覽器環(huán)境里真正需要跨域處理的是 H5 端和管理端。開發(fā)時(shí)我用的代理方案Vite 配置文件里設(shè)置server.proxy把/api前綴的請求代理到http://localhost:8080。這樣做的好處是前端代碼里請求的 URL 可以寫相對路徑/api/xxx不需要關(guān)心后端實(shí)際的 IP 和端口部署時(shí)切換環(huán)境也只需要改代理配置。后端 Controller 的RequestMapping我統(tǒng)一加了/api前綴這樣語義清晰也能跟非接口的靜態(tài)資源請求區(qū)分開。5.2 Nginx 部署與 HTTPS 證書配置生產(chǎn)環(huán)境我選擇用 Nginx 做反向代理承載前端的靜態(tài)資源服務(wù)同時(shí)把/api請求轉(zhuǎn)發(fā)給后端 Java 進(jìn)程。Nginx 配置文件的關(guān)鍵部分如下server { listen 443 ssl; server_name yourdomain.com; ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; # 前端資源 location / { root /var/www/admin-dist; index index.html; try_files $uri $uri/ /index.html; } # 后端接口 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 圖片資源 location /upload/ { alias /data/upload/; } }需要注意的細(xì)節(jié)try_files這行是 SPA 路由的基礎(chǔ)配置沒有它刷新 Vue 路由子頁面會報(bào) 404。proxy_pass后面的 URL 末尾有沒有/會影響路徑拼接——http://127.0.0.1:8080不帶斜杠表示保留完整原始 URI帶斜杠會去掉location匹配到的前綴這個(gè)規(guī)則容易搞混我是吃了虧才記住的。HTTPS 證書我用的是免費(fèi)證書配合自動續(xù)期腳本到期前自動續(xù)簽基本不需要人工干預(yù)。微信小程序要求所有請求域名必須配置在request合法域名中而且必須是 HTTPS沒有證書小程序根本發(fā)起不了請求這部分在開發(fā)時(shí)就要規(guī)劃好不能等到上線前才臨時(shí)搞。5.3 MySQL 連接、Redis 緩存與并發(fā)扣庫存數(shù)據(jù)庫我用了 MySQL 8.x連接池使用 HikariCP這是 SpringBoot 2.x 之后默認(rèn)集成的連接池性能非常出色。HikariCP 有幾個(gè)關(guān)鍵參數(shù)值得配置maximum-pool-size連接池最大連接數(shù)我設(shè)為 20minimum-idle最小空閑連接數(shù)設(shè)為 5connection-timeout連接超時(shí)設(shè)為 30000 毫秒。如果是個(gè)人開發(fā)環(huán)境保持默認(rèn)值也完全夠用但生產(chǎn)環(huán)境建議至少設(shè)置一下maximum-pool-size否則高并發(fā)下連接數(shù)不夠會導(dǎo)致接口緩慢。Redis 在這個(gè)項(xiàng)目里我用在三個(gè)方面首頁菜品列表的緩存、用戶 token 黑名單、驗(yàn)證碼存儲。菜品列表緩存是性價(jià)比最高的優(yōu)化手段——菜品數(shù)據(jù)一般不經(jīng)常變化我在新增、修改、刪除菜品時(shí)主動刪除對應(yīng)緩存查詢時(shí)先查緩存緩存不存在再查庫并回填。這個(gè)策略能顯著減少數(shù)據(jù)庫壓力在高峰期尤其明顯。并發(fā)扣庫存的部分我使用 Redis 的DECR命令實(shí)現(xiàn)原子扣減防止超賣。菜品表中有stock字段表示庫存用戶提交訂單時(shí)對菜品 ID 對應(yīng)的 Redis key 執(zhí)行DECR如果返回值小于 0 則說明庫存不足回滾事務(wù)。這個(gè)方案比數(shù)據(jù)庫的樂觀鎖更簡單而且天然支持分布式場景。不過要注意Redis 只是扣減計(jì)數(shù)的“臨時(shí)臺賬”最終庫存的持久化還是要靠數(shù)據(jù)庫更新同時(shí)配合定時(shí)任務(wù)做數(shù)據(jù)對賬。外賣場景下超出庫存的訂單還會觸發(fā)短信通知運(yùn)營人員補(bǔ)貨。5.4 支付回調(diào)丟失、訂單不同步等典型問題聯(lián)調(diào)階段遇到最多的問題集中在支付環(huán)節(jié)。第一種是支付回調(diào)丟失用戶付了錢但訂單狀態(tài)沒更新。排查思路先看后端日志有沒有收到微信回調(diào)如果沒收到大概率是notify_url配置錯(cuò)誤或者回調(diào)接口響應(yīng)不合法微信要求接口必須返回{code:SUCCESS}的 XML 格式且 HTTP 狀態(tài)必須為 200。我踩過最蠢的一個(gè)坑回調(diào)接口返回了 JSON 格式微信服務(wù)器認(rèn)為回調(diào)失敗連續(xù)重試多次全部失敗后放棄通知只能靠用戶反饋才發(fā)現(xiàn)。第二種是訂單狀態(tài)不一致。用戶支付成功但后端由于回調(diào)延遲還未更新訂單狀態(tài)用戶刷新頁面看到“待付款”就重復(fù)支付了一次。用前面提到的“前端支付成功后輪詢訂單狀態(tài) 后端回調(diào)冪等”方案后這個(gè)問題基本杜絕。另外我在訂單表中增加了pay_time字段對賬時(shí)可以根據(jù)這個(gè)字段排查支付記錄和訂單狀態(tài)是否匹配。第三種是小程序冷啟動后登錄態(tài)丟失。由于 JWT 存在本地存儲中用戶刪除小程序后重新打開本地 token 清空按常理應(yīng)重新靜默登錄。我在App.vue的onLaunch中先讀取本地 token有 token 就帶著去請求用戶信息接口驗(yàn)證有效性如果 token 無效或過期再走wx.login()重新登錄。這套流程能夠保證用戶打開就能點(diǎn)餐同時(shí)不會頻繁彈登錄框打擾正常使用。5.5 數(shù)據(jù)備份與日志排查的必備技巧上線后最怕的就是數(shù)據(jù)丟失。我的備份策略是每天凌晨 2 點(diǎn)執(zhí)行一次 MySQL 全量備份使用mysqldump命令導(dǎo)出 SQL 文件保留最近 7 天的備份再加上異地備份一份到云存儲。備份腳本用 crontab 定時(shí)執(zhí)行關(guān)鍵命令如下0 2 * * * mysqldump -u root -pXXXXXX ordering /backup/ordering_$(date \%Y\%m\%d).sql find /backup/ -name *.sql -mtime 7 -exec rm {} \;日志排查方面SpringBoot 項(xiàng)目我使用logback配置了按天滾動的文件日志。生產(chǎn)環(huán)境一旦出問題我先看logs/spring.log重點(diǎn)搜索 ERROR 和 Exception 關(guān)鍵字同時(shí)配合retention參數(shù)配置了 Redis 的鍵過期時(shí)間避免內(nèi)存無限增長。這里有個(gè)經(jīng)驗(yàn)在 Controller 層統(tǒng)一加一個(gè)日志切面自動打點(diǎn)記錄請求路徑、參數(shù)、耗時(shí)、響應(yīng)碼聯(lián)調(diào)和排錯(cuò)能省一半時(shí)間。切面 AOP 配置如下Around(execution(* com.example.controller.*.*(..))) public Object logAround(ProceedingJoinPoint pjp) throws Throwable { long start System.currentTimeMillis(); Object result pjp.proceed(); long elapsed System.currentTimeMillis() - start; log.info(Request: {}, Params: {}, Cost: {}ms, Response: {}, pjp.getSignature(), JSON.toJSONString(pjp.getArgs()), elapsed, JSON.toJSONString(result)); return result; }這套日志方案配合后續(xù)的鏈路追蹤基本可以覆蓋絕大多數(shù)異常的定位需求。實(shí)測在生產(chǎn)環(huán)境高峰時(shí)每秒鐘幾十個(gè)請求日志量雖然不小但配合 grep 工具定位一個(gè)異常通常幾分鐘就能完成。6. 經(jīng)驗(yàn)總結(jié)與擴(kuò)展方向這個(gè)項(xiàng)目從立項(xiàng)到上線前前后后花了我一個(gè)多月時(shí)間中間踩過的坑、收獲的經(jīng)驗(yàn)我覺得可以總結(jié)成幾條第一前后端分離是發(fā)展趨勢但溝通成本會顯著上升。接口文檔一定要及時(shí)維護(hù)我一開始用 Word 手寫后來切換到 Apifox 在線文檔聯(lián)調(diào)效率提升了一個(gè)檔次。建議所有接口變更都同步更新文檔不要“順手改了代碼忘了改文檔”否則后端改完接口前端還在用舊參數(shù)調(diào)用排查半天才發(fā)現(xiàn)是兩邊對不上。第二狀態(tài)機(jī)設(shè)計(jì)決定了業(yè)務(wù)流程的清晰度。訂單狀態(tài)從待付款到已完成每一步都要有明確的操作入口和權(quán)限控制。不要為了省事把狀態(tài)流轉(zhuǎn)寫死在多個(gè)頁面的判斷邏輯里我最初的版本就是這樣后來發(fā)現(xiàn)新增一個(gè)“退款中”狀態(tài)幾乎要改十幾個(gè)文件痛定思痛后重構(gòu)為集中式狀態(tài)管理后續(xù)擴(kuò)展就從“改動無數(shù)處”變成了“改一個(gè)枚舉類”省心太多。第三測試環(huán)境要盡量貼近生產(chǎn)。小程序端最忌諱拿開發(fā)者工具里的模擬數(shù)據(jù)去測微信支付、微信登錄這些能力必須真機(jī)調(diào)試才能暴露真實(shí)問題。我建議在開發(fā)早期就做好內(nèi)測流程重點(diǎn)測支付流程、多端適配、弱網(wǎng)環(huán)境這三個(gè)場景。第四關(guān)于項(xiàng)目的后續(xù)擴(kuò)展我列幾個(gè)可以玩的方向一個(gè)是接入 WebSocket 實(shí)現(xiàn)商家端實(shí)時(shí)接單提醒用戶在 App 上下單后商家能立刻收到彈窗而不是靠輪詢幾秒才刷新一次另一個(gè)是引入更靈活的營銷能力比如優(yōu)惠券、滿減、會員積分這個(gè)模塊的核心是規(guī)則引擎設(shè)計(jì)需要考慮的地方更多還有一個(gè)是把小程序端升級為 React Native 或原生進(jìn)一步提升復(fù)雜頁面的性能比如商品列表更長的場景下scroll-view的渲染性能會到瓶頸需要考慮虛擬列表。如果你也想做點(diǎn)餐類項(xiàng)目我建議第一版不要貪大求全優(yōu)先保證核心閉環(huán)能跑通用戶能瀏覽菜品、加購、下單、支付商家能收到訂單、出餐、完成訂單。把這些跑通了就已經(jīng)是一套能用的商業(yè)系統(tǒng)了。后面那些花里胡哨的功能等真正有客戶在使用、有真實(shí)痛點(diǎn)了再加也不遲。本文還有配套的精品資源點(diǎn)擊獲取