SpringBoot电影院售票系统开发实战：数据库设计与订单状态管理

做这套Springboot基于web的电影院售票系统，前前后后折腾了三周。中途换过一次数据库设计方案，临时加了两个字段，最后又花了一天把模拟支付从“直接改状态”升级成了“先创建订单再付款”的完整流程。整个过程踩过的坑，比我在教程里看到的要多得多。

这个系统本身不算复杂，但它把电影院售票业务里最核心的链路都串起来了：影片信息管理、影厅座位布局、场次排片、用户在线选座、生成订单、模拟支付、订单查询，以及管理端的销售统计。可以说，一个web项目的增删改查、状态流转、权限区分、数据统计这些知识点，它全都涉及了。所以这类题目既成了课程设计里的“常青树”，也是很多同学做毕业设计时的第一选择。

后面我会把完整经验拆成六块：第一，整体设计思路；第二，数据库表结构和业务约束；第三，页面功能和实现要点；第四，从数据库初始化到打包部署的完整流程；第五，实操中最容易踩的坑；第六，那篇一万字论文具体怎么组织。无论你是从零开始搭，还是已经拿了整套源码准备二次开发，这篇都可以直接当一份“排雷笔记”用。

1. 项目整体设计与思路拆解

1.1 为什么选Spring Boot，而不是SSH或SSM

很多类似题目在多年以前都是用SSH或者SSM来做的。现在再让我从零做一遍，我不会有任何犹豫，直接用Spring Boot。原因有三个，都很实际。

第一，开发效率差了一个量级。Spring Boot 的 starter 机制把常用依赖组合固定好了。引入 spring-boot-starter-web 之后，内嵌Tomcat，不用再额外装外部容器，写个带 main 方法的 Application 类就能跑起来。这种好处在课设和毕设场景下尤其明显：你本来就需要在有限时间里把功能写完，而不是把时间花在配置环境上。

第二，配置简化很多。SSM 时代见过太多同学在 applicationContext.xml、spring-mvc.xml、mybatis-config.xml 这几个文件之间来回切换，一个字母写错，整个项目启动失败。Spring Boot 里大部分配置只需要在 application.yml 里写上数据源、MyBatis 映射、端口号就完事了，报错信息也直白，新手自己就能定位问题。

第三，和就业需求衔接。现在企业里维护的业务系统，用 Spring Boot 的比例非常高。课设阶段用这套框架，写进简历不算突兀，面试官也不至于觉得你不接地气。

有人会在 MyBatis 和 JPA 之间纠结。我在这套系统里用的是 MyBatis，原因两个：一是 SQL 可控性强，影院售票涉及统计报表，手动控制查询逻辑心里有底；二是能查到的资料和示例代码多，出现问题抓取旧帖子也容易解决。JPA 上手虽然简单，但复杂一点的连表统计和级联操作，对新手来说排查成本很高。

1.2 把影院业务拆成“影片、场次、座位、订单”四个要素

刚拿到题目时，容易被“售票系统”四个字带偏，一上来就想着做支付、做选座动画。其实冷静下来，把业务拆开看，整个系统就四个核心要素：

• 影片：电影标题、海报、导演、主演、类型、时长、简介、上映日期。它只描述“有什么可看的”。
• 场次：某部电影在哪个影厅、哪个时间段放，票价多少。它描述的是“什么时间在什么地方看”。
• 座位：影厅的物理座位加上某个场次的占用情况。它解决的是“坐哪儿”的问题。
• 订单：用户和场次之间的关系，包含座位、金额、支付状态、创建时间。它解决的是“交易怎么留下记录”的问题。

四个要素拆清楚之后，数据库表的雏形基本就出来了。后续所有功能模块，比如管理员排片、用户选座、订单查询，都能归到这四个要素的增删改查和状态流转上。这也是我在论文里写系统需求时最省力的部分，哪怕不写一行代码，先把这四层关系讲明白，需求分析那一章就有内容可写。

1.3 前后端分离还是服务端渲染

现在技术社区里到处都是 Vue、React，很多同学一上来就问我，这个项目是不是应该做前后端分离。我的回答是，看场景。如果是企业级项目，前后端分离没问题；但如果是课设、毕设，我建议优先做服务端渲染，用 Thymeleaf 模板引擎。

