基于Spring Boot的咖啡店点单收银系统毕业设计全解析

1. 这个毕设项目到底在做什么

1.1 从一个点单场景说起

假设你走进一家咖啡店，店员在收银机上点了几下：选择一杯拿铁，选了中杯、少冰、半糖，加了一份浓缩，系统自动算出价格，扫码付款后打出一张小票，上面有个取餐号。后厨的屏幕上同步弹出这杯咖啡的制作指令，做完了喊号取餐。整个过程二十秒不到。

这套东西就是“点单收银系统”，也是本次毕业设计项目的核心：基于 Spring Boot 实现一整套咖啡店点单收银管理方案，覆盖顾客下单、商品规格选择、订单结算、会员优惠、库存联动、报表统计等环节。它表面上是“给咖啡店做收银”，本质上是一个非常典型的管理系统开发练习，Spring Boot 负责后端接口，MySQL 存数据，前端页面或小程序负责人与系统交互，代码量适中，完整度很高，用来做毕业设计再合适不过。

这个项目适合三类人：想练手但不想做烂大街“图书管理”的人，想冲刺优秀毕业设计的人，以及准备找工作但项目经验空白的同学。无论是 Spring Boot 框架搭建、Maven 依赖管理、JPA/MyBatis 持久层、还是 JWT 登录鉴权，毕业后写在简历上都是能直接和面试官聊起的话题。

1.2 系统的三个角色和核心模块

整个系统围绕三类用户来设计：普通顾客、收银员/店员、系统管理员。

顾客端负责点单，能看到商品列表，选择规格（大杯还是中杯，热还是冰，糖度怎么调），加入购物车，提交订单，然后完成支付。这里做的是模拟支付，实际项目里通常不会真接微信支付宝支付，用一张“支付成功”的状态切换代替，必要时可以接入第三方沙箱环境。

店员端负责处理订单，包括查看所有待制作订单，按取餐号排序，标记“制作完成”，还兼着收银职能，比如顾客到店现场点单，店员在电脑端直接帮顾客下单结算，操作完打印小票、扫码取餐码。

管理员端负责系统基础配置，包括商品信息上下架、分类管理、门店信息、优惠活动、会员等级、销售报表等。角色不同，看到的菜单和操作权限都不一样，这正好考察了 RBAC 权限模型的设计能力。

三个角色对应三种视图，接口逻辑是同一套 Spring Boot 工程，只是登录后的身份不同。实现起来条理清晰，论文和答辩也能讲出层次感：不是只做了一个 CRUD，而是分析了真实业务场景里的角色和流程。

2. 技术选型为什么要这么搭

2.1 Spring Boot 为什么是毕业设计的主选

先解决一个经常被问的问题：为什么用 Spring Boot，而不用 Servlet、SSH、SSM？不是说老技术不能做，问题是毕业设计的时间窗口太短，一个学期几十个课时产出，你要花大量时间去配置 XML、处理各种 jar 包冲突，那不值当。

Spring Boot 做的是“开箱即用”。Maven 或 Gradle 引入依赖后，内嵌 Tomcat 直接启动，不需要单独装服务器，也不用部署 war 包。很多模块通过自动装配完成，比如引入了 spring-boot-starter-data-jpa 后，只需要配置数据源，实体类写好注解，基本的 CRUD 方法就能用，这对课程设计来说效率极高。

再一个原因是生态成熟度。项目的核心功能——用户登录、权限校验、商品管理、订单管理、报表统计——这些全部有成熟的 Starter 和支持方案，碰到问题随便一搜就有答案，不太需要从底层源码慢慢抠。当然我建议你做完了以后还是要去看一眼 Spring Boot 的自动装配源码，比如 @SpringBootApplication 背后到底发生了什么，这个在面试和答辩里是加分项，也是热搜里大家常问的“Spring Boot 自动装配原理”那题的来源。

2.2 前端、数据库、Redis 这些配件怎么选

点单收银系统的前端形式有几种常见做法：

• 纯后端模板渲染：用 Thymeleaf，服务端把 HTML 渲染好返回，适合一个人搞全套、工程结构最简单。
• 前后端分离：用 Vue 3 + Element Plus 做管理后台，小程序或者 H5 做点单页，Spring Boot 只出 JSON 接口。这个做出来面试能讲的东西多，但工作量也上去了。
• 轻量 H5 方案：用一个开源前端模板改造，不做复杂构建，适合时间紧的同学。

