Spring Boot+Vue台球厅管理系统：RBAC权限、状态机与并发控制实战

简介：这是一份基于Spring Boot与Vue.js的校园台球厅人员与设备管理系统毕业设计资源，适合计算机相关专业学生用于毕业设计参考或前后端分离项目实践。系统采用B/S结构，以MySQL作为数据库，涵盖用户管理、会员账号管理、会员充值管理、球桌信息管理、会员预约、普通预约、留言反馈和系统管理等完整功能模块。压缩包共806个文件，大小约22.98MB，包含Java后端源码、Vue前端组件、JavaScript脚本、CSS样式、图片图标资源、SQL数据库脚本、毕业论文和答辩PPT等，目录结构便于按模块检索。已有126人学习下载，适合参考系统设计、数据库关系分析与前端交互实现，也适合作为课程设计与求职作品集素材。论文和PPT可辅助快速梳理答辩重点，帮助读者从环境搭建、数据库设计到前后端联调深入理解完整开发流程。

1. 毕业设计从「会写接口」到「能答辩」的关键一步

如果你的开题题目是「基于Spring Boot+VUE的校园台球厅人员与设备管理系统」，大概率是冲着「前后端分离 + 权限管理 + 设备状态追踪」这条技术线去的。这类题目的难点从来不在增删改查本身，而在三件事：一是多人角色（学生、管理员、前台）的权限边界怎么设计，二是台球桌这种「按时计费」的资源状态怎么在并发下保持一致，三是设备维修记录、会员储值这类业务字段怎样落到表结构里，让论文里的ER图和设计说明站得住。本文从工程落地角度，把这张题目的四层架构、接口设计、前端路由与状态管理、打包部署和答辩演示节奏串成一条可以照做的路径，适合打算拿Spring Boot和Vue框架做完整课设、同时需要同步产出毕业论文和答辩PPT的读者。

2. Spring Boot + Vue 的系统分层与「台球厅」业务映射

2.1 四层架构里每一层该放什么，别把 Controller 写成万能类

Spring Boot 四层架构（Controller / Service / Mapper / Entity）在课程设计里最常见的翻车点是「Controller 里直接查数据库」。答辩时老师只要问一句「事务边界在哪」，就会卡住。常见的做法是把架构拆成下面这张对照表，每一层只干一件事：

在 Spring Boot 工程里，代码结构一般这样组织：

com.campus.billiards ├── controller // 接收 HTTP 请求 ├── service // 业务接口与实现 ├── mapper // MyBatis-Plus 的 Mapper 接口 ├── entity // 数据库对应实体 ├── dto // 请求/响应对象 ├── config // 跨域、拦截器、WebMvc 配置 └── common // 统一返回结果、异常处理

写 Service 时有一条硬性要求：凡是涉及金额、库存、设备状态变更的方法，必须加@Transactional。比如「用户开台」这个方法，要扣余额、改桌台状态、生成订单记录，三步必须在一个事务里，否则扣款成功但开台失败，前端就出现「钱没了台子没开」的脏数据。Controller 里禁止直接注入 Mapper，这是答辩时老师看代码风格的第一眼。

2.2 用 RBAC 权限模型区分学生、前台、管理员

校园台球厅至少有三类角色：学生用户（在小程序或网页端预约台桌、查看账单）、前台人员（开台结账、登记设备故障）、系统管理员（管理用户、查看营收统计、维护设备信息）。