前后端分离意味着你要维护前端工程、后端接口、跨域配置、接口鉴权，等于同时写两个项目，工作量直接翻倍。而且答辩老师更关心的往往是“业务流程是否完整”“数据库是否合理”“功能能不能跑通”，而不是你有没有用最新版前端框架。Thymeleaf 和 Bootstrap 组合，页面写起来不慢，整个项目也能保持单一工程，部署打包更方便。这套系统我全部使用 Thymeleaf 渲染页面，选座交互用原生 JavaScript 加点 Ajax 实现，已经能满足需求。

2. 数据库设计：从表结构到业务约束

2.1 六张核心表各自负责什么

数据库设计是这套系统的命根子。表设计错了，后期所有代码都得返工。我最终用了六张核心表，分别对应刚才说的四个要素，再把用户和订单明细单独拆开：

看一下建表 SQL 的关键部分，方便理解字段关系：

sql复制CREATE TABLE `movie` (
  `id` INT PRIMARY KEY AUTO_INCREMENT,
  `title` VARCHAR(100) NOT NULL,
  `poster` VARCHAR(255),
  `director` VARCHAR(50),
  `actors` VARCHAR(255),
  `type` VARCHAR(50),
  `duration` INT COMMENT '单位分钟',
  `intro` TEXT
);

CREATE TABLE `schedule` (
  `id` INT PRIMARY KEY AUTO_INCREMENT,
  `movie_id` INT NOT NULL,
  `hall_id` INT NOT NULL,
  `start_time` DATETIME NOT NULL,
  `end_time` DATETIME NOT NULL,
  `price` DECIMAL(10,2) NOT NULL,
  KEY `idx_movie` (`movie_id`),
  KEY `idx_hall` (`hall_id`)
);

CREATE TABLE `orders` (
  `id` INT PRIMARY KEY AUTO_INCREMENT,
  `order_no` VARCHAR(32) NOT NULL UNIQUE,
  `user_id` INT NOT NULL,
  `schedule_id` INT NOT NULL,
  `total_price` DECIMAL(10,2) NOT NULL,
  `status` TINYINT DEFAULT 0 COMMENT '0待支付 1已支付 2已取消 3已过期',
  `create_time` DATETIME,
  `pay_time` DATETIME,
  KEY `idx_user` (`user_id`),
  KEY `idx_schedule` (`schedule_id`)
);

这里有两个细节要提醒。第一，movie 表的 duration 字段要用整数，单位是分钟，不要用字符串“1小时30分”这种格式，否则后面做统计和展示不好处理。第二，orders 表里要单独保存 total_price，不要在设计上指望每次都用场次价格乘座位数现算。因为票价可能后续会被管理员调整，订单一旦生成，金额就要固化成历史数据。

2.2 座位占用状态：字符串存储还是独立表

座位设计是这套系统里最大的坑。最开始我是用独立座位表来做的，每个场次预先给每一个座位生成一条记录，再有订单就更新状态。后来发现两个问题：一是数据量膨胀得很厉害，一个100座影厅排30天场次，就是3000条座位数据；二是并发情况下，同一个座位数条记录的状态容易互相覆盖，排查问题非常麻烦。

第二次改方案，我直接把每个场次座位占用记录放到 schedule 表的一个字段里，比如 occupied_seats 存字符串，格式是“1-1,1-2,2-3”，代表第一排第一座、第一排第二座、第二排第三座。用户下单时，后端解析这个字段，判断目标座位有没有落在里面，没有就追加进去，有就提示已被选。

这个方案在中小型系统里非常实用。优点很明显：表简单，代码好写，占用状态一眼就能看懂。缺点是并发量一大，两个用户同时选同一个座位，可能出现前后端都判定“座位空闲”的情况。解决办法也不复杂，用 synchronized 或者数据库行锁把创建订单的方法锁一下，这种项目规模完全够用。

挑选座位时，前端拿到的是一个可用座位列表和一个不可用座位集合，再根据这些数据渲染按钮状态。后端封装一个方法统一处理字符串和集合的互相转换，避免在多个 Controller 里重复解析。

2.3 订单状态不能靠删除，要靠流转

很多新手会犯一个错：用户没付款，就把订单记录删掉；取消订单，也删掉。表面看数据库很干净，但后面统计票房、查操作日志时就会抓瞎，因为没有任何痕迹。