数据库首选 MySQL。只有一个实例也能撑起这套系统的全部需求，事务支持成熟稳定，订单和库存这类强一致性数据放在 MySQL 里最放心。表设计尽量遵循第三范式，但某些统计字段可以适当冗余，比如订单表里存一份商品快照，避免商品价格改了以后历史订单跟着变，这一点在答辩里能看出你懂业务。

Redis 在标准毕设里不是必需品，但如果项目里写了“领取优惠券”“热点商品排行榜”这类功能，用个 Redis 缓存就会显得技术含量上了一个台阶。缓存首页商品列表、缓存用户 Token、用 Redis 的 Set 数据结构做每日取餐号计数，都很提气。

权限方案可以直接上 Spring Security + JWT，也可以自己写一个简单的拦截器校验 Token。毕设层面我建议用 Spring Security，因为这也是面试里被反复问到的点，做过和没做过，聊起来差别很明显。简单归简单，Session 共享、CSRF、密码加密这些老问题让专库处理，自己写的拦截器反而容易漏细节。

2.3 技术栈版本怎么选才少踩坑

很多同学栽在版本上。Spring Boot 现在 2.x 和 3.x 并存，3.x 要求 JDK 17，如果你电脑上还是 JDK 8，两个版本不匹配，项目启动直接报错，就会出现“source release 17 requires target release 17”这种一脸懵的提示。

我的建议是：

• Java 8 搭配 Spring Boot 2.7.x，最稳，资料最多，毕业设计完全够用。
• JDK 17 搭配 Spring Boot 3.x，适合你想拿新技术点加分的情况，能聊可观测性、AOT、虚拟线程这些新特性，但需要接受版本的坑也更新的现实。

选定了组合以后，整个团队或者你个人的开发环境要统一，不要出现本机是 Spring Boot 2.7、写文档时又推荐 3.2 的情况。版本统一这件事，答辩时是加分细节。

3. 数据库设计：一个订单要经历什么

3.1 数据表设计全景

我按一个完整的咖啡点单流程来梳理需要哪些表，这个思路也适合写论文里的“需求分析”章节。一张订单从生成到完结，至少经历这样几个环节：用户登录、浏览商品、选择规格、提交订单、支付、制作、取餐。因此表结构围绕这几个环节展开。

核心表大约有这些：

用户表 sys_user：用户 ID、用户名、密码密文、手机号、头像、会员等级、创建时间。顾客、店员、管理员都放在这张表里，用角色字段区分。

角色表 sys_role 和用户角色关联表：做多角色时用，一个用户可拥有多个角色。

分类表 category：咖啡分类，比如经典咖啡、风味拿铁、茶饮、甜品小食。

商品表 product：商品 ID、名称、价格、图片、描述、所属分类、上下架状态、创建时间。这里需要注意，商品价格是基准价，实际结算时受规格影响。

规格表 product_spec：用来存放“大杯/中杯”“冷/热”“糖度”“冰块”这些选项。比如“冰吸生椰拿铁”在售规格可能是中杯、大杯、冰、半糖，每种规格组合对应一个加价规则。

购物车表 cart：用户 ID、商品 ID、商品快照、规格快照、数量、加入时间。

订单主表 order_info：订单号、用户 ID、订单状态、订单原价、优惠金额、实付金额、支付方式、取餐号、下单时间、支付时间、完成时间。

订单明细表 order_item：订单 ID、商品名快照、商品图快照、规格快照、单价、数量、小计。为什么要存快照？因为用户买了 100 杯咖啡，一年后商品价格改成 60 了，历史订单如果不存快照，统计报表时会发现金额和明细对不上。这是业务系统非常常见的一个设计细节。

支付流水表 payment：支付单号、订单 ID、支付方式、支付金额、支付状态、回调时间。

优惠券表 coupon 和用户优惠券表 user_coupon：用于满减、折扣、新人券。

日志表：操作日志、登录日志，简单实现可以只靠 Spring 的 AOP 切面写。

3.2 订单状态机设计

订单状态是整个项目里最值得深讲的地方，也是最容易出 bug 的部分。很多同学把状态随便写成“0 表示未支付，1 表示已支付”，然后到处在 Java 代码里写魔法数字，后面一加功能就乱了。

我建议用状态枚举类管理：

PENDING_PAYMENT（待支付）、PAID（已支付，排队制作中）、MAKING（制作中）、COMPLETED（已完成可取餐）、TAKEN（已取餐）、CANCELLED（已取消）、REFUNDED（已退款）。

状态流转方向是单向的，从待支付到已支付，再到制作中、已完成、已取餐，中间可以转到已取消。不允许从已支付直接退回待支付，也不允许从已完成再变回制作中。

