SpringBoot+Vue+MySQL构建台球厅管理系统：从CRUD到业务闭环实战

你有没有想过，一个看似传统的台球厅，背后其实藏着一整套复杂的运营逻辑？会员充了钱，怎么快速核销？黄金时段的球桌，怎么避免被重复预约？每天的流水和耗材，老板怎么一眼看清？这些问题，靠手写登记本或者简单的Excel表格，不仅效率低下，还容易出错、引发纠纷。

很多计算机专业的同学在做毕业设计时，会选择这类“XX管理系统”。选题看似普通，但真正动手后才发现，从需求分析到技术选型，从数据库设计到前后端联调，每一步都暗藏玄机。一个能跑通的Demo和一套真正考虑过业务闭环、异常处理和用户体验的系统，中间隔着不止一个“Hello World”的距离。

今天，我们就以“台球厅管理系统”这个典型的毕业设计课题为例，深入拆解如何用SpringBoot + Vue + MySQL这套经典技术栈，不只是“做出来”，而是“做明白”。我们将超越简单的CRUD（增删改查），探讨如何将零散的业务点，串联成一个有逻辑、可扩展、能应对真实场景的完整项目。这不仅是完成一份作业，更是理解一个真实软件产品从构思到落地的核心脉络。

1. 先想清楚：台球厅管理系统，到底要管什么？

在打开IDE写第一行代码之前，最关键的步骤是厘清业务边界。一个管理系统不是功能的堆砌，而是对现实业务流程的数字化抽象。对于台球厅，我们可以从“人、物、事、钱”四个维度来拆解核心模块。

1.1 核心业务对象建模（“人”与“物”）

这是系统的基石，模型设计的好坏直接决定了后续开发的复杂度。

• 会员（Member）： 不仅仅是存储姓名电话。一个完整的会员模型至少包括：

  • 基础信息： ID、姓名、手机号（可作为登录账号）、注册时间。
  • 账户信息： 会员等级（普通/VIP，关联折扣）、账户余额（用于消费扣款）、积分。
  • 状态信息： 账户状态（正常/冻结）。
  • 设计思考： 手机号需要唯一索引。余额变动（充值、消费）必须记录流水，不可直接修改余额字段，这是保证财务数据准确性的铁律。

• 球桌（Table）： 核心资源，其状态驱动着整个预约流程。

  • 基础信息： 桌号、类型（斯诺克/美式黑八/九球）、每小时单价。
  • 状态信息：当前状态（空闲/使用中/清洁中/维修中）。这是整个系统最“动态”的字段。
  • 设计思考： 单价可能因时段（闲时/忙时）或会员等级而变化，初期可以简化，但在数据库设计时要预留扩展字段或考虑关联价格策略表。

• 商品（Product）： 除计时收费外的收入来源，如酒水、小吃。

  • 基础信息： 名称、分类、单价、库存。
  • 设计思考： 需要管理库存，销售后扣减。商品可能参与套餐促销，模型设计需考虑灵活性。

1.2 核心业务流程闭环（“事”与“钱”）

业务对象是静态的，流程让它们动起来，并产生价值（数据）。

• 预约-消费-结算流程： 这是系统的主动脉。

  1. 预约： 会员选择球桌、时段 -> 系统检查冲突 -> 生成预约单（状态：待使用）。
  2. 开局： 会员到店，前台“激活”预约 -> 预约单状态变为“使用中”，球桌状态同步变为“使用中”。这里开始计时。
  3. 消费追加： 使用过程中，可能加时、购买商品。这些操作都挂载在当前消费单下。
  4. 结算： 会员结束使用 -> 系统计算总费用（计时费+商品费）-> 选择支付方式（余额、现金、扫码）-> 完成结算。消费单状态变为“已完成”，球桌状态释放为“空闲”或“清洁中”。
  • 关键点： 必须有一张“消费单/订单（Order）”表来串联整个流程，记录预约ID、会员ID、桌号、开始时间、结束时间、总金额、支付状态、支付方式等。它是财务对账的核心依据。

• 会员充值流程： 资金流入。

  • 生成充值订单 -> 支付（对接支付接口或标记现金收讫） -> 会员余额增加，同时必须生成一条充值流水记录。流水记录应包含操作员、充值前余额、充值金额、充值后余额、时间。这为后续任何对账或争议提供不可篡改的证据链。

• 库存管理流程： 商品进销存。

  • 采购入库 -> 库存增加。销售出库 -> 库存减少。需设置库存预警阈值。

1.3 容易被忽略的“非功能”需求

这些是区分“玩具项目”和“可用系统”的关键。