正确的做法是用状态字段控制订单生命周期。一个订单从创建开始，经历待支付、已支付、已取消、已过期这几个状态。用户取消时不是删除数据，而是把 status 改为2；超时未支付由定时任务改成3。这样保留整条记录，论文里写“订单生命周期管理”“异常流程处理”也好写，系统抗争议的能力也强。

订单号我用时间戳加三位随机数生成，保证全局唯一。写代码时用 SimpleDateFormat 生成字符串就可以，没必要引入复杂雪花算法。毕竟不是分布式环境，别过度设计。

3. 页面功能与接口实现要点

3.1 用户端的完整操作流

用户端的流程是按“逛影院”的真实习惯设计的。游客可以访问首页和影片列表，但点选座时会自动跳转登录页。登录后的完整链路：

首页浏览影片列表，点进影片详情看到上映场次，选定场次后进入选座页面，点选座位提交订单，订单页面展示金额和座位信息，确认后进入模拟支付页面，支付成功回到订单列表。

这条链路对应的核心接口我简单列一下，方便对照调试：

java复制// 影片模块
GET /movie/list // 分页查询影片
GET /movie/{id} // 影片详情和排片场次

// 场次和选座
GET /schedule/seats/{scheduleId} // 获取某个场次的座位状态
POST /order/create // 创建待支付订单

// 订单模块
POST /order/pay // 模拟支付
GET /order/myOrders // 查询当前用户订单
POST /order/cancel // 取消订单

逻辑上要注意一件事：创建订单时就要立刻计算总价并且锁定座位。不要等到支付时才去算价格和座位，否则会出现用户点击支付时座位被别人抢走、或者票价被改动的情况。

3.2 管理端的排片和场次管理

管理端功能主要集中在影片管理和排片管理上。影片管理就是常规的增删改查，这里有个容易忽略的点：海报上传。