在代码层面，所有订单状态的更新入口都集中到一个方法里，比如 OrderStatusService.changeStatus(orderNo, fromStatus, toStatus)，这样既方便加日志，又不会出现多个地方都在改状态、状态被改乱的问题。

这里我用一个简单的枚举示例说明：

java复制public enum OrderStatusEnum {
    PENDING_PAYMENT(0, "待支付"),
    PAID(1, "已支付"),
    MAKING(2, "制作中"),
    COMPLETED(3, "已完成"),
    TAKEN(4, "已取餐"),
    CANCELLED(5, "已取消"),
    REFUNDED(6, "已退款");

    private final int code;
    private final String desc;

    OrderStatusEnum(int code, String desc) {
        this.code = code;
        this.desc = desc;
    }
}

3.3 库存与原料联动

咖啡店的“库存”和普通电商商品库存不太一样。一杯拿铁卖出去，不光是“商品少了一件”，还意味着消耗了咖啡豆、牛奶、糖浆。毕设如果能把库存做到原料层面，概念上就能超过绝大多数管理系统。

我的设计是增加一张 ingredient（原料表）和 product_ingredient（商品和原料的关系表），比如一杯中杯拿铁需要 18g 咖啡豆、250ml 牛奶、10ml 糖浆。下单支付成功后，系统自动扣减对应原料库存。原料库存低于阈值时，给后台弹出“补货提醒”。

这套逻辑做起来不算难，但能让答辩材料特别出彩。评审老师看到的不只是“会写 CRUD”，而是能理解真实世界中咖啡店的物料成本管理逻辑。当然这也意味着要做事务控制：订单生成、明细写入、库存扣减三个操作必须在一个事务里完成，否则会出现“订单下了，库存没减”或者反过来，这个细节可以专门准备一段话在答辩时讲。

4. 核心代码模块实现解析

4.1 登录鉴权与角色权限

系统采用 JWT 做身份认证。流程是：用户提交用户名密码、后端校验通过后，生成一个包含用户 ID 和角色信息的 Token 返回给前端。前端后续请求在 Header 中带上 Authorization: Bearer token，后端用一个拦截器或 Spring Security 过滤器解析 Token，获取当前用户。

核心代码大致如下：

java复制@Component
public class JwtUtil {

    private static final String SECRET = "your-secret-key";

    public String generateToken(Long userId, String role) {
        return Jwts.builder()
                .setSubject(String.valueOf(userId))
                .claim("role", role)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 2))
                .signWith(SignatureAlgorithm.HS256, SECRET)
                .compact();
    }

    public Claims parseToken(String token) {
        return Jwts.parser()
                .setSigningKey(SECRET)
                .parseClaimsJws(token)
                .getBody();
    }
}

用 Spring Security 时，把 JWT 过滤器插入过滤器链中，在 SecurityFilterChain 里放行登录接口、商品查询接口，拦截订单操作和管理接口。角色上可以用 @PreAuthorize("hasRole('ADMIN')") 控制接口访问。

如果嫌配置 Spring Security 麻烦，也可以手写一个拦截器 HandlerInterceptor，继承 WebMvcConfigurer 注册拦截路径。但对于“Java 面试八股文”里高频提到的 Spring Security，自己亲自配一遍绝对不亏。

4.2 点单关键流程：规格、购物车、订单生成

点单容易出错的是规格组合。商品的规格不是固定写死的，而是由多个维度组合而成，比如温度维度（热/冰）、杯型维度（中杯/大杯）、糖度维度（标准糖/半糖/无糖）、加料维度（加浓缩、加奶油）。每个维度可能影响价格。

设计上我习惯用一张 spec_definition 配置表，存“维度名称、选项名称、加价金额”，这样以后要加一个“少冰”选项，不需要改代码，只加一条配置就行。前端点单时按商品 ID 查询可选规格，选了以后由后端计算最终价格：

java复制@PostMapping("/order/preview")
public Result previewOrder(@RequestBody PreviewOrderRequest request) {
    // 1. 遍历购物项，读取商品基础价
    // 2. 根据规格ID集合，累加规格加价
    // 3. 计算整单原价
    // 4. 计算会员折扣和优惠券减价
    // 5. 返回最终价格明细
}

订单生成时，要解决一个“并发下重复下单”的老问题。防重放到表单重复提交层，通过前端按钮置灰解决；在服务端，可以在创建订单时对同一个用户的操作加锁，或者利用数据库唯一索引约束。取餐号也需要保证当天唯一，比如用 Redis 的 INCR 配合日期前缀生成，例如 20250601001，第 1 号单就是当天第一单。

