Spring Boot电影订票系统源码解析：从数据库设计到部署避坑

我第一次拿到这份基于Spring Boot的电影订票系统源码时，第一反应是“这也太常规了”——用户登录、影片列表、选座下单、订单管理，似乎每个培训班项目都长这样。可当我真把源码跑起来，又动手把几个模块拆开看过之后，才意识到这类项目能一直流传是有原因的：它几乎覆盖了Java Web开发从数据库设计到接口联调的所有基础动作，又不像电商系统那样一上来就被高并发、分布式事务、支付回调这些复杂概念淹没。所以不管你是准备交课程设计，还是想系统过一遍Spring Boot的完整开发链路，这个项目都很适合拿来当练手对象。

这篇文章会结合这套基于Spring Boot的电影订票系统，说清楚三件事：项目到底做了什么、每个核心模块是怎么实现的、以及真正部署运行时最容易卡住你的那几个坑。我会尽量还原我在实际运行、改动、补全这套代码时的思路，而不是把源码里的README复述一遍。

1. 先看业务再看框架：一个订票系统要拆成哪几块

很多初学者拿到项目源码的第一反应是打开IDE直接点运行，跑起来之后对着页面点两下就算看完。这个习惯其实很浪费。源码只是结果，真正的价值在于设计者为什么把系统拆成这些模块、每个模块的边界画在哪。

1.1 角色与核心流程

电影订票系统最基础的用户角色有两类：前台购票用户和后台管理员。

用户端的核心链路非常清楚：注册登录 → 浏览影片 → 查看场次 → 选择座位 → 创建订单 → 模拟支付 → 查看订单。管理员端的核心链路则是：维护影片信息 → 管理影厅与场次 → 处理订单状态 → 基础数据统计。

这两条链路合起来，就是一个典型的“前台商城 + 后台管理”结构，和电商、酒店预订、演出票务的底层逻辑几乎一致。所以学透这一个项目，你再看其他预订类系统，大部分功能都能对号入座。

1.2 系统边界：哪些东西项目里故意没做

看源码之前先看边界，这能帮你判断项目复杂度是否可控。

这套系统没有对接真实支付网关，支付环节通常做成模拟支付或者沙箱回调；没有做复杂的座位分区定价，一般就是同一个场次一个统一票价；也没有做影院级别的排片调度，一个影厅一个场次的时间冲突检测可能只是做了简单校验。这些“缺省”不是设计失误，而是课程设计和毕业设计里为了控制工作量的有意取舍。

知道边界之后，你才能判断后续怎么扩展。比如你已经会了模拟支付，那真正接入微信支付或支付宝沙箱，本质只是把“模拟支付成功”的方法体换成调用支付网关SDK，再接收异步通知而已。

1.3 这套源码适合谁看

如果你已经学完了Java基础、MySQL和Spring Boot的CRUD，但对“怎么把零散功能拼成一个完整系统”没概念，这套源码就是很好的参考。如果你在准备毕业设计，需要一个能讲清楚需求分析、数据库设计、核心接口实现的完整案例，它也比零散的代码片段有价值得多。

我个人不太建议零基础的同学直接啃这套源码。至少你要先看得懂@RestController、@Service、@Mapper这些注解，知道HTTP请求是怎么被Spring MVC处理的，否则很容易在“每个类都能看懂、但连起来不知道在干嘛”的状态里卡很久。

2. 技术选型与工程骨架：为什么是Spring Boot 2.7而不是3.x

这个项目的技术栈很主流：Spring Boot + MyBatis-Plus + MySQL + 前端模板或前后端分离。搜索引擎里关于“springboot版本太高”“springboot jdk1.8打包到docker desktop”的搜索量一直居高不下，说明版本问题确实是新人最容易踩的坑。

2.1 版本选择是我最想提醒你的事

如果你拿到的源码是基于Spring Boot 2.x写的，建议老老实实用2.7系列，不要手滑升级到3.x。原因很现实：Spring Boot 3.0的基线是JDK 17，而大量课程设计环境还停留在JDK 8；同时Spring Boot 3.x把javax.*包迁移到了jakarta.*，很多老代码的import javax.servlet全部要改。

