基于SpringBoot的电影票预订系统：锁座并发与订单状态机设计解析

简介：面向Java课程作业与毕业设计，一个基于SpringBoot的电影票预订系统设计与实现资料包，覆盖前端Vue和HTML、CSS、JavaScript，后端采用SpringBoot搭配MySQL数据库。系统功能完整，用户端支持注册登录、浏览影片详情、在线选座购票并模拟支付，还能根据注册喜好推荐影片，支持观影评论与论坛交流，用户可在个人中心维护资料并查看订票和支付记录；后台管理端则对管理员、注册用户、电影、推荐、评论、论坛、购票订单和支付信息进行统一管理。资源共1229个文件，包含518个JavaScript脚本、104个HTML页面、74个CSS样式、51个Java源文件以及Vue组件和SQL数据库脚本，压缩包仅18.36MB，目录清晰易查。目前已有59人学习，可直接用于课程设计或毕业设计参考；随包附带论文、开题报告和PPT答辩材料，便于完善项目文档与演示，也能帮助理解完整业务流程和代码结构。

1. 这不是一个「电影院官网」：基于 springBoot 的电影票预订系统到底交付了什么

如果你在毕设题库里见过“电影票预订系统”，第一反应多半是做一个好看的选座页面。但真正决定这套 JAVA 毕设能不能过的是另一件事：锁座、订单、场次的数据链路在 springBoot 框架里怎么落地。这份资源是一个典型的毕业设计四件套——JAVA 后端源码、毕业论文、开题报告、答辩 PPT。它给你的是一套能启动、能演示、能写进论文的基线版本：前台用户选座购票，后台管理员排片管座，订单状态自动流转。适合两类人：一是选题是这个方向的课程作业或毕业设计学生，二是想快速理解 springBoot 管理系统写法但不想从零搭骨架的初学者。这套资源解决的，是从“拿到题目”到“站上答辩台”的最后一公里问题。

2. 模块与表设计：从功能角色到六张核心表的拆解

2.1 系统按角色切开：用户端与管理端各自管什么

先把这个系统的功能边界画出来。这个资源里的系统分两条线，一条面向普通用户，一条面向管理员。

普通用户这边，注册登录之后能做的事是：浏览电影列表、查看某部电影某天的场次、进入场次选座、下单支付（毕设里一般是模拟支付）、查看自己的历史订单。这里有一个隐含的设计前提：座位是跟“场次”绑定的，不是跟“影厅”绑定的，所以用户进入某个场次时，看到的是这个场次专属的座位快照，这个点后面表结构部分会继续展开。

管理员这边，核心操作围绕“排片”和“管座”展开：维护电影信息（片名、海报、时长、简介、上映状态）、维护影厅与座位（几排几列、哪些座位永久不可售）、创建场次（电影 + 影厅 + 开场时间 + 票价）、查看订单与处理退票。用户端和管理端在代码里通常是同一个 springBoot 应用，靠不同的 Controller 前缀区分接口路径，再用拦截器按 session 里的角色字段做权限控制。答辩时被问权限怎么做，把“拦截器 + 白名单路径”这套答出来就够，没必要把 Spring Security 的完整过滤器链背一遍。

2.2 六张核心表：字段设计与建表 SQL

数据库是这份资源里最值得复用的部分。核心表可以收敛成六张：用户表、电影表、影厅表、场次表、座位表、订单表。为什么座位要单独成表？因为“某个场次里 3 排 5 座是否可售”是选座页面的展示基础，而且这个状态会在用户抢座时被并发修改，单独成表才能方便做行级并发控制。

典型的建表语句如下，这个资源通常是 MySQL 5.7/8.0 加 InnoDB 引擎：