4.3 收银结算与多种支付方式模拟

收银台是店员的日常操作界面。顾客点完单，收银员确认订单，选择支付方式：现金、微信、支付宝、会员余额。毕设里对接真实支付通道不太实际，但可以做一个简洁的“支付渠道抽象”，把支付动作封装成接口，这样代码结构会显得专业很多：

java复制public interface PaymentStrategy {
    boolean pay(Long orderId, BigDecimal amount);
}

@Service("cashPayment")
public class CashPayment implements PaymentStrategy {
    @Override
    public boolean pay(Long orderId, BigDecimal amount) {
        // 标记订单为已支付，登记现金流水
        return true;
    }
}

@Service("wechatPayment")
public class WechatPayment implements PaymentStrategy {
    @Override
    public boolean pay(Long orderId, BigDecimal amount) {
        // 模拟第三方支付回调
        return true;
    }
}

后续如果想对接支付宝沙箱，只要新增一个实现类，把 Spring 容器里的策略注入到 PaymentContext 中，客户端代码不用动。

价格计算时有一个很容易被忽略的问题：数据库存金额字段用什么类型？不要用 float 或 double，会出现 0.1 + 0.2 不等于 0.3 这种精度问题，做金额计算必须用 BigDecimal。字段上对应数据库的 decimal(10, 2)，在 Java 实体里用 BigDecimal 映射。这个细节写进论文和答辩里，是专业度的直接体现。

4.4 取餐叫号与任务调度

线下店取餐一般靠叫号，系统里可以做简单的“大屏取餐页”或“叫号推送”。前端轮询后端接口，查询状态为“已完成”的订单，通过 WebSocket 推送叫号消息。如果毕设时间不够，轮询 + 前端定时刷新就行，数据结构简单，也够用。

制作超时预警用定时任务扫描：订单状态为“已支付”超过 2 分钟还没加工，给店员端推送提醒“有订单待制作”。Spring Boot 里直接用 @Scheduled 注解就够了：

java复制@Component
public class OrderTimeoutTask {

    @Autowired
    private OrderInfoService orderInfoService;

    @Scheduled(cron = "0 */1 * * * ?")
    public void remindPendingOrder() {
        // 查询超过 2 分钟状态仍为 PAID 的订单
        // 调用通知消息服务
        // 写日志
    }
}

如果一个项目里同时出现 @Scheduled、@Async、Redis 缓存，答辩的时候可讲的技术点就非常扎实了。

5. 调试、运行与部署避坑指南

5.1 本地跑起来的完整步骤

很多同学把自己的代码发给别人跑，结果对方启动就报错，绝大多数问题出在环境不一致。这里分享一下我在本地跑这个项目的标准流程。

第一步，环境准备。安装 JDK（版本要和 pom.xml 里的一致）、Maven 3.6 以上、MySQL 5.7 或 8.0、IDEA。数据库建好库，例如 coffee_order，执行项目里配好的 sql/init.sql，把表结构和基础数据初始化好。

第二步，修改配置文件。核心是 application.yml：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/coffee_order?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: yourpassword
  jpa:
    hibernate:
      ddl-auto: update
    show-sql: true

jwt:
  secret: your-secret-key
  expire: 7200

里面最坑的是 serverTimezone=Asia/Shanghai。不加这个配置，启动时会报时区错误，很多第一次做项目的同学都在这里卡住。另外 MySQL 8 的驱动是 com.mysql.cj.jdbc.Driver，MySQL 5 是 com.mysql.jdbc.Driver，不要混。

第三步，启动。在 IDEA 里右键启动类，看到 Spring Boot 的启动横幅后访问 http://localhost:8080。如果前端是 Vue 项目，需要先 npm install，再 npm run dev，通过代理方式把 /api 转发到 8080。

5.2 常见报错与排查实录

我总结几个实际调试中高频出现的问题。

端口被占用。Tomcat 启动报 Port 8080 was already in use。在命令行执行 netstat -ano 找到占用进程，结束进程，或者干脆改 server.port 为 8081。

数据库连接失败。检查 MySQL 服务是否启动、用户名密码是否正确、数据库是否已创建。很多人漏了“创建数据库”这一步，就会一直报 Unknown database。

依赖下载失败或版本冲突。Maven 项目刚拉下来时会从中央仓库下载很多依赖，国内网络环境下载慢，建议配置阿里云镜像。再一个问题，如果 spring-boot 和 mysql-connector 版本不兼容，启动时会有类找不到的报错，调整依赖版本到稳定组合即可。