• 权限管理（RBAC）： 前台收银员、店长、系统管理员看到和能操作的界面肯定不同。Spring Security 或 Shiro 是实现RBAC的标准选择。设计好用户-角色-权限表结构。
• 数据统计与报表： 老板最关心的部分。日/月营收报表、球桌使用率高峰时段、热门商品销售排行。这需要你编写复杂的查询SQL，或使用ECharts等图表库在前端可视化。统计功能是毕业设计答辩时的亮点。
• 操作日志： 关键业务操作（如充值、结算、修改单价）需要记录“谁在什么时间做了什么”。这对于内部管理和审计至关重要。

注意： 不要试图在第一版实现所有功能。采用迭代思维，先核心（会员、球桌、预约、消费），再扩展（商品、库存），最后完善（报表、日志）。先让主流程跑通。

2. 技术选型与架构：为什么是 SpringBoot + Vue + MySQL？

这套组合不是随意拼凑，而是经历了市场检验的、适合快速开发业务系统的“黄金搭档”。理解其优势，能让你在答辩时言之有物。

2.1 后端：SpringBoot 如何化繁为简

传统Spring项目需要繁琐的XML配置。SpringBoot的核心价值是约定大于配置和自动装配。

• 快速启动： 一个@SpringBootApplication注解的主类，内嵌Tomcat，直接java -jar就能运行。这让你能专注于业务逻辑，而非环境搭建。

• 简化配置： 在application.yml中集中配置数据源、端口、日志等。Profile功能（application-dev.yml,application-prod.yml）轻松区分开发、生产环境。

• 丰富的Starter： 这是最大的利器。

  • spring-boot-starter-web： 快速构建Web接口。
  • spring-boot-starter-data-jpa或mybatis-spring-boot-starter： 便捷操作数据库。JPA更面向对象，MyBatis对复杂SQL更灵活。毕业设计推荐MyBatis-Plus，它在MyBatis基础上提供了强大的CRUD封装和条件构造器，能极大提升开发效率。
  • spring-boot-starter-security： 集成安全框架。
  • spring-boot-starter-aop： 方便地实现日志切面。

• 项目结构建议：

  src/main/java/com/billiards/ ├── BilliardsApplication.java // 启动类 ├── config/ // 配置类（如跨域、MyBatis-Plus分页插件） ├── controller/ // 控制器，接收请求 ├── service/ // 业务逻辑层接口 ├── service/impl/ // 业务逻辑层实现 ├── mapper/ // MyBatis Mapper接口 ├── entity/ // 实体类，对应数据库表 ├── dto/ // 数据传输对象，用于前后端交互 ├── vo/ // 视图对象，用于接口返回 └── common/ // 通用类（常量、工具类、统一响应体）

2.2 前端：Vue 3 的响应式与组件化

Vue的核心是数据驱动视图和组件化开发，这让构建复杂交互的管理后台变得清晰。

• 组合式 API (Composition API)： Vue 3 推荐的方式。使用setup()函数和ref、reactive等函数组织逻辑，相比Vue 2的选项式API，逻辑关注点更集中，代码复用性更强（自定义Hook）。
• 前端路由 (Vue Router)： 管理页面切换，实现单页面应用(SPA)体验。对应后台的菜单结构。
• 状态管理 (Pinia)： Vue 3 官方推荐的状态管理库，比Vuex更简洁。用于管理跨组件共享的状态，如当前登录用户信息。
• UI框架选择：强烈建议使用成熟的UI组件库，如Element Plus(对应Vue 3) 或Ant Design Vue。它们提供了丰富的表格、表单、弹窗、日期选择器等组件，能节省你大量写基础样式和交互的时间，让你聚焦业务页面组装。
• 前端项目结构建议：

  src/ ├── api/ // 封装所有对后端接口的请求函数 ├── assets/ // 静态资源 ├── components/ // 公共组件（如搜索框、分页器） ├── router/ // 路由配置 ├── stores/ // Pinia状态管理 ├── views/ // 页面组件（会员管理、预约管理） ├── utils/ // 工具函数 └── App.vue, main.js

2.3 数据层：MySQL 的设计要点与优化

数据库设计是系统的“心脏”。

• 表结构设计： 遵循三范式基础，但不必教条。根据上述业务分析，你至少需要：member（会员）、billiard_table（球桌）、product（商品）、order（消费订单）、order_item（订单明细，用于记录商品消费）、reservation（预约记录）、recharge_record（充值流水）、user（后台用户）。
• 字段类型选择：
  • 金额使用DECIMAL(10,2)，避免浮点数精度问题。
  • 状态字段使用TINYINT或VARCHAR(10)，并在代码中用枚举类管理。
  • 时间字段使用DATETIME或TIMESTAMP。