我自己的建议是：除非你对新版本特性有明确需求，否则课程设计和学习阶段使用Spring Boot 2.7.18是最稳妥的方案。这个版本是2.x的最终维护版本，稳定且踩坑资料多。

2.2 ORM框架选择：MyBatis-Plus的优势

持久层框架选MyBatis-Plus，核心原因有三点：第一，它继承了MyBatis的灵活SQL能力，复杂查询可以手写XML；第二，BaseMapper内置了增删改查，单表操作基本不用写SQL；第三，分页插件PaginationInnerInterceptor配置一次，全项目通用。

java复制@Configuration
@MapperScan("com.kaic.movie.mapper")
public class MybatisPlusConfig {

    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

这段分页配置就是新人最容易漏的：如果你查出来的分页数据一直是全量，先看看是不是没加这个拦截器。

2.3 前端方案与权限设计

这套项目的前端有两种常见形态。一种是传统的Thymeleaf模板加Bootstrap，所有页面由后端渲染，适合只想搞懂服务端逻辑的同学；另一种是Spring Boot + Vue前后端分离，前端通过Axios调用后端接口，适合想顺带练前端工程化的同学。

权限控制上，课程设计和毕业设计里比较常见的做法有两种：Session方案和JWT方案。

Session方案的逻辑是用户登录后把用户信息放进HttpSession，后续请求通过拦截器检查Session中是否存在用户标识。优点是实现简单、无需额外依赖，缺点是前后端分离时跨域场景比较麻烦。

JWT方案的逻辑是登录成功后服务端签发一个Token返回给前端，前端后续请求带上Authorization: Bearer <token>，服务端通过拦截器或过滤器解析校验。这套方案的优点是无状态、适合前后端分离，缺点是需要自己处理过期时间和Token续期。

对学习项目来说，两种方案都能用。我个人的习惯是：手写服务端渲染就用Session，前后端分离就用JWT。无论哪种，关键要理解拦截器的作用——它是整个系统权限控制的咽喉。

3. 数据库设计：电影、场次、座位、订单怎么串起来

数据库设计是整个订票系统里最值得花时间琢磨的部分。很多源码跑起来没问题，但一想要改需求就发现表结构撑不住，根源就是当初设计表时没有捋清实体关系。

3.1 核心表结构

一个标准的电影订票系统，基本表有5张以上：用户表、电影表、影厅表、场次表、订单表，还可能加一张座位表。

sql复制-- 电影表
CREATE TABLE `t_film` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `film_name` varchar(100) NOT NULL COMMENT '片名',
  `film_type` varchar(50) DEFAULT NULL COMMENT '类型',
  `director` varchar(50) DEFAULT NULL COMMENT '导演',
  `actors` varchar(200) DEFAULT NULL COMMENT '主演',
  `duration` int(11) DEFAULT NULL COMMENT '片长(分钟)',
  `poster_url` varchar(255) DEFAULT NULL COMMENT '海报地址',
  `description` text COMMENT '简介',
  `status` tinyint(4) DEFAULT '1' COMMENT '上映状态 1-热映 0-下架',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

sql复制-- 场次表
CREATE TABLE `t_session` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `film_id` bigint(20) NOT NULL COMMENT '电影ID',
  `hall_id` bigint(20) NOT NULL COMMENT '影厅ID',
  `start_time` datetime NOT NULL COMMENT '开场时间',
  `end_time` datetime DEFAULT NULL COMMENT '散场时间',
  `price` decimal(10,2) NOT NULL COMMENT '票价',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这两张表是影片和场次的骨架。t_film负责存影片的静态信息，t_session负责存某部电影在某个影厅的放映场次和票价。一个电影对应多个场次，一个场次只对应一个电影。

3.2 座位和订单的关系是核心难点

座位和订单的关系，是订票系统与普通商品系统最大的不同点。买普通商品，你买的是SKU，库存是一个数字；但买电影票，你要指定“几排几座”，而且同一个座位的同一场次不能被两个人同时购买。

常见设计有两种。第一种是只设计订单表，订单里存座位信息字符串，比如"3排5座,3排6座"，靠程序判断同一场次座位是否冲突。第二种是单独设计座位表，每个座位一条记录，订单明细关联座位记录。

我在源码里见过最多的是第一种，实现简单，但并发下单时容易出现超卖问题。第二张表结构更严谨，适合需要做选座界面的场景。

sql复制-- 订单表（简化版）
CREATE TABLE `t_order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(64) NOT NULL COMMENT '订单号',
  `user_id` bigint(20) NOT NULL COMMENT '用户ID',
  `session_id` bigint(20) NOT NULL COMMENT '场次ID',
  `seat_info` varchar(255) NOT NULL COMMENT '座位信息，如 3排5座,3排6座',
  `amount` decimal(10,2) NOT NULL COMMENT '总金额',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态 0-待支付 1-已支付 2-已取消',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这套简化设计里，判断座位是否被占用的核心SQL是：查同一session_id下已支付或待支付的订单中，是否已有包含目标座位的记录。这个逻辑在数据量小的时候没问题，但你要能意识到它的并发局限。

3.3 订单号与状态字段设计的细节

订单号我建议用时间戳加随机数和用户ID拼接，比如202506011230450001。不要用数据库自增ID做订单号，那样会暴露业务量，而且不利于后续对接支付时作为商户订单号使用。

状态字段我习惯用tinyint存数字，而不是直接存字符串。0-待支付、1-已支付、2-已取消、3-已退款，这个设计的好处是数据库存储小、判断逻辑快，前端展示时再通过枚举或字典翻译成文字。

如果你在源码里看到订单表有pay_time、cancel_time这类时间字段，说明设计者考虑了状态流转的可追溯性。如果没有，建议自己补上，这在演示项目答辩时是一个很加分的细节。

4. 核心接口实现：从影片列表到订单支付的完整链路

看懂了表结构，接下来最该做的是把整条用户购票链路在代码里走通。这一节我按一个真实用户购票的操作顺序，把后端接口逐个拆开讲。

4.1 影片列表与场次查询

影片列表通常是系统首页的第一个接口，逻辑很直接：分页查询状态为上映中的影片，按热度或上映时间排序。用MyBatis-Plus的话，一段LambdaQueryWrapper就能搞定。

java复制@GetMapping("/film/list")
public Result<IPage<Film>> list(@RequestParam(defaultValue = "1") int page,
                                @RequestParam(defaultValue = "10") int size) {
    LambdaQueryWrapper<Film> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(Film::getStatus, 1)
           .orderByDesc(Film::getPublishDate);
    IPage<Film> filmPage = filmMapper.selectPage(new Page<>(page, size), wrapper);
    return Result.success(filmPage);
}

点击某部电影后，用户要看到的是“哪个影厅、几点开演、票价多少”。这个接口需要关联查询：根据filmId查t_session，再关联影厅名。这里就是JOIN的用武之地。

java复制@GetMapping("/session/list")
public Result<List<SessionVO>> listByFilmId(@RequestParam Long filmId) {
    List<SessionVO> sessionList = sessionMapper.selectSessionListByFilmId(filmId);
    return Result.success(sessionList);
}

对应的XML里写一个连表查询，把场次表、电影表、影厅表三张表串起来，查出场次ID、开始时间、影厅名、票价。这里我想强调一个习惯：列表接口的返回值尽量用VO，不要直接用数据库实体。你不想把description这种大字段每次都发给前端，也不想把userId这种内部字段暴露出去。新建一个SessionVO只放需要展示的字段，是项目代码规范的分水岭。

4.2 选座与订单创建：并发问题从这里开始

选座是订票系统里最有技术含量的环节。用户在页面上能看到的座位状态，来自一个查询接口：根据sessionId查询所有已生成订单的座位信息。但真正考验逻辑的是创建订单接口。

创建订单的常规流程是：前端传来sessionId和seatList，后端先验参，然后锁定座位，再生成订单。这里最关键的步骤是“锁定座位”，防止两个用户同时抢同一个座位。

java复制@Transactional(rollbackFor = Exception.class)
public Order createOrder(Long userId, Long sessionId, List<String> seatList, BigDecimal amount) {
    // 1. 检查场次是否存在
    Session session = sessionMapper.selectById(sessionId);
    if (session == null) {
        throw new BizException("场次不存在");
    }

    // 2. 检查座位是否被占用
    for (String seat : seatList) {
        int count = orderMapper.countSeatOccupied(sessionId, seat);
        if (count > 0) {
            throw new BizException("座位已被占座: " + seat);
        }
    }

    // 3. 生成订单号并插入订单
    String orderNo = generateOrderNo();
    Order order = new Order();
    order.setOrderNo(orderNo);
    order.setUserId(userId);
    order.setSessionId(sessionId);
    order.setSeatInfo(String.join(",", seatList));
    order.setAmount(amount);
    order.setStatus(0);
    orderMapper.insert(order);

    return order;
}

上面的实现是“先查再插”，并发场景下存在时间差风险。更稳的做法是直接用一条UPDATE语句去原子地占用座位：UPDATE t_seat SET status = 1, order_id = ? WHERE id = ? AND status = 0，如果影响行数为1说明占用成功，为0则说明座位已经被抢。这才是真正的并发安全。

4.3 模拟支付与订单状态流转

项目里没有真实支付网关，通常的做法是提供一个模拟支付接口：用户点击“支付”，后端直接把订单状态改成已支付，然后返回成功。这块逻辑虽然简单，但你要理解真实支付流程中的两个关键点。

第一是支付回调。真实项目中，用户支付成功后是支付平台异步通知你的服务器，而不是前端告诉你“我付了”。所以模拟支付接口的写法虽然方便演示，但它绕过了回调校验这层逻辑。想扩展的话，可以了解支付宝SDK里的AlipayTradePagePayRequest和异步通知验签机制。

第二是订单状态机。一个订单的合法状态流转是：待支付 → 已支付 → 已消费/已退款，待支付 → 已取消。写代码的时候要提醒自己加上状态判断，不能允许从已支付跳到已取消。

4.4 订单超时未支付怎么处理

课程设计里这个功能经常被忽略，但实际上很能体现系统设计水平。用户下单后迟迟不支付，座位就被一直锁着，其他用户就买不了。常规方案有两种：一是定时任务扫描超时订单并取消，二是用延迟队列或Redis过期监听。

java复制@Component
public class OrderTimeoutTask {

    @Scheduled(fixedRate = 60000)
    public void cancelTimeoutOrders() {
        LocalDateTime deadline = LocalDateTime.now().minusMinutes(15);
        List<Order> timeoutOrders = orderMapper.selectTimeoutOrders(deadline);
        for (Order order : timeoutOrders) {
            order.setStatus(2);
            orderMapper.updateById(order);
            // 释放座位
            seatService.releaseSeat(order.getSessionId(), order.getSeatInfo());
        }
    }
}

@Scheduled在Spring Boot里开箱即用，只要在启动类上加上@EnableScheduling即可。这种实现方式不复杂，但在答辩和面试里讲出来，绝对比“订单要手动取消”高一个档次。

5. 真实部署中的坑：版本、配置、打包三板斧

源码在本地能跑和在任何环境下都能跑，是两码事。我见过太多人卡在环境问题上，所以这一节把最常见的坑集中讲一遍。

5.1 Spring Boot版本太高导致的连锁反应

“Spring Boot版本太高”是最近搜索热词，也是新手最容易中的招。默认情况下，你在Spring Initializr上创建项目选的最新版本是3.x，而很多老源码是基于2.x写的。一旦版本升级，会出现：javax.servlet包找不到、MyBatis-Plus分页插件报错、JDK版本不兼容等问题。

解决方案一是在pom.xml里手动改成2.7.18：

xml复制<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.18</version>
</parent>

方案二是干脆用JDK 17并全面适配Spring Boot 3.x，但这需要把源码里的javax.全部替换为jakarta.，且确认MyBatis-Plus版本在3.5.3以上。

5.2 数据库配置与MySQL驱动坐标

连不上数据库是启动时报错率最高的问题。最常见的两点是时区和驱动坐标。

时区问题老生常谈，JDBC连接串里最好显式加上serverTimezone=Asia/Shanghai：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/movie_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: 123456

驱动坐标在MySQL 8.0之后要注意：老写法com.mysql.jdbc.Driver已经废弃，要写com.mysql.cj.jdbc.Driver。同时Maven坐标也有变化：

xml复制<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <scope>runtime</scope>
</dependency>

如果你的源码里用的是mysql-connector-java，在Spring Boot 2.7里也能用，但本质上它已经被重命名成mysql-connector-j了，新项目建议直接用新坐标。

5.3 Tomcat端口占用与静态资源404

启动报“Port 8080 was already in use”，说明8080端口被占用。最简单的处理是换端口，在application.yml里加：

yaml复制server:
  port: 8081

如果换了端口还是不生效，检查是不是没启动对配置文件。

静态资源404是另一个高频坑。如果你把前端页面放在了src/main/webapp目录下，打包成JAR时这些资源默认不会被打进去。Spring Boot的默认静态资源目录是src/main/resources/static、public或resources。把HTML、CSS、JS放到static目录下，访问路径就是http://localhost:8080/index.html。

5.4 打包与部署：JDK 8环境下的Docker处理

把Spring Boot项目打包成JAR再部署，是所有流程里最容易出细节问题的一步。项目根目录执行mvn clean package -DskipTests，生成的目标JAR包，执行java -jar xxx.jar就能启动。这是最基础的玩法。

如果你想用Docker部署，一个常见问题是“JDK 8的镜像怎么选”。注意不要用openjdk:latest，因为新版可能已经不是8了。标准做法是：

dockerfile复制FROM openjdk:8-jre-alpine
COPY target/movie-ticket.jar /app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

在“springboot jdk1.8打包到docker desktop”的搜索场景里，很多人卡在镜像拉取或JDK版本上。实际排查思路很简单：先在宿主机上java -version确认打的JAR确实是在JDK 8下编译的，再确认Dockerfile里的基础镜像也是8，两个版本对齐了问题就少一大半。

5.5 常见报错排查对照表

6. 还可以怎么改：几个实用的扩展方向

源码看懂了、跑通了，不代表这个项目就结束了。真正拉开差距的是你在这个项目基础上做了哪些有价值的改动。这里我给几个既不会难度爆炸、又能让项目明显上档次的方向。

6.1 引入Redis管理座位状态

如果你已经理解了数据库锁座位的原理，想让并发能力更强，可以把“可选座位查询”和“临时锁座”放到Redis里做。用Redis的SET存储某场次已被选择的座位，用SETNX或Lua脚本做原子占座。座位信息在Redis里操作，订单落库后再异步同步座位最终状态。

这个改动的意义在于，你会真实体会到“缓存 + 数据库”双写的一致性问题，这在真实企业项目里是核心话题。

6.2 支付模块升级为真实沙箱

在模拟支付接口的基础上，接支付宝沙箱环境。沙箱提供了一整套测试账号和密钥，后端只需要引入官方SDK，配置gateway地址、appId、privateKey和publicKey，然后按照官方文档发起支付请求、接收异步通知验签。整个过程不需要真实资金，但能让你完整跑通一套支付链路。

6.3 增加定时任务与统计报表

除了超时取消订单，定时任务还能做每日票房统计、影片热度排行。比如用@Scheduled每天凌晨统计前一天的订单数据，写入一张统计表。后台管理页面再用ECharts展示趋势图。这个功能看起来简单，但能把聚合查询、定时任务、数据可视化三个技能点串起来。

6.4 前后端彻底分离

如果当前版本是服务端渲染，想顺着现在的招聘主流方向走，可以试试把前端改成Vue 3 + Element Plus，后端只提供纯JSON接口。重点要解决的就是跨域和登录态问题，正好把JWT方案和CORS配置一起练了。

我在实际改动这套源码的时候，最大的感受是：项目本身不难，难的是你愿意站在设计者的角度去思考“为什么这里要这么做”。比如为什么要用事务包裹下单流程、为什么座位状态要单独判断、为什么订单状态要独立成字段，这些问题想明白了，你从源码里拿走的就绝不仅仅是一段能跑的代码。