摘 要
随着移动互联网、即时零售和线下新消费模式的发展，咖啡门店对数字化点餐、订单流转和门店运营管理提出了更高要求。传统人工点单方式存在排队时间长、定制信息记录不完整、订单状态不透明、门店协同效率低等问题，难以满足用户对便捷性和个性化服务的需求。为解决上述问题，本文设计并实现了一套基于微信小程序的遇见咖啡店点餐系统。
系统面向顾客、店员、店长和管理员四类角色，构建了"顾客端小程序+门店管理端+系统管理端"的业务闭环。顾客可完成登录注册、商品浏览、饮品定制、购物车管理、下单支付、订单跟踪、消息通知和门店切换；店员可进行订单接单、制作处理、取餐核销和催单处理；店长负责商品、分类、员工、退款、订单和数据统计管理；管理员负责门店管理、用户管理与系统配置。系统采用UniApp + Vue3实现微信小程序顾客端，采用Vue3 + Element Plus + ECharts实现Web管理端，后端基于Spring Boot 2.7、Spring Security + JWT、MyBatis-Plus、MySQL 8.0构建，并结合WebSocket实现订单状态的实时同步。
系统设计兼顾了业务可用性、安全性和可扩展性，可有效提升门店点餐效率、制作协同能力和运营管理水平，为中小型咖啡门店的信息化建设提供了一种可落地的实现方案。
关键词：微信小程序；咖啡店点餐系统；Spring Boot；UniApp；Vue3
目 录
[++++第1章 绪论++++](#第1章 绪论)
[++++1.1 研究背景与意义++++](#1.1 研究背景与意义)
[++++1.1.1 研究背景++++](#1.1.1 研究背景)
[++++1.1.2 研究意义++++](#1.1.2 研究意义)
[++++1.2 国内外研究现状++++](#1.2 国内外研究现状)
[++++1.3 主要研究内容++++](#1.3 主要研究内容)
[++++1.4 论文组织结构++++](#1.4 论文组织结构)
[++++1.5 本章小结++++](#1.5 本章小结)
[++++第2章 相关技术介绍++++](#第2章 相关技术介绍)
[++++2.1 微信小程序与UniApp技术++++](#2.1 微信小程序与UniApp技术)
[++++2.2 Vue3与Element Plus++++](#2.2 Vue3与Element Plus)
[++++2.3 ECharts可视化技术++++](#2.3 ECharts可视化技术)
[++++2.4 Spring Boot 2.7框架++++](#2.4 Spring Boot 2.7框架)
[++++2.5 Spring Security与JWT认证++++](#2.5 Spring Security与JWT认证)
[++++2.6 MyBatis-Plus数据访问技术++++](#2.6 MyBatis-Plus数据访问技术)
[++++2.7 MySQL 8.0数据库++++](#2.7 MySQL 8.0数据库)
[++++2.8 WebSocket实时通信技术++++](#2.8 WebSocket实时通信技术)
[++++2.9 本章小结++++](#2.9 本章小结)
[++++第3章 需求分析++++](#第3章 需求分析)
[++++3.1 可行性分析++++](#3.1 可行性分析)
[++++3.1.1 技术可行性++++](#3.1.1 技术可行性)
[++++3.1.2 操作可行性++++](#3.1.2 操作可行性)
[++++3.1.3 经济可行性++++](#3.1.3 经济可行性)
[++++3.2 功能需求分析++++](#3.2 功能需求分析)
[++++3.2.1 顾客端功能需求++++](#3.2.1 顾客端功能需求)
[++++3.2.2 店员端功能需求++++](#3.2.2 店员端功能需求)
[++++3.2.3 店长端功能需求++++](#3.2.3 店长端功能需求)
[++++3.2.4 管理员端功能需求++++](#3.2.4 管理员端功能需求)
[++++3.3 非功能需求分析++++](#3.3 非功能需求分析)
[++++3.4 业务流程与数据需求分析++++](#3.4 业务流程与数据需求分析)
[++++3.4.1 顾客点餐业务流程++++](#3.4.1 顾客点餐业务流程)
[++++3.4.2 门店订单处理流程++++](#3.4.2 门店订单处理流程)
[++++3.4.3 数据实体需求++++](#3.4.3 数据实体需求)
[++++3.5 本章小结++++](#3.5 本章小结)
[++++第4章 系统设计++++](#第4章 系统设计)
[++++4.1 系统架构设计++++](#4.1 系统架构设计)
[++++4.2 系统总体流程设计++++](#4.2 系统总体流程设计)
[++++4.2.1 用户登录流程++++](#4.2.1 用户登录流程)
[++++4.2.2 顾客下单流程++++](#4.2.2 顾客下单流程)
[++++4.2.3 门店订单处理流程++++](#4.2.3 门店订单处理流程)
[++++4.2.4 退款审核流程++++](#4.2.4 退款审核流程)
[++++4.3 系统总体功能设计++++](#4.3 系统总体功能设计)
[++++4.4 数据库设计++++](#4.4 数据库设计)
[++++4.4.1 概念设计++++](#4.4.1 概念设计)
[++++4.4.2 数据库表设计++++](#4.4.2 数据库表设计)
[++++4.5 本章小结++++](#4.5 本章小结)
[++++第5章 系统实现++++](#第5章 系统实现)
[++++5.1 顾客端功能实现++++](#5.1 顾客端功能实现)
[++++5.1.1 用户登录++++](#5.1.1 用户登录)
[++++5.1.2 商品浏览++++](#5.1.2 商品浏览)
[++++5.1.3 商品详情与加购++++](#5.1.3 商品详情与加购)
[++++5.1.4 订单列表查询++++](#5.1.4 订单列表查询)
[++++5.1.5 取餐码展示++++](#5.1.5 取餐码展示)
[++++5.2 店员端功能实现++++](#5.2 店员端功能实现)
[++++5.2.1 订单看板与接单处理++++](#5.2.1 订单看板与接单处理)
[++++5.2.2 订单筛选与状态流转++++](#5.2.2 订单筛选与状态流转)
[++++5.3 店长端功能实现++++](#5.3 店长端功能实现)
[++++5.3.1 经营数据看板++++](#5.3.1 经营数据看板)
[++++5.3.2 商品与分类管理++++](#5.3.2 商品与分类管理)
[++++5.3.3 库存维护++++](#5.3.3 库存维护)
[++++5.4 管理员端功能实现++++](#5.4 管理员端功能实现)
[++++5.4.1 后台登录++++](#5.4.1 后台登录)
[++++5.4.2 消息中心管理++++](#5.4.2 消息中心管理)
[++++5.4.3 员工账号维护++++](#5.4.3 员工账号维护)
[++++5.5 本章小结++++](#5.5 本章小结)
[++++第6章 系统测试++++](#第6章 系统测试)
[++++6.1 测试目的++++](#6.1 测试目的)
[++++6.2 测试环境与方法++++](#6.2 测试环境与方法)
[++++6.3 测试内容++++](#6.3 测试内容)
[++++6.3.1 用户登录测试用例表++++](#6.3.1 用户登录测试用例表)
[++++6.3.2 商品加购与下单测试用例表++++](#6.3.2 商品加购与下单测试用例表)
[++++6.3.3 订单列表与取餐码测试用例表++++](#6.3.3 订单列表与取餐码测试用例表)
[++++6.3.4 订单管理测试用例表++++](#6.3.4 订单管理测试用例表)
[++++6.3.5 商品与分类管理测试用例表++++](#6.3.5 商品与分类管理测试用例表)
[++++6.3.6 数据统计测试用例表++++](#6.3.6 数据统计测试用例表)
[++++6.4 本章小结++++](#6.4 本章小结)
[++++第7章 总结与展望++++](#第7章 总结与展望)
研究背景与意义
1.1.1 研究背景
近年来，移动互联网消费习惯不断深化，用户对"随时下单、到店即取、过程可追踪"的服务模式提出了更高要求。咖啡消费场景具有高频、小额、定制化强和门店高峰集中的特点，传统线下收银点单方式在早晚高峰时段容易出现排队时间长、人工记录口味偏差、订单状态传递不及时等问题，既影响顾客体验，也增加了门店运营压力。
微信小程序1凭借免安装、入口便捷、易传播和与微信生态融合度高等优势，已经成为餐饮行业数字化转型的重要载体。对于咖啡门店而言，基于微信小程序构建点餐系统，能够将商品展示、饮品定制、在线支付、订单通知和到店核销等业务环节进行统一整合，为门店建立更加清晰、高效的数字化经营流程。
1.1.2 研究意义
从应用价值上看，咖啡店点餐系统的建设有助于提升顾客点餐效率和门店服务质量。顾客可以在到店前完成商品浏览、口味定制与在线支付，减少线下等待时间；门店可以通过订单状态流转和实时提醒优化制作与出杯节奏，提高高峰时段的接单能力和取餐秩序。
从工程实践上看，该课题涵盖前端交互设计、后台权限控制、实时消息推送、数据库建模和多角色业务协同等内容，具有较强的综合性。通过本系统的设计与实现，可以验证微信小程序、Web后台与Java后端服务协同开发的可行性，为餐饮门店信息化建设和同类项目开发积累经验。
功能需求分析
根据咖啡门店实际业务流程和不同岗位职责，本系统共包含顾客、店员、店长和管理员四类角色。UML（统一建模语言）用例图是需求分析阶段常用的工具，能够直观反映系统功能与参与者之间的关系。因此，本文按照角色划分对系统功能进行分析，并借助用例图展示各角色的核心操作场景。
3.2.1 顾客端功能需求
顾客端是系统面向消费者的核心入口，需要满足从登录注册到订单完成的完整业务需求。首先，系统应支持手机号注册登录、验证码登录和密码重置，确保用户能够便捷进入系统。其次，顾客需要浏览商品分类、查看商品详情，并根据咖啡饮品特性选择杯型、温度、甜度、加料和备注等定制选项。
在交易环节，顾客端应提供购物车管理、门店选择、订单确认和在线支付等功能，并支持查看订单详情、订单状态、取餐码、取消订单、申请退款和催单提醒。此外，系统还应具备消息通知与门店信息查看功能，帮助顾客及时获取支付成功、制作完成和取餐提醒等信息。
顾客用例图如图3.1所示。
店员端功能需求
店员端主要面向门店制作人员，其核心任务是保障订单处理链路顺畅。系统需要提供订单看板功能，实时展示新订单、制作中订单和待取餐订单，并支持按时间、状态等条件筛选查看。店员应能够查看订单商品明细、定制要求和备注内容，以保证饮品制作准确性。
同时，店员端还应支持接单、完成制作、取餐核销、处理催单和记录内部备注等功能。当顾客到店取餐时，系统需支持扫码核销或手动输入取餐码核销，并在核销后自动更新订单状态，确保门店取餐流程规范可追踪。
店员用例图如图3.2所示。
店长端功能需求
店长端主要承担门店运营管理职责，需要在系统中完成商品管理、分类管理、员工管理、退款管理、订单管理和数据统计等功能。其中，商品管理应支持新增、编辑、删除和上下架控制；分类管理应支持分类维护与排序调整；员工管理应支持创建账号、编辑信息、禁用账号和重置密码等操作。
在经营分析方面，店长端还应能够查看销售概览、商品销量排行、订单状态分布、时段销售情况以及顾客复购率等统计数据，从而为商品调整、排班安排和促销活动制定提供依据。
店长用例图如图3.3所示。
管理员端功能需求
管理员端主要面向系统级维护工作，需要对多个门店和全局配置进行统一管理。系统应支持门店新增、编辑、禁用和店长分配等功能，保证门店组织结构清晰。与此同时，管理员需要能够查看顾客信息、管理员工账号、禁用异常用户，并维护系统运行所需的基础配置和支付配置。
通过管理员端的统一管理，可以实现多门店业务的标准化配置和账号权限治理，为系统持续运行提供后台保障。
管理员用例图如图3.4所示。
系统总体功能设计
在功能划分上，系统围绕四类角色展开设计。顾客端强调点餐体验和信息反馈，店员端聚焦订单执行，店长端聚焦门店运营，管理员端承担系统级配置与多门店治理任务。各模块之间相互独立又能够通过统一的数据模型完成协同，系统功能结构如图4.6所示。
数据库表设计
在物理表设计阶段，需要将概念模型映射为具体的数据表结构，并对字段名称、数据类型、长度以及是否为空等属性进行定义。综合系统业务流程与后端接口实现，本系统重点设计了用户表、门店表、商品分类表、商品表、订单主表、订单明细表、退款申请表和消息通知表等核心表。
sys_user（用户表）
存储系统所有用户的核心信息，包括登录账号、密码、角色、联系方式等基础资料，同时记录账号状态和创建时间，是系统身份认证和用户管理的核心表。
表4.1 用户表（sys_user）
|--------|-------------|----------|--------|--------|--------|
| 序号 | 列名 | 数据类型 | 长度 | 主键 | 说明 |
| 1 | id | bigint | 20 | 是 | 主键ID |
| 2 | user_no | varchar | 50 | | 用户编号 |
| 3 | username | varchar | 100 | | 登录账号 |
| 4 | password | varchar | 200 | | 登录密码 |
| 5 | role | varchar | 30 | | 角色类型 |
| 6 | nickname | varchar | 100 | | 姓名/昵称 |
| 7 | phone | varchar | 20 | | 联系电话 |
| 8 | avatar | varchar | 255 | | 头像地址 |
| 9 | status | tinyint | 1 | | 账号状态 |
| 10 | create_time | datetime | | | 创建时间 |
store_info（门店信息表）
管理线下门店的基础信息，涵盖门店编号、名称、地址、联系方式、营业时间等，关联店长的用户 ID，同时标记门店状态，支撑门店运营和管理相关业务。
表4.2 门店信息表（store_info）
|--------|-------------|----------|--------|--------|--------|
| 序号 | 列名 | 数据类型 | 长度 | 主键 | 说明 |
| 1 | id | bigint | 20 | 是 | 主键ID |
| 2 | store_no | varchar | 50 | | 门店编号 |
| 3 | store_name | varchar | 100 | | 门店名称 |
| 4 | manager_id | bigint | 20 | | 店长账号ID |
| 5 | phone | varchar | 20 | | 联系电话 |
| 6 | address | varchar | 255 | | 门店地址 |
| 7 | open_time | varchar | 50 | | 营业时间 |
| 8 | status | tinyint | 1 | | 门店状态 |
| 9 | create_time | datetime | | | 创建时间 |
product_category（商品分类表）
对商品进行分类管理的基础表，记录分类编号、名称、排序号和启用状态，用于规整商品体系，方便商品的分类展示和检索。
表4.3 商品分类表（product_category）
|--------|---------------|----------|--------|--------|--------|
| 序号 | 列名 | 数据类型 | 长度 | 主键 | 说明 |
| 1 | id | bigint | 20 | 是 | 主键ID |
| 2 | category_no | varchar | 50 | | 分类编号 |
| 3 | category_name | varchar | 100 | | 分类名称 |
| 4 | sort_no | int | 11 | | 排序号 |
| 5 | status | tinyint | 1 | | 启用状态 |
| 6 | create_time | datetime | | | 创建时间 |
product（商品信息表）
存储具体商品的详细信息，关联所属门店和商品分类，包含商品编号、名称、价格、库存、图片地址、上下架状态等核心字段，是商品售卖的核心数据载体。
表4.4 商品信息表（product）
|--------|--------------|----------|--------|--------|--------|
| 序号 | 列名 | 数据类型 | 长度 | 主键 | 说明 |
| 1 | id | bigint | 20 | 是 | 主键ID |
| 2 | product_no | varchar | 50 | | 商品编号 |
| 3 | category_id | bigint | 20 | | 分类ID |
| 4 | store_id | bigint | 20 | | 所属门店ID |
| 5 | product_name | varchar | 100 | | 商品名称 |
| 6 | price | decimal | 10,2 | | 基础价格 |
| 7 | image_url | varchar | 255 | | 商品图片 |
| 8 | stock | int | 11 | | 库存数量 |
| 9 | shelf_status | tinyint | 1 | | 上下架状态 |
| 10 | create_time | datetime | | | 创建时间 |
orders（订单主表）
记录订单的整体信息，包括订单编号、下单用户、取餐门店、订单状态、支付状态、金额、取餐码等关键信息，是订单生命周期管理的核心表。
表4.5 订单主表（orders）
|--------|--------------|----------|--------|--------|--------|
| 序号 | 列名 | 数据类型 | 长度 | 主键 | 说明 |
| 1 | id | bigint | 20 | 是 | 主键ID |
| 2 | order_no | varchar | 64 | | 订单编号 |
| 3 | user_id | bigint | 20 | | 下单用户ID |
| 4 | store_id | bigint | 20 | | 取餐门店ID |
| 5 | order_status | varchar | 30 | | 订单状态 |
| 6 | pay_status | varchar | 30 | | 支付状态 |
| 7 | total_amount | decimal | 10,2 | | 订单总金额 |
| 8 | pay_amount | decimal | 10,2 | | 实付金额 |
| 9 | pickup_code | varchar | 20 | | 取餐码 |
| 10 | remark | varchar | 255 | | 订单备注 |
| 11 | create_time | datetime | | | 创建时间 |
order_item（订单明细表）
作为订单主表的附属表，记录单个订单中每个商品的购买明细，包括商品 ID、购买数量、单价、小计金额等，精准拆分订单内的商品消费构成。
表4.6 订单明细表（order_item）
|--------|-------------|----------|--------|--------|--------|
| 序号 | 列名 | 数据类型 | 长度 | 主键 | 说明 |
| 1 | id | bigint | 20 | 是 | 主键ID |
| 2 | order_id | bigint | 20 | | 订单ID |
| 3 | product_id | bigint | 20 | | 商品ID |
| 4 | quantity | int | 11 | | 购买数量 |
| 5 | spec_text | varchar | 255 | | 规格描述 |
| 6 | unit_price | decimal | 10,2 | | 单价 |
| 7 | subtotal | decimal | 10,2 | | 小计金额 |
| 8 | create_time | datetime | | | 创建时间 |
refund_request（退款申请表）
存储用户发起的订单退款申请信息，包含退款原因、审核状态、审核人及审核说明等，跟踪退款申请的全流程审核状态。
表4.7 退款申请表（refund_request）
|--------|--------------|----------|--------|--------|--------|
| 序号 | 列名 | 数据类型 | 长度 | 主键 | 说明 |
| 1 | id | bigint | 20 | 是 | 主键ID |
| 2 | order_id | bigint | 20 | | 订单ID |
| 3 | user_id | bigint | 20 | | 申请用户ID |
| 4 | reason | varchar | 255 | | 退款原因 |
| 5 | audit_status | varchar | 30 | | 审核状态 |
| 6 | audit_user | varchar | 100 | | 审核人 |
| 7 | audit_remark | varchar | 255 | | 审核说明 |
| 8 | create_time | datetime | | | 申请时间 |
notification（消息通知表）
管理系统向用户推送的各类消息通知，记录接收用户、通知标题 / 内容、业务类型、已读状态等，实现用户消息的统一管理和状态追踪。
表4.8 消息通知表（notification）
|--------|-------------|----------|--------|--------|--------|
| 序号 | 列名 | 数据类型 | 长度 | 主键 | 说明 |
| 1 | id | bigint | 20 | 是 | 主键ID |
| 2 | user_id | bigint | 20 | | 接收用户ID |
| 3 | title | varchar | 100 | | 通知标题 |
| 4 | content | varchar | 255 | | 通知内容 |
| 5 | biz_type | varchar | 30 | | 业务类型 |
| 6 | read_status | tinyint | 1 | | 已读状态 |
| 7 | create_time | datetime | | | 创建时间 |
系统实现
5.1 顾客端功能实现
5.1.1 用户登录
顾客端登录页面采用简洁的单列布局，将输入框、登录按钮与提示信息集中展示。用户输入账号与密码后即可完成登录，登录成功后系统根据令牌保存用户会话信息，并自动跳转到首页。用户登录界面如图5.1所示。
商品浏览
顾客进入首页后可按照经典咖啡、特调饮品、手工茗茶和烘焙甜点等分类浏览商品。系统在页面中集中展示商品图片、名称、价格和快捷加购入口，便于用户快速完成商品筛选。商品浏览界面如图5.2所示。
商品详情与加购
顾客点击商品后可进入详情页查看饮品主图、商品名称、价格和口味备注等信息，并通过数量调节与加入购物车按钮完成加购操作。该页面兼顾了商品展示与购买转化，能够为后续下单流程提供清晰入口。商品详情与加购界面如图5.3所示。
店员端功能实现
5.2.1 订单看板与接单处理
店员端订单看板是门店处理订单的核心页面，界面按列表形式展示订单信息、状态标签和处理按钮，方便店员快速识别待处理订单。接单后，系统立即更新订单状态并同步到顾客端。订单看板界面如图5.6所示。
店长端功能实现
5.3.1 经营数据看板
店长端首页以经营看板形式展示销售总额、订单数量、客单价、订单完成率和时段销售趋势等指标，并通过柱状图、饼图和排行榜呈现关键经营数据。该页面能够帮助管理者快速掌握门店经营情况。经营数据看板如图5.8所示。
管理员端功能实现
5.4.1 后台登录
管理员通过统一登录入口进入系统后台，系统在登录页提供账号密码输入、错误提示和登录状态校验功能。登录成功后即可访问门店管理、账号管理和系统配置等全局模块。后台登录界面如图5.11所示。
消息中心管理
管理员可以在消息中心统一查看订单状态提醒、催单处理结果、退款进度和系统通知等内容。页面提供关键字检索、类型筛选和已读状态回显，便于管理员快速定位异常消息并跟踪业务处理过程。消息中心界面如图5.12所示。
总结与展望
本文围绕基于微信小程序的遇见咖啡店点餐系统展开研究，从研究背景、关键技术、需求分析、系统设计、系统实现和系统测试等方面对课题进行了系统阐述。论文构建了面向顾客、店员、店长和管理员四类角色的业务模型，完成了顾客点餐、门店接单、订单制作、取餐核销、商品分类维护、库存管理、消息通知和经营统计等核心功能设计与实现。
从实现效果来看，系统借助UniApp与微信小程序完成了轻量化顾客端建设，借助Vue3和Element Plus实现了易维护的后台界面，后端通过Spring Boot、Spring Security、JWT、MyBatis-Plus和MySQL构建起稳定的数据处理与权限控制能力，并通过WebSocket提升了订单状态同步的实时性。测试结果表明，系统能够较好地满足中小型咖啡门店在数字化点餐和门店管理方面的需求。
尽管如此，系统仍有进一步优化空间。后续工作可以围绕以下几个方向展开：其一，引入更完善的会员体系、优惠券与积分机制，提高用户留存和复购率；其二，补充更加精细的库存预警、原料消耗和门店排班分析功能，提升运营辅助能力；其三，优化支付与消息推送的真实接口接入，增强系统在实际商业环境中的可落地性；其四，结合推荐算法与用户行为分析，为顾客提供更加个性化的商品推荐服务。