★ FEATURED ARTICLE 点餐小程序的本质就是把线下餐饮的交易链路完整搬到线上。用户在小程序里完成“浏览菜单、加购、下单、支付、查看订单状态”这一整串动作商家在管理后台处理订单、维护菜品。听起来不复杂但真正落地一套能跑通前后端的系统牵扯到的东西远比想象中多前端组件拆分、状态管理、路由守卫、接口封装、订单状态流转、支付回调、后端数据模型设计任何一个环节没想清楚后期维护都是噩梦。这篇文章我想从一个实际可运行的“Vue外卖点餐小程序系统2026年最新版”项目出发聊聊这套系统的完整设计思路与实操落地过程。我会拆掉后端和前端两层把项目结构、核心模块、关键代码逻辑、部署联调步骤以及我在开发中踩过的坑全部摆到台面上。无论你是刚开始学Vue、想做毕业设计还是想给团队快速搭一套点餐Demo做业务验证这篇内容都能给你一个可以直接照着做的参考框架。1. 项目全景这个点餐系统到底做了什么1.1 面向的角色与使用场景这套系统模拟了一个完整的点餐业务闭环涉及两个端面向消费者的点餐小程序端以及面向商家的运营管理端。先说用户端。用户进入小程序后第一眼看到的是店铺首页包含店铺信息、公告、推荐菜品轮播。往下是菜品分类区左侧是分类导航热销、主食、小吃、饮品……右侧是对应分类下的菜品列表每个菜品卡片展示图片、名称、月售、价格点击可进入菜品详情页查看规格和描述。用户可以把菜品加入购物车在购物车中调整数量、清空提交订单后进入确认页面选择配送地址和备注然后模拟支付支付成功后生成订单。订单列表中能看到“待支付/进行中/已完成/已取消”等状态对应的订单详情页会展示完整的商品快照、金额明细和配送信息。再说商家端。商家通过管理后台登录后可以维护菜品分类与菜品信息包括上架/下架、改价格、传图片、调整库存可以处理订单比如接单、制作完成、配送中、完成还可以查看简单的统计数据比如今日订单数、营收额、热销菜品Top榜等。这基本覆盖了一个外卖小程序在MVP阶段需要的全部核心功能。如果你要拿去做毕设或者企业内部演示Demo这个功能边界是够用的而且能完整体现业务闭环。1.2 技术栈选型与版本说明项目标称为“2026年最新版”这里面的关键点在于前端使用了Vue 3的全家桶方案而不是老旧的Vue 2。客户端部分用了Vue 3 TypeScript Pinia Vue Router。组件通信和全局状态通过Pinia管理相比VuexPinia的API更简洁对TypeScript的支持也更好写起来几乎没有冗余模板代码。路由使用Vue Router 4配合路由守卫做登录态校验和页面访问控制。跨端方案上项目通过uni-app实现小程序端的构建。uni-app的核心价值在于一套代码编译到微信小程序、H5等多个平台。对于点餐这种业务最大的收益不是真的要做多端发布而是在调试阶段可以先用H5模式在浏览器里快速跑通流程最后再编译到小程序开发工具里验证开发效率高很多。服务端部分完整版项目里附带了一个基于Node.js的API服务用Express搭建配合一个轻量的JSON文件或SQLite存储数据。没有引入重型数据库这样本地部署成本极低不需要装MySQL、Redis只需要有Node环境就能跑起来对新手特别友好。整个架构是典型的前后端分离模式。小程序端通过HTTP请求访问Node服务Node服务负责处理业务逻辑、读写数据、对接模拟支付。支付环节没有接真实微信支付而是用“模拟支付”按钮代替真实打款流程这一点对学习场景反而更友好不需要申请商户号也不用处理复杂的回调验签。2. 前端核心细节从页面拆分到状态设计2.1 页面结构与路由规划整个小程序端的页面结构是围绕“用户点单路径”来设计的页面不多但每个页面承担的任务非常明确。主包页面包括首页店铺首页 分类菜品列表 购物车浮层商品详情页购物车页确认订单页订单列表页订单详情页个人中心页登录页在uni-app的项目结构中这些页面放在pages目录下路由配置在pages.json里。这里的核心设计思路是首页承载了浏览和加购的主要操作购物车以“浮层独立页”两种形态存在。浮层让用户在主流程中不用跳转就能看到购物车情况独立页则解决用户想仔细核对商品的需求。路由层面项目用uni-app自带的uni.navigateTo和uni.switchTab管理跳转不需要像纯Web应用那样手动配Vue Router。但如果你把同一套代码跑在H5端Vue Router依然在底层起作用。所以理解“uni-app的路由本质上仍然是Vue Router的封装”这一点很重要跳转传参的方式、页面栈的概念都是相通的。2.2 状态管理的核心设计点餐业务中状态管理中最核心的部分就是购物车。购物车数据必须做到持久化 跨页面共享。用户从首页加购跳到详情页再返回购物车数量不能丢小程序杀掉重开购物车最好还能恢复至少不能直接被清空。这两个需求分别对应Pinia的Store设计和持久化策略。项目中购物车Store的核心设计思路是用Map结构或普通对象存储商品ID为键、商品项为值的映射关系。每个购物车项除了包含商品基本信息名称、图片、价格还必须包含以下字段interface CartItem { id: string; // 购物车项ID productId: string; // 菜品ID name: string; price: number; image: string; quantity: number; spec?: string; // 规格比如中杯/大杯 checked: boolean; // 用于结算勾选 stock: number; // 下单时校验库存 }购物车的操作API设计成五个核心方法addItem、removeItem、updateQuantity、clearCart、settleSelectedItems。每个方法都同时负责更新内存状态和同步持久化缓存。持久化用uni.setStorageSync和uni.getStorageSync每次操作购物车后同步写入本地App启动时再从本地恢复。这里一个关键决策是为什么不把购物车数据全部交给服务端原因是体验问题。外卖场景中用户加购、改数量非常频繁每次修改都打接口会明显增加页面卡顿感而且网络异常时购物车就废了。所以购物车采用“本地为主、服务端校验”的策略本地负责流畅的交互反馈提交订单时再传服务端做最终的价格计算和库存扣减。这是电商类项目里非常经典的方案。2.3 请求层封装与接口设计请求层是全项目中最容易被忽略但极其重要的一层。在未封装的状态下代码里到处是零散的uni.request({ url: xxx, success: ... })后期改域名、加token、做统一的错误提示全得靠人肉搜索替换。这个项目里做了一层统一的request封装核心代码如下// utils/request.ts const BASE_URL http://localhost:3000/api/v1 interface RequestOptions { url: string method?: GET | POST | PUT | DELETE data?: any loading?: boolean } const request async T(options: RequestOptions): PromiseT { const token uni.getStorageSync(token) return new Promise((resolve, reject) { uni.request({ url: ${BASE_URL}${options.url}, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: token ? Bearer ${token} : }, success: (res) { const data res.data as any if (data.code 0) { resolve(data.data as T) } else { uni.showToast({ title: data.message || 请求失败, icon: none }) reject(data) } }, fail: (err) { uni.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) } export const http { get: T(url: string) requestT({ url, method: GET }), post: T(url: string, data?: any) requestT({ url, method: POST, data }), put: T(url: string, data?: any) requestT({ url, method: PUT, data }), delete: T(url: string, data?: any) requestT({ url, method: DELETE, data }) }这段封装主要做了四件事统一拼接BASE_URL整个项目只需要维护一个域名常量切换测试环境、生产环境时只改一处。自动从本地存储读取token并注入Authorization头登录态统一处理。统一切割后端返回格式。约定后端一律返回{ code: 0, message: ok, data: ... }前端在成功时直接取出data失败时统一弹Toast业务代码里不需要再写重复的错误处理逻辑。返回Promise对象让业务层用async/await书写异步逻辑避免回调地狱代码可读性大幅提升。这套模式是标准做法但很多初学者容易在两个点上犯错一是BaseURL配置中用相对路径而不是绝对路径导致真机调试时请求全部404二是不做统一的错误拦截导致每一个请求回调里都写一遍showToast代码冗余严重。这两个问题在真实项目中非常典型。2.4 用户登录与权限控制点餐系统里登录流程的体验直接影响下单转化率。项目中的登录采用“静默登录 一键登录”结合的方式。所谓静默登录是指用户打开小程序时通过uni.login获取临时授权码code发给后端换取自定义登录态token此时用户其实已经是一个“匿名用户”可以浏览和加购只是没有真实手机号绑定。到真正下单或查看订单时如果用户没有绑定手机号则弹出授权界面通过uni.getUserProfile或手机号快捷验证完成绑定。这里涉及到一个在2022年后变成硬性合规要求的变化微信小程序不再提供默认的“用户点击按钮即可获取头像昵称”接口。如果你的项目是2026年最新版还保留着旧版getUserProfile获取头像昵称的方式在审核时会被打回。所以新版项目里用户头像昵称改为由用户主动填写或使用微信头像昵称填写组件手机号则使用button open-typegetPhoneNumber的官方能力。我在项目里看到的做法是后端下发一个POST /api/v1/auth/login接口接收code参数返回token和userInfo。前端在App启动时检查本地有无token没有则静默登录有则用token拉取用户信息。路由跳转时在需要登录的页面前统一加守卫判断。2.5 核心页面实现逻辑拆解拿首页来说它的UI结构是典型的“左分类右列表”布局。页面通过scroll-view实现左右两个滚动区域并且需要保证左右滚动互不干扰、点左侧分类右侧列表滚动到对应分组、右侧滚动时左侧分类自动高亮。这是一段非常经典的双向联动逻辑。分类切换用activeCategoryId变量记录当前选中分类左侧点击分类时右侧列表通过scroll-into-view属性滚动到对应分组的锚点anchor-xxx。右侧滚动时通过scroll-view的scroll事件结合IntersectionObserver或手动计算各分组位置来判断当前视口顶部的分组反向更新左侧高亮。这套联动逻辑在移动端很常见新手写起来容易卡住关键是锚点命名必须与分组ID严格对应。购物车浮层则是另一处核心交互。首页底部的购物车栏在无商品时显示灰色背景有商品时变为主题色并展示总价、总件数。点击后弹出半屏弹层展示已加菜品清单支持滑动删除单项、快捷加减数量。半屏弹层在小程序里通常用uni-popup组件或自己用position: fixedtransition实现。开发时要注意iPhone底部安全区弹层底部要加env(safe-area-inset-bottom)的适配否则在全面屏上会挡住内容。3. 后端接口与代码组织搭建数据流的核心骨架3.1 数据模型与外键关系设计后端的数据层设计直接决定前端能做什么操作。这个项目核心的数据模型有四组用户、菜品、订单、购物车购物车在后端只作为结算校验不存长期状态所以重点是前三个。用户表保存openid、nickname、avatar、phone、created_at。订单表保存order_id业务编号、user_id、total_amount、status、address、remark、created_at、paid_at等。菜品表保存category_id、name、desc、price、image、stock、is_on_sale。订单明细表保存order_id、product_id、product_name、product_image、price、quantity、spec。这里有一个设计要点订单明细中必须保存下单那一刻的商品快照产品名、原价、图片、规格而不是只存商品ID。原因很容易理解——商家后续修改了菜品价格或者直接下架了某道菜历史订单里如果只存了商品ID那用户查看历史订单时价格和名称就会变成现在的价格甚至显示“商品已失效”这是严重的数据完整性问题。快照存储是外卖系统甚至整个电商系统的通用原则。订单状态字段用数字枚举表示0待支付1待接单2制作中3配送中4已完成5已取消。前端在对应用户端展示时把数字映射成对应的中文文案和操作按钮比如待支付显示“去支付”配送中显示“联系骑手”等。这个状态机的流转规则必须严格在后端校验比如只有“待支付”能变成“已取消”已完成的订单不能再修改状态。3.2 API列表与前端调用关系整套后端接口设计遵循RESTful风格核心接口大致如下模块方法路径说明认证POST/api/v1/auth/login登录换token认证GET/api/v1/auth/profile获取用户信息菜品GET/api/v1/categories获取分类列表菜品GET/api/v1/products获取菜品列表支持分类筛选菜品GET/api/v1/products/:id获取菜品详情订单POST/api/v1/orders创建订单订单GET/api/v1/orders获取当前用户订单列表订单GET/api/v1/orders/:id获取订单详情订单POST/api/v1/orders/:id/pay模拟支付订单POST/api/v1/orders/:id/cancel取消订单商家GET/api/v1/admin/overview数据统计商家GET/POST/PUT/api/v1/admin/products菜品管理商家GET/PUT/api/v1/admin/orders/:id订单处理前后端联调时前端页面和接口的对应关系非常清晰首页加载时并发请求categories和products登录后创建订单调用orders接口支付调用pay接口个人中心展示用户信息和订单入口。这里所有接口都是按约定好的数据格式返回前端request封装统一处理后业务代码里完全不需要关心网络层的细节。3.3 模拟支付与订单状态流转实现真实项目中接入微信支付需要企业资质、商户号、证书、回调域名等一系列前置条件。在学习和演示场景下项目用“模拟支付”替代真实支付让业务链路完整跑通。核心逻辑是用户点击“去支付”按钮前端调用POST /api/v1/orders/:id/pay后端不真正请求微信接口而是直接把这个订单的状态从0待支付改为4已完成同时记录支付时间和支付方式为“模拟支付”然后返回支付成功。前端收到成功后跳转订单详情页展示支付结果。如果你将来要接入真实支付核心改造点就在这个pay接口里。真实流程是后端先调用微信支付的下单接口获取prepay_id然后返回给前端payParams前端用uni.requestPayment拉起收银台。用户支付完成后微信服务器会异步调用你配置的回调地址后端在回调里验签、更新订单状态。这里有两个非常关键的实践提醒一是订单金额必须在后端计算绝不能信任前端传的金额否则用户篡改请求价格就能低价下单二是支付回调必须是幂等逻辑因为微信会重试回调同一笔订单可能收到多次通知。4. 完整部署与运行从零跑起这个项目4.1 环境准备与目录结构说明要跑起这套系统本地需要准备的环境极其轻量Node.js 18 及以上版本2026年这个时间点Node 20是稳定版本建议直接用20微信开发者工具用于编译运行小程序端HBuilderX可选如果用H5模式调试则不需要Git用于拉取代码建议准备一个HBuilderX是因为uni-app的工程导入、运行到小程序模拟器、甚至App打包目前最省事的路径还是通过HBuilderX。如果你更习惯命令行也可以用cli方式创建uni-app项目但那个需要额外配置vue-cli等工具链对新手不够友好。项目的目录结构大概是这样的project-root ├── client # 小程序端代码uni-app │ ├── pages # 页面组件 │ ├── components # 公共组件 │ ├── stores # Pinia状态管理 │ ├── utils # 请求封装、工具函数 │ ├── static # 静态资源 │ ├── App.vue │ ├── main.ts │ ├── pages.json # 路由与页面配置 │ └── manifest.json # 应用配置appid、小程序特有配置 ├── server # Node.js后端API服务 │ ├── routes # 接口路由 │ ├── controllers # 业务逻辑控制层 │ ├── models # 数据模型JSON文件/内存存储 │ └── app.js # 服务入口 └── docs # 接口文档与部署说明4.2 后端启动步骤后端启动是整个项目最简单、也最容易出错的第一步。首先进入server目录执行依赖安装cd server npm install安装完成后启动开发服务npm run dev正常情况下控制台会输出Server is running on http://localhost:3000。此时可以用浏览器直接访问http://localhost:3000/api/v1/categories如果看到了分类列表的JSON数据说明后端API已经跑通了。这里有一个新手极容易踩的坑Node服务启动后控制台看着正常但前端请求时一直报网络错误。排查方向首先看控制台有没有报错再看命令窗口有没有被占用如果是远程开发环境还要检查防火墙和端口映射。但最常见的其实还是URL问题后面我会专门展开。4.3 前端在小程序模拟器中运行小程序端的启动方式有两种用HBuilderX导入client目录然后选择“运行到小程序模拟器”或者用微信开发者工具直接导入编译后的dist/dev/mp-weixin目录。推荐流程是先用HBuilderX打开client目录确认manifest.json里的mp-weixin配置正确尤其是appid可以先用测试号然后点击“运行 - 运行到浏览器”先在浏览器里以H5模式调试一遍确认功能无误后再点击“运行到小程序模拟器”。选择H5模式先调试有两个好处第一浏览器开发者工具的调试效率远高于小程序模拟器第二小程序模拟器的缓存问题有时会导致代码更新不及时H5模式没有这个问题。但要注意H5模式和小程序模式下部分API行为不同比如uni.login在H5下不支持所以登录逻辑在小程序模拟器里必须单独验证。当你用微信开发者工具打开编译后的小程序时如果一切正常首页应能看到分类和菜品列表。这时候如果列表数据空白大概率是网络请求的域名或地址没配对这就引出了下面的网络联调问题。4.4 联调配置的关键细节在小程序里请求本地Node服务和网页里请求本地接口有一个巨大的差异小程序不能直接访问localhost。在微信开发者工具的模拟器中localhost指向的是你的开发机理论上可以通但在真机调试时手机无法解析到电脑的localhost所以在请求封装中BASE_URL必须改成你电脑在局域网中的IP地址。操作方法在命令行运行ipconfigWindows或ifconfigMac查看本机局域网IP比如192.168.1.100然后修改utils/request.ts中的BASE_URL为http://192.168.1.100:3000/api/v1。同时需要在微信开发者工具中选择“详情 - 本地设置 - 不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”来绕过域名校验因为开发环境下后端是HTTP而非HTTPS且域名是IP。如果你以后要发布正式版后端必须升级为HTTPS并配置合法备案域名否则小程序无法在线上环境发出请求。这一步是整个项目联调中最折磨人的环节尤其是第一次接触小程序开发的人往往会在这个地方卡上很久。解决问题的核心套路是先用浏览器H5模式确认后端接口没问题再在小程序工具里看Console的报错信息确认到底是“请求未发起”还是“请求被拦截”前者是接口写错后者是工具配置问题。5. 常见问题排查与避坑实录5.1 请求与数据渲染问题速查问题现象可能原因排查与解决页面空白控制台无报错接口返回为空或异步数据未渲染检查Network面板确认API是否返回数据确认是否设置了loading态小程序请求一直转圈后端未启动或BASE_URL指向错误在终端访问接口地址确认后端启动改用局域网IP真机调试无法请求本机IP不可访问或小程序工具开启了域名校验确认手机与电脑在同一WiFi关闭域名校验分类点击不切换菜品分类ID对比类型不一致字符串 vs 数字检查activeCategoryId数据类型确保严格相等购物车数量不显示状态未同步到本地缓存检查addItem后是否有调用persistCart()订单支付成功后状态未变后端状态机更新逻辑错误查看后端日志确认pay接口是否被调用、状态更新是否命中5.2 Pinia持久化的坑与解决方案这里有一个很典型的坑我身边不止一个人踩过页面刷新后Pinia状态丢失。在小程序的H5模式下刷新页面导致Store重新加载数据自然清空。如果实现购物车持久化时只写了cartStore.addItem()没在初始化时主动读取缓存用户每次刷新购物车都会空掉。正确的做法是在Store初始化时主动恢复缓存比如在main.ts中调用一个初始化函数或把恢复逻辑写在createPinia后的App启动生命周期中。代码逻辑大致是// store/cart.ts export const useCartStore defineStore(cart, { state: () ({ items: [] }), actions: { restoreFromCache() { const cached uni.getStorageSync(cart_items) if (cached) this.items cached }, addItem(product: Product) { // 添加或增加数量 this.saveToCache() }, saveToCache() { uni.setStorageSync(cart_items, this.items) } } })然后App启动时调用useCartStore().restoreFromCache()。同时uni.setStorageSync存储的数据量是有限制的一般单个key不超过1MB购物车只有几十个商品时完全够用但如果以后要做大量数据的本地缓存建议分key存储或使用Storage模块化封装。5.3 关于“2026年最新版”的适配注意事项所谓“最新版”不只是噱头2026年这个时间点有几个技术层面的事情需要特别注意。第一Vue 3已经成为绝对主流。如果你还在看Vue 2的老项目或者在一些旧教程里看到main.js里写Vue.use(Vuex)、new Vue({...})这些代码在Vue 3里已经无法运行。学习时要认清这一点网上大量的Vue 2教程已经不太适合直接照抄。第二微信小程序的安全规则仍在收紧。比如头像昵称填写的合规改造、手机号快速验证组件的普及、对获取用户隐私信息的严格限制都要求项目的登录和用户信息模块必须是“新写法”。这套2026年版项目在设计登录流程时已经把这类合规要求考虑进去了。第三Node版本要足够新。旧的Node 12/14无法运行新版依赖连npm install都会因为依赖版本要求而报错。装好Node 20后npm install基本不会遇到依赖版本冲突。5.4 数据一致性问题的处理经验在订单创建这个环节最容易出现的数据一致性问题是用户在前端修改了购物车商品价格再提交订单。虽然正常的用户不会这么干但恶意用户完全可以抓包篡改请求体。所以后端在POST /api/v1/orders中必须做两件事一是通过前端传入的商品ID列表重新从数据库查询当前价格计算订单总金额二是检查库存是否充足不足则返回错误。前端传金额只是作展示用后端必须覆盖校验。同理订单状态的每次变更都要在后端重新校验当前状态是否允许该操作。这类“前端展示、后端校验”的思路是整套系统设计和真实生产环境的接轨点也是面试官最爱追问的细节之一。写在最后的几点体会这套系统我自己在本地完整跑过一遍之后最大的感受是它不是一个“花架子”Demo而是一个能体现很多工程化思想的完整项目。购物车用本地缓存加服务端校验的混合方案后端对订单快照和状态机的处理请求层的统一封装这些都是在实际工作里真的会用到的东西而不是教科书里那种“学完就忘”的知识点。如果你是自己学习Vue和小程序开发我建议别急着看代码先试着不看源码把你心中“外卖点餐”应该有哪些页面、哪些流程画出来然后对照这个项目的结构去理解作者为什么这么分、为什么这么设计。很多初学者觉得看源码两眼一抹黑其实是因为心里没有完整的业务地图等你自己把地图画出来再去看代码整个项目就会非常透明。最后送你一个我从这个项目里总结出来的小技巧调试小程序时务必把后端接口的访问地址单独做成一个配置文件不要写死在请求层里。后续换测试环境、生产环境只改一处配置即可这个好习惯能让你在接真实后端时少改一堆代码。这个项目可以作为你学习小程序开发的“最后一公里”参考也可以作为你踏进电商类系统开发的一块跳板。把它的业务逻辑吃透你就能在这个基础上延伸出更多东西比如优惠券模块、商家入驻、骑手端配送都能顺着已有的骨架长出来。
阅读完成 · 觉得有帮助？
