SpringBoot+Vue3前后端分离体育馆预约系统实战解析

很多做校园或社区项目的朋友都问过我有没有一个完整的前后端分离项目能拿来练手或者改造既能覆盖日常开发的核心技术点又不至于复杂到看不下去。我手头这个体育馆使用预约平台就是很合适的样本——后端用 SpringBoot MyBatis 操作 MySQL前端用 Vue3 做单页应用整个预约流程从场地浏览、场次选择到订单确认全部打通后台还能做场馆管理。这篇文章就是我对这个项目从需求拆分、数据库设计到具体编码、部署上线的完整复盘里面所有坑都是实际踩过的你可以直接照着做也可以把它当成课设、毕设的骨架来改。1. 需求先行体育馆预约平台的业务边界与功能拆解很多开发者拿到“预约平台”这类需求第一反应就是打开 IDEA 建表写接口结果写着写着发现业务边界模糊一会儿想做支付一会儿想做会员卡最后变成一锅粥。我习惯的做法是先把业务场景用一句人话讲清楚一个用户能按场馆、按日期、按时间段查看可预约的资源选中后提交订单管理员能维护场馆信息和场次安排并查看所有订单。1.1 核心用户角色普通用户与管理员这个系统的用户权限模型非常简单不做 RBAC 那种复杂的东西两张角色就够用普通用户注册登录后可以查看场馆列表按日期查看某一场馆的可约场次提交预约、取消预约以及查看自己的预约记录。管理员除了用户的基本功能还能维护场馆增删改查、设置每日场次以及查看全平台的所有预约记录。这里的权限控制在实践中用拦截器就能解决——后端在 Controller 方法上加一个RequireRole(admin)之类的自定义注解拦截器里判断当前登录用户的角色即可。没必要为了这个体量的项目引入 Spring Security JWT 做全套过度设计是个人项目最常见的坑。1.2 核心业务流程从选场到预约成功需要几步预约流程我梳理成了五步每一步对应一个页面或接口用户登录拿到 JWT Token前端存到 localStorage。浏览场馆列表点击任意场馆进入详情页。在详情页选择日期系统返回该场馆当天的全部场次包括可约、已满、已过期三种状态。用户点击某个“可约”场次弹出确认框提交预约请求。后端在校验场次空闲后创建订单返回成功用户可在“我的预约”中看到这条记录。需要特别注意的是第 4 步到第 5 步之间用户点击提交和系统真正写入订单之间有一个时间差如果两个人同时抢最后一个名额数据库层面必须做并发控制。这一块我在后面“数据库设计与并发控制”那一节专门讲这是整个项目最核心的技术难点。1.3 非功能性需求顺手要解决的隐性问题除了上面这些明面上的功能还有几个点在实际开发时不能忽略接口安全性所有预约相关的接口必须校验登录状态防止未授权调用。参数校验预约日期不能是过去的日期手机号格式要校验场地 ID 必须存在等。页面体验前端在提交预约后要有 loading 状态防止用户重复点击造成重复订单。统一返回格式前后端联调时最怕各写各的我统一用{ code, message, data }作为返回结构所有异常都封装成这个格式前端 Axios 拦截器拿到 code ! 200 时统一弹出错误提示。把上面这些内容整理成需求文档后再开始写代码效率会高很多因为你不会写到一半发现需要加字段、加表、改接口。2. 技术选型与项目骨架这套技术栈到底怎么配合这套系统的技术栈组合是 src: Java 17 SpringBoot 2.7 Vue3 MyBatis MySQL 8.0前后端完全分离。下面说清楚每个组件在这个项目里承担什么职责以及为什么不换成其他方案。2.1 后端选型SpringBoot 2.7 与 JDK 版本的选择SpringBoot 我选的 2.7不是 3.x。原因是 MyBatis 的mybatis-spring-boot-starter在 SpringBoot 2.x 里有非常成熟的整合方案而 SpringBoot 3.x 要求 JDK 17 且jakarta.*命名空间变更很多老版本的第三方依赖会踩坑。如果是为了学习2.7 JDK 8 或者 2.7 JDK 17 都可以稳定运行。工程结构上我走了标准的 maven 多模块思路实际因为项目体量不大单模块也能扛住关键是包结构要清晰com.example.sportbooking ├── controller // 接口层 ├── service // 业务逻辑层 ├── mapper // MyBatis 数据访问层 ├── entity // 数据库实体类 ├── dto // 请求/响应的数据传输对象 ├── common // 统一返回体、异常处理、工具类 ├── config // 跨域、拦截器、WebMvc 配置 └── interceptor // 登录与角色拦截器2.2 前端选型Vue3 Vite Element Plus 的快速搭建Vue3 搭配 Vite 的优势是开发环境启动快、语法现代化组合式 APIsetup语法糖让组件逻辑比 Options API 好维护得多。UI 库我选的 Element Plus它和 Vue3 的配合度是几个组件库中最成熟的表格、表单、日期选择器、消息提示这些做后台管理系统几乎是开箱即用。搭建命令如下npm create vitelatest sport-frontend -- --template vue cd sport-frontend npm install element-plus axios vue-router pinia前端项目的基础目录如下src ├── api // 所有接口请求的封装 ├── assets ├── components // 通用组件 ├── router // 路由配置 ├── store // Pinia 状态管理 ├── views // 页面组件 └── utils // 请求工具Axios 实例、拦截器2.3 MyBatis 与 MySQL为什么不用 MyBatis-Plus需要先说明的是原生 MyBatis 和 MyBatis-Plus 之间没有任何贬低后者的意思。MyBatis-Plus 的BaseMapper和 LambdaQueryWrapper 确实开发效率高很多。但如果你还在学习阶段我强烈建议你先用原生 MyBatis 写一个完整项目。原因很简单你会真正理解#{}和${}的区别理解参数映射和结果集映射的底层逻辑。你能看懂 SQL 在业务中是怎么被拼接和执行的而不是隐身于“封装好的魔法”后面。互相面试时问MyBatis 一级缓存二级缓存、分页插件原理你用过才答得上来。这个项目里MyBatis 主要负责动态 SQL 按条件查询场馆、更新场次状态、插入预约订单。分页用的是 PageHelper 插件它基于 MyBatis 的拦截器机制在真正执行 SQL 之前动态拼接LIMIT语句并且自动执行一条SELECT COUNT(*)查询总数这个原理在后面专门讲。MySQL 的作用就是存储最终数据表结构在下一节详细展开。3. 数据库设计五张表如何撑起整个预约系统数据库是预约系统的地基表设计不好后面写业务代码会处处别扭。我这个系统的核心表就五张用户表、场馆表、场地表、场次表、预约订单表。下面把这五张表的字段设计和关联关系讲明白。3.1 用户表、场馆表、场地表基础数据怎么定义用户表user是最基础的表字段包括id、username用户名唯一、password加密后存储、phone手机号、role0 表示普通用户1 表示管理员、create_time等。这里有个安全细节密码不能明文存储。我用的是 Spring Security 中自带的BCryptPasswordEncoder对密码做哈希注册时哈希后入库登录时把用户输入的明文哈希后与库中的哈希比对。虽然没引入完整的 Spring Security但单独拿这个加密器使用很方便。场馆表venue代表物理上的一栋体育馆或一个分区字段包括id、name体育馆名称、location位置、description介绍、image封面图 URL。场地表court则代表具体的场地比如羽毛球场 1 号、篮球场 A 区。它通过venue_id外键关联场馆表一个场馆下可以有多个场地。为什么要把场馆和场地分开因为预约的最小单位是场地而不是场馆。一个体育馆下有多个不同项目的场地如果不分表用户想约“羽毛球 篮球”时数据会非常混乱。3.2 场次表与预约订单表时间维度和状态流转场次表session是预约业务里最关键的维度。它由管理员维护字段包括id、court_id关联场地、date日期、start_time开始时间、end_time结束时间、status0 表示可约1 表示已约满2 表示已过期。为什么要单独建场次表而不是在订单表里直接存开始时间和结束时间因为预约场景下时段是事先放出来的“商品”用户不能随便自定义时间只能在管理员配置好的场次里选。这样设计的好处是简化了并发冲突的判断逻辑——大家抢的是同一个固定 ID 的场次只需要保证同一场次不被重复预约即可。预约订单表order的结构如下CREATE TABLE order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id bigint NOT NULL COMMENT 用户ID, session_id bigint NOT NULL COMMENT 场次ID, court_id bigint NOT NULL COMMENT 场地ID, book_date date NOT NULL COMMENT 预约日期, start_time varchar(10) NOT NULL COMMENT 开始时间, end_time varchar(10) NOT NULL COMMENT 结束时间, status tinyint NOT NULL DEFAULT 1 COMMENT 1-已预约 2-已取消, create_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_session_id (session_id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有个索引设计技巧order_no用唯一索引保证订单编号不重复session_id建普通索引因为查询“某场次已经被预约了几次”是高频操作。order是 MySQL 的保留字建表时最好用反引号包起来或者干脆把表名命名为booking_order避免麻烦。3.3 并发控制如何防止同一场次被“超卖”这是整个系统最核心的问题两个用户同时看到某个场次“可约”同时点了提交数据库如何保证只有一个成功方案有两个:方案一悲观锁。在事务里对场次记录加锁SELECT * FROM session WHERE id #{sessionId} FOR UPDATE;拿到锁之后检查 status 是否仍为可约如果是则占用把 status 改为已约满并创建订单然后提交事务。这个方案实现简单但会把行的写锁一直持有到事务结束并发量高时会产生锁等待适合中小型系统。方案二乐观锁。在 session 表加一个version字段更新时检查版本号UPDATE session SET status 1, version version 1 WHERE id #{sessionId} AND status 0 AND version #{oldVersion};如果影响行数为 0说明被别人抢先了事务回滚并提示“手慢了场次已被约满”。这个方案性能更好但需要处理重试逻辑。我最终选择的是方案一因为业务场景是“体育馆预约”并发量通常不高而且实现起来最直观还避免了乐观锁在多线程场景下反复重试的额外复杂度。如果要做高并发版本可以用 Redis 预扣库存 异步落库那就是另一套架构了。4. 后端核心实现SpringBoot MyBatis 从配置到接口后端是整个系统的“大脑”这一节从项目配置开始到接口实现结束一步步还原出完整的后端代码结构。4.1 关键依赖与 application.yml 配置pom.xml里的核心依赖就是下面这几个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdcom.github.pagehelper/groupId artifactIdpagehelper-spring-boot-starter/artifactId version1.4.7/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependencyapplication.yml中最容易出问题的配置是 MyBatis 的 mapper 扫描路径和驼峰映射。我第一次运行时查询结果全部是 null排了半天才发现是忘记开驼峰映射mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.sportbooking.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplmap-underscore-to-camel-case: true的作用是让数据库的create_time自动映射到实体的createTime字段这个必须开启。log-impl配成StdOutImpl后控制台会打印执行的 SQL 和参数调试时特别有用。跨域配置也是前后端分离项目的必需品。我用一个配置类实现 WebMvcConfigurer添加跨域映射Configuration public class WebConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }4.2 MyBatis 动态 SQL 与分页插件的实际用法场馆列表页的筛选条件比较多——按名称模糊查询、按可预约状态过滤、按场地类型过滤直接用动态 SQL 最方便。以下是一个典型的 mapper 示例select idlistVenues resultTypecom.example.sportbooking.entity.Venue SELECT * FROM venue where if testname ! null and name ! AND name LIKE CONCAT(%, #{name}, %) /if if teststatus ! null AND status #{status} /if /where ORDER BY id DESC /select分页插件 PageHelper 的用法比很多人想象中简单得多它甚至不需要改 SQL只要在调用 mapper 方法之前设置分页参数public PageResultVenue pageVenues(int pageNum, int pageSize, String name) { PageHelper.startPage(pageNum, pageSize); ListVenue venues venueMapper.listVenues(name); PageInfoVenue pageInfo new PageInfo(venues); return new PageResult(pageInfo.getTotal(), pageInfo.getList()); }PageHelper.startPage(pageNum, pageSize)使用 ThreadLocal 存储分页参数然后 MyBatis 的 Executor 在真正执行 SQL 前拦截自动生成LIMIT语句和总数查询。这里有一个非常经典的坑startPage 后面必须紧跟第一条要分页的查询如果中间插了其他查询分页参数会被下一次无关查询消费掉导致莫名其妙的分页错乱。4.3 预约接口的实现与事务管理预约接口是核心中的核心它的完整逻辑链是参数校验 → 锁定场次 → 检查状态 → 创建订单 → 修改场次 → 返回订单号。直接看代码Transactional(rollbackFor Exception.class) public BookingOrder bookSession(BookRequest request, Long userId) { // 1. 参数校验 Session session sessionMapper.selectByIdForUpdate(request.getSessionId()); if (session null) { throw new BizException(场次不存在); } if (session.getStatus() ! 0) { throw new BizException(该场次已被预约或已过期); } // 2. 生成订单号时间戳 随机数 String orderNo generateOrderNo(); // 3. 创建订单 BookingOrder order new BookingOrder(); order.setOrderNo(orderNo); order.setUserId(userId); order.setSessionId(session.getId()); order.setCourtId(session.getCourtId()); order.setBookDate(session.getBookDate()); order.setStartTime(session.getStartTime()); order.setEndTime(session.getEndTime()); order.setStatus(1); orderMapper.insert(order); // 4. 把场次置为已约满 session.setStatus(1); sessionMapper.updateById(session); return order; }关键点是第一行查询用了selectByIdForUpdate对应 SQL 就是SELECT * FROM session WHERE id #{id} FOR UPDATE。这句话的意思是在事务内锁定这一行其他事务必须等这个事务提交或回滚之后才能操作同一行。加上Transactional注解后从加锁到提交的整个区间都是安全的。这里还需要注意rollbackFor Exception.class。Spring 默认只在遇到运行时异常时回滚如果业务代码抛的是检查异常比如BizException继承 Exception不写这个参数会导致事务不生效订单写进去了但场次状态没改产生脏数据。4.4 拦截器实现登录校验与角色控制登录校验我用 JWT 拦截器完成流程图是用户登录成功后后端签发一个有效期 24 小时的 Token前端每次请求在 Header 里带Authorization: Bearer token后端登录拦截器解析 Token把用户 ID 和角色放入请求上下文。自定义注解 拦截器的代码结构如下Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { String value() default user; }拦截器里先用HandlerMethod判断方法或类上有没有RequireRole注解有的话再校验角色是否匹配public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 放行 OPTIONS 预检请求 if (OPTIONS.equals(request.getMethod())) { return true; } String token request.getHeader(Authorization); // 解析 token ... UserContext.set(userId, role); return true; }有一个坑必须提醒前后端分离后浏览器跨域情况下会先发一个OPTIONS预检请求这个请求不带实际业务参数拦截器必须放行它否则所有前端请求都会卡在 CORS 阶段返回 403。5. 前端页面从登录到预约完成的交互链路设计前端这部分对很多后端工程师来说是短板但前后端分离项目里前端不跑通整个系统就玩不转。下面我把 Vue3 这边从请求封装到页面组件的关键逻辑过一遍。5.1 请求封装与拦截器统一处理 Token 和错误码Axios 的二次封装是整个前端最基础、最实用的工具。我的utils/request.js大概长这样import axios from axios import { ElMessage } from element-plus import router from ../router const request axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截器自动附加 Token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 响应拦截器统一处理业务错误和登录过期 request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { ElMessage.error(网络异常请稍后重试) return Promise.reject(error) } ) export default requestbaseURL 配成/api配合 Vite 的代理解决开发环境跨域问题。在vite.config.js中配置export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样前端请求/api/venue/list时Vite 开发服务器会把请求转发到后端的localhost:8080完美绕开开发阶段的跨域限制而且后端接口里不需要写死全路径。5.2 场馆列表与场地详情组合式 API 的典型写法场馆列表页用 Vue3 的setup语法糖写逻辑集中在script setup中。核心代码大概是script setup import { ref, onMounted } from vue import { getVenueList } from ../api/venue import { useRouter } from vue-router const router useRouter() const loading ref(false) const venueList ref([]) const total ref(0) const pageNum ref(1) const pageSize ref(8) const keyword ref() async function loadVenues() { loading.value true try { const res await getVenueList({ pageNum: pageNum.value, pageSize: pageSize.value, name: keyword.value }) venueList.value res.data.list total.value res.data.total } finally { loading.value false } } onMounted(() loadVenues()) function goDetail(id) { router.push({ path: /venue/${id} }) } /script这套写法比 Options API 简洁的地方在于相关逻辑可以集中在一起而不用分散在data、methods、mounted三个选项里。页面里的列表用 Element Plus 的el-cardel-table组合展示卡片布局比纯表格更适配“体育馆”这种面向消费者的场景。5.3 预约日期选择与场次状态渲染场地详情页的预约区域是整个前端交互最复杂的部分。它需要日期选择器禁用过去日期当天场次列表按“可约/已约满/已过期”渲染不同样式点击可约场次时弹出确认框。日期选择的逻辑用得最多的是禁用过去日期这一招Element Plus 的disableDate参数可以精确控制el-date-picker v-modelselectedDate typedate :disabled-datedisabledDate placeholder选择预约日期 changeloadSessions / script setup function disabledDate(time) { return time.getTime() Date.now() - 24 * 60 * 60 * 1000 } /script场次状态用不同的按钮类型渲染el-button v-forsession in sessionList :keysession.id :typesession.status 0 ? primary : info :disabledsession.status ! 0 clickhandleBook(session) {{ session.startTime }} - {{ session.endTime }} /el-button当用户点击一个可约场次弹窗确认后调用后端预约接口前端拿到成功结果后立刻刷新场次列表把那一个场次的可约状态更新掉避免用户反复点击。这里有个交互细节我实际体验后非常推荐提交预约时给按钮加上 loading 状态并且把接口防重放在前端一层。因为用户连点两下会发两次请求虽然后端有锁保证不会超卖但第二次请求会返回“已被预约”的错误提示用户体验非常差。5.4 用户端“我的预约”和管理端的订单管理“我的预约”页面是查询当前用户所有订单记录展示场馆、场地、日期、时间段、状态并且对“已预约”的订单提供“取消预约”按钮。取消预约的逻辑是把订单状态改为取消同时把对应的场次状态改回可约前提是场次还没过期。管理端订单管理主要是用el-table展示全平台所有订单支持按用户名、场馆、日期筛选同时提供查看统计信息比如某天某场地的预约量。取消预约的操作也会影响场次状态这个逻辑需要和后端接口保持一致。6. 部署与上线从本地开发到服务器运行的完整步骤项目写到能跑还不够能部署到服务器上给真实用户体验才算完整。这一节分享我常用的部署流程和踩过的环境坑。6.1 后端打包与运行maven 打包和 jar 运行后端用 Maven 打包成 jarmvn clean package -DskipTests打包成功后在target目录下找到sport-booking-0.0.1-SNAPSHOT.jar。上传到服务器后运行nohup java -jar sport-booking-0.0.1-SNAPSHOT.jar --server.port8080 --spring.profiles.activeprod app.log 21 用nohup让程序在后台持续运行把日志输出到app.log。我第一次部署时犯过一个低级错误直接运行java -jar后关闭终端窗口进程就被 SIGHUP 信号杀掉了服务立刻不可用。6.2 前端打包与 Nginx 配置前端打包后是纯静态文件npm run builddist目录里的文件部署到 Nginx 的html目录下Nginx 配置的核心有两个功能托管静态页面 反向代理后端接口。server { listen 80; server_name your-domain.com; location / { root /usr/share/nginx/html/sport-frontend; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files $uri $uri/ /index.html这行是必须的否则前端路由用 history 模式时刷新二级页面会报 404。它的作用是找不到对应的物理文件时统一返回index.html让 Vue Router 接管路由解析。6.3 上线前必查清单根据我自己在这个项目上踩过的坑列一个上线前逐项检查的清单检查项说明MySQL 时区JDBC 连接串加serverTimezoneAsia/Shanghai否则日期差 8 小时MySQL 字符集建库使用utf8mb4否则中文乱码跨域配置服务器上线后前后端同域Nginx 已代理接口可以关闭后端的 CORS密码安全生产环境不要用弱密码数据库连接密码不要写在代码里放配置文件外挂端口开放服务器安全组放行 80或 443不一定需要放行 8080JWT 有效期个人项目 24 小时够用过期后前端需要重新登录数据库备份上线前做一次初始数据备份上线后每天定时备份这些问题在开发环境基本不会被发现但上了生产环境任何一个都能让服务不可用。提前处理好上线过程会顺利很多。7. 写在最后体育馆预约平台这个项目麻雀虽小五脏俱全它覆盖了前后端分离项目的完整链路涉及了权限控制、动态 SQL、分页、事务、锁、跨域、部署等核心知识点对学习和面试都很有价值。我个人在开发过程中的一个体会是不要为了炫技引入过度复杂的技术方案。这个项目没有用 Redis没有用消息队列没有用 Spring Cloud但核心功能照样跑得稳。真实业务场景中先满足功能、再谈优化一套能跑通全流程的简单架构远胜于黑洞一样复杂但跑不起来的“高并发架构”。把这里面的每一个环节练透你不仅会做预约系统还建立了对后端工程全流程的整体认知。如果后续有时间可以考虑增加更多功能比如接入微信登录、预约提醒短信通知、按角色分配场地价格、生成预约统计报表这些都是在当前骨架上很容易扩展的方向。先把基础版本的代码完整写一遍、跑通一遍你会对这个技术栈有完全不一样的理解。