CREATE TABLE `schedule` ( `id` bigint NOT NULL AUTO_INCREMENT, `movie_id` bigint NOT NULL COMMENT '电影 id', `hall_id` bigint NOT NULL COMMENT '影厅 id', `start_time` datetime NOT NULL COMMENT '开场时间', `end_time` datetime NOT NULL COMMENT '散场时间', `price` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '票价', PRIMARY KEY (`id`), KEY `idx_movie_id` (`movie_id`), KEY `idx_hall_id` (`hall_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `seat` ( `id` bigint NOT NULL AUTO_INCREMENT, `schedule_id` bigint NOT NULL COMMENT '场次 id', `row_no` int NOT NULL COMMENT '排号', `col_no` int NOT NULL COMMENT '列号', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0可售 1锁定 2已售', PRIMARY KEY (`id`), UNIQUE KEY `uk_schedule_row_col` (`schedule_id`, `row_no`, `col_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

schedule 表里的 movie_id 和 hall_id 分别关联电影表和影厅表，但我没写 FOREIGN KEY 外键约束，只建了普通索引。原因是外键在选座这种高频写场景下会拖慢 InnoDB 的行锁效率，而且毕设答辩演示时插入顺序稍乱就可能导致建表失败，用“索引 + 应用层逻辑控制”是更常见的做法。end_time 可以由前端根据电影时长算好提交，也可以在 service 层拿到 movie 表的 duration 字段自动推算，两种实现我都见过，后者答辩时更好讲。

seat 表是整个设计的核心。UNIQUE KEY (schedule_id, row_no, col_no) 保证同一个场次里同一个座位只有一条记录；status 字段就是并发控制的主角，第 4 章会专门讲它怎么被 UPDATE 语句利用。

订单表的结构一般是：

CREATE TABLE `orders` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '业务订单号', `user_id` bigint NOT NULL, `schedule_id` bigint NOT NULL, `seat_id` bigint NOT NULL COMMENT '锁定的座位 id', `amount` decimal(10,2) NOT NULL COMMENT '实付金额', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0待支付 1已支付 2已取消 3已退票', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `pay_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意我用了orders而不是order，因为 order 是 SQL 保留字，虽然用反引号能建表，但后面写 MyBatis 自定义 SQL 时到处要加反引号，很容易漏。拆过的资源里也有直接用order的，你要是拿到那种版本，所有手写 SQL 都要记得带反引号，否则直接语法错误。订单表里的 order_no 是业务生成的唯一字符串，推荐用时间戳加随机数，而不是直接把自增主键抛给用户，因为答辩老师大概率会问“订单号为什么不用自增”，标准回答是自增主键会暴露订单量，也不利于做业务流水号统一管理。

剩下的 user 表和 movie 表字段比较直白：user 表有 id、username、password、phone、role，密码用 BCrypt 加密存储；movie 表有 id、title、poster、duration、synopsis、publish_date、status。这两张表不展开 SQL，字段命名和注释在资源里是齐全的，直接对应页面表单即可。

2.3 表关系和查询路径：一次选座购票要经过几张表

把表之间的关系串一遍：电影和场次是一对多，一个电影可以排多个场次；影厅和场次是一对多；场次和座位是一对多——每个场次都会复制一份影厅的座位布局，生成该场次自己的座位快照。用户和订单是一对多，订单和座位在简化实现里是一对一，一张订单对应一个座位。

用户选座的完整查询路径是：打开某部电影 -> 查 schedule 表拿到场次列表 -> 进入某个场次 -> 查 seat 表过滤 status = 0 -> 选座 -> 创建订单 -> 更新 seat.status = 1（锁定）-> 模拟支付 -> 订单状态改为已支付，同时 seat.status = 2（已售）-> 支付超时或手动取消则回退为 0。

至于为什么座位要复制影厅的布局而不是直接关联影厅座位，是因为场次一旦开场，座位布局就应该冻结。如果影院后来调整了影厅座位，已经卖出去的场次不能跟着变，否则用户手里的票和现场座位对不上。这个“快照”语义在论文的数据流设计里写一笔，答辩会很加分。把这条路径背下来，老师按着“断点在哪里、失败怎么办”追问时，你至少能把三个关键节点的回退逻辑讲清楚，整场答辩最核心的技术部分就站住了。

3. 跑通项目：JDK 版本、Maven 依赖和 MySQL 初始化

3.1 环境版本对照：先看你本机装的是什么

这个资源是 springBoot 系，版本差异是最先翻车的地方。先给一份我按常见组合整理的版本对照表：

拿到资源后先别急着启动，打开 pom.xml 看 springBoot 的 parent 版本。如果是 2.5.x 到 2.7.x 区间，JDK 8 就能跑；如果写的是 3.x，JDK 必须 17 以上，而且很多老代码里的 javax.servlet 要改成 jakarta.servlet，否则编译直接报错。这个检查花不了两分钟，能省掉后面一整轮折腾。

3.2 配置文件里的关键参数：端口、数据源、MyBatis-Plus

把 application.yml 打开，重点看三块。以最常见的 springBoot 2.x + MyBatis-Plus 组合为例：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/movie_ticket?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

url 里最容易被忽略的是 serverTimezone 和 allowPublicKeyRetrieval。MySQL 8.x 驱动要求时区参数，不写会在启动时报 “The server time zone value” 异常；allowPublicKeyRetrieval 在 SSL 连接校验开启时也要加，否则 IDEA 测试连接会失败。这两个参数是 mysql-connector-j 8.x 最常见的两个坑，网上大量报错帖都跟它们有关。

MyBatis-Plus 的 log-impl 配成 StdOutImpl 后，控制台会打印每一条执行的 SQL。调试和答辩演示阶段建议保留，论文截图也能直接用；真要部署上线再关掉。map-underscore-to-camel-case 开启后，数据库的 create_time 能自动映射到实体的 createTime 字段，这是 MyBatis-Plus 默认行为，不要关。

如果资源里的 application.yml 分成了 application-dev.yml 和 application-prod.yml，说明它有按环境切换配置的习惯，本地跑把 spring.profiles.active 改成 dev 即可。

3.3 初始化数据与启动顺序：先建库再起后端

数据库连接串里的 movie_ticket 是库名，但资源里一般不会自动帮你建库。拿到手先执行根目录下的 db.sql，它会建库、建表、插入演示数据。我建议你先打开它看一眼里面有没有 INSERT 语句，没有的话说明演示数据要靠前端页面手动造，答辩前要提前准备好账号和影片数据。

顺序上，先建库再启动后端：

mysql -uroot -p < db.sql cd /path/to/project mvn spring-boot:run

看到Tomcat started on port(s): 8080就说明后端起来了。也可以mvn clean package打成 jar，再java -jar target/movie-ticket-0.0.1-SNAPSHOT.jar运行，效果一样，后者对后面第 5 章提到的离线演示更友好。

提示：mvn 第一次运行会拉非常多依赖，卡在 download 阶段超过十分钟，先检查 Maven 的 settings.xml 有没有配阿里云镜像，这是国内环境最典型的玄学问题，跟代码没关系。

后端起来后，如果资源带 Vue 前端，在前端目录里执行npm install再npm run dev，访问的通常是另外一个端口。前端代码里配置的后端地址要和 8080 对上，对不上就会出现接口 404 或者跨域报错。

3.4 前后端分离的联调参数：代理与路径前缀

带 Vue 前端的资源一般在 vue.config.js 里配了代理，写法类似：

devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

意思是前端所有以 /api 开头的请求都转发到后端 8080。联调时最容易出问题的是路径前缀不统一：后端 Controller 写的路由是 /user/login，前端请求却是 /api/user/login，于是出现 404。拆资源时经常遇到两种风格不一致的情况，先对一遍前后端路径前缀再启动，比启动后慢慢排查快得多。

如果后端接口确实都带 /api 前缀，Nginx 部署时也要保证 location /api 的转发规则和后端路由一致，否则本地跑通了，部署到服务器又断。

4. 业务核心：选座三态、锁座并发与订单状态机

4.1 座位状态的三种形态：0、1、2 分别代表什么

第 2 章的建表 SQL 里 seat.status 用了三个值：0 可售、1 锁定、2 已售。为什么需要三种状态？

如果只有“可售 / 已售”两态，用户选座的瞬间座位就变成已售，可他可能只是点着看看，还没付款就关了页面，这个座位就永久被占住。加“锁定”就是给两个动作之间留缓冲：用户点了座位 -> 状态变成锁定（1）-> 用户跳到支付 -> 支付成功才变成已售（2）-> 超时未支付则回退可售（0）。

这个资源的 service 层一般是把逻辑包在一个带事务的方法里，核心代码是这个套路：

@Transactional(rollbackFor = Exception.class) public void lockSeat(Long seatId) { // 目标状态：锁定；期望当前状态：可售 int rows = seatMapper.updateStatus( seatId, SeatStatus.LOCKED.getCode(), SeatStatus.AVAILABLE.getCode() ); if (rows == 0) { throw new BizException("座位已被他人选中，请重新选择"); } }

这段逻辑的关键在 updateStatus 的 SQL，本质是UPDATE seat SET status = 目标状态 WHERE id = #{seatId} AND status = #{期望状态}。受影响行数是 0，说明这条 UPDATE 没匹配到“当前状态为可售”的记录，也就是座位已经被别人改成锁定或已售，直接抛业务异常，前端收到提示后刷新座位图。这种写法叫乐观锁，用 WHERE 条件做并发控制，不需要 SELECT ... FOR UPDATE，是毕设项目里最通用、也最容易跟答辩老师讲清楚的方案。

但要提醒一点：用户一次选多个座位时，要保证所有座位都成功才整体提交，否则会出现一个订单里部分座位锁成功、部分失败的中间状态。我一般会在方法上直接加 @Transactional，让多座位锁定要么全成功要么全回滚，不建议去掉事务。

4.2 并发锁座：为什么两个用户同时抢一个座位只有一个能赢

锁座是这套系统最值得在答辩时讲的技术点。实现要点是不要“先 SELECT 再 UPDATE”，而是直接用一条带条件的 UPDATE 完成“读状态 + 改状态”。前者的经典问题是两个线程同时 SELECT 都看到状态是 0，然后都执行 UPDATE 成功，同一个座位卖给了两个人，这就是超卖。

这个资源如果用了 MyBatis-Plus，对应的 mapper XML 写法更直观：

<update id="updateStatus"> UPDATE seat SET status = #{targetStatus} WHERE id = #{seatId} AND status = #{expectStatus} </update>

在 InnoDB 默认的 REPEATABLE READ 隔离级别下，这条 UPDATE 执行时会对命中的行加行锁，第二个事务必须等第一个提交，等它执行时 WHERE 里的 status 已经匹配不上，受影响行数为 0，于是不会超卖。这个保证来自数据库层面，不是靠 Java 代码里加 synchronized 实现的。

答辩有一个高频追问：为什么不用分布式锁？回答思路：单实例部署时数据库行锁已经足够，分布式锁是为多实例、多服务场景准备的，毕设项目单机演示用不到，硬加反而增加复杂度。老师如果追问 Redis 方案，把 SETNX 加过期时间、以及“锁超时后怎么处理”讲两句就基本过关了。

4.3 订单状态机：待支付、已支付、已取消、已退票

订单表的状态字段需要一套明确的状态流转约束，按最常见的毕设实现整理如下：

待支付订单的超时释放，常见实现是 springBoot 里的定时任务：用 @Scheduled 每 30 秒扫一次订单表，找出创建时间超过 15 分钟且状态仍为 0 的订单，把订单置为已取消，同时把对应座位回退为可售。代码很短：

@Scheduled(fixedRate = 30000) public void releaseExpiredOrders() { List<Order> expiredList = orderMapper.selectExpiredUnpaid(15); for (Order order : expiredList) { orderService.cancel(order.getId()); // 内部完成订单改状态 + 座位回退，同一事务 } }

fixedRate = 30000 表示每 30 秒执行一次；selectExpiredUnpaid(15) 里的 15 是分钟，SQL 用create_time < NOW() - INTERVAL 15 MINUTE判断超时。注意扫描间隔越短，状态回退越及时，但数据库压力越大；毕设数据量下 30 秒完全够用。

另外别忘记在启动类上加 @EnableScheduling，否则 @Scheduled 不会生效。这是一个隐蔽坑，代码没问题但定时任务就是不跑，多半是启动类少了这个注解。写论文时把“状态机 + 超时释放”放一章，标题可以叫“订单状态管理设计”，配上面这个状态表，内容支撑度很高。

5. 毕业设计避坑：从启动到答辩最常见的五类翻车点

5.1 启动报错：端口占用、JDK 版本、Mapper 找不到

现象：mvn spring-boot:run 后控制台报Port 8080 was already in use，或者项目启动失败提示 JDK 相关异常，又或者接口调用时报Invalid bound statement (not found)。

原因分三种：端口被其他进程占用；JDK 版本和 springBoot 版本不匹配，比如用 JDK 17 跑 springBoot 2.x 的旧依赖；Mapper 接口和 XML 文件扫描路径不一致，XML 没被打进 classpath。

解决：端口占用在 mac 或 Linux 下用lsof -i:8080找到进程再 kill，或者直接改 application.yml 里的 server.port。JDK 版本问题先回 pom.xml 确认 springBoot 版本再切 JDK。Mapper 找不到时检查 @MapperScan 扫描的包路径是否覆盖了 mapper 接口所在包，同时确认 XML 文件存在于 target/classes 里，IDEA 里右键项目执行 Build -> Rebuild Project 经常能解决 XML 没被拷贝的问题。

5.2 数据库连接失败：时区、编码、驱动名三个老演员

现象：启动时报java.sql.SQLException: The server time zone value '...' is unrecognized，或者Unknown database，或者控制台中文变乱码。

原因：MySQL 8.x 驱动必须指定 serverTimezone；库名没建或者连接串里库名写错；表或库的字符集不是 utf8mb4，客户端读取中文变成乱码。

解决：url 里加serverTimezone=Asia/Shanghai和useSSL=false；连上 MySQL 执行 SHOW DATABASES 确认库名和连接串完全一致；建库语句统一用CREATE DATABASE xxx DEFAULT CHARACTER SET utf8mb4，连接串再带 characterEncoding=utf8。这三步能覆盖九成以上的数据库连接失败。

5.3 并发抢座演示翻车：两个浏览器窗口同时下单

现象：答辩时开两个浏览器标签页同时抢同一个座位，结果两个订单都创建成功，或者其中一个提示“座位已选”但页面数据没刷新。

原因：后端锁座逻辑没问题，但前端选座成功后没有立即重新拉取座位状态；也可能演示节奏太快，没等后端事务提交就点了第二个窗口。

解决：演示前先把座位状态全部重置为可售，执行UPDATE seat SET status = 0，同时把未完成订单清掉；演示时点完第一个座位停顿两秒，等前端接口返回后再操作第二个窗口。另外确认前端在锁座成功回调里有刷新整个座位图的操作，没有的话提前在代码里补一行。

5.4 论文查重偏高：框架代码、配置描述、系统设计三处重灾区

现象：论文查重率超过 30%，翻看报告，相似段落集中在 springBoot 框架介绍、系统功能模块描述、数据库设计说明这些“人人都这么写”的位置。

原因：框架介绍和模块划分直接抄了网上模板或源码说明文档，这些文本早就进了查重库；数据库表结构描述和建表 SQL 也和大量同类毕设高度重合。

解决：系统设计部分改成结合本项目的话术，少用通用句式，比如不要写“本系统采用 B/S 架构”，而是写“本系统的用户端通过浏览器访问，后端接口部署在同一台服务器上，前端静态资源由后端统一托管”；框架介绍里少整段复制官方文档，改成“本项目使用 MyBatis-Plus 主要利用它的条件构造器简化 SQL 编写，同时依赖它的分页插件实现场次列表分页”；建表 SQL 保留字段但调整注释和顺序，论文里用表格展示字段集合，多数查重系统对表格的重复计算权重很低。

5.5 答辩演示环境：现场没网、端口冲突、数据被改乱

现象：答辩教室的电脑连不上外网，npm install 卡在 dependencies 拉取；演示到一半发现选座页面大片红色不可选，数据被前面的操作改乱了。

原因：没在答辩前把整个环境离线化，前端依赖还挂着 npm 在线源；演示过程中反复下单、取消、退票，积累了脏数据。

解决：提前一天把后端打成 jar，把前端 build 成静态文件放进 springBoot 的 static 目录由后端一起托管；或者用 Nginx 同时托管前端静态文件后端反向代理 8080，确保断网也能完整演示。演示前写一个 reset.sql，内容就是几条 UPDATE 把订单清空、座位复位、场次还原，答辩开始执行一次。这套“单机离线 + 一键还原”的组合能救回一半以上的演示事故。

6. 把它改成自己的项目：二开方向与验收验证清单

最省事的二开方向是加一个“电影评论”模块。现有表结构里 movie、user、orders 都在，评论需要的外键直接齐全。先建一张 comment 表，字段只需要 id、movie_id、user_id、content、create_time，然后补一个 service 和一个 controller，前端在电影详情页挂一个评论区。这样改动量不会太大，但答辩时的创新点说明可以从“实现了一个电影票预订系统”变成“在基础购票流程之上引入用户评价闭环，帮助其他用户做观影决策”，叙事高度明显不一样。

另一个低成本方向是把“模拟支付”换成“微信/支付宝扫码支付的对接流程说明”。毕设时间紧的话不必真的接入沙箱，画清楚时序图，把支付回调里订单状态从待支付改成已支付的代码写出来，足够应付追问。但要注意回调幂等：支付平台可能因为网络重试发多次回调，处理前先查订单是不是已支付，避免重复改状态。

验证这块，我自己的习惯是维护一张清单。每次改完代码，按这个顺序走一遍：启动无异常、注册登录能走通、管理员能创建场次、用户能选座下单、支付后座位变已售、取消订单后座位回退、两个窗口抢同一座位只有一个成功。这套资源里最容易因加代码而坏掉的就是锁座那一步，改过 seat 相关代码后，并发测试一定要重新跑，别只看到单线程下单没问题就收工。

有一个真实教训：之前拆另一套类似资源时，我为了加会员折扣改了订单金额计算逻辑，结果没注意支付回调那里也重新算了金额，演示时付一次款，订单金额变了两次。从那以后，每次改完订单相关代码，我都会强制走一遍“下单 -> 支付 -> 查订单金额 -> 退票”的完整链路，确认金额只在支付成功那一瞬间落定。这个习惯后来救了我不只一次。

希望帮到你。拿到这份电影票预订资源后，先按第 3 章跑通环境，把第 2 章的表结构和第 4 章三个业务点整理成自己的笔记，再考虑第 6 章的二开方向，整套东西才会真正变成你的项目。

本文还有配套的精品资源，点击获取