企业官网建设流程全解析

这两年线下沉浸式娱乐行业回暖得很快，剧本杀场馆数量蹭蹭往上涨。一个很现实的现象是，很多新开的沉浸式推理游戏场馆，运营方式还停留在“微信群接龙 + Excel排表”的阶段：高峰期店员一边回消息一边手动改表格，同一房间重复被约的情况几乎每个周末都会出现。剧本杀预约系统的需求，就是从这个真实痛点里长出来的。这篇文章把我完整做完并跑通的一个基于SpringBoot的剧本杀预约系统，从需求拆解、数据库设计、核心功能代码到部署运行的全过程讲清楚。它本质上是一个JavaWeb驱动的剧本推理体验服务预约与社区交流系统，既能管理场馆和剧本排期，又支持用户在线约场次、管理订单、发帖交流。如果你正在找毕业设计参考，或者想从零搭一个预约类项目练手，这篇可以直接收藏照着做。

1. 需求拆解与整体设计思路

1.1 剧本杀预约场景的运营痛点在哪儿

要写一个预约系统，首先得搞清楚这个行业到底怎么运转。一个典型的剧本杀场馆，日常运营大概是这样的：场馆里有几个不同风格的房间，比如古风、民国、科幻、恐怖；每个房间能容纳的玩家人数不一样；店长根据剧本库安排一天的场次，比如某房间下午两点到五点安排某个剧本；顾客提前预定某个场次的某个剧本，同时要确定好人数和价格。

听起来不复杂，但真正落地到运营上，问题就冒出来了：顾客根本看不到哪些场次还能约，只能反复问客服；店员排表完全靠手工，同一时段撞单是家常便饭；“约好了、玩完了、取消了”这些状态没有统一管理，一团浆糊。这套系统的核心目标，不是做一个看起来好看的增删改查Demo，而是把“场次、场馆、剧本、订单、用户”这几条线串起来，让预约行为有明确的状态流转，数据对得上。

1.2 功能模块怎么划分：用户端和管理端各管什么

功能模块的划分决定了整个项目的骨架。从角色维度来拆，我认为至少要分成两个端，一个给普通用户，一个给管理员。

用户端核心功能包括注册登录、浏览场馆和剧本、查看可预约场次、提交预约订单、管理自己的订单记录、在社区里发帖和评论。管理端要能够维护场馆信息、维护剧本信息、创建场次排期、查看和处理订单、管理用户和角色。

这个功能清单基本覆盖了绝大多数毕设评分点：CRUD操作、业务逻辑、权限控制、多表关联查询，再加上一个社区交流模块，整体的完整度就很能打了。需要注意的是，功能可以预设多一点，但实现优先级要有取舍，先把预约的主链路跑通，再补社区的边边角角。

1.3 为什么选SpringBoot，而不是传统SSM/SSH

早期做JavaWeb项目，很多人接触的框架组合是SSH（Struts2 + Spring + Hibernate）或者SSM（SpringMVC + Spring + MyBatis）。这类组合的性能和分层都没问题，但配置文件量是真的大，web.xml、spring.xml、mybatis-config.xml，光配环境就能耗掉一两天，效率很低。

SpringBoot的核心价值是“约定优于配置”。它内置了Tomcat，不需要单独部署war包；自动配置帮我们把大量的Bean管理、数据源配置、模板引擎配置都处理掉了；配合Maven统一管理依赖，真正的启动成本非常低。而且SpringBoot的生态很完善，Spring Data JPA、MyBatis-Plus、Spring Security、Thymeleaf这些组件都能低成本集成，特别适合课程设计和毕业设计的节奏。

我实际搭这套系统时用到的技术栈可以看这张表：

这里要说明一下，毕设项目不需要把技术选型搞得太花哨。堆一堆微服务、Redis、消息队列，看着高大上，但答辩的时候如果讲不透，反而容易给老师留问号。用最主流、最稳妥的技术栈，把业务逻辑做扎实，把代码写整洁，是更明智的选择。

1.4 项目目录结构怎么规划

项目结构直接影响代码的可维护性和可读性。我自己习惯用分层模式来组织，每个请求的链路是 Controller → Service → Repository → DB，职责非常清晰。一个合理的结构大概是这样的：

src/main/java/com/project/scriptshot/ ├── config/ # 配置类：拦截器、跨域、资源映射 ├── controller/ # 控制器层 ├── service/ # 业务逻辑接口与实现 ├── repository/ # 数据访问层 ├── entity/ # 数据库实体类 ├── dto/ # 请求和响应的数据对象 ├── enums/ # 状态枚举 ├── common/ # 通用返回类、异常处理、工具类 ├── ScriptShotApplication.java # 启动类