RBAC 模型落地时就是三张表加两张关联表：sys_user、sys_role、sys_menu、user_role、role_menu。Spring Boot 后端用拦截器校验登录态，再用 AOP 或注解做按钮级控制。最常见的做法是定义如下注解：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequirePermission { String value(); // 例如 "billiards:table:update" }

结合 Spring Boot 的 HandlerInterceptor，在preHandle中解析用户角色对应的权限集合，如果请求方法上没有对应权限标识就直接返回 403。这里要注意：权限标识的命名建议用「资源:操作」格式，例如table:occupy、device:repair、order:refund。这个细节在论文的数据字典部分可以写得很漂亮，答辩时也容易展开。

2.3 台球厅特有的状态机设计

台球厅的核心业务是「开台 → 计时 → 结账」，外加「设备维修 → 恢复使用」。这些状态如果只用 int 字段乱写，后续统计报表会很难写。常见落法是这样定义状态字典：

• 台桌状态：0 空闲，1 使用中，2 已锁定（维修/预留）
• 订单状态：0 进行中，1 已结账，2 已取消
• 设备状态：0 正常，1 故障报修，2 维修中，3 已报废

在 Service 层里只暴露「开台」「结账」「报修」「维修完成」这几个动作方法，禁止直接对外提供「更新台桌状态」这种通用接口。这样做的意义在论文里可以对应「业务规则封装」这一节，在代码层面就是防止前端乱传参数把台桌状态改成非法值。

3. 后端核心接口：计时计费、设备管理与文件上传

3.1 开台与结账的接口设计与并发控制

台球厅的计费逻辑是「按时段计费 + 超时加费」。比如普通时段 20 元/小时，晚 7 点后 30 元/小时，超过半小时按一小时收。开台接口大致长这样：

@PostMapping("/api/table/occupy") public R occupyTable(@RequestBody OccupyRequest req) { Long tableId = req.getTableId(); Long userId = req.getUserId(); // 1. 使用乐观锁更新台桌状态：只有 state=0 才能更新为 1 int updated = tableMapper.occupyIfFree(tableId, 0, 1); if (updated == 0) { throw new BizException("该台桌已被占用或锁定"); } // 2. 开启一个计费订单 Order order = new Order(); order.setUserId(userId); order.setTableId(tableId); order.setStartTime(LocalDateTime.now()); order.setStatus(0); orderMapper.insert(order); return R.ok(order); }

XML 里对应的方法是这个：

UPDATE table_info SET state = 1, update_time = NOW() WHERE id = #{tableId} AND state = 0

这里用的是乐观锁思路，而不是「先查再改」。两个人同时开同一张台桌时，数据库层面的行锁保证了只有一个请求能updated=1，另一个直接失败。这个点写在论文里比「加了 synchronized」要高级得多，因为它说的是数据库层面的并发安全。

结账接口要算出费用，并同时完成「订单关闭 + 台桌释放 + 扣用户余额」三个动作：

@Transactional public void settleOrder(Long orderId) { Order order = orderMapper.selectById(orderId); if (order.getStatus() != 0) { throw new BizException("订单已结算"); } long minutes = Duration.between(order.getStartTime(), LocalDateTime.now()).toMinutes(); BigDecimal fee = calcFee(order.getStartTime(), minutes); userMapper.deductBalance(order.getUserId(), fee); order.setEndTime(LocalDateTime.now()); order.setAmount(fee); order.setStatus(1); orderMapper.updateById(order); tableMapper.updateState(order.getTableId(), 0); }

注意calcFee这个私有方法要单独抽出来。答辩时老师通常会对计费规则提问，比如跨时段怎么算、不满半小时怎么算。把费率配置放到application.yml里而不是写死在代码中，后续改价就不用重启改代码。

3.2 设备管理接口：维修记录要关联设备与经办人

设备管理部分的表设计通常是device_info（设备基础信息）和device_repair_record（维修记录）两张表：

public class DeviceRepairRecord { private Long id; private Long deviceId; // 关联 device_info.id private String faultDesc; // 故障描述 private String status; // 待维修 / 维修中 / 已完成 private Long handlerId; // 维修人员（关联 sys_user.id） private LocalDateTime createTime; private LocalDateTime finishTime; }

列表查询时，前端往往要同时展示设备名称和维修人姓名，这时不要用select *然后内存拼接，直接在 Mapper 里写连表查询：

<select id="selectRepairVOList" resultType="com.campus.billiards.vo.RepairRecordVO"> SELECT r.*, d.device_name, d.device_code, u.real_name AS handler_name FROM device_repair_record r LEFT JOIN device_info d ON r.device_id = d.id LEFT JOIN sys_user u ON r.handler_id = u.id ORDER BY r.create_time DESC </select>

如果用了 MyBatis-Plus，也可以直接用@Select注解写在 Mapper 接口上，但复杂的条件筛选（按设备类型、按状态、按时间范围）建议还是走 XML，可读性更好。设备管理模块在答辩的 PPT 里适合放截图：一个设备列表页，带搜索框、状态标签、维修历史弹窗，技术点上覆盖了「一对多关联」和「状态流转」，属于非常好讲的功能点。

3.3 使用 Spring Boot 上传文件：设备图片与选课照片通用做法

校园台球厅系统里，用户头像、设备照片、故障照片都需要文件上传功能。Spring Boot 上传文件的常见实现是本地存储 + 返回静态资源 URL：

file: upload-dir: ./upload access-path: /files/**

对应的配置类把本机目录映射为静态资源：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${file.upload-dir}") private String uploadDir; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceHandler("file:" + uploadDir + "/"); } }

上传接口的写法在 Spring Boot 3.x 里要注意构造器注入：

@PostMapping("/api/file/upload") public R upload(@RequestParam("file") MultipartFile file) { String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFileName = UUID.randomUUID() + ext; File dest = new File(uploadDir, newFileName); file.transferTo(dest); String url = "/files/" + newFileName; return R.ok(url); }

这里有两个容易踩的坑：一是transferTo之前要确保uploadDir目录存在，用File.mkdirs()创建；二是文件后缀要做白名单校验，.jpg、.png之外的文件直接拒绝，防止上传恶意脚本文件。配置里的spring.servlet.multipart.max-file-size默认只有 1MB，设备照片往往拍出来好几 MB，需要明确设成10MB，否则前端会收到 500 错误。

4. 前端 VUE：路由、状态管理与 m3u8 视频流的接入点

4.1 Vue 项目初始化与目录结构

Vue 项目脚手架一般用 Vite 创建，如果你使用的 Node 版本较老，也可以继续用vue-cli。这里以常见做法为准：

npm create vue@latest campus-billiards-web cd campus-billiards-web npm install npm install vue-router@4 pinia axios element-plus

安装依赖时如果网络不好，把镜像源切到国内 npmmirror 可以快很多：

npm config set registry https://registry.npmmirror.com npm run dev

前端目录建议按模块拆分，而不是所有页面平铺在views下面：

src ├── api // axios 请求封装 ├── router // 路由表与守卫 ├── stores // pinia 状态仓库 ├── views │ ├── system // 用户管理、角色管理 │ ├── device // 设备列表、维修记录 │ └── order // 订单开台、账单列表 └── utils // token 存储、格式化工具

axios 封装里要包含请求拦截器和响应拦截器。请求拦截器把本地存的 token 加到Authorization头，响应拦截器统一处理 401（跳转登录页）和业务错误码（弹出错误消息）。这样可以做到每个业务接口只关心res.data，不用重复写错误处理。

4.2 vue-router 路由守卫与角色权限过滤

台球厅系统的路由表分两类：公开路由（登录页、注册页）和需要登录的路由（首页、订单页、设备管理）。在 Vue Router 中通过路由守卫实现：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path === '/login') { next() return } if (!token) { next('/login') return } if (to.meta.roles && !to.meta.roles.includes(userStore.role)) { next('/403') return } next() })

注意to.meta.roles的使用方式：在路由定义中给管理页加上roles: ['ADMIN']，这样学生账号即使手动输入/system/user也进不去。这个机制和后端的 RBAC 是配套的，前端做界面层拦截，后端做真正的数据安全拦截，两者同时存在才合理。写论文时可以对比说明「前端路由守卫解决体验问题，后端拦截器解决安全问题」。

4.3 Pinia 管理登录态与桌面状态

Vue 状态管理在 Vue 3 项目中优先选择 Pinia（Vuex 虽然也能用，但 Pinia 对 TypeScript 的类型推导更友好）：

export const useUserStore = defineStore('user', { state: () => ({ token: localStorage.getItem('token') || '', userInfo: {} }), actions: { setToken(token) { this.token = token localStorage.setItem('token', token) }, logout() { this.token = '' this.userInfo = {} localStorage.removeItem('token') } } })

台球厅还有一个值得用全局状态管理的场景：开台后，前台页面的「台桌状态面板」需要轮询后端获取每张台桌的剩余时间。如果不做全局状态管理，每个组件各自轮询会造成大量重复请求。常见的做法是在 Pinia 里维护一个tableStatusMap，由台桌面板容器组件统一定时请求，子组件从 store 读取展示。

4.4 Vue 播放 m3u8：台球厅监控画面的接入

校园台球厅系统常有「查看台球厅实时画面」的模块，此时如果设备是海康/大华等摄像头，取流地址往往是 HLS 协议的.m3u8格式。这类媒体流不能在 Vue 里直接用<video src="...">播放，需要借助 hls.js 库：

npm install hls.js

封装一个视频组件：

<template> <video ref="videoRef" controls muted></video> </template> <script setup> import Hls from 'hls.js' import { ref, onMounted } from 'vue' const props = defineProps({ src: { type: String, required: true } }) const videoRef = ref(null) onMounted(() => { if (Hls.isSupported()) { const hls = new Hls() hls.loadSource(props.src) hls.attachMedia(videoRef.value) } else if (videoRef.value.canPlayType('application/vnd.apple.mpegurl')) { // 直接赋值给 video 标签 src，适用于 Safari / iPhone 端 videoRef.value.src = props.src } }) </script>

原理上，m3u8 是一个索引文件，里面记录了若干个.ts分片文件的地址，Hls.js 会动态拉取分片并交给 video 标签解码播放。这个功能放在课设里非常加分，因为一般项目都是纯 CRUD，能处理流媒体说明你接触过真实业务场景。答辩时重点讲「为什么不能直接用<video>播放」——因为 Safari 之外的主流浏览器不支持原生 HLS，必须靠 MSE 分片喂数据。

4.5 Vue 打包后布局异常的排查路径

课程设计最常见的报错是「开发环境正常，npm run build后页面空白或图片丢失」。这个问题九成出在静态资源路径上，Vite 默认打包后资源路径是/asset/xxx，部署到服务器二级路径（如http://ip:8080/web/）就会 404。

要在vite.config.js中设置：

export default defineConfig({ base: './', // 相对路径，适配任意子路径 server: { port: 3000, proxy: { '/api': 'http://localhost:8080' } } })

这里base: './'让打包后的index.html用相对路径引用 JS/CSS，就不会出现「刷新后 404」的问题。另一个常见坑是 Vue Router 的 history 模式：打包部署后刷新非首页时 Nginx 返回 404，需要在 Nginx 配置里加try_files $uri $uri/ /index.html;，或者偷懒改回 hash 模式。如果你没有 Nginx 操作权限，建议直接用 hash 模式提交课设，答辩演示时基本不会出意外。

5. 带论文答辩的完整交付技巧与验收清单

5.1 用测试数据撑起毕业论文的验证章节

论文里的「系统测试」部分最怕空截图。常见的做法是准备一份「演示数据脚本」：创建 10 个测试用户（学生/前台/管理员各若干）、5 张台桌（含一张待维修状态）、一周内的历史订单（手工造一些跨时段订单，方便展示计费规则）。数据脚本写成.sql文件随项目提交，在application.yml中配置spring.sql.init.mode=never，需要时手动执行，避免每次启动都重置数据。

测试表格建议做一张功能测试矩阵表，横向列举功能模块和对应权限，纵向记录测试步骤和预期结果。这张表能同时用在论文的「功能测试」小节和答辩 PPT 的「运行效果」页。性能测试部分对于课设来说可以写轻量级的：用 JMeter 工具对「开台」接口做 50 个并发请求，验证乐观锁是否生效。不要用「系统稳定运行」这种空话，给出具体数字和响应时间。

5.2 答辩演示的顺序和操作脚本

答辩演示最忌讳现场临场乱点。建议按下面顺序整理成一个操作脚本：

1. 先演示登录页，说明使用 JWT 做身份认证，简单讲一下登录流程。
2. 切到「台桌状态面板」，点开台，展示用户余额被扣减、台桌变红计时开始。
3. 再点结账，展示订单金额的计算明细与余额退回结果。
4. 切到「设备维修」页面，新增一条故障记录，刷新后状态变为「待维修」。
5. 如果镜头时间充裕，打开监控画面页面，展示 m3u8 视频流能正常播放。

每步控制在 1 分钟以内，讲解时聚焦「这个页面背后的表结构或接口逻辑」。比如点结账时，说一句「这里用了事务注解，三张表一起更新，任何一步失败都会回滚」比演示操作本身更能拿分。

5.3 文档与 PPT 的对应关系

毕业论文的结构一般包含绪论、需求分析、系统设计、系统实现、系统测试五大部分，交付的 PPT 页数在 15 到 20 页之间。建议 PPT 中每页只突出一个重点：系统架构图、功能结构图、ER 图、核心技术难点、页面截图。答辩老师翻论文时，大概率会看数据表设计是否合理，所以论文中的数据库设计章节要另附一张完整的数据表字段表，字段给出注释，类型精确到DECIMAL(10,2)、DATETIME，不要用笼统的 varchar 概括。这部分如果直接复刻上面的订单表和维修记录表设计，改改字段名就能用。

最后再给一个细节：将整个项目打成 Zip 压缩包，里面包含后端源码、前端源码、数据库脚本、论文 Word 和 PDF 版本、答辩 PPT、演示视频录屏。录制一段 3 分钟的核心功能操作视频放在压缩包里，即便现场设备出问题，也可以放录像救场。这既是工程交付习惯，也是连验收老师都会认可的职业态度。

本文还有配套的精品资源，点击获取