1. 接手体育馆管理系统时我先把预约这件事拆清楚了我在帮一个社区体育馆做管理系统之前第一反应也是这有啥难的不就是CRUD嘛。但现在回头看体育馆管理系统最核心的难点从来不是增删改查而是场地预约的时间冲突处理和会员、教练、管理员三种角色的权限边界。你如果只是把网上开源的商城模板拿来改一改多半会在预约排程这块翻车。这个项目最后用的技术组合是 SpringBoot2 Vue3 MyBatis-Plus MySQL8.0前后端分离代码和文档都整理成了完整的一套。适合的人群有两类一类是拿它做毕业设计或者课程项目的在校生另一类是确实想给自己场馆做一套内部系统的运营人员。前者关心的是技术点能不能写进论文、答辩能不能说清楚后者关心的是能不能真正跑起来、数据能不能存得住。我这篇文章会把两边的需求都覆盖到。先说场馆的实际业务场景一个中型体育馆通常有羽毛球场地、篮球场地、乒乓球台、健身房区域每种场地收费标准不一样开放时间段也不一样。会员需要提前预约到了现场核销教练需要排课管理员要能看到每天的收入和场地使用率。如果这些全靠Excel和微信群接龙一旦场地超过五片冲突就不可避免。所以系统里最重要的不是花哨的界面而是预约状态的一致性。我按照先理业务流程、再定数据模型、最后写代码的顺序来做。下面每个环节都会给出我实际采用的方案和踩过的坑尤其是那些文档里不会写、只有跑起来才会发现的问题。2. 数据库设计会员、场地、预约订单三张核心表怎么建模2.1 先确认功能模块清单体育馆管理系统一般绕不开这几个模块我在设计初期列了一张表方便和场馆运营方逐项确认模块功能点说明会员管理注册、充值、续费、会员卡类型区分普通会员、年卡会员、时段卡会员场地管理场地类型、时间段单价、场地状态场地启用/停用维修中要第一时间标记预约管理在线选场地、按时段预约、取消预约核心模块需要锁定场地时段教练管理教练资料、可约时段、课时记录排课和场地预约可以联动收费管理预约扣费、充值记录、退费金额涉及流水必须留痕统计报表场地使用率、营收日报/月报管理员最看重这个这里有一个很容易忽略的点场馆运营方往往说不清自己的真实需求。他们只会说我要一个能预约的页面但如果追问同一个场地同一时间被两个人预约了怎么办会员预约了迟到半小时怎么处理年卡会员和单次付费用户预约权限是否一致他们才会认真想。所以你在动数据库之前一定要把这类边界问题问清楚否则建好的表结构一定要返工。2.2 预约时段的数据模型设计我最终设计了五张核心表member会员、venue场地、venue_time_slot场地时段、booking_order预约订单、charge_record充值/扣费流水。最关键的关联关系是一个场地拥有多个时段venue_time_slot一个时段只能被一个订单锁定订单和会员是多对一关系。CREATE TABLE venue_time_slot ( id BIGINT PRIMARY KEY AUTO_INCREMENT, venue_id BIGINT NOT NULL, slot_date DATE NOT NULL, start_time TIME NOT NULL, end_time TIME NOT NULL, price DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 1 COMMENT 1-可预约 2-已锁定 3-已停用, lock_member_id BIGINT DEFAULT NULL, version INT DEFAULT 0, UNIQUE KEY uk_venue_slot (venue_id, slot_date, start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;version字段是留给乐观锁用的后面处理并发预约时它派上了大用场。UNIQUE KEY则从数据库层面兜底防止同一场地同一日期同一开始时间被插入两次。这块是数据库设计里性价比最高的一个约束因为就算业务代码有bug数据库也能挡住最严重的重复预约。2.3 MySQL8.0 建库的细节处理MySQL8.0 和 MySQL5.7 在使用上有几个明显的差异点第一次用8.0的同学很容易踩默认认证插件变了。MySQL8.0 默认是caching_sha2_password而一些老版本的驱动或可视化工具可能只支持mysql_native_password。如果用的连接驱动是 5.x 版本连的时候会直接报Unable to load authentication plugin caching_sha2_password。解决办法是换用mysql-connector-java8.x 版本的驱动不要试图把认证方式改回去。时区问题。数据库连接串上建议明确写serverTimezoneAsia/Shanghai否则在高版本的JDBC驱动下默认时区取的是服务器系统时区一旦服务器是 UTC你存进去的时间会和你本地看到的差 8 个小时。字符集。建库时建议直接指定utf8mb4因为要兼容会员备注里的 emoji 表情和特殊字符utf8在 MySQL 里实际上是utf8mb3存不了四字节字符。CREATE DATABASE gym_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;另外数据库的表统一用 InnoDB外键约束能用就不用。我在项目里刻意没有建物理外键而是靠应用层逻辑保证数据完整性。原因是后续做分库分表或者归档历史数据时物理外键会变成障碍而且体育馆系统的并发量虽然不大但频繁删除历史订单时外键级联会拖慢速度。3. 后端落地SpringBoot2 分层结构和 MyBatis-Plus 的正确用法3.1 项目结构别照抄网上的包名项目基础框架选的 SpringBoot 2.7.x因为 2.x 系列经过大量生产验证配合 MyBatis-Plus 3.5.x 很稳定。虽然 SpringBoot3 已经发布但如果你用的是 JDK8 或 JDK11那就老老实实留在 2.x没必要追求最新版给自己添堵。包结构我按 controller / service / mapper / entity / common 划分业务逻辑必须放在 service 层controller 只做参数接收和结果返回。很多学生写的代码把查询逻辑全部堆在 controller 里当时是方便但一旦要做权限校验、事务管理你就得大面积重写。我习惯在每个 Service 接口实现类上都加Transactional(readOnly true)只有写操作的方法单独加Transactional覆盖这样既能保证只读方法不会误触发事务又能让写操作有明确的事务边界。Service public class BookingOrderServiceImpl extends ServiceImplBookingOrderMapper, BookingOrder implements BookingOrderService { Override Transactional(rollbackFor Exception.class) public boolean createBooking(BookingRequest request) { // 1. 校验会员余额 // 2. 乐观锁锁定时段 // 3. 生成订单 // 4. 扣减余额 // 5. 记录流水 } }3.2 解锁 MyBatis-Plus 几个高频玩法MyBatis-Plus 提供了BaseMapper和IService常规单表 CRUD 确实一行代码不用写。但实际开发中有三个点值得记录一是条件构造器QueryWrapper和LambdaQueryWrapper的选择。我统一用LambdaQueryWrapper因为它能避免硬编码数据库字段名代码里写的是实体类的属性名重构的时候不容易出错。比如查询某天可预约的时段LambdaQueryWrapperVenueTimeSlot wrapper Wrappers.VenueTimeSlotlambdaQuery() .eq(VenueTimeSlot::getSlotDate, date) .eq(VenueTimeSlot::getStatus, 1) .orderByAsc(VenueTimeSlot::getStartTime);二是分页插件必须注册。很多人引入 MyBatis-Plus 后直接用selectPage发现分页不生效返回的数据还是全量原因是没有配置MybatisPlusInterceptor分页插件。这是 MyBatis-Plus 3.4 之后的强制要求Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }三是字段自动填充。create_time和update_time这种字段手动 set 太容易遗漏。我在实体类上加了TableField(fill FieldFill.INSERT)和TableField(fill FieldFill.INSERT_UPDATE)然后实现MetaObjectHandler插入时自动填入当前时间更新时自动修改更新时间。Component public class MyMetaObjectHandler implements MetaObjectHandler { Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, createTime, LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } }这里有个细节严格填充模式strictInsertFill只有在实体类字段为 null 时才会填充如果你在业务代码里手动了 set它不会覆盖这样可以避免无意的数据覆盖。3.3 登录认证JWT 和拦截器配合体育馆系统有三种角色管理员、教练、会员不能所有接口都裸奔。我用了 JWT SpringMVC 拦截器实现认证没有引入 Spring Security因为项目角色少、权限规则简单Spring Security 的配置成本大于收益。用户登录后后端签发一个 token里面带上 userId 和 role有效期为 24 小时。拦截器里通过HandlerInterceptor验证 token把用户信息放进ThreadLocal里的UserContext这样后续 service 层可以直接拿到当前操作人的信息。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { throw new BusinessException(401, 未登录); } // 解析token成功则放入UserContext LoginUser user JwtUtil.parseToken(token.replace(Bearer , )); UserContext.set(user); return true; } }一个关键注意点拦截器里解析 token 失败时不要直接 response 写死字符串。更规范的做法是抛出自定义业务异常然后由全局异常处理器统一返回 JSON。这样返回格式和正常报错保持一致前端 Axios 拦截器也好统一处理。3.4 预约并发一旦多人抢同一个时段怎么办这是全系统最值得单独说的地方。假设下午 15:00 那片羽毛球场地特别抢手三个会员同时点击预约如果只是先 select 再 update那么三个人都能看到可预约状态然后一起执行 update最后时段被后提交的人覆盖但另外两个人也收到了预约成功的提示。这就是典型的线程安全问题。我采用两层保护第一层是update语句带条件boolean success update(new LambdaUpdateWrapperVenueTimeSlot() .eq(VenueTimeSlot::getId, slotId) .eq(VenueTimeSlot::getStatus, 1) .set(VenueTimeSlot::getStatus, 2) .set(VenueTimeSlot::getLockMemberId, userId));update返回影响行数如果影响行数为 0说明时段已经被别人锁走本次预约失败。这种方式比先查再改安全得多因为检查状态和修改状态被压缩到了同一条 SQL 里数据库的行锁保证了原子性。第二层是乐观锁版本号。我在更新语句里带上version条件更新成功后version 1。如果更新返回 0 就说明版本号已经变化需要提示用户重新选择。实测下来体育馆这种量级用乐观锁完全够不需要引入 Redis 分布式锁除非你要做秒杀级别的并发。另外数据库隔离级别保持默认的 REPEATABLE READ 就可以。我在最初配置时想过要不要改成 READ COMMITTED后来发现这套业务没有复杂的跨表一致性需求保持默认最稳改隔离级别反而容易引入新问题。4. Vue3 前端从环境搭建到预约页面的完整链路4.1 工程化搭建Vite 项目结构和依赖版本前端选了 Vue3 Vite Element Plus Pinia Vue Router Axios 这套组合。Vite 启动速度快开发体验比 Webpack 时代好一大截而且 Vue3 官方生态已经完全转向 Vite。用 Vite 创建项目的时候有一个小坑npm create vite会让你选框架模板注意选vue而不是vue-ts除非你打算全项目用 TypeScript。体育馆管理系统规模不大我用的 JavaScript 写法配合script setup语法开发效率非常高。setup语法糖让组件内部代码更简洁省去了setup()返回值的过程变量和方法声明后直接在模板里用。依赖版本上element-plus需要和 Vue3 匹配。很多报错组件未定义或样式不生效往往是 Element Plus 版本和 Vue 版本错位导致的。我这里锁定的是element-plus2.x配合element-plus/icons-vue使用图标。4.2 Axios 封装三个必须处理的问题前端对接后端Axios 封装是第一个要做的事。我的封装里处理了三类问题请求拦截每次请求自动带上 token。从localStorage取出 token加到请求头Authorization前缀Bearer。响应拦截统一处理后端返回结构。后端约定返回{code, message, data}code 为 200 表示成功。当 code 为 401 时说明 token 失效前端自动跳回登录页。这里有个容易踩的坑响应拦截器里跳转路由要避免循环依赖。如果拦截器直接import router而 router 文件又通过某个模块间接 import 了封装的 axios 文件就会出现空引用。我采用的是在拦截器里动态import或者把 router 实例通过window挂载后取出具体项目可以按自己的方式协调。const service axios.create({ baseURL: /api, timeout: 15000 }); service.interceptors.response.use( (response) { const res response.data; if (res.code ! 200) { ElMessage.error(res.message || 请求失败); if (res.code 401) { localStorage.removeItem(token); window.location.href /login; } return Promise.reject(new Error(res.message)); } return res; }, (error) { ElMessage.error(网络异常请稍后重试); return Promise.reject(error); } );请求取消切换路由时取消上一个页面的未完成请求。体育馆管理系统的报表页面可能会同时请求多个月的数据用户快速切换模块时旧请求的响应会覆盖新页面的状态。我用了axios.CancelToken在路由守卫里统一取消上一轮标记的请求实测能明显降低页面卡顿。4.3 预约界面日历加时段表格怎么实现预约页面是产品核心我最初想做日历控件但 Element Plus 的日历组件本质上是个展示组件用于选择某一天再配合时段选择表格更合适。最终交互逻辑是顶部选择日期默认今天禁止选择过去日期中间展示场地列表每种场地一个区块每个场地下方是该日期剩余的时段用卡片形式展示可预约的显示预约按钮已被占用的置灰这个界面看起来不复杂但有一个关键逻辑必须处理好当前日期切换后所有场地时段的状态要重新从后端拉取。如果不重新拉取用户从 3 号切到 4 号看到的数据还是 3 号的。我监听日期变化触发一个fetchSlotsByDate函数每次切换立即请求并给表格加v-loading遮罩防止用户重复点击。另一个坑是时段按钮的禁用状态和后端实际状态的同步。前端会根据返回的status字段判断是否禁用但当用户 A 在手机上已经约走了 15:00 时段用户 B 的浏览器还是旧数据他点击预约时会提交一个已失效的时段。所以前端不能只靠按钮禁用来兜底点击预约时后端会重新校验如果失败则弹出错误提示并刷新当前时段列表。前端要做的就是把后端返回的错误信息原样展示出来而不是吞掉异常。4.4 路由守卫和权限控制三种角色的登录用户能看到的菜单不一样管理后台能看到会员管理、订单管理、营收报表会员端只能看到自己的预约记录。我用 Vue Router 的meta.roles字段标记每个路由可以访问的角色然后在beforeEach守卫里判断。const routes [ { path: /admin/members, component: MemberManage, meta: { roles: [admin] } }, { path: /member/orders, component: MyOrders, meta: { roles: [admin, member] } } ];路由守卫里注意一点不要只做跳转拦截还要在用户角色变化后手动重置路由。比如管理员退出登录切换到会员账号登录如果不重置路由浏览器地址栏直接输入/admin/members还是会被动态添加的路由规则放行。我在退出登录时调用router.matcher.resetRouter()重新初始化路由表再动态添加当前角色的路由这样权限控制才真正生效。5. 联调和部署跨域、时间差、打包这三个坑我逐个填平5.1 跨域配置别只依赖前端代理前后端分离项目最常见的联调问题就是跨域。开发阶段我建议用 Vite 的 proxy 代理来解决而不是在每个后端接口上加CrossOrigin。理由很简单代理方案在代码里没有任何侵入上线后只需要把前端的构建产物放到 Nginx让 Nginx 把/api路径转发到后端服务即可前端代码一行都不用改。但你要注意Vite 的 proxy 只对开发环境生效。很多人上线后发现请求全部 404就是因为生产环境没有配置 Nginx 反向代理前端直接localhost:8080/api访问后端 8081 端口必然失败。我在 Nginx 里的配置是这样的server { listen 80; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files那行不能少否则 Vue Router 的 history 模式刷新子页面时Nginx 会返回 404。这是我见过最多的部署问题必须写进文档里提醒使用者。5.2 前端时间和后端时间差了 8 小时这个坑我在联调阶段卡了整整一个下午。前端提交预约时间到后端数据库里存的时间比预期早 8 个小时。排查方向有两个第一MySQL 连接串的serverTimezone参数不对。我一开始写的serverTimezoneUTCMySQL 数据库本身是 Asia/Shanghai 时区结果存进去的时间被转换成 UTC比本地上午 10 点存成了凌晨 2 点。改成serverTimezoneAsia/Shanghai后问题解决。第二Jackson 序列化 LocalDateTime 的格式。SpringBoot 返回的LocalDateTime默认序列化成 ISO 格式的数组或者带 T 的字符串前端拿到后端解析会出现格式问题。我在application.yml里做了全局配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai前端侧也要注意Element Plus 的DatePicker组件如果绑定返回的日期字符串需要转换成Date对象或字符串格式统一。我在 Axios 拦截器里没有做全局转换而是让后端统一返回yyyy-MM-dd HH:mm:ss字符串前端展示时直接用提交时再转成后端需要的格式减少了类型不匹配的烦恼。5.3 Maven 打包和 Node 构建的顺序项目打包上线时我建议按这个顺序先npm run build构建前端产物再mvn clean package -DskipTests打包后端 jar最后把前端 dist 部署到 Nginxjar 交给 systemd 或 Docker 部署。如果不想维护两套部署环境可以把前端构建产物放进后端src/main/resources/static目录这样单个 jar 就能启动整个系统。不过这样做后续前端改动就要重新打包后端迭代效率低我只推荐给部署条件受限的场景。后端 jar 部署时别忘了设置--spring.profiles.activeprod切换生产环境配置。我在项目里区分了application-dev.yml和application-prod.yml生产库的连接信息、日志级别都放 prod 配置里避免把开发环境的数据库连接带到线上。关于日志我额外加了一句配置logging: file: name: logs/gym-system.log level: com.example.mapper: warn把 MyBatis 的 SQL 日志级别调成 warn 而不是 debug因为生产环境每天预约量大SQL 日志刷屏会快速膨胀磁盘空间。排查问题时再临时把某个 mapper 的日志打开即可。6. 这套系统跑通半年后我留下的几点总结和改造建议项目上线后实际跑了半年说几句话也许比上面所有技术细节都重要。第一不要把技术栈当成卖点要把业务完整性当作核心。当时有人建议我把系统加上 Redis 缓存热点场馆数据、用 MQ 异步处理订单通知对体育馆这种一天几百单量级的系统来说纯属过度设计。我用乐观锁和数据库唯一约束已经解决了并发问题系统跑半年没出过一次数据不一致。真正让人觉得系统不好用的反而是小事——比如管理员想批量导入会员 Excel 表格运营方想要手机端的简单核销页面。这些业务功能带来的价值远大于炫酷的架构。第二文档要写给接盘的人看。我整理的那份文档除了系统架构说明重点写了两块数据库表的字段注释、部署步骤的完整命令。如果文档里只有系统采用SpringBootVue技术栈这种废话对后来者一点帮助没有。我甚至在文档里附上了 Nginx 配置原文、MySQL 建库语句、常见报错对照表后来有一个学弟拿这份代码做毕业设计一天之内就本地跑起来了。第三关于二次扩展方向。如果这个项目要继续深化我建议优先做两点一是把预约时间段做成可配置的模板不同场馆类型、工作日和节假日用不同时段模板这样运营方不需要改代码就能调整场地开放计划二是加入场地使用率和会员流失分析报表给管理员一个按月对比的图表而不是只有冷冰冰的订单流水。这两个功能都是运营方主动提出来的说明它们是真痛点。最后分享一个我在实际排查中形成的小习惯每次改动数据库表结构都顺手更新sql目录下的建表脚本并且在脚本头部写上变更时间和备注。体育馆系统的数据表不算多但只要经过三四个人接手表结构和字段含义就会开始变得混乱这种看起来不起眼的习惯能省下后面大量沟通成本。这套 SpringBoot2 Vue3 MyBatis-Plus MySQL8.0 的组合做管理类系统非常顺手代码结构清楚开发效率高踩坑点也都能在文档里找到对应答案。如果你正在找这类系统的参考实现建议先照着文章把数据库表建好再跑通一次预约下单的完整流程感受一下项目里对时间冲突的处理逻辑这比盯着源码逐行看有价值得多。