SpringBoot+Vue+UniApp 校园饭堂订餐系统：档口入驻、供餐时段与取餐号订单闭环的设计与实现

SpringBootVueUniApp 校园饭堂订餐系统档口入驻、供餐时段与取餐号订单闭环的设计与实现演示环境均为本地启动后的真实截图数据来自内置演示库的种子数据非空态摆拍。一、前言高校饭堂是校园里人流量最稳定的场所但它的信息化程度往往最低今天各档口卖了什么菜、哪个窗口人少、供餐到几点学生只能靠现场转一圈才知道档口想调整菜品或者搞个折扣活动也只能靠窗口贴一张手写海报。饭堂的管理方后勤或餐饮中心则面对另一层问题——新档口想进驻资质怎么审学生对某个档口的服务不满意投诉和评价有没有沉淀成可查的数据「青桔校园饭堂订餐」就是围绕这三个角色做的完整方案学生端用 UniApp 实现一套代码可编译为微信小程序和 H5 移动页负责按档口浏览菜品、加购下单、凭订单编号到窗口取餐档口端和管理端共用一个 Vue2 Element UI 的后台档口自主维护菜品与供餐时段管理员负责档口入驻审核和内容治理后端是 SpringBoot 单体服务用 JWT 把 ADMIN、BUSINESS、USER 三种角色隔离在同一套接口之下。与市面上常见的到店扫码点餐、社会化外卖平台相比这个项目的立足点不一样它把「档口」当作核心业务主体来建模。档口不是菜单里的一个筛选条件而是有独立入驻审核、独立供餐时段、独立菜品体系和独立订单流的数据实体。这也让它特别适合作为毕业设计选题——业务主体清晰每张表都有真实场景支撑不会做成「商品列表加购物车」的空壳 Demo。二、技术栈与系统架构整个系统的技术选型遵循「三层三端」的朴素结构每一层都是 Java 系毕业设计里最容易讲清楚、也最容易跑起来的组合层技术说明学生端UniAppVue2 语法一套源码可发布微信小程序也可构建 H5 移动页档口端/管理端Vue 2.6 Element UI 2.15单页后台路由按角色渲染菜单后端SpringBoot 2.5.9 MyBatis PageHelper内嵌 Tomcat 独立运行RESTful 接口鉴权java-jwtHMAC256登录签发 Token拦截器统一校验数据库MySQL 8utf8mb413 张业务表脚本一键建库工具库Hutool 5.8雪花订单号、文件读写、Bean 拷贝后端有几个值得展开的设计点。鉴权设计上登录接口按角色分流到三张账号表校验成功后用 JWT 把「用户ID-角色」写进 Token 载荷、以该账号的数据库密码做签名密钥之后每个请求经过拦截器解析 Token、回库取账号、再验签——改密码即让旧 Token 全部失效这个细节比常见的Token 只存 ID要严谨。接口风格上全部响应统一为 code/msg/data 三段 JSON配合全局异常处理器兜底前端只需判断 code。数据访问上MyBatis 负责映射PageHelper 做物理分页档口角色的查询在 Service 层被强制追加自己的 businessId 条件从源头避免越权看到别的档口的数据。订单号用 Hutool 的雪花算法生成19 位纯数字全局唯一在学生端直接作为取餐凭证展示。三、功能设计功能上系统围绕「学生点得顺、档口管得住、后勤看得见」三条线展开共三端十七项功能档口入驻审核制是第一个差异点。新档口注册后处于「待审核」状态只有管理员在后台确认资质营业执照图片随档口档案一起存档并通过审核才会出现在学生端的档口列表里。这条流程让食品安全谁负责有了数据层面的答案每一个在线经营的档口背后都有一条通过审核的档案记录。供餐时段独立化是第二个差异点。每个档口的档案里有独立的供餐时段字段茶饮档口可以写 6:30-21:30卤味档口写 10:30-19:00时段跟档口走而不是全校一刀切学生端在档口列表和详情页都能看到。订单编号即取餐号是第三个差异点。学生下单并模拟支付后订单状态从待支付依次流转到待发货、待收货、待评价、已完成另有已取消、已退款两个分支状态每个状态都可以在学生端触发对应的动作——支付、申请退款、确认收货、评价。订单详情页把 19 位订单编号放在最醒目的位置学生到窗口报号即可核对取餐不需要额外的叫号硬件也不需要人脸或者扫码设备。除此之外菜品维度支持折扣定价订单结算时按原价×折扣计算优惠与实付、上下架状态、原材料与口味规格描述评价体系用「5 分基础分 已有评分均值」的方式为每个档口聚合出综合评分展示在学生端的档口卡片上收藏、收货地址、公告、轮播等外围功能一应俱全。四、数据库设计数据库 canteen_order 共 13 张表围绕档口这一主体展开表含义关键字段business档口档案name、time_range 供餐时段、status 审核状态、license 营业执照goods菜品price、discount 折扣、status 上下架、business_id / category_idcategory菜品分类name、business_idorders订单order_no 订单编号、status、amount/discount/actual 三额、pay_typeorders_item订单明细order_id、goods_id、goods_name/price 快照、numcart购物车goods_id、num、user_id、business_iduser / admin学生 / 管理员账号username、password、roleaddress收货地址address、user、phone、user_idcomment评价content、star、user_id / business_id / goods_id / order_idcollect收藏user_id、business_idnotice / banner公告 / 轮播title/content 与 img/business_id两张细节值得说说。一是订单明细做了快照goods_name 和 price 在下单那一刻复制进 orders_item之后档口改价、改名都不影响历史订单的还原这是电商类数据库设计的标准手法答辩时很好讲。二是订单表把「订单编号、状态、三个金额」并列设计amount 是按原价合计的总额discount 是折扣让利actual 是实付三者由后端的购物车结算接口统一计算写库前端不做任何金额运算避免了双端算钱不一致的经典 bug。建库脚本开头带 CREATE DATABASE 与 USE 语句MySQL 5.7/8.0 空库上一键导入即可得到带完整演示数据的库。五、系统演示管理端以管理员登录左侧菜单按角色渲染。首页轮播展示饭堂通知档口信息页是管理端的核心四个档口的账号、名称、Logo、简介、所在地梅园/荷园饭堂的具体楼层档口号、营业执照、审核状态与供餐时段一字排开审核操作直接改 status 字段生效菜品信息页维护 33 道演示菜品折扣、口味、规格、上架日期、所属档口一应俱全图片走后端文件接口存取菜品分类页展示分类与档口的归属关系订单管理页则汇总了覆盖七种状态的 10 笔演示订单支持按订单编号模糊查询档口评论页把学生评价、星级评分、评价人与订单编号关联呈现后勤对差评的追踪有了抓手学生端 H5 构建产物在浏览器打开即是完整的移动体验。UniApp 工程在 HBuilderX 里发行 H5或用 uni-app 命令行工程执行UNI_PLATFORMh5构建产物是纯静态目录任意静态服务器托管即可同一份源码切换发行目标为微信小程序就能得到功能一致的小程序端两端共享 config.js 里集中定义的接口地址切换后端环境只改一处。首页自上而下是轮播图、公告栏、分类图标区奶茶饮品、轻食简餐、炸鸡汉堡、特色美味和热门档口卡片综合评分、已售数、出餐时效、档口简介档口详情页左侧是菜品分类竖排导航右侧是带折扣价与到手价的菜品列表顶部的星级由该档口全部评价聚合而来搜索页支持按名称模糊匹配菜品「我的」页汇总了收货地址、收藏、评价中心等个人功能入口订单列表按全部/进行中/待评价/已退款四个页签过滤每张订单卡片展示档口名、菜品摘要、实付金额与状态标签待支付订单可直接触发支付订单详情页是取餐环节的关键页面——19 位订单编号即取餐号配合下单时间、档口名、菜品明细与优惠小计一起展示确认订单页串起购物车结算链路选择收货地址、填写备注、选择支付方式后提交后端在同一事务里生成订单、写入明细并清空购物车六、小结从毕业设计的角度看这套校园饭堂订餐系统的价值在于业务主体选得准以档口为中心向上牵出入驻审核与供餐时段的运营语义向下牵出菜品、订单与评价的数据链条JWT 三角色鉴权、雪花订单号、订单金额服务端统算、明细快照这些工程细节又都有真实的设计动机可以讲不是为堆技术而堆技术。如果要在它的基础上继续演进方向也很自然给取餐号加一块档口端的叫号大屏、订单完成后自动回写档口销量榜单、结合供餐时段做预点单错峰取餐甚至把评价文本做个简单的舆情聚类。整个工程结构清晰、模块边界干净适合作为 Java Web 方向的毕业设计参考也适合直接改造为实际可用的校园餐饮工具。实现过程中遇到问题欢迎评论区交流。青桔校园饭堂订餐源码 SpringBootVueUniAppMySQL毕业设计/课程设计