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