Lombok 无法使用方法。这是 IDE 插件问题，IDEA 里安装 Lombok 插件，并在 Build 选项里启用 Annotation Processing。

Thymeleaf 页面 404。确认资源文件放在了 templates 目录下，并且 Controller 返回的视图名正确。

Unchecked cast 类型转换、空指针，这类问题要慢慢定位。建议整个项目打印日志用 Logback 而不是 System.out.println，生产环境排查问题会舒服得多。

5.3 部署到服务器和 Docker

毕设有余力的同学，可以把项目部署到云服务器，展示给老师看线上效果。后端部署用两种常见做法。

第一种：Maven 打包成 jar 包，服务器装好 JDK，把 jar 放到服务器上执行 nohup java -jar coffee-system.jar > logs/out.log 2>&1 &。记得在安全组开放 8080 端口。

第二种：Docker 部署。项目根目录写一个 Dockerfile：

dockerfile复制FROM openjdk:8-jre-alpine
COPY target/coffee-system.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app.jar"]

再用 docker build -t coffee-system . 构建镜像，docker run -d -p 8080:8080 coffee-system 启动。如果要用 Docker Compose 把 MySQL 和 Redis 也编排进去，可讲的内容更多。

网上搜“springboot jdk1.8 打包到 docker desktop”这类问题的人不少，常见坑是基础镜像选择了不兼容的架构，或者本地 jar 没先打包好就执行 docker build。记住固定顺序：先 mvn clean package -DskipTests，确认 target 目录下有 jar，再构建镜像。

5.4 请求链路排查技巧

这个项目调试时，建议打开浏览器开发者工具，看网络请求。如果接口报 500，直接看后端控制台堆栈；报 404，大概率是路径写错，或者拦截器拦截了请求；报 401/403，检查 Token 有没有传、角色是否符合接口要求。

找一个趁手的接口调试工具很重要。IDEA 自带的 HTTP Client，或者 Postman 都可以。像我平时习惯把常用接口保存下来，启动完项目以后先用接口工具跑一遍登录、商品列表、下单流程，确认没问题再打开前端页面操作，不至于前端后端混在一起找 bug。

6. 答辩重点与扩展方向

6.1 评审老师最容易问的问题

毕业设计答辩最怕的是“代码是你写的吗”一问就露馅。这里我把高频问题整理成速查表，每个问题背明白，答辩就稳了：

平时自己多问几遍“如果用户连续点了两次提交怎么办”，把它想清楚，答辩的自然程度会大幅提升。

6.2 三个高性价比扩展方向

如果主系统已经跑通，时间还有富余，可以挑一两个方向做扩展，直接提升项目档次。

第一个是优惠券与会员体系。瑞幸这类咖啡品牌对会员运营非常看重。设计会员等级（普通、银卡、金卡），不同等级享受不同折扣，再加新客立减券、满减券、下午茶时段折扣券。这个模块能引出 Redis 缓存、定时任务、条件查询等一堆技术点。

第二个是数据可视化大屏。用 ECharts 做一个门店经营看板，展示今日销售额、订单量趋势、热销商品 Top5、时段客流分布。后端写几个统计接口，用聚合函数按天/小时分组查询。视觉效果好，答辩时直接放截图，吸引力拉满。

第三个是移动端小程序。微信小程序点单体验更接近真实场景，顾客在线选杯型、加料、下单、支付成功后生成取餐码，店员扫描核销。小程序端用原生开发或 uni-app 都行，Spring Boot 后端接口不变，只需增加几个开放接口。工作量适中，但技术覆盖面一下子涵盖到移动端，简历上写“小程序 + Spring Boot 全栈项目”会很有竞争力。

最后分享一点我的实际体会

做这个项目我踩过的最大一个坑是：一开始把重心全放在“功能多”上，结果光用户权限、商品规格就写了一堆，最后没有时间认真做测试和写文档，论文被老师打回来好几次。后来重新梳理，把项目拆成订单、商品、用户、统计四个大模块，每个模块先做核心流程，再往里添新特性，节奏立刻顺了很多。

所以我的建议是，不论标题里写了多少功能要点，第一步一定是先跑通“下单支付出小票”这条主干，把数据库的主表字段定好，再慢慢长出枝叶。不要一上来就研究那些炫酷的扩展功能，主干不倒，项目就立得住。

还有一点，源码和文档一定要同步维护。每完成一个功能，花十分钟更新数据库更新脚本和 README，记录遇到的问题和解决思路。最后写论文的时候，你会发现这些记录比任何参考资料都有用。祝各位的毕设顺利过关，也能从这个项目里真正学到东西。