如果你不打算接对象存储，就把图片以文件形式保存到项目本地的 upload 目录，数据库里存相对路径。页面用图片标签直接访问相对路径。这里特别要注意，Spring Boot 默认不开放静态目录外的文件资源，需要配置一个资源映射，把 /upload/** 映射到本地上传目录。另外表单上传时，一定要给 MultipartFile 加大小限制，否则传了大文件会报异常，页面没有提示，看起来就是“莫名其妙失败”。

排片管理是管理端最重要的功能。添加一场排片，需要选择影片、选择影厅、给定开始时间和价格。结束时间不用管理员手填，系统根据影片时长自动计算。这个细节很加分的，答辩时老师大概率会问“结束时间怎么算”，你直接说是根据影片时长算出来的，比回答说“也是手动填的”效果好得多。

场次重复校验也要注意，同一个影厅在同一时间范围内不能同时排两部电影。可以在数据库层面不好查，但代码里可以用一个简单的区间碰撞查询来判断：查找该影厅已有排片，是否存在 start_time 小于新结束时间且 end_time 大于新开始时间的记录。

3.3 选座界面：表格渲染与座位锁定

选座页面是整个系统的门面。用表格渲染座位有两个优势：一是界面天然是网格，二是不用引入复杂前端框架。每个座位就是一个 button，状态分三种：可用、已选、已售。

我用一个数据接口返回当前场次的座位状态，前端拿到后循环渲染。核心逻辑大概长这样：

javascript复制var rows = ${seatRows}; // 影厅行数
var cols = ${seatColumns}; // 影厅列数
var occupied = ${occupiedSeats}; // 已占用座位集合

function renderSeats() {
    for (var r = 1; r <= rows; r++) {
        var rowDiv = $('<div class="seat-row"></div>');
        for (var c = 1; c <= cols; c++) {
            var key = r + '-' + c;
            var cls = occupied.indexOf(key) > -1 ? 'occupied' : 'available';
            var btn = $('<button class="seat ' + cls + '" data-seat="' + key + '">' + r + '排' + c + '座</button>');
            btn.on('click', function() {
                if ($(this).hasClass('occupied')) return;
                $(this).toggleClass('selected');
                updateSelectedSeats();
            });
            rowDiv.append(btn);
        }
        $('#seatArea').append(rowDiv);
    }
}

这里有个小技巧，座位状态不要用布尔值判断，而是页面保留一个已选座位数组，每次点击后在数组里增删。提交订单时，把数组用逗号拼接成一个字符串传到后端，后端再解析。这个方法看起来简单，但避免了每次点击都去改样式中间件的复杂度，逻辑不容易出bug。

还要加上一个限制：单次购买座位数量不能超过6个，防止有人一次锁太多座位不付款。这个限制放在后端校验，不要只在前端做。前端限制只是体验问题，后端限制才是业务保证。

3.4 模拟支付环节的四种做法

模拟支付有四种常见做法，从易到难：

第一种是订单状态直接改为已支付。最简单，但演示效果很差，老师会觉得你没用心。

第二种是做一个独立的模拟支付页面，页面显示支付金额和订单号，点一下“确认支付”，后端把状态改为已支付。这套系统采用的就是这种方式，够用且有完整的界面转换。

第三种是接入支付宝沙箱。展示效果最好，真金白银体验一把完整的支付回调，但需要申请支付宝开发者账号，配置密钥和回调地址，课设周期内容易卡在账号审核或回调问题上。

第四种是做一个“钱包余额”概念，用户注册时给个虚拟余额，支付时扣余额。这种方式可以把支付页面做得更真实，但把简单问题复杂化了。

我做的时候选择了第二种，重点考虑了稳定性和演示效果。设计上让支付页面还显示订单创建时间、座位信息、倒计时提示，演示时观感完整，又不会因为外部接口不稳定翻车。

4. 环境准备与完整部署流程

4.1 开发环境与工具清单

这套系统我用的环境组合比较保守，也是目前运行最稳的一套：

JDK 版本这里特意说一下，不要一上来就装 JDK 17 或者更高版本。有些扩展插件和 MyBatis 相关组件在高版本 JDK 上会有警告甚至编译报错，课设阶段用 JDK 1.8 省心得多。

4.2 数据库初始化与 application.yml 配置

拿到源码后，第一步不是急着启动，而是把数据库建好。用 Navicat 新建一个数据库，比如叫 cinema_db，然后导入项目里的 cinema_db.sql 脚本。脚本里包含建表语句和测试数据，注意确认数据库的字符集设为 utf8mb4，不然中文会乱码。

第二步配置 application.yml。核心配置长这样：

yaml复制server:
  port: 8080
  servlet:
    context-path: /

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/cinema_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
  thymeleaf:
    cache: false

mybatis:
  mapper-locations: classpath:mapper/*.xml
  configuration:
    map-underscore-to-camel-case: true

这里有几个关键点值得反复强调。字符集参数 useUnicode=true&characterEncoding=utf8 必须写，哪怕数据库本身就是 utf8mb4 也要写，不然插入中文数据极易出现乱码。serverTimezone 必须设成 Asia/Shanghai，否则 MySQL 8.x 驱动会报时区错误，连接失败。

map-underscore-to-camel-case 这个配置特别重要。开启之后，数据库的字段 order_no 自动映射到 Java 属性 orderNo，不用在Mapper里一个个写 resultMap 映射，编码量大减。

4.3 打包、启动与验证

数据库配好之后，启动登录功能。IDEA 里直接运行 XxxApplication 类的 main 方法就行。如果之前没构建过，首次会下载大量依赖，建议提前配置好阿里云 Maven 镜像，国内下载速度能翻几倍。

打包部署的流程我用的是标准方式：

bash复制mvn clean package -DskipTests
cd target
java -jar cinema-0.0.1-SNAPSHOT.jar

打完包的 jar 文件可以直接放到服务器上运行。启动日志里看到 “Started XxxApplication” 就说明成功了，浏览器访问 http://localhost:8080 就能看到首页。

这里提示一个部署细节，写论文需要部署截图时，不要只截桌面环境，可以加一张用 MobaXterm 之类的工具连接到服务器上执行 java -jar 的截图，会更显专业。纯本地 IDEA 截图说服力弱一点。

如果 8080 端口被占用，启动时报端口冲突，用命令查一下占用进程：

bash复制netstat -ano | findstr 8080
taskkill /F /PID 进程号

Mac 或 Linux 上则是 lsof -i:8080 后 kill 对应进程。

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

5.1 典型问题速查表

这套系统开发过程中我记录了不少高频问题，整理成表格，大家逐个对照排查基本能解决一半的启动问题：

最隐蔽的一个问题是 Mapper 接口与 XML 文件命名不统一。比如接口叫 MovieMapper.java，XML 文件却叫 movieMapper.xml，大小写不一致在某些系统上也能加载，偶尔会报奇怪错误。规范改成同一个名字和路径，避免无谓排查。

5.2 调试阶段的几个保命习惯

实际操作里，以下五个习惯帮我节省了非常多时间。

第一，后端接口先独立调通再加页面。我习惯把所有接口在 Postman 里先跑一遍，确认返回 JSON 正常后，再回头写 Thymeleaf 页面。如果页面有错，会先怀疑参数传递问题，而不是后端逻辑问题。

第二，日志保留到文件。开发环境虽然控制台能看到日志，但部署到服务器后出现问题，控制台刷过去就没了。建议在 application.yml 里加一个日志文件配置，logging.file.name 指定路径，出了问题直接翻文件。

第三，每次改表结构前导出 SQL 备份。数据库改坏了，一键导入恢复，比手工回滚快太多。这个习惯在写论文期间尤其重要，因为你可能会反复调整测试数据。

第四，静态资源改动后强刷浏览器。Thymeleaf 启动时默认模板缓存开启，我发现页面改动看不出来，一度以为代码没生效，其实清了缓存刷新就好。开发阶段在 yml 里设置 thymeleaf.cache=false 可以避免这种困扰。

第五，把系统里所有业务校验放在后端。后端是最后一道防线，前端的所有限制都只是优化体验。比如“座位是否已占用”这种判断，如果前端写了、后端没写，用户直接构造请求就能绕过限制，一次多订，系统就崩了。

6. 从项目到论文：一万字怎么组织

6.1 论文骨架与各章分配建议

代码做完，论文还有一关。很多同学代码没问题，但一万字硬是憋不出来。其实不是没内容，是不知道每一章该写什么。按照这套系统的结构，我建议这样分配：

这个分配方式的好处是，技术章节占大头，各章之间逻辑递进自然，老师审论文时会觉得结构完整。其中“详细设计”和“系统实现”是最容易写满也最容易出彩的。

6.2 关键截图与用例描述技巧

论文不能全是文字，功能模块截图是业务最好的证明。这里有个很重要的原则：每一个功能模块都要有“正常流程”和“异常流程”两组截图。

比如选座模块，正常流程展示的是选座成功、订单生成、支付成功的页面；异常流程则展示座位被占用时的红色提示、订单已取消的状态页面。这种对应关系在答辩时尤其加分，说明你不仅实现了正常逻辑，还处理了异常情况，思维比大多数同学完整。

用例描述可以借助简单表格，而不必全部写成长段文字。格式参考：

这种表格一篇论文里放七八个，内容量和专业度都提升了，而且每个只需几行字，不需要编故事。

6.3 怎么把字数写满又不显得注水

论文最忌讳堆无意义的空话。我的原则是，用一个细节描述代替一段套话。什么意思？不要写“系统具有良好的可扩展性”，而写“本系统将影片和场次进行分离设计，用户通过场次关联影片信息，排片时直接选择影片即可，新增影片不需要修改排片逻辑，方便后续接入更多影片类型”。

数据字典也是个很好的补字数工具。把所有表结构整理成数据字段表格，包括字段名、类型、是否为空、说明，这张表撑起几千字完全没问题，而且内容极其实用，答辩老师翻开看会觉得你做得很细致。

再加两张图就更加充实：一张E-R图描述表关系，一张系统功能模块图描述角色和功能。这两个图用通用绘图工具就能完成，放进去后论文结构立刻有立体感。

技术选型对比表是另一种高效补字数的办法。比如 Spring Boot 和 SSM 对比、MyBatis 和 JPA 对比，列三行优势劣势再加一句结论，相关技术那一章就非常扎实了。

我个人在实际操作中的体会是，这类系统的代码难度其实没有数据设计大，真正让人返工的都是对业务状态的理解不到位。座位占用方式、订单状态流转、模拟支付流程，这三个点想清楚了，整个项目就顺了。后面如果你想扩展，可以再加一个基于 Quartz 的定时任务，把超时未支付订单自动取消，也可以在用户端加一个电影收藏功能。这些方向都比重复堆功能模块更能体现系统深度，论文里也更有话可说。