• 索引策略：
  • 主键： 每张表必须有自增主键id。
  • 唯一索引： 会员手机号、球桌桌号。
  • 普通索引： 高频查询条件，如订单表的member_id、status、create_time。预约表的table_id、reservation_time。
• SQL编写： 在Service层或Mapper层，使用MyBatis-Plus的条件构造器或编写XML映射文件。复杂查询（如报表）可能需要联表或多条SQL组合。

2.4 前后端分离与联调

这是现代Web开发的标准模式。

• 交互方式： 前端通过Axios库发送HTTP请求（GET/POST/PUT/DELETE）到后端接口。
• 数据格式： 前后端统一使用JSON进行数据交换。
• 跨域问题 (CORS)： 开发时，前端运行在localhost:8080，后端在localhost:8081，浏览器会因同源策略阻止请求。在后端SpringBoot中，通过@CrossOrigin注解或全局配置类解决。
• 接口文档： 使用Swagger或Knife4j自动生成API文档。这不仅能方便前端查看，也是你毕业设计文档中“系统实现”部分的重要素材。

3. 从零到一：关键功能模块实战拆解

让我们聚焦几个最具挑战性也最体现业务逻辑的功能，看看代码如何落地。

3.1 球桌预约模块：解决资源与时间的冲突

这是系统的核心难点，核心问题是：如何防止同一张球桌在同一时间段被重复预约？

后端实现逻辑：

1. 接口设计：POST /api/reservation接收预约请求。
2. 参数校验： 检查会员是否存在、球桌是否存在且状态是否为“空闲”、预约时段是否合法（如不能预约过去的时间）。
3. 冲突检测（最关键步骤）： 在插入新预约记录前，必须查询数据库。

   SELECT COUNT(*) FROM reservation WHERE table_id = #{tableId} AND status != 'CANCELLED' -- 已取消的预约不计入冲突 AND ( (start_time < #{newEndTime} AND end_time > #{newStartTime}) )

   如果查询结果大于0，则说明时间段有重叠，直接返回“该时段已被预约”的错误。
4. 事务操作： 检测通过后，在一个数据库事务中执行：
   • 插入一条新的预约记录（状态为“待使用”）。
   • （可选）更新球桌状态为“已预约”。（另一种设计是，球桌状态只维护“空闲/使用中/清洁中/维修中”，预约状态单独由预约表管理）。
5. 预约状态流转： 提供“取消预约”、“开局”（转为消费单）等接口，并相应更新预约状态和球桌状态。

前端实现要点：

• 使用 Element Plus 的DatePicker和TimePicker组件选择日期和时间。
• 在提交前，可以前端先做基础校验（如时间是否晚于当前时间）。
• 提交后，根据后端返回结果，给出成功或失败提示。

3.2 消费结算模块：保证财务准确性

从开局到结算，涉及多个状态变更和金额计算。

后端实现逻辑：

1. 开局：POST /api/order/start。根据预约ID或直接选择会员和球桌，创建一条初始消费订单，记录开始时间。将球桌状态置为“使用中”。
2. 消费追加：POST /api/order/{orderId}/addItem。可以添加“加时”项目（按规则计算加时费用）或商品项目（从商品表读取单价，扣减库存）。
3. 结算：POST /api/order/{orderId}/settle。
   • 计算总费用： 重新计算所有项目的总和。计时费 = (结束时间 - 开始时间) * 单价。商品费直接累加。
   • 会员折扣： 根据会员等级，对总费用应用折扣。
   • 支付： 支持多种方式。如果使用余额支付，需要：
     1. 检查余额是否充足。
     2. 在一个事务中：扣减会员余额 -> 更新订单状态为“已支付” -> 记录支付流水 -> 释放球桌状态。
   • 生成收据： 可以使用像EasyExcel这样的库动态生成结算单PDF或Excel，供打印或下载。

关键点：

• 金额计算务必在服务端进行，前端只做展示。所有涉及资金变动的操作，必须放在数据库事务中，保证原子性。
• 时间处理： 使用Java 8+的LocalDateTime，并在数据库存取时注意时区问题。

3.3 数据统计报表：从数据中洞察业务

这是展示你SQL能力和前端可视化能力的舞台。

后端实现逻辑：

1. 定义统计维度：
   • 营收报表：按日、月统计总收入、现金收入、余额收入、商品收入。
   • 球桌使用率：统计每张球桌每天/月的总使用时长、空闲时长。
   • 会员分析：新增会员数、会员消费排行、会员充值排行。
