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