src/main/resources 下面再放 templates（Thymeleaf模板）、static（静态资源）、application.yml。这个分层的好处是，写论文画架构图的时候很好表述，自己后期加功能也不用在一个Controller里堆几千行代码。

2. 数据库设计与关键表结构解析

2.1 核心实体识别与关系建模

数据库设计是整个系统的地基，地基歪了，代码写再多也白搭。我先识别出这套系统的核心实体：用户、场馆/房间、剧本、场次、预约订单、社区帖子、评论。实体之间的关系不难理解：

一个用户可以有多个订单，一个订单只能属于一个用户；一个房间在不同时间可以有不同的场次，一个场次只能关联一个房间；一个剧本可以被多个场次引用；一个场次可被多个用户预约；一个帖子下面有多条评论。用ER图表达会更直观，画图的时候有个细节要注意，就是必须把“场次”这个实体单独拎出来。

很多第一次做预约系统的人会有一个惯性思维：直接让用户去预约“某房间+某时间”不就行了，为什么非得加一个场次表？我当时也犹豫过。但实际排期运营的场景是这样的：管理端要先把“哪个房间、哪个剧本、什么时间开始、什么时间结束、最多多少人”打包成一个场次，用户预约的其实是这个被定义好的场次。场次本质上就是一个“可售商品”，和电影院排片是同一个逻辑。没有场次表，管理端的排期功能根本没有落点，订单数据也不好关联。

2.2 核心表结构设计

这里我直接给出几张核心表的建表SQL，是我在这个项目里验证过的实际结构。

用户表：

CREATE TABLE t_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), phone VARCHAR(20), role TINYINT NOT NULL DEFAULT 1 COMMENT '0=管理员 1=普通用户', created_at DATETIME DEFAULT CURRENT_TIMESTAMP );

房间表：

CREATE TABLE t_room ( id BIGINT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL, capacity INT NOT NULL COMMENT '最大容纳人数', style VARCHAR(20) COMMENT '房间风格', equipment VARCHAR(200) COMMENT '设备描述', status TINYINT DEFAULT 1 COMMENT '1=可用 0=维护中' );

场次表：

CREATE TABLE t_session ( id BIGINT AUTO_INCREMENT PRIMARY KEY, room_id BIGINT NOT NULL, script_id BIGINT NOT NULL, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, max_capacity INT NOT NULL, booked_count INT DEFAULT 0 COMMENT '已预约人数', status TINYINT DEFAULT 1 COMMENT '0=已取消 1=可约 2=已满员', version INT DEFAULT 0 COMMENT '乐观锁版本号', CONSTRAINT fk_session_room FOREIGN KEY (room_id) REFERENCES t_room(id), CONSTRAINT fk_session_script FOREIGN KEY (script_id) REFERENCES t_script(id) );

场次表的几个字段值得多说一句。max_capacity并不是直接取房间的容量，因为同一个房间可以排不同人数的剧本，比如一个房间能坐10个人，但某个本的上限是6人，那这个场次的最大容量就应该按剧本的参团上限来算。booked_count是已预约人数，查询余量的时候用 max_capacity 减去 booked_count 就能算出来，不必每次count订单表。version字段是乐观锁用的，后面讲并发防超卖的时候再展开。

订单表：

CREATE TABLE t_order ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE, user_id BIGINT NOT NULL, session_id BIGINT NOT NULL, persons INT NOT NULL COMMENT '预约人数', total_price DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT '0=待确认 1=已确认 2=已完成 3=已取消', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, CONSTRAINT fk_order_user FOREIGN KEY (user_id) REFERENCES t_user(id), CONSTRAINT fk_order_session FOREIGN KEY (session_id) REFERENCES t_session(id) );

订单关联的是场次，而不是直接把房间和剧本信息冗余到订单表里。这样做的理由是保证信息一致性：如果房间信息或者剧本价格变了，历史订单不需要跟着变，查订单详情的时候通过场次关联回去就能拿到完整的房间和剧本信息。

2.3 订单状态机的设计思路

有一件事能明显拉开项目质量差距，就是订单状态的设计。如果只用数据库里的一个status字段，更新的时候不校验前置状态，代码写到后面一定会乱套。我当时做这套系统的时候，先用枚举把状态流转关系定义清楚了再动手写代码。

我定义的订单状态包括：待确认、已确认、已完成、已取消。流转关系是这样的：