2. 编写统计SQL： 这通常涉及GROUP BY、日期函数 (DATE())、聚合函数 (SUM,COUNT)、多表连接 (JOIN)。

   -- 示例：每日营收统计 SELECT DATE(create_time) as date, COUNT(*) as order_count, SUM(total_amount) as total_income, SUM(CASE WHEN pay_method = 'CASH' THEN total_amount ELSE 0 END) as cash_income, SUM(CASE WHEN pay_method = 'BALANCE' THEN total_amount ELSE 0 END) as balance_income FROM `order` WHERE status = 'PAID' AND create_time BETWEEN #{startDate} AND #{endDate} GROUP BY DATE(create_time) ORDER BY date;

3. 提供数据接口： 创建GET /api/report/dailyIncome等接口，接收时间范围参数，返回统计结果。

前端实现要点：

• 使用ECharts或 AntV 等图表库。
• 提供日期范围选择器，让用户自定义查询。
• 将后端返回的数据，映射成图表所需的option配置，渲染出柱状图、折线图、饼图等。

4. 超越CRUD：让毕业设计脱颖而出的进阶思考

完成基本功能只是及格线。要让你的项目在答辩时令人印象深刻，需要体现更多的工程化思维和解决复杂问题的能力。

4.1 处理高并发场景：预约秒杀与乐观锁

想象一下，周末晚上8点，所有球桌刚释放，多名会员同时在线抢订。简单的“查询-插入”流程会导致超售。

• 问题： A和B同时查询某球桌8-10点时段，系统都返回“空闲”。两人同时插入预约，导致重复预订。
• 解决方案：乐观锁。
  1. 为球桌表增加一个版本号字段version（整数）。
  2. 预约时，先查询球桌信息和当前version。
  3. 执行更新操作时，将版本号作为条件：

     UPDATE billiard_table SET status = 'RESERVED', version = version + 1 WHERE id = #{id} AND version = #{oldVersion};

  4. 检查更新影响的行数。如果为0，说明在此期间版本号已被其他请求修改（即资源被抢），则返回失败给用户。
• 用户体验： 前端在提交预约后，如果因冲突失败，应友好提示“您选择的时段已被抢订，请重新选择”。

4.2 定时任务：自动化状态管理

有些状态需要系统自动推进，而不是依赖人工操作。

• 场景： 预约了晚上8点的台子，会员8:20才到。系统应该在8:10（预约时间后10分钟）自动将“待使用”的预约标记为“已过期”，并释放球桌状态。
• 实现： 使用Spring Boot的@Scheduled注解创建定时任务。

  @Component public class ReservationTask { @Scheduled(cron = "0 */5 * * * ?") // 每5分钟执行一次 public void checkExpiredReservations() { // 查询所有状态为‘待使用’且预约开始时间已过10分钟的预约记录 // 将其状态更新为‘已过期’，并关联球桌状态恢复为‘空闲’ } }

4.3 缓存优化：提升高频查询性能

像“空闲球桌列表”这种数据，被查询的频率极高，但变化不频繁（只在开局、结算时变化）。

• 方案： 引入Redis。在球桌状态变更时（开局、结算、清理完成），同步更新Redis中的缓存。查询空闲球桌列表时，首先从Redis获取，获取不到再查数据库并回填缓存。
• 价值： 极大减轻数据库压力，提升页面响应速度。在答辩中提及缓存设计，能显著体现你对性能的考量。

4.4 部署与文档：项目的最后一公里

一个无法运行的项目是没有价值的。

• 后端部署：
  • 使用mvn clean package打包生成可执行的jar文件。
  • 在服务器（或本地模拟）通过nohup java -jar your-project.jar &后台运行。
  • 考虑使用Docker容器化部署，将应用和依赖环境打包，实现一键部署，这是非常加分的技能点。
• 前端部署：
  • 运行npm run build生成静态资源文件（dist目录）。
  • 将其放入Nginx或Apache等Web服务器中，并配置代理，将API请求转发到后端服务。
• 项目文档：
  • README.md： 项目简介、技术栈、快速启动指南。
  • 数据库设计文档： ER图、表结构说明。
  • 接口文档： 通过Swagger自动生成，并补充重要的业务说明。
  • 部署文档： 清晰的服务器环境要求、安装步骤、配置项说明。

从一张球桌的预约状态，到一个会员的消费流水，再到整个店铺的营收报表，构建一个管理系统本质上是在用代码为真实的商业世界建模。这个毕业设计项目，最大的价值不在于你用了多少时髦的技术，而在于你是否通过它，完整地走完了一次“需求分析 -> 设计 -> 实现 -> 测试 -> 部署”的软件生命周期，并理解了数据如何驱动业务，逻辑如何闭环。当你能够清晰地向答辩老师解释，为什么预约需要冲突检测，为什么资金变动必须用事务，为什么需要定时任务时，你的项目就已经超越了大多数单纯的“增删改查”练习，具备了解决真实问题的雏形。