Spring Boot剧本杀拼团管理系统设计：从数据库到并发控制

咱们直接聊正题。这两年大家常说的沉浸式剧本娱乐，说白了就是线下推理游戏社交，剧本杀门店在全国开得铺天盖地。可门店老板最头疼的不是本子不够好，而是“拼车难”。工作日白天组不起人、有人临时跳车、团长口头组局放鸽子，这些问题不解决，再好的剧本也卖不出去空转场。所以 SpringBoot 驱动的剧本社拼团管理系统，本质就是解决线下门店“组队难、拼单难、预约乱”的一套业务管理系统，用 Java 技术栈把“发起拼团、加入组队、到点成团、玩家核销”这条完整链路线上化。

如果你正准备拿这个题目做毕业设计，或者是一个想了解真实业务系统怎么落地的后端学习者，这篇内容会比你想象中有价值得多。我不打算从零开始给你贴一张又长又没用的功能清单，而是从一个做过类似项目的人的角度，把业务拆解、数据表设计、并发加团的坑、定时任务的坑、状态流转的坑一条条讲清楚。保证你照着能复现，答辩时也能说出个一二三四。

1. 项目全貌与核心价值拆解

1.1 剧本杀门店为什么需要一套拼团系统

先从业务现场说起。一个门店一天大概有 10 到 20 个可预约的场次，每个场次对应一个剧本，建议游玩人数通常写在剧本封面上：有的是 4 人本、有的是 7 人本、恐怖本甚至能到 10 人。问题在于，来店的玩家很少能一次凑齐一个完整车队，更多是一两个人想玩某个本，现场等人补位。这个“等”字，在线下靠店长拿手机拉微信群，在线上靠玩家自己发朋友圈，效率极低。

更麻烦的是“跳车”。有人口头答应了今天下午来，临开场一小时说加班来不了，剩下已经到店的人只能干等。所以系统必须把“意向用户”变成“拼团房间中的数字”，用房间状态机来管理：招募中、已成团、已完成、已取消。 这个设计思路不是凭空想出来的，而是从拼多多拼单、美团拼饭这类成熟模式迁移过来的。剧本杀的本质也是一种“满员才发车”的生意，和拼团天然契合。

1.2 三种角色与一条主线流程

我建议系统不要拍脑袋设计四个端、五张权限表，先把角色想清楚。这个项目里最合理的角色划分是这三种。

• 普通玩家：可以浏览剧本、按城市或者门店筛选、创建拼团房间成为团长、通过邀请码加入别人房间、查看我的拼团记录、确认到场。
• 店家/店长：维护自己门店下的剧本和场次排期、查看今天有哪些房间要开、对到店玩家进行核销。
• 平台管理员：对门店、剧本、用户、拼团房间做统一管理，看数据报表，比如成团率、热门本排行。

角色划分想明白之后，主流程就一条直线：玩家创建拼团房间 → 其他玩家加入 → 人数满自动成团 → 系统通知全部成员 → 准时到店 → 店长核销 → 房间状态变成已完成。
整个系统要做的就是保证这条链路不破，并且处理过程中的各种取消、跳车、超时未成团、满员并发加入等异常分支。

2. 技术选型与项目初始化要点

2.1 后端框架为什么选 Spring Boot 而不是其他

作为毕业设计，技术选型确实要考虑稳妥和后期的答辩发挥。Java + Spring Boot 在国内业务系统里的地位不用多说，网上资料和学习路线最成熟，任何一个报错你都能在搜索引擎里翻到解决方案。选它不吃亏。

Spring Boot 在这个项目里最大的优势是“自动装配”能力。 比如你想连 MySQL，加一个 spring-boot-starter-data-jpa 或 MyBatis 依赖，配置一下数据源就能跑起来；想开发 RESTful 接口，引入 Web 依赖后有内嵌 Tomcat，不用单独部署 war 包。这些特性能让你的开发重心放在业务逻辑上，而不是折腾环境配置。

我们在实际项目中常见的配套组合是：