待确认(0) ├─ 用户取消 → 已取消(3) └─ 管理端确认 → 已确认(1) 已确认(1) ├─ 用户取消（开场前） → 已取消(3) └─ 场次结束 → 已完成(2) 已取消(3) // 终态 已完成(2) // 终态

在Java层用枚举来实现状态描述：

public enum OrderStatus { PENDING(0, "待确认"), CONFIRMED(1, "已确认"), COMPLETED(2, "已完成"), CANCELLED(3, "已取消"); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code = code; this.desc = desc; } // getter... }

状态机最大的价值是防止脏数据。比如“已取消”的订单不应该被标记成“已完成”，“待确认”的订单也不应该直接跳到“已完成”。Service层每次做状态更新，都要先校验当前状态是否允许跳转。加了这层约束，订单数据的可信度会明显提升。

2.4 社区交流模块的表设计

社区模块很多人会想得很复杂，实际上基础模型就是帖子和评论两张表。

CREATE TABLE t_post ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL, title VARCHAR(100) NOT NULL, content TEXT NOT NULL, view_count INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_comment ( id BIGINT AUTO_INCREMENT PRIMARY KEY, post_id BIGINT NOT NULL, user_id BIGINT NOT NULL, content VARCHAR(500) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

这里有个很容易忽略的细节：要给 post_id 和 user_id 都加上索引。原因很直接：帖子详情页要拉取评论列表，按 post_id 过滤；用户个人主页要查这个用户发过的帖子，按 user_id 过滤。没有索引的话，数据量一上来查询就会变慢，虽然毕设阶段数据量不大，但这是一个值得刻意养成的习惯。至于点赞、收藏、举报等扩展功能，我建议放到“后续扩展”里写，不必一开始就全部做出来，把预约主链路走通比什么都重要。

3. 核心功能实现：预约流程全解析

3.1 管理端排期：怎么创建不冲突的场次

排期是这套系统的源头，所有的预约都从场次开始。管理端选择房间、剧本、起止时间，系统生成一个可预约的场次。Service层的核心逻辑要同时做几件事：校验房间和剧本是否存在、校验时间区间是否合法、校验这个房间在目标时间段是否已经有别的场次。

时间冲突查询是这里最容易写错的地方。判断两个区间 [A, B) 和 [C, D) 是否重叠，标准条件是 A < D 且 C < B。用JPA的@Query可以这样实现：

@Query("SELECT s FROM Session s WHERE s.room.id = :roomId " + "AND s.status <> 0 " + "AND (s.startTime < :endTime AND s.endTime > :startTime)") List<Session> findOverlapping(@Param("roomId") Long roomId, @Param("startTime") Date startTime, @Param("endTime") Date endTime);

边界情况要考虑清楚：首尾相接算不算冲突？我的处理是不算。如果一个场次是14:00到16:00，另一个是16:00到18:00，运营上完全可行，因为16:00的玩家进场时，14:00那批正好结束离场，中间留了时间收拾房间。所以条件里用小于而不是小于等于，正好留出缓冲空间。

3.2 用户预约下单：扣减名额与生成订单必须在一个事务里

用户端的预约链路是：浏览场次列表 → 查看场次详情和剩余名额 → 填写预约人数 → 提交订单。前面几步都是页面和查询逻辑，最核心的是最后一步——提交订单。

提交订单涉及两个数据操作：给场次的已预约人数加一，同时生成一条新订单。这两个操作必须放在同一个事务里，并且要处理好并发问题。

Service实现：

@Transactional public Order createOrder(Long userId, Long sessionId, Integer persons) { Session session = sessionRepository.findById(sessionId) .orElseThrow(() -> new RuntimeException("场次不存在")); if (session.getStatus() != SessionStatus.AVAILABLE.getCode()) { throw new RuntimeException("该场次暂不可预约"); } int affected = sessionRepository.decreaseStock(sessionId, persons); if (affected == 0) { throw new RuntimeException("该场次已被约满，请选择其他场次"); } Script script = session.getScript(); BigDecimal totalPrice = script.getPrice().multiply(new BigDecimal(persons)); Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setSessionId(sessionId); order.setPersons(persons); order.setTotalPrice(totalPrice); order.setStatus(OrderStatus.PENDING.getCode()); return orderRepository.save(order); }

对应的Repository原子扣减SQL：

@Modifying @Query("UPDATE Session s SET s.bookedCount = s.bookedCount + :persons " + "WHERE s.id = :sessionId " + "AND s.status = 1 " + "AND s.bookedCount + :persons <= s.maxCapacity") int decreaseStock(@Param("sessionId") Long sessionId, @Param("persons") Integer persons);

这个写法的精妙之处在于，数据库在执行UPDATE时会自动对这条记录加行锁。当两个用户同时预约同一个场次时，数据库会把两个UPDATE串行执行，第二个UPDATE执行的时候发现bookedCount已经涨上去了，条件不满足，返回affected = 0，直接在SQL层就拦截了超卖。比Java层先查后改的写法可靠太多。

3.3 并发防超卖的几种方案对比

面试和答辩都可能问到这个问题。我整理一下常见的防超卖方案。

做毕设或者小型预约系统，用第三种条件UPDATE的方案就够了，不需要引入Redis分布式锁那一套，单库单机条件下完全能防住超卖。

这里要再强调一句：原子扣减和生成订单必须在同一个事务里。如果扣减成功但后续生成订单抛了异常，事务回滚，bookedCount也会跟着回滚，数据就保持一致了。千万不要把两步拆到两个事务里，不然一旦出现异常，库存扣了但订单没生成，排查起来很头疼。

3.4 用户取消订单，别忘了释放名额

取消订单是一个容易忽略的细节。用户取消之后，场次的bookedCount要相应地减回去，否则会出现“订单取消了，但场次还是显示满员”的尴尬情况。释放名额的SQL就是把扣减操作反过来：

@Modifying @Query("UPDATE Session s SET s.bookedCount = s.bookedCount - :persons " + "WHERE s.id = :sessionId") int releaseStock(@Param("sessionId") Long sessionId, @Param("persons") Integer persons);

取消订单的状态机约束也要先做校验，只有待确认和已确认状态才能取消，已完成和已取消都是终态，不能再操作。操作顺序上，先释放名额再更新订单状态，从逻辑上优先恢复业务资源，虽然同一个事务里异常会整体回滚，但这个顺序看起来更合理，也方便阅读代码的人理解业务意图。

3.5 社区交流模块的实现

社区功能是整个系统里最接近传统增删改查的模块，主要就是发帖、浏览帖子列表、查看帖子详情、发表评论。老规矩，列表要分页。Spring Data JPA里的Pageable可以直接实现。

Page<Comment> page = commentRepository.findByPostId(postId, PageRequest.of(pageNum, pageSize));

浏览量和发帖人这些字段，可以在帖子表里做冗余。这里我踩过一个坑：早期直接实时联表查用户表拿昵称，数据量不大还没事，数据一多，热点帖子每次加载都要多查一次用户表。后来干脆在帖子表里冗余了用户昵称字段，展示直接用这个字段，只有在帖子详情页需要展示完整用户信息时才去查用户表。冗余带来的收益，在这种读多写少的场景里非常明显。

4. 实操部署与运行全流程

4.1 环境准备清单

开发环境不需要多高端，但版本问题要确认清楚。我的推荐组合是这样：

• JDK 1.8 或 11，SpringBoot 2.x 两个版本都支持
• Maven 3.6+
• MySQL 5.7 或 8.0
• IDEA 2020以上，社区版也够用
• Navicat 或 MySQL Workbench，管理数据库用

4.2 创建项目与核心依赖

创建SpringBoot项目最快的方式是到Spring Initializr官网生成一个zip包，或者直接在IDEA里新建Spring Initializr项目。依赖方面，至少需要引入Web、Thymeleaf、Spring Data JPA和MySQL驱动。

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

4.3 application.yml 配置文件要点

配置文件的细节决定项目能不能一次跑通。我这份配置基本可以直接复用：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/script_shot?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver jpa: hibernate: ddl-auto: update show-sql: true properties: hibernate: format_sql: true thymeleaf: cache: false

几个容易踩坑的地方我直接标注出来：连接串必须带serverTimezone=Asia/Shanghai，否则MySQL 8会报时区错误；MySQL 8的驱动类名是com.mysql.cj.jdbc.Driver，不要再写老的com.mysql.jdbc.Driver；开发阶段ddl-auto用update自动建表很方便，生产环境要记得改成none或validate，防止误操作动表结构，这是个好习惯。

4.4 初始化数据库与启动项目

先在MySQL里建库：

CREATE DATABASE script_shot DEFAULT CHARACTER SET utf8mb4;

首次启动时Hibernate会根据实体自动建表。然后需要手工插入管理员账号和几个测试剧本、测试房间数据。也可以在resources目录下放一个data.sql，SpringBoot启动时会自动执行，但我不建议一开始就混合使用，如果你已经用ddl-auto: update自动建表了，再配合data.sql容易引发冲突，手动插入测试数据更可控。

运行方式就两种：IDEA里直接运行主类的main方法，或者打包成jar运行：

mvn clean package java -jar target/script-shot-0.0.1-SNAPSHOT.jar

启动成功后访问 http://localhost:8080 就能看到首页了。

4.5 部署到云服务器对外访问（可选）

如果希望老师或者其他用户体验系统，可以部署到一台云服务器上，流程不复杂：服务器安装JDK和MySQL，把jar包传上去，用nohup方式启动，安全组放行8080端口。要注意的是，部署前必须把application.yml里的数据库地址改成服务器的本地地址，账号密码改成服务器上的真实账号，别拿着本地配置去打生产环境的包，这个错误我见过不止一次。

5. 常见问题与排查技巧实录

5.1 数据库连接失败或时区报错

启动时报 Communications link failure 或者 The server time zone value is unrecognized，通常是两个原因：一是MySQL服务没启动，二是连接串缺时区参数。先命令行执行 mysql -u root -p 确认能不能进，能进就说明服务正常；进不去就先启动MySQL服务。确认服务正常后，在连接串后面补上 serverTimezone=Asia/Shanghai，问题基本就解决了。另外建库的时候建议尽量用 utf8mb4，比 utf8 支持更完整的字符集，中文和特殊符号都不会乱码。

5.2 并发预约超卖问题重现与验证

如果预约代码用的是“先查bookedCount判断余量，再更新库存”的写法，并发场景下一定出问题。两个请求同时读到同一份余量数据，都判断为有库存，结果两个订单都生成了，总人数超出了场次容量。

我用一个比较笨但有效的验证方式：创建一个容量为10的测试场次，用Postman的Runner功能发20个并发预约请求，每个请求预约1人。最终检查订单表和场次的bookedCount，如果生成成功的订单数是10条，且bookedCount等于10，防超卖逻辑就没问题。如果订单数超过10，说明并发控制失效，赶紧换成前面讲的条件UPDATE原子扣减方案。

5.3 Thymeleaf模板渲染报错

页面报 TemplateInputException 或者 TemplateProcessingException，先检查这几处：templates目录下是否存在对应的html文件，文件实际路径和Controller返回的视图名是否一致，模板语法是否写错。最常见的低级错误是返回的视图名写成了“post/list”，但文件在 templates/community/post_list.html，名字对不上，自然渲染不出来。另一个坑是模板里混用了原生JavaScript的模板字符串语法，Thymeleaf解析的时候会直接报错，排查时可以先删除可疑的JS片段，再逐个恢复定位出错位置。

5.4 静态资源加载不出来

页面能打开，但css、js全部失效，多半是路径写错了。Thymeleaf模板里尽量用 th:href="@{/css/style.css}" 形式的URL表达式，不要写死成绝对路径。静态资源统一放到 src/main/resources/static 目录下。如果你在项目里加了拦截器或者Spring Security，放行规则里要加上 /css/, /js/, /images/**，否则这些资源请求会被拦截器拦下来。

5.5 端口占用导致启动失败

启动时提示 Port 8080 was already in use，说明8080端口被其他进程占了。最简单的办法是改端口，在application.yml里把 server.port 改成8081。如果想找出占用进程，Windows上可以用 netstat -ano | findstr 8080，然后 taskkill /PID xxx /F；Linux或者macOS用 lsof -i:8080 也能查到进程号。改端口虽然省事，但如果部署到服务器，记得安全组里也要放行对应的新端口。

5.6 打包运行报NoClassDefFoundError

mvn package 成功，但 java -jar 启动时报 NoClassDefFoundError，大概率是没有配置SpringBoot的repackage插件，打出来的是一个普通jar包，并不是包含全部依赖的可执行fat jar。解决方法是确保pom.xml的build节点里有这个插件：

<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build>

重新 mvn clean package 之后再试，基本就能正常启动了。

我在实际做这个项目时，最大的体会是：预约类系统的难点不在某个单一功能有多难写，而在业务流程的整体闭环。排期影响场次，场次约束订单，订单驱动名额，每一步都有上下游的关联。代码写好后，最好的自测方式就是把整条链路从头到尾走一遍：管理端建房间、放剧本、开排期，用户端注册登录、预约、取消，再到管理端确认订单、标记完成，每个环节都过一遍，就能暴露大部分逻辑漏洞。如果你也在做类似的预约系统，建议把状态机约束和并发扣减这两块代码最先写好，它们是整个系统最值钱的地方。