小区体育运动中心预约管理系统算是我这几年接触到的选题里最典型的一类。Vue3 SpringBoot 前后端分离把篮球场、羽毛球馆、乒乓球室这些场地排期搬到线上居民不用再跑到前台问“今晚还有没有场地”管理员也不用拿Excel一张张贴通知。这篇文章就把这个系统从需求拆解、数据库设计、后端接口、前端交互到部署避坑完整过一遍适合正在做毕设的同学也适合想给小区物业做一个轻量预约工具的技术朋友。1. 项目概述与需求拆解1.1 这个标题背后到底是什么项目“小区体育运动中心预约管理系统”这个标题看着长拆开其实就四件事场地、时间、用户、订单。小区有篮球场、羽毛球场、乒乓球室、健身房有的还带游泳池场地资源有限晚上和周末经常撞车。业主想运动不知道哪个时段有空管理员只能在微信群里手动接龙或者拿纸笔登记一旦有人取消又得重新通知非常低效。这个系统就是把整个预约流程从线下挪到线上用户登录之后看到实时排期选一个空闲时段提交预约管理员在后台审核或直接自动确认系统自动记录每一笔订单。做这种项目最大的价值不是代码本身而是把“预约”这个业务模型彻底弄明白。标题里带了“设计与实现”意味着这不只是一个 CRUD 页面而是要交出一套完整的技术方案前端页面、后端接口、数据库表、权限控制、异常处理、部署说明。不少同学做毕设选这类题目因为业务清楚、场景贴近生活答辩时谁都能听懂功能也好演示。我个人觉得这个题目比“商城系统”“新闻发布系统”更合适因为预约业务里存在真正的技术难点——并发冲突一个场地同一个时段只能被一个人预约这是可以展开讲出深度的点。1.2 为什么选 Vue3 SpringBoot 而不是其他组合技术栈锁死为 Vue3 SpringBoot不是赶时髦是这两者目前在小团队和毕业生项目里生态最顺。Vue3 的组合式 API 写业务逻辑比 Vue2 的 options API 更灵活配合 Vite 启动快、热更新快开发体验很好。SpringBoot 的好处是用 Java 开发后端服务时省掉大量配置内置 Tomcat一个 jar 就能跑起来项目结构清晰对做学生项目来说非常合适。如果换成 React Node.js也不是不行但前后端都是 JavaScript/TypeScript对很多人的 Java 后端基础是一种浪费如果全用 JSP Servlet 又太老答辩时技术点不够亮眼。Vue3 SpringBoot 属于“前端工程化 后端工程化”组合面试和答辩时能讲出点东西。这里提醒一句选型不要追求新奇要选自己能在两个月内写得完、能讲清楚的技术。Vue3 SpringBoot 正是这种“稳妥但不平庸”的组合。1.3 功能模块与角色权限这个系统一般分成两个端用户端和管理端。用户端功能包括注册登录、浏览场地列表、查看指定日期和场地的空闲时段、提交预约、取消预约、查看我的预约记录。管理员端功能包括维护场地信息、设置场地开放时间段和价格、查看所有预约记录、确认或取消订单、统计场地使用率。角色权限我建议用简单的 RBAC 模型但不必做得很重。用户表 user 里加一个 role 字段USER 和 ADMIN后端在拦截器里判断接口权限。对这种小区内部系统一般不需要设计细粒度的权限点用户和管理员两种角色足够覆盖需求。前端路由再根据角色决定是否显示“后台管理”菜单双端控制虽然会有重复但能做到页面不泄露即可真正的安全校验必须放在后端。在需求评审阶段就要把业务规则钉死一个人每天最多预约几次提前多久可以预约取消后多久内可再次预约超时未到场算不算爽约这些规则如果一开始不定清楚后面写代码会反复改。我见过不少项目数据库都建好了突然客户说“一个用户一天只能约一次”然后所有逻辑推倒重来代价很大。2. 整体架构与数据库设计2.1 系统架构与请求链路整体是典型的前后端分离架构。前端 Vue3 应用跑在浏览器里通过 HTTP 请求访问后端 API后端 SpringBoot 提供 RESTful 接口操作 MySQL 数据Redis 用来做缓存和分布式锁。生产环境用 Nginx 托管前端打包后的静态文件再把 /api 前缀的请求反向代理到 SpringBoot 服务。请求链路大概是Vue 页面 - Axios 发起请求 - Nginx - SpringBoot Controller - Service - Mapper - MySQL。用户操作时前端会尽量做一层预校验比如日期不能选过去、时段不能重复点击但真正决定能不能预约成功的一定是后端因为前端校验可以被绕过并发情况下前端显示有空不代表别人没在抢。这套架构的好处是前端和后端可以独立开发、独立部署。前后端只通过接口文档约定数据格式只要接口不变前端换皮、后端加服务都不影响整体。对团队协作或单人开发来说边界都很清楚。多人开发时可以前端一人、后端一人Git 分支互不干扰单人做完一个阶段也能自己把前端后端分开测定位问题更快。2.2 核心表结构设计数据库设计是整个预约系统的地基表之间最关键的是预约表和排期表的关系。这里列出实际可用的几张核心表字段以够用为准不搞冗余设计。用户表 userid、username、password、phone、avatar、role、status、create_time。密码要存加密后的密文不要存明文推荐 BCrypt。场地表 placeid、name、type篮球场/羽毛球馆/乒乓球室/健身房、location、cover_image、price_per_hour、open_time、close_time、status1正常 0停用、description。把场地本身的属性固化和预约业务解耦。排期表 place_scheduleid、place_id、book_date、start_time、end_time、status0空闲 1已预约 2已锁定、version。这张表是预约冲突判断的核心。理论上可以把“时段”直接写进预约表但独立成表后查询更方便比如某天羽毛球馆有哪些空闲时段直接查表就能拿到。预约订单表 reservationid、order_no、user_id、place_id、schedule_id、book_date、start_time、end_time、total_amount、status0待支付 1已确认 2已使用 3已取消 4已爽约、remark、create_time、update_time。订单表里特意冗余了场地名、日期、时间等字段虽然违反了部分范式但查询我的预约记录时不用反复关联场地表展示性能好很多。表之间关系是一个场地对应多个排期一个用户对应多个预约订单一个排期在某一天只能被一个订单占用。设计时我会在 schedule_id 上建唯一索引同时由业务代码保证同一个场地同一天同一时段不会被并发重复预约。业务规则跑偏的时候唯一索引是最底层的兜底加上字段 status 可以在极端情况下阻止脏数据。2.3 预约状态机与业务规则预约订单的状态不能随意跳需要定义清楚。订单新建时是待支付或待确认状态这取决于系统要不要在线支付。如果只是预约登记直接置为已确认如果要模拟支付可以用一个“待支付”状态用户点击模拟支付后变为已确认。场地使用结束后变为已使用用户在开场前取消则变为已取消并把对应排期释放为空闲用户超过预约时间未到场并且未取消则标记为已爽约。状态流转最容易出的问题是把“取消”和“过期”混为一谈。设计时要注意用户主动取消时必须判断当前时间是否早于开始时间如果已经开始不能取消只能算爽约管理员强制取消需要单独走管理员接口并且要释放排期。还有当预约状态变成已取消后排期表里对应的时段要同步更新为空闲否则会出现“预约记录没了但系统里时段还被占着”的尴尬情况。这些规则不需要一开始全部做成配置但至少要保证代码里到处判断的是同一套逻辑。我的习惯是写一个 ReservationStatus 枚举类把可以流转的目标状态写在枚举里各环节只允许走到合法目标。后面就算改了业务规则也只要在枚举处集中修改不会出现改了 Service 忘了 Controller 的问题。3. 后端实操SpringBoot 核心实现3.1 工程结构与通用封装SpringBoot 工程我常用基础包结构controller、service、mapper、entity、dto、vo、config、common。entity 对应数据库表dto 接收前端参数vo 返回给前端数据common 放通用返回结果和异常。这样分层之后Controller 里基本只做参数接收和调用 Service业务逻辑全部写在 Service 层避免 Controller 越来越肿。Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ... } public static T ResultT error(String message) { ... } }全局异常处理用 RestControllerAdvice 捕获业务异常和未知异常统一转成 Result 结构。这样做前端拦截器就能统一判断 code不用每个接口单独 try-catch。如果项目里还用到了参数校验注解可以在全局异常里专门处理 MethodArgumentNotValidException把第一个校验失败的提示返回给用户。关于 MyBatis-Plus我建议直接用它内置 CRUD 方法写烦人的单表操作会快很多。这里有个细节MyBatis-Plus 的字段自动填充 create_time、update_time 很顺手但分页插件需要单独配置 PaginationInnerInterceptor不配置的话 IPage 分页不生效这是新手很容易踩的坑。3.2 登录鉴权与用户身份用户登录的常见实现是 JWT。简单做法是登录成功时用 userId 和 role 生成 token返回给前端前端每次请求在 Authorization 头带上 token后端写一个拦截器在进入 Controller 前解析 token把用户信息放入 ThreadLocal 或 Request 对象的 attribute。小项目不用引入 Spring Security拦截器足够清爽。我用 ThreadLocal 保存当前登录用户的 userId 和 role方便后面业务里直接取。但要注意一次请求结束后必须调用 remove 方法清除否则 Tomcat 线程池复用时信息会串到其他请求。这个坑很隐蔽线上会出现“用户A的请求偶尔看起来像用户B”的诡异现象。代码大概是这样public class UserContext { private static final ThreadLocalLong USER_ID new ThreadLocal(); public static void setUserId(Long id) { USER_ID.set(id); } public static Long getUserId() { return USER_ID.get(); } public static void clear() { USER_ID.remove(); } }拦截器配置里需要放行登录接口、注册接口和场地列表查询接口。有的项目连场地列表都要登录才能看我觉得没必要公开信息就让用户先浏览再决定是否注册体验更好。放行接口时要注意路径匹配顺序/api/user/login 和 /api/user/info 这种前缀一样的接口别用一个通配符把所有 user 接口都放行了。3.3 预约接口的并发控制预约系统的核心难点就是防止重复预约。假设现有排期表记录 scheduleId100用户A和用户B同时提交预约如果只是“先查该时段是否空闲再插入预约记录”两个请求都会查到空闲然后都插入成功就超卖了。解决思路有三个层次。第一数据库唯一索引。在预约订单表上给 schedule_id 建唯一索引这样即使业务代码出了问题数据库也会拒绝第二条记录。这个办法成本最低应该无条件做。第二事务内加锁。在 Service 方法上标注 Transactional查询排期时用 SELECT ... FOR UPDATE 把排期行锁住另一个事务只能等待必须等前一个事务提交后才能查保证不会并发插入相同排期。第三Redis 分布式锁。如果系统要部署多个实例数据库行锁就无法控制跨实例并发这时可以用 Redis 的 setnx 或者 Redisson 的 lock 来锁“场地ID 日期 时段”这个 key。对单机部署的小区系统用事务 行锁就够了设计简单、好答辩。核心逻辑Transactional public Long createReservation(CreateReservationDTO dto) { PlaceSchedule schedule scheduleMapper.selectByPlaceAndTime(dto.getPlaceId(), dto.getDate(), dto.getStartTime()); if (schedule null || schedule.getStatus() ! 0) { throw new BizException(该时段不可预约); } PlaceSchedule locked scheduleMapper.selectForUpdate(schedule.getId()); if (locked.getVersion() ! schedule.getVersion()) { throw new BizException(该时段已被预约请刷新后重试); } // 创建订单、更新排期状态 reservation.setScheduleId(schedule.getId()); scheduleMapper.updateStatusById(schedule.getId(), 1); return reservation.getId(); }注意 selectForUpdate 必须放在事务方法里才有锁效果如果锁查方法运行在无事务的 Service 外层锁会在方法返回后立即释放并发问题依旧存在。这也是我见过最多的错误写法。另外出异常时事务要回滚如果创建订单成功但更新排期失败事务会回滚成什么都没发生这个靠 Transactional 默认行为即可但请不要把异常在 Service 内部 catch 掉后正常返回那样事务就不会回滚。3.4 超时释放与定时任务如果系统有“待支付”状态用户提交预约后 15 分钟内未支付订单要自动取消同时释放排期。这个功能没有特别复杂的逻辑用 SpringBoot 自带 Scheduled 定时任务扫描超时订单即可。建议扫描频率设置为每 1 分钟一次不要每 30 秒甚至每秒一次没必要给数据库增加压力。Scheduled(cron 0 */1 * * * ?) Transactional public void handleTimeoutReservations() { ListReservation list reservationMapper.selectTimeoutOrders(15); for (Reservation r : list) { r.setStatus(ReservationStatus.CANCELED); reservationMapper.updateById(r); scheduleMapper.updateStatusById(r.getScheduleId(), PlaceScheduleStatus.FREE); } }这里要小心批量更新和事务的粒度。如果失败一条直接导致整体回滚那排期和订单状态能保持一致但可能出现一条死信阻塞后面所有更新的情况。更稳妥的办法是单条处理catch 后记录日志继续下一条避免一次任务整体崩掉。定时任务默认是单线程执行多个 Scheduled 方法同时跑时有可能互相等待如果任务逻辑都比较短其实不用纠结。4. 前端实现与交互细节4.1 Vite 初始化与依赖安装前端我直接用 Vite 创建 Vue3 项目。命令很固定npm create vitelatest sports-center -- --template vue-ts cd sports-center npm install npm install element-plus axios vue-router4 pinia这里有个建议模板选 vue-ts 而不是 vue带上 TypeScript 后在写接口数据模型时会更舒服Element Plus 组件类型提示也完整。如果对 TS 不熟先用 JS 也可以但提前声明预约排期这种数据用 TS 定义后字段名写错会在编译期暴露省去很多在浏览器里调试的时间。安装 Element Plus 后可以在 main.ts 全量引入虽然打包体积大但简单也可以按需自动导入。毕设项目全量引入完全没问题加载速度在演示环境几乎感受不到差别。Vite 5 或更高版本要求 Node 18如果本机还在用 Node 16npm create 时常常报错先把 Node 升一下。4.2 路由守卫和登录态保持前端的路由要区分公开页面和登录页。公开路由包括首页、场地列表、场地详情需要登录的路由包括我的预约、预约提交只有管理员能访问后台管理页面。路由配置里给 meta 增加 requiresAuth 和 roles 字段。路由守卫逻辑router.beforeEach((to) { const token localStorage.getItem(token); if (to.meta.requiresAuth !token) { return { path: /login, query: { redirect: to.fullPath } }; } if (to.meta.roles !to.meta.roles.includes(userRole)) { return { path: /403 }; } return true; });注意登录态不要只靠 localStorage 是否存在 token 来判断token 可能过期。很多项目遇到“明明登录了刷新又跳回登录页”就是因为没有把 token 过期时间或用户信息一起存起来也没有在路由守卫里调后端校验。简单做法是登录时存 token 和用户基本信息在守卫里判断 token 和过期时间复杂做法是每次进入页面请求一次 /user/info 校验有效性我一般用后者虽然登录后首次进入应用时会多一次请求但安全很多。4.3 场地排期组件与预约表单场地预约页是整个项目交互最热闹的地方。我推荐用 DatePicker 选择日期下面放一个表格行是场地列是开放时段表格里的每个格子有三种状态空闲可点击、已预约禁用、不可用停用。点击空闲格子弹出确认框显示日期、时段、价格确认后调用预约接口。排期数据结构里不需要发送整个二维表前端选定时间和场地后只要把 placeId、date、startTime、endTime 提交给后端即可。后端返回的排期列表可以直接用 Element Plus 的 el-table 渲染。这里有一个 Vue3 的注意事项v-for 循环渲染表格行时:key 不要用 index用场地 id 或 schedule id否则动态数据变更时容易出现勾选状态错位。如果想让体验更好可以在页面上加一个“只看空闲场地”的筛选框这个功能数据量小直接前端过滤即可不用额外请求后端。还有日期选择范围要限制在当天到未来 7 天之间防止用户选择过去日期后接口报错。前端限制只能算是操作引导后端接口同样要校验日期不能早于今天不能完全信任前端。4.4 Axios 封装和跨域前后端联调时最闹心的就是跨域。开发环境下Vite Vue 项目跑在 5173 端口后端 SpringBoot 跑在 8080浏览器会拦截跨域请求。最简单的方式是在 vite.config.ts 配置 proxy把 /api 开头的请求转发到后端前端代码里就写 /api/xxx不需要后端额外配置 CORS。export default defineConfig({ plugins: [vue()], server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } });Axios 封装要统一做三件事请求拦截器加 token响应拦截器判断 code网络错误统一提示。我习惯在后端返回 Result 结构后响应拦截器直接判断 data.code如果不等于 200就 ElMessage.error 提示并 return Promise.reject。这样业务代码里写接口时就不用每个都要关心报错弹窗只需要处理成功后逻辑。还有一个细节res 里如果直接返回 axios 的完整响应解构时要 data如果不小心写错会出现“拿不到预期数据”的调试困局。5. 系统安全、缓存与部署5.1 接口防刷与参数校验预约接口是写操作也是容易被狂点的接口。小区系统虽然不像电商大促那样高并发但也得防止有人连续刷接口占着排期不放。轻量做法是后端自定义一个简单限流记录当前用户在最近 1 分钟内的预约次数超过 3 次就拒绝。数据可以直接放在 Rediskey 用 userId过期时间 60 秒。第二道是校验参数日期格式、开始时间、结束时间、场地 ID 是否存在、时段是否在场地开放时间内。推荐使用 javax.validation 注解 全局异常处理例如 NotNull、Size、Pattern。请求 DTO 里对时间格式统一用 JsonFormat 保证解析。还有别忘了在 Service 层对“开始时间必须早于结束时间”这种跨字段校验做一次判断因为注解校验不到字段间关系。安全问题中MyBatis-Plus 的查询封装天然用了预编译普通 where 条件不会产生 SQL 注入但如果你写出了字符串拼接的 SQL还是要小心。5.2 Redis 缓存策略预约系统的热点数据是场地列表和最近几天的排期。场地列表基本不变化Redis 缓存 10 分钟没有问题。排期数据更新频繁缓存策略要谨慎不要在用户每次查询时都去更新缓存那样反而多一次 Redis 写操作。我的做法是用户查询某天某个场地的排期时先查 Redis没有则查数据库并把结果缓存 60 秒用户预约成功后直接把该日期该场地对应的缓存 key 删除保障下一个查询看到最新状态。缓存穿透也要提一下。如果一个用户连续查询不存在的场地 ID缓存里没有数据库里也没有每次都会打到数据库。简单处理是在查到空值时往 Redis 放一个空对象并设置较短过期时间比如 30 秒。对预约系统来说场地面向小区业主数量有限不存在的场地 ID 通常不会高频出现但做一下总没坏处。部署 Redis 时要注意密码和端口配置不要写死放在 application.yml 里用环境变量引用。我遇到过把 Redis 密码明文写在配置文件就提交到 Git 的情况虽然不是生产事故但习惯不好。配置示例spring: data: redis: host: ${REDIS_HOST:localhost} port: ${REDIS_PORT:6379} password: ${REDIS_PASSWORD:}5.3 前后端部署与 Nginx 配置部署环节通常被忽略等到答辩前一天才开始弄结果手忙脚乱。前端执行 npm run build 后会在 dist 目录生成静态文件把 dist 里的内容放到 Nginx 的 html 目录即可。后端执行 mvn clean package 后得到一个 jar用 java -jar 启动。注意数据库连接、Redis 地址这些配置要根据部署环境重新设置别把本地的 localhost 带到服务器上。Nginx 配置有两个重点第一把 / 路径指向 dist 目录的 index.html第二把 /api/ 路径代理到后端端口。这样前端请求走同一个域名不会再有跨域问题。还有一个容易被忽略的点Vue Router 如果用的是 history 模式在访问非首页的深链接时 Nginx 需要配置 try_files 指向 index.html否则刷新页面直接 404。这段配置很关键server { listen 80; server_name your-domain.com; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }5.4 备份与日志预约数据是有价值的业务数据数据库必须定期备份。最简单的方案就是 crontab 每天凌晨执行 mysqldump保留最近 7 天备份文件。这个操作两分钟就能配置好但项目里加一个说明文档答辩时能加分。日志方面SpringBoot 默认的 console 输出在部署后不好查询。建议引入 Logback 配置把日志输出到文件按天滚动。关键业务点要打日志预约提交、支付回调、取消订单、定时释放至少留 traceId 或 orderNo排查问题时能快速定位。6. 踩坑记录与问题排查6.1 SpringBoot 版本与 JDK 兼容搜索“springboot版本太高”的人非常多原因就是 SpringBoot 3.x 强制要求 JDK 17如果电脑安装的 JDK 8新建项目时会直接编译报错。遇到这个问题不用硬着头皮升 JDK直接退回 SpringBoot 2.7.x它基于 JDK 8对大部分毕业设计和轻量系统完全够用。2.7 也支持大部分常用组件比如 MyBatis-Plus 3.5.x。如果你的机器已经装了 JDK 17那直接用 SpringBoot 3.x 也可以只是要注意Spring Security 6 的配置方式变了原来继承 WebSecurityConfigurerAdapter 的写法在 SpringBoot 3 里已经废弃用 SecurityFilterChain 配置 Beanjavax 包名改成了 jakarta导入时容易报错。这些差异在写代码时会时不时遇到最好在项目一开始就定好版本中途不要频繁切换。6.2 Vue3 响应式和表单校验问题Vue3 里最容易被绊倒的是响应式丢失。用 reactive 定义了对象然后解构出来用比如 const { placeList } formData得到的是一个普通变量后续修改 formData.placeList 页面不会更新。需要修改时用 ref 代替或者解构后用 toRefs 包一层。还有一个场景是 el-form 的表单校验不通过很多新手找不到原因。常见症结是 el-form-item 的 prop 名称没写对或者 el-form 绑定的 model 与表单元件的 v-model 对不上。Element Plus 的校验规则里trigger 设置成 blur 还是 change 也要匹配否则输入时不触发校验提示。动态添加删除表单行也有固定写法。v-for 渲染的每行里输入框 v-model 必须绑定 formList[index].fieldel-form-item 的 prop 也要写动态下标例如proplist.${index}.name并在 rules 里对应的 name 字段加校验。如果只写了静态 prop每一行都会用同一个字段名校验永远只生效在最后一行。6.3 并发预约数据不一致问题模拟两个账号同时预约同一天同一个时段结果两个都提示成功这是很多预约系统查 bug 时最容易遇到的场景。先确认数据库里 reservation 表对 schedule_id 是否建了唯一索引如果没建业务代码并发控制再强都可能有漏网之鱼。再确认 Service 方法是不是真的在一个事务里selectForUpdate 有没有生效。调试时可以在两个请求里分别打断点观察第二个请求是否阻塞在 selectForUpdate 上。如果没阻塞大概率是事务没生效比如同类内部方法调用绕过了 Spring AOP 代理Transactional 就没起作用。还有种情况是只有一个实例部署但前台和移动端同时访问这时候数据库行锁已经够用。如果以后要改成多实例部署就要引入 Redis 分布式锁或者把预约接口签名设计成“幂等键”让同一个订单号只能创建一次。排查这类问题建议用压测工具并发跑 20 个预约请求看最终成功数量和数据库脏数据数量不能只靠眼睛看页面。6.4 本地联调与生产环境细节本地开发跨域用 Vite proxy 很轻松但有人会问为什么我在本地改了 proxy 就好用部署到服务器上又跨域了因为 Vite proxy 只在开发服务器里生效npm run build 后根本不走 Vite生产环境必须靠 Nginx 反向代理。所以生产环境不管前端还是后端都建议挂在同一个域名下。还有一个生产细节SpringBoot 的 MyBatis 配置里map-underscore-to-camel-case 要保持 true否则下划线字段映射到驼峰属性会失败。另外如果数据库时区没设置可能遇到日期差 8 小时的问题建议 MySQL 连接串加上 serverTimezoneAsia/Shanghai前端展示时间也从后端返回时间戳或标准字符串前端不自己做本地时区转换。最后分享一个经验这类预约系统上线后真正维护成本最高的是“人为取消”和“爽约”的记录。做的时候把状态流转处理好再给管理员加一个简单的按日期和场地的预约明细导出功能会比想象中的有用很多。Excel 导出不需要用太重的高级库直接用 EasyExcel 写一个导出方法管理员每天导出一次看板比在系统里做一堆华丽图表更贴近实际需求。业务被真实使用两三个月你会对“状态一致性比功能丰富更重要”这句话有更深的理解。