• Spring Boot 2.7.x
• JDK 1.8 或 11（版本不要太新，避免和依赖兼容性较劲）
• MySQL 8.0
• MyBatis-Plus（减少大量单表 CRUD 代码）
• Maven 3.8+
• Hutool 工具包（内置 ID 生成、日期处理等常用工具）

2.2 项目结构与额外中间件取舍

我见过很多同学看完热搜词之后，恨不得把 Flowable、Quartz、ActiveMQ、Redis 全部塞进项目里。这里我要泼一盆冷水：不是用得越多越好，而是要让每个技术点都服务于业务。

拼团流程虽然涉及状态变化，但远没到需要工作流引擎那种“多人多分支走审”的复杂度。用 Flowable 或者 Activiti 反而会让你陷入流程定义文件的泥潭，答辩时被问到一个细节，你可能自己都讲不清楚。消息通知也完全不需要引入 ActiveMQ 或 RocketMQ，毕竟这个系统里没有大量削峰填谷的场景，Spring Boot 自带的定时任务配合一张通知表就够了。

不过 Redis 和 JWT 可以加上去，因为这两个点很容易在答辩中讲出亮点。Redis 可以用来做验证码缓存、热门剧本缓存；JWT 用来做无状态登录认证。我不会在后续讲实现的时候略过这些点。

3. 数据模型设计：先把表关系理顺

3.1 核心表关系概览

数据库设计是这类业务系统最容易暴露问题的地方。你要是直接把用户表和订单表一对一连起来，后面所有功能都会写得很别扭。拼团系统里有几个关键实体：用户、剧本、门店、拼团房间、拼团成员、场次排期、预约订单、通知消息。

我给出的建议是至少拆出下面这些核心表。

这里最核心的业务表是 t_group_room。它的字段设计直接决定了拼团逻辑能否顺利实现。

3.2 拼团房间表的关键字段解析

拼团房间表要表达的信息很多：哪个剧本、哪家门店、计划几点开始、谁是团长、现在几个人、目标几个人、现在处于什么状态。关键 DDL 大致长这样。

sql复制CREATE TABLE `t_group_room` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `room_no` varchar(32) NOT NULL COMMENT '房间号/邀请码',
  `script_id` bigint NOT NULL COMMENT '剧本ID',
  `store_id` bigint NOT NULL COMMENT '门店ID',
  `session_plan_id` bigint DEFAULT NULL COMMENT '场次计划ID',
  `room_status` tinyint NOT NULL DEFAULT '1' COMMENT '1招募中 2已成团 3已完成 4已取消',
  `member_current` int NOT NULL DEFAULT '1' COMMENT '当前参团人数',
  `member_limit` int NOT NULL COMMENT '本团目标人数',
  `captain_id` bigint NOT NULL COMMENT '团长用户ID',
  `start_time` datetime NOT NULL COMMENT '计划开局时间',
  `expire_time` datetime DEFAULT NULL COMMENT '超时未成团自动取消时间',
  `create_time` datetime NOT NULL,
  `update_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_room_no` (`room_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='拼团房间表';

为什么会把 member_current 单独存一个字段？你可以直接统计 t_group_member 表数量，但那样每次判断“还能不能加入”都要走一次 count 查询，并且在高并发加入场景下无法用一条原子 SQL 控制超卖。存一个冗余字段，配合“条件更新”就能很好地解决并发问题，这一点我在下一部分展开说。

3.3 房间状态流转设计

拼团房间的 room_status 是典型的有限状态机。只用一个数字字段，你必须把每个状态迁移规则画清楚。

• 创建房间成功时，状态为 1，表示招募中。
• 当 member_current 到达 member_limit，状态变为 2，即已成团，等待到店。
• 玩家到店并核销完成后，状态变为 3，表示已完成。
• 团长主动解散、系统自动取消超时未成团的房间，状态变为 4。

有个很容易忽略的场景：房间处于已成团状态时，某个成员因故退出，此时 member_current 减 1 会小于 member_limit。这时候状态必须从 2 回退到 1，允许其他人继续补位。 很多同学第一次写时只处理了“人数满就成团”，忘了“成团后有人退出要重新开放招募”，导致房间状态卡死在已成团但人数不够的尴尬局面。

4. 拼团核心业务实现与并发控制

4.1 创建拼团房间的实现细节

创建房间的接口是整个流程的起点。用户在页面选择门店、剧本、预开局时间，并选择自己想当团长。后端接收请求后要做四件事：校验门店是否存在、校验剧本是否属于该门店、校验开局时间不能早于当前时间、生成唯一房间号并写入房间表。

房间号不能随便用自增 ID，因为要给用户当邀请码用，比如“102486”要比“123456”更像一个可传播的口令。我采用时间戳加随机数生成：

java复制public String generateRoomNo() {
    String timePart = LocalDateTime.now()
            .format(DateTimeFormatter.ofPattern("yyyyMMddHHmmssSSS"));
    int randomPart = (int) ((Math.random() * 9 + 1) * 1000);
    return timePart + randomPart;
}

在插入数据库时，room_no 有唯一索引，如果因为巧合撞上了就重新生成一次。对于毕设系统来说这个方案完全够用，真要追求更严谨，可以改成“每天自增序号 + 随机字母”，但没必要过度设计。

团长在创建房间后要自动成为第一个成员。这里两个表必须同时写入：房间表插入一条记录，成员表插入一条团长记录。所以创建房间方法一定要加 @Transactional，避免出现“房间建好了但成员表里没有团长”的脏数据。这两个操作要么都成功，要么都回滚。

4.2 加入拼团：一行 SQL 解决并发超卖

咱们重点说这个环节。一个只有 5 个名额的房间，假设 8 个玩家同时点击“加入”，系统的前几次请求都可能查到 member_current = 4，然后想着自己还能加进去。如果先去读当前人数，在内存里加 1，再写回数据库，那 8 个人可能全部成功，最后房间人数变成 13 人，直接超卖。

正确做法是让数据库行锁帮我们做判断，用条件更新 SQL 一步完成：

xml复制<update id="increaseCurrentIfRecruiting">
    UPDATE t_group_room
    SET member_current = member_current + 1,
        update_time = NOW()
    WHERE id = #{roomId}
      AND room_status = 1
      AND member_current &lt; member_limit
</update>

这条 SQL 的意思是：只有当房间还在招募中、当前人数还没到上限时，才把人数加 1，并且这个过程是原子性的。数据库在同一行记录上更新会自动加锁，两个并发请求同时执行时，后一个会等前一个提交后再判断条件，如果此时人数已经满了，受影响行数为 0，就说明无法加入。

在 Service 层对应的逻辑是：

java复制@Transactional(rollbackFor = Exception.class)
public JoinResult joinRoom(Long roomId, Long userId) {
    // 1. 检查是否已经在这个房间中
    if (groupMemberMapper.exists(roomId, userId)) {
        throw new BizException("你已经在这个团里了");
    }
    // 2. 先插入成员记录
    GroupMember member = new GroupMember();
    member.setRoomId(roomId);
    member.setUserId(userId);
    member.setJoinTime(LocalDateTime.now());
    groupMemberMapper.insert(member);
    // 3. 再用条件更新占用名额
    int rows = groupRoomMapper.increaseCurrentIfRecruiting(roomId);
    if (rows == 0) {
        throw new BizException("手慢了，该团已满员或房间已关闭");
    }
    // 4. 判断是否满员，满员就成团
    GroupRoom room = groupRoomMapper.selectById(roomId);
    if (room.getMemberCurrent().intValue() >= room.getMemberLimit().intValue()) {
        groupRoomMapper.compareAndSetStatus(roomId, 1, 2);
    }
    return JoinResult.success();
}

这里有一个细节：插入成员记录后，如果第 3 步的条件更新失败，由于同一个方法被 @Transactional 包裹，整个事务会回滚，刚插入的成员记录也会被撤销，不会出现“成员表有记录但房间人数没增加”的脏数据。

4.3 成团后有人退出怎么办

“跳车”是剧本杀行业的日常。成团后有人想退出，绝对不能只是删掉一条成员记录就完事。你要考虑几个联动点：人数扣减、房间状态回退、释放出来的名额是否需要通知其他等待者。

我设计的取消参团方法核心同样是条件更新：

xml复制<update id="decreaseMemberIfActive">
    UPDATE t_group_room
    SET member_current = member_current - 1,
        room_status = CASE
            WHEN member_current - 1 &lt; member_limit AND room_status = 2 THEN 1
            ELSE room_status
        END,
        update_time = NOW()
    WHERE id = #{roomId}
      AND member_current > 1
      AND room_status IN (1, 2)
</update>

然后调用方还需要真正删除成员表里的记录。注意一个关键点：如果房间已经处于“已完成”或“已取消”状态，就不该允许普通成员退出；如果房间还没成团但只剩团长一个人，退出后房间将没有任何成员，这时应该直接把房间取消，而不是保留一个空房间。这种分支逻辑在写代码时必须考虑进去。

5. 预约与场次排期模块的关键点

5.1 场次排期如何与拼团房间联动

很多人会把“预约”和“拼团”分成两个完全独立的功能，这是不合理的。你认真想一下门店的运营逻辑：店家会发布“今天下午 2 点有一场《雾都孤儿的秘密》，主持人和房间都已经准备好”，这就是一个场次计划。玩家拼团的时候，也应该能选择加入一个已经排好板的场次，而不是凭空定一个无法履约的时间。

因此 t_session_plan 表至少要包含这些字段：门店 ID、剧本 ID、计划开场时间、可容纳人数、已预约人数。 拼团房间创建时可以关联一个场次计划 ID，这样系统在展示时就能告诉玩家“下午 2 点到 4 点在 3 号房，主持人小鹿已确认”。

我给出的建议是：场次计划可以做简单的容量控制，但不要做成电影票那种严格座位表。剧本杀行业对开场时间的弹性比较大，真正刚性的约束是房间人数上限，你要守住的是这个，而不是具体坐几号位。

5.2 玩家预约、核销与取消的完整闭环

从用户视角看，预约一个剧本杀团的位置，核心操作是“提交预约单”。预约单关联用户、拼团房间，并记录预约状态。状态我建议用 0 待支付、1 已支付待开局、2 已核销、3 已取消、4 已退款。如果你不打算接微信支付或者支付宝，可以做一个模拟支付按钮，本质上就是把待支付改成已支付，但结构上要留出来，方便后续扩展。

真正执行核销的是店长。店长在“今日待开局”列表里看到即将开场的房间，玩家到店后，点击“核销”按钮，输入或扫描订单号，预约单状态从待开局变为已核销。当该房间所有成员都核销或者开场时间到达后，房间状态由 2 变为 3。这里要注意不要把核销和房间状态混在一起更新，因为可能存在有人迟到、同房间部分人先核销的场景。先更新预约单状态，再单独判断是否要把房间改成已完成。

我想强调一点：所有更新房间状态的地方都应该尽量用条件更新，例如：

sql复制UPDATE t_group_room SET room_status = 3
WHERE id = #{roomId} AND room_status = 2

这样可以防止两个请求同时把房间状态推到“已完成”或者更后面的状态，造成状态错乱。

6. 用户认证与后台管理落地

6.1 JWT 登录认证怎么接最省事

毕设里常见的登录方案有两种：Session 和 JWT。我推荐用 JWT，理由很简单：前后端分离时后端不需要保存会话，也不用担心集群部署后 Session 不同步的问题。

具体实现上不一定非要上 Spring Security。Spring Security 对初学者来说配置门槛太高，一个 SecurityFilterChain 配错，所有接口全 403，排查半天还找不到原因。你可以用“HandlerInterceptor + 自定义注解”的方式实现一个轻量认证框架：

java复制public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request,
                             HttpServletResponse response,
                             Object handler) throws Exception {
        if (!(handler instanceof HandlerMethod)) {
            return true;
        }
        HandlerMethod handlerMethod = (HandlerMethod) handler;
        RequireLogin requireLogin = handlerMethod.getMethodAnnotation(RequireLogin.class);
        if (requireLogin == null) {
            return true;
        }
        String token = request.getHeader("Authorization");
        if (token == null || !token.startsWith("Bearer ")) {
            throw new BizException("未登录或登录已过期");
        }
        Claims claims = JwtUtil.parseToken(token.replace("Bearer ", ""));
        UserContext.setUserId(Long.parseLong(claims.get("userId").toString()));
        UserContext.setRole(claims.get("role").toString());
        return true;
    }
}

要注意几个要点。解析 JWT 时要把 userId、角色放进去；拦截器通过 WebMvcConfigurer 注册，注意放行登录注册接口、Swagger 文档路径；最后在 Controller 方法上打注解标识这个接口需要登录。最核心的安全准则是：所有拼团接口的操作用户都从 token 里取，不能信任前端传过来的 userId 参数。这个点讲出来能体现你确实知道鉴权需要注意什么。

6.2 管理后台的数据报表怎么设计

管理后台不能只是简单罗列列表，最好能有一些统计维度。比如店长关心今天的成团率、本周哪几个本最受欢迎、哪个场次经常被捡起来；管理员关心平台总用户数、门店订单量排行。

这些统计用 SQL 就能完成。查询某个月的成团率：

sql复制SELECT
    DATE_FORMAT(create_time, '%Y-%m') AS month,
    COUNT(*) AS total_count,
    SUM(CASE WHEN room_status = 2 OR room_status = 3 THEN 1 ELSE 0 END) AS success_count
FROM t_group_room
WHERE create_time >= '2025-01-01' AND create_time < '2025-06-01'
GROUP BY DATE_FORMAT(create_time, '%Y-%m');

在 Service 层把 total_count 和 success_count 拿出来做一次除法，乘 100 转成百分比，前端就能直接展示。热门剧本排行也简单，按 script_id 分组统计房间数排序取前 10 即可。这里要多嘴一句：聚合统计不影响正常业务流程，如果数据量大了，可以把统计结果放到缓存或者单独的表里，但毕设阶段直接查源表完全没有问题。

7. 定时任务与消息通知机制

7.1 超时未成团自动取消

现实场景里，一个团很可能从早到晚都凑不齐人。如果这些团一直挂在“招募中”状态，玩家看着满屏房间不知道选哪个，店家也没法清理。所以系统必须支持“到某个时间还没满员就自动取消”。

创建房间时，可以设定一个默认的 expire_time，比如开局前 2 小时。然后写一个后台定时任务，每隔一段时间扫描有没有“已超时且仍招募中”的房间：

java复制@Component
public class GroupRoomScheduleTask {

    @Scheduled(fixedDelay = 60 * 1000)
    public void cancelExpiredRecruitingRooms() {
        List<GroupRoom> expiredRooms = groupRoomMapper.selectExpiredRecruiting(LocalDateTime.now());
        for (GroupRoom room : expiredRooms) {
            try {
                cancelRoomBySystem(room);
            } catch (Exception e) {
                log.error("取消超时房间失败，roomId={}", room.getId(), e);
            }
        }
    }

    @Transactional(rollbackFor = Exception.class)
    public void cancelRoomBySystem(GroupRoom room) {
        groupRoomMapper.compareAndSetStatus(room.getId(), 1, 4);
        // 给所有成员发送“流局”通知
        notificationService.notifyRoomCanceled(room.getId());
    }
}

不要忘记在主启动类上添加 @EnableScheduling，否则定时任务根本不会启动。另外 Spring 自带的 @Scheduled 默认单线程执行，如果系统里同时有多个任务，一个长时间任务会卡住后面的任务。改进方式也很简单，实现 SchedulingConfigurer 配置一个线程池即可。

7.2 满员提醒与临场提醒的推送策略

通知模块不建议一开始就接短信或者微信公众号模板消息，原因有二：一个是这些能力往往需要企业资质，个人开发者很难申请到；另一个是短信按条计费，演示过程中容易产生费用。站内信是这个阶段最稳的方案。

用户登录后的首页可以展示一个“通知列表”，未读数标记红点。每次加入拼团、成团、房间取消、开局前提醒，都往 t_notification 表插入一条数据。开局前 30 分钟提醒这种能力，也交给定时任务来做。后台每隔一分钟扫描一次：

• 开团时间距当前时间 30 分钟左右；
• 房间状态为已成团；
• 已有 30 分钟前提醒的记录则跳过；
• 给该房间所有成员生成一条站内信。

虽然站内信非常简单，但是配合一个未读标记，就已经形成了完整闭环，而且你不需要依赖任何第三方 SDK，答辩时反而更容易说清楚。如果你确实想加点亮点，可以预留一个“WebSocket 实时通知”接口，用于用户停留在页面时首页角标能自动刷新，这是一种可选增强，不是必须。

8. 真实开发中的常见坑与排查思路

8.1 并发导致超卖

前面已经重点说了加团时的原子更新。其实还有一个更隐蔽的场景：取消和加入同时发生。比如当前人数是 4，限制 5，一个用户正要退出，另一个用户正好请求加入。如果你不加条件处理，可能出现退出的扣减操作把人数减成 3，然后加入操作又把人数加回 4，这本身还好；但如果加入的先执行，把人数从 4 变 5，状态变 2，退出的后执行，把人数从 5 变 4，状态却没有被回退，那房间状态就停留在“已成团但只有 4 人”的孤岛上。

排查这类问题最好先复现：压测工具模拟并发加团、并发退出，看看日志里最终人数和状态是否一致。我在写代码时的习惯是，把所有房间状态和人数变更统一收敛到几个 Mapper 方法里，避免到处 updateById，这样可以尽量保证一致性。

8.2 事务失效

一个很典型的错误是，Service 里方法 A 调用了同类里的方法 B，B 上有 @Transactional，但方法 B 的事务没有生效。因为 Spring 的事务是通过代理实现的，同类内部方法调用不会经过代理对象。如果你真的要把创建房间和添加团长成员放在一个事务里，建议把这两个操作放在一个 public 方法中，由 Controller 调用进代理，而不是写一个 createRoom() 方法再偷偷调另一个同类方法。

排查时可以在日志中打开事务相关输出：

yaml复制logging:
  level:
    org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG

如果看到 Creating new transaction 说明事务开启正常，如果看到 Skipping transactional execution 那就要检查是不是同类调用或者类没有被 Spring 管理。

8.3 时间格式化和时区

这是 Java 后端最常见的“小问题”。数据库里存的是 datetime，后端用 LocalDateTime 接收，接口返回 JSON 时默认可能变成“2025-06-01T14:30:00”这种带了 T 的格式，或者因为服务器时区不是 UTC 导致前端显示的时间比实际慢了 8 小时。

最简单的方式是在 application.yml 里统一指定：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

同时 MySQL 连接串加上 serverTimezone=Asia/Shanghai。这样前后端看到的时间基本就不会打架了。

8.4 定时任务重复执行

如果项目部署到了多台服务器，Spring 自带的 @Scheduled 会在每个节点都执行一次，导致同一批超时房间被扫描两次，通知也可能重复发送。毕设阶段部署在一台服务器，问题不大，但答辩老师如果问到，你要能给出解决思路：一种是用 Redis 分布式锁让同一时间只有一个节点执行；另一种是使用 xxl-job 这类分布式调度框架。你可以说目前单体架构足够，未来多实例部署时再引入锁机制。

8.5 记住“用户主动操作要二次确认”

系统里有些动作不可逆，比如团长解散房间、成员退出已成团的房间，这类操作前最好增加二次确认弹窗。技术上后端可以增加一个 confirm 参数，前端做弹窗提示。这不仅是交互设计问题，也能减少误操作引发的大量取消通知打扰。

给准备动手的同学的一个最后建议

我从自己的实践体会出发说一句：拿这个题目练手的时候，别急着去堆功能，也别一上来就把前端页面搭得花里胡哨。最好先把“玩家创建房间 → 他人加入 → 满员成团 → 店长核销”这条主线跑通，把房间状态机搞扎实。我见过太多同学先把一堆列表接口写完了，结果核心拼团逻辑并发一请求就崩，最后只能临时改成串行处理来演示，这非常可惜。

如果你对这块感兴趣，后续还可以往“用户信用分”“团长评价”“按位置推荐附近门店”这些真实业务里延伸。但第一步永远是站在门店老板的角度问自己：一个用户进到系统里，能不能在 30 秒内发起或者加入一个团，并且不需要打电话找店长确认。答案如果是能，那这个系统就成功了一多半。