1. 项目概述与设计思路
1.1 为什么选这个题目做毕设
电影购票系统可以说是计算机毕设里"性价比"非常高的一类选题，原因很直白：业务链路完整、技术点覆盖面够广、功能边界清晰，而且答辩的时候评委一听就懂，不需要费半天口舌解释"你这个系统到底是干什么的"。
从用户端看，有电影浏览、场次查询、选座下单、订单支付、订单管理这几条核心链路；从管理端看，有影片管理、影厅管理、场次排片、订单审核、数据统计这些标配功能。一套做下来，Spring Boot、关系型数据库设计、缓存、事务、权限控制、前端交互这些核心技术点基本都碰了一遍，写在简历上也拿得出手。
另外一个实际的考虑是工作量可控。相比电商系统、外卖平台这类动辄十几张业务表的项目，电影购票系统的表结构大概在6到8张左右，业务规则集中在线下选座和订单状态流转上，不至于做到一半发现收不住。我当时就是看中这一点，才最终定了这个方向。
1.2 技术选型背后的实际考量
Spring Boot作为主框架基本没什么好纠结的，社区活跃、资料多、遇到问题一搜就有答案，这对毕设阶段非常重要。真要说选型时需要动脑子的，是下面这几个搭配问题：
第一，Java版本和Spring Boot版本的对应关系。如果你还在用JDK 8，那就老老实实选Spring Boot 2.x，而不要贪新用Spring Boot 3.x——因为Spring Boot 3强制要求JDK 17，很多教学资料和现成代码都是基于2.x写的，照着敲不容易踩版本坑。
第二，ORM框架的选择。这里有一个常见的分岔路口：Spring Data JPA和MyBatis-Plus。我个人的建议是，如果本身对SQL比较熟，想掌控每一条查询语句，就用MyBatis-Plus，它对单表CRUD的封装非常友好，代码生成器一键生成实体和Mapper，能省不少重复劳动。如果你更想减少代码量、而且不介意学习一点点JPA的方言，那Spring Data JPA也完全够用。我自己用的是MyBatis-Plus，后面文章里讲到的代码也都是基于它。
第三，前端方案要提前定死。千万不要做着做着后端又纠结要不要改成前后端分离。毕设项目我推荐直接用Spring Boot自带模板引擎Thymeleaf加Bootstrap或者Layui这类现成UI框架，原因很简单：不用处理跨域问题、部署简单、一个jar包跑起来就能演示。前后端分离（Vue + Spring Boot）当然更贴近企业实际，但开发和联调成本会明显上升，万一中途卡住就比较被动。
1.3 项目模块怎么划分
整个系统按角色划分成三个端：C端用户端、B端管理后台、以及公共的基础模块。用户端对应的是普通观众，核心诉求是"快速找到想看的电影并完成选座购票"；管理端对应的是影院运营人员，核心诉求是"排片管理、影片上下架、订单监控和数据统计"。
在代码结构上，我用的是标准的Controller-Service-Mapper三层架构，按功能模块分包，没有用那种按技术类型分包的写法。这样做的最大好处是，答辩时讲代码结构非常顺——controller包下按电影、场次、订单、用户、评论等业务域各自建类，service层处理具体的业务逻辑，mapper层只管数据访问。评委问"某个功能对应的代码在哪里"，你几秒钟就能定位到，这种印象分是很值的。
2. 数据库设计与核心功能拆解
2.1 六张核心表怎么设计
数据库设计是一套系统的地基，表结构没设计好，后面写业务代码的时候处处难受。电影购票系统的核心表我梳理成了六张，外加两张辅助表，下面逐个说设计要点。
用户表：字段包括用户名、密码（必须加密存储，推荐BCrypt）、昵称、手机号、余额（用于模拟充值支付）、角色标识（区分普通用户和管理员）。这里有个容易忽视的点——注册时间和最后登录时间最好都要有，因为后续统计用户活跃度、做简单的用户增长分析时都要用到。
电影表：电影名称、导演、主演、类型、片长、上映日期、下映日期、海报URL、剧情简介、状态。状态字段要学会用status来控制，比如0代表未上映、1代表热映中、2代表已下架。不要通过"当前日期是否在上映区间内"去实时计算状态，那样后续统计和管理端列表展示会非常别扭。
影厅表：影厅名称、座位容量、座位布局（存JSON格式的座位图，例如{"rows":8,"cols":10,"disabledSeats":["1_3","2_5"]}）。把座位数据设计成JSON存，实现灵活多变座位布局，这是在数据灵活性和查询性能之间取了一个平衡点。
场次表：关联电影和影厅，字段包括电影ID、影厅ID、放映时间、语言版本（原声/配音）、票价。这里需要特别注意：票价最好不要直接写在订单表里，而是跟着场次走。因为同一个电影不同场次的定价可能不同（早场便宜、黄金场贵、IMAX厅加价），分析性的统计也要依赖场次价格。
订单表：订单号、用户ID、场次ID、座位信息、总金额、状态、创建时间、支付时间。订单号需要自己生成，推荐用"时间戳+随机数"的方式，不要直接用数据库自增ID作为订单号展示给用户——一方面暴露业务量，另一方面也不够随机。
评论表：用户对电影的评分和评论内容，用于丰富系统功能，让答辩时功能列表更好看。
为了让大家直接照抄，我把建表SQL的要义列在下面，字段类型和注释都标清楚了。座位信息在订单表里建议用seat_ids字符串存，格式类似3_5,3_6，代表第3排第5、6座，方便显示和状态校验。
CREATE TABLE `user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码', `nickname` varchar(50) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `balance` decimal(10,2) DEFAULT 0.00 COMMENT '账户余额', `role` tinyint DEFAULT 0 COMMENT '0-普通用户 1-管理员', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;2.2 用户端功能清单与核心逻辑
用户端的功能，说白了就围绕着一条购票主链路：浏览影片 -> 查看场次 -> 选座 -> 生成订单 -> 模拟支付 -> 查看订单。
首页与影片列表：按"正在热映"和"即将上映"两个维度展示影片，支持按类型筛选、按名称模糊搜索。这里要用上MySQL的LIKE查询，建议在movie_name上建索引，量小无所谓，但设计规范一点答辩的时候有的讲。
场次列表：点进电影详情，展示该片未来几天的场次。这里有一个非常实际的问题：日期切换怎么实现？最简单可靠的做法是后端接收前端传的date参数，通过WHERE DATE(show_time) = ?这样的方式去查数据库。注意，不要用BETWEEN加上当天零点之类的做法——因为索引失效的问题，数据量一大查询会变慢，虽然毕设体量无所谓，但讲解时可以主动提这个优化点，是加分项。
选座购票：这是整个系统最核心的页面逻辑。前端渲染一个座位图，根据后端返回的"已售座位集合"把对应座位置灰，用户点击座位选中（灰色不可点、红色待选中、绿色可选），选完点击提交。设计已售座位时需要格外留神：后端返回的应该是"已被锁定/已售出"的座位集合，因为存在用户选中座位但未支付的情况，这类座位也必须禁止他人重复选择，否则就会出现两个用户在同一座位上"撞车"的严重问题。
订单支付：我采用的是模拟支付，支付方式不接支付宝/微信，而是直接用账户余额。用户下单后，订单状态为"待支付"，此时调起支付页面可以选择余额支付。如果余额不足，提示用户先充值；充值功能同样做成模拟的，点击"充值"后余额增加，不需要真的对接第三方支付接口。
2.3 管理端功能清单与核心逻辑
管理端主打一个"运营后台"的感觉，功能包括管理员登录拦截、影片CRUD管理、影厅和场次管理、订单管理、数据统计看板。
管理端比较容易被忽略但实际很重要的一个点是：所有管理员操作都需要做权限校验。实现上不搞复杂，用Spring Boot拦截器（HandlerInterceptor）就可以：写一个LoginInterceptor，检查session里是否有人登录、角色是否为管理员，如果不是就重定向到登录页。注意要放行登录页和静态资源，否则会出现"登录接口也被拦截"的尴尬问题。
数据统计看板也是管理端的一个亮点功能，建议至少包含三个指标：每日订单数趋势、热门影片Top5票房统计、各影厅上座率。SQL层面无非就是GROUP BY DATE(create_time)、GROUP BY movie_id ORDER BY SUM(total_amount) DESC、SUM(座位数) / 影厅容量这类聚合查询。做这个功能的意义不仅是"功能丰富"，更重要的是让评委觉得你有真实业务思维——管理系统不只是增删改查，而是能辅助运营决策的。
3. 核心业务实现与完整实操复盘
3.1 用户注册登录与拦截器配置
用户注册登录虽然看起来基础，但有两个点必须处理好，否则后期返工很烦。
第一是密码加密。我强烈建议使用Spring Security里的BCryptPasswordEncoder，不要用MD5加盐这种"自己造轮子"的方式。BCrypt的特点是每次加密的结果不同，但校验时能判断是否匹配，而且自带强度因子，安全性在业界是被验证过的。引入方式不需要整套Spring Security，单独引入spring-security-crypto依赖即可，不要杀鸡用牛刀导致登录流程被安全框架接管。
第二是登录状态的保存方式。毕设最常用的就是Session方式：登录成功后将用户ID和用户名写入Session，拦截器中从Session读取，读到并校验通过就放行，否则跳转登录页。很多同学在这里会纠结要不要用JWT做Token，我的建议是：如果做前后端分离，用JWT没问题；但你用Thymeleaf模板渲染，老老实实用Session，简单、不跨域、能自圆其说。
拦截器配置是Spring Boot里的一个小经典，注意放行路径和拦截路径的划分：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns( "/user/login", "/user/register", "/index/**", "/movie/**", "/css/**", "/js/**", "/images/**" ); } }这段配置的逻辑是：拦截所有请求，但对登录注册、电影浏览首页、静态资源直接放行。注意/movie/**这种浏览类接口要放行，因为未登录用户也应该能浏览电影列表，只有选座下单时才要求登录——这是符合真实产品体验的设计。
3.2 选座与锁座机制深入解析
选座是整个系统的"技术上最有的讲"的部分。我第一次做的时候天真地以为"插入订单前去数据库查一下已售座位，如果没卖就下单"，结果测试时开了两个浏览器窗口同时选同一个座位，两个请求都通过了校验——这就是典型的并发问题。肉眼测不出问题，但答辩时评委一问"多个用户同时抢同一个座位怎么办"，答不上来就很减分。
解决思路要根据项目体量来选，我推荐一个性价比最高的方案：数据库行锁加状态机制。核心思路就一句话：用SELECT ... FOR UPDATE对场次记录加行锁，锁住之后当前只有一个请求能继续往下走，其他请求会阻塞等待。
伪代码逻辑如下：
@Transactional public Order createOrder(Long sessionId, List<String> seatIds, Long userId) { // 1. 锁定场次记录，防止并发操作 Session session = sessionMapper.selectByIdForUpdate(sessionId); // 2. 查询当前场次所有已售+锁定中的座位 List<String> soldSeats = orderMapper.selectSeatIdsBySessionId(sessionId); // 3. 用集合判断用户选择的座位是否与已售座位有交集 for (String seat : seatIds) { if (soldSeats.contains(seat)) { throw new BizException("座位 " + seat + " 已被锁定，请重新选择"); } } // 4. 创建订单，状态为待支付 Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setSeatIds(String.join(",", seatIds)); order.setStatus(0); orderMapper.insert(order); return order; }对应的Mapper方法要加FOR UPDATE：
<select id="selectByIdForUpdate" resultType="com.example.entity.Session"> SELECT * FROM session WHERE id = #{id} FOR UPDATE </select>FOR UPDATE会开启一个数据库层面的行级锁，事务提交后释放。整个过程简短、可解释性强，而且能实实在在说明白"为什么要先锁再查再插入"这套流程。高并发场景下使用Redis分布式锁自然更优，但毕设阶段能做到数据库行锁这一层已经是一个完整的进阶亮点了。
订单的超时处理同样值得一提。用户选了座位但迟迟不支付，这个座位就会一直占着不放。两种常用策略：一是定时任务扫描"超时未支付订单"并释放座位，用Spring Boot自带的@Scheduled即可；二是用户主动取消订单时释放。我在实际项目里是两个都做了，定时任务每5分钟跑一次，把所有创建超过15分钟且状态仍为"待支付"的订单改为"已取消"，同时因为座位是跟着订单走的，订单取消后座位自然就释放了，不需要额外的座位表字段。
这里有个细节：@EnableScheduling别忘了加在启动类上，整个定时任务才算真正生效。很多同学就是栽在这种小地方。
3.3 订单模块、支付流程与事务边界
订单模块的要害在于状态机的设计。订单状态我用整数表示：0-待支付, 1-已支付, 2-已取消, 3-已完成。这个状态流转不能乱跳，比如"待支付"只能流向"已支付"或"已取消"，"已支付"只能流向"已完成"。
事务边界也很关键。支付操作涉及两件必须同时成功的事：扣减用户余额、更新订单状态为已支付。这两个操作必须放在同一个事务里，任何一步失败都要整体回滚。我在OrderService.pay()方法上加@Transactional，方法内部先查用户余额判断是否足够，再执行余额扣减和订单更新。Spring的@Transactional默认只在RuntimeException时回滚，如果业务里抛出的是自定义检查异常，还会出现"事务没回滚"的坑——所以自定义业务异常最好是继承RuntimeException。
另外提醒一个很多人在毕业设计里忽略的问题：重复支付。用户疯狂点击"支付"按钮，会不会扣两次款？最简单的防重复手段是在支付接口开头做一个状态判断，先查订单状态，如果不是"待支付"直接拒绝；同时因为整个方法在同一个事务里，同一时刻并发请求会被数据库的行锁挡住。为了稳妥，可以在order表的状态字段上再做一个乐观锁版本号version，更新时带WHERE version = #{oldVersion}，更新成功影响行数为0就说明被别人改过了。这些点不一定全实现，但实现一个并且能讲清楚，答辩时都是一个亮点。
3.4 前端页面开发与Thymeleaf渲染细节
Thymeleaf写页面，有几点如果你提前知道，能省下大量"页面出不来"的排错时间：
第一，页面模板放对位置。src/main/resources/templates目录下，返回视图的逻辑视图名对应模板文件名。Controller里return "index"就会渲染templates/index.html，这个对应关系要记牢。
第二，静态资源路径约定。CSS、JS、图片放src/main/resources/static下。我在制作时犯过一个错：CSS文件引不进来，页面裸奔特别难看。最后发现是路径写错了，比如/css/style.css前面少了一个/，Thymeleaf的th:href="@{/css/style.css}"一定会自动加上项目上下文路径，但如果自己写死了href="css/style.css"，当前URL层级一变路径就废了。
第三，列表循环和条件渲染的语法。th:each用于循环，如果你想在循环里判断座位状态，就用th:if。座位图渲染的核心代码思路如下：
<div th:each="row : ${seatMap}" class="seat-row"> <span th:text="${row.rowNum} + '排'" class="row-label"></span> <div th:each="col : ${row.cols}" class="seat-cell"> <div th:classappend="${col.status == 'sold'} ? 'seat sold' : (${col.selected ? 'seat selected' : 'seat available'})" th:data-row="${row.rowNum}" th:data-col="${col.colNum}" th:onclick="'selectSeat(' + ${row.rowNum} + ',' + ${col.colNum} + ')'"> </div> </div> </div>第四，表单提交。简单的登录注册用th:action="@{/user/login}"配合method="post"。但选座下单这种带动态参数的，我更推荐直接用JavaScript发Ajax请求。页面先渲染座位图，用户点座位后在JS里维护一个"已选座位数组"，点击"提交订单"按钮时把数组作为JSON传给后端。这样前端交互更灵动，也避免了表单数据拼接的麻烦。
3.5 项目打包部署与演示环境准备
毕设最终都要部署演示，这一步我踩过最大的坑是：在IDEA里能跑，打包成jar之后反而不行。问题的根源通常有三个。
第一个是打包插件缺失。Spring Boot项目必须引入spring-boot-maven-plugin，否则打出来的jar不包含内嵌Tomcat，跑起来就报"没有主清单属性"：
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build>第二个是数据库连接配置问题。本地开发时数据库地址常常写着localhost，但演示环境如果换了一台机器，就要改成对应的IP。更推荐的做法是把配置外置，通过启动命令传入参数覆盖：java -jar cinema.jar --spring.datasource.url=jdbc:mysql://xxx:3306/cinema，这样就不需要为每个环境改配置再重新打包。
第三个是端口占用。默认是8080端口，如果演示的电脑上已经有程序占用了8080，就会启动失败。启动时通过--server.port=8081指定一个备用端口即可。这个小技巧我建议所有同学都记住，现场演示时打开不了一定是最尴尬的情况。
4. 开发中常见问题的排错实录
4.1 字段名与驼峰映射的隐藏陷阱
用MyBatis-Plus时有一个几乎每个人都会遇到的坑：数据库字段是create_time（下划线风格），而Java实体里的属性是createTime（驼峰风格）。如果没有开启驼峰映射，你会发现查询出来的数据全是null，但不报错，排查起来特别费劲。
解决办法有两步。第一步，确保application.yml里配置了：
mybatis-plus: configuration: map-underscore-to-camel-case: true第二步，如果个别字段对不上，比如数据库字段叫order_no，实体属性叫orderNo，就需要用@TableField("order_no")注解去显式映射。也可以直接在实体类字段上统一加@TableField，更保险，尤其在字段命名不太规范的遗留数据库上工作，这个习惯能救命。
4.2 日期时间格式化差八小时
项目中涉及到show_time（放映时间）会频繁出现"存入数据库的日期时间与页面上显示的不一致"的情况，数据库存的是8点，页面显示却是0点或16点。这通常是时区问题：MySQL驱动连接串上没有指定时区，默认用了服务器的UTC时间。
我的解决办法是在数据库连接URL上明确指定serverTimezone=Asia/Shanghai，同时在实体类的LocalDateTime字段上加上@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")以保证输出格式统一。排查这个问题时可以用最笨但也最有效的办法：把SQL直接拿到Navicat里执行，看数据库里存的值是否是预期的，再对比Java代码里查询出来的值——一步步缩小偏差发生在"写库"还是"读库"环节。
4.3 事务不生效的三种可能
这个坑尤其隐蔽：你在Service里加了@Transactional，数据却还是出现了"只扣钱没更新订单"或者"订单更新了但钱没扣"的情况。从我见过的代码来看，最常见的三种原因是：
- 异常被吞掉：方法里自己写了
try/catch，捕获了异常并正常返回，事务感知不到异常，当然不会回滚。记住，事务回滚靠的是异常传播，catch住就必须在catch块里显式抛出RuntimeException，或者干脆不catch，让全局异常处理器处理。 - 方法被内部调用：同一个类里的A方法调用B方法，B上有
@Transactional，此时事务不生效。因为Spring事务是基于AOP动态代理的，内部方法调用不走代理。解决办法是把需要事务的方法拆到另一个Service类里，或者自行注入自身代理（不推荐，毕设不需要这么玩）。 - 数据库引擎不支持事务：MySQL的MyISAM引擎不支持事务。如果建表时默认引擎是MyISAM，
@Transactional加多少都没用。检查一下建表SQL，确保是ENGINE=InnoDB。
4.4 前端调试三板斧
前端页面出问题时，不要急着改代码，先开浏览器开发者工具（F12）。我复盘自己调试效率最高的流程顺序是：先看Network面板——请求有没有发出去、状态码是多少、后端返回的JSON长什么样；再看Console面板——JS有没有报错，比如常见的xxx is not defined大概率是拼写错误或者th:inline="javascript"没有启用；最后排查元素检查——如果页面结构渲染出来了但样式不对，多半是CSS类名没匹配上。
举个例子，前端页面报错说selectSeat is not defined，但是JS文件确实引入了，此时先看控制台有没有资源加载的404报错，往往就是th:src="@{/js/main.js}"写成了src="/js/main.js"，导致模板未被正确解析。这类问题一抓一个准，熟练之后几分钟就能定位。
5. 关于毕设的真心话
5.1 这几个环节千万不要省
第一，代码注释一定要写。不是写"这段代码是干嘛的"那种废话注释，而是要写"为什么这么实现"。比如在锁座的方法上写一句"使用FOR UPDATE防止并发重复购票"，答辩时你照着注释讲，思路清晰，评委也容易抓住重点。
第二，项目里一定要有一个你自己真正动脑解决的难点。哪怕它不复杂，但它必须是"你在实现过程中遇到过问题、查过资料、最终自己找到了解决方案"的功能点。选座锁座、超时取消、事务回滚，三个里挑一个好好写进论文的"核心实现"章节。有真实的解决问题过程，论文和答辩都扎实得多，这不仅是篇幅的充实，更是逻辑能力的呈现。
第三，演示数据要提前造好。不要等到答辩前才在系统里录入数据，提前录入20部电影、5个影厅、一周的场次、几十条订单记录。图片海报能好看一点就好看一点，界面视觉效果是评委对一个系统最直观的印象分，这个分不能丢。
5.2 系统的进一步扩展方向
如果完成得比较早，或者想给论文增加一点含金量，可以在现有基础上做三个难度递进的扩展：
- 引入Redis缓存热门电影列表和场次座位信息，降低数据库压力，这也是面试时高频出现的优化点。
- 增加一个简单的推荐模块，根据用户历史购票记录的电影类型偏好，在首页推荐相似影片，哪怕用最简单的标签匹配也能跑通。
- 把定时任务升级为延迟队列模式，用RabbitMQ或者Redisson延迟队列处理订单超时，比数据库轮询扫描更优雅。
说到底，个人设计和实现一个电影购票系统，是一个"麻雀虽小五脏俱全"的完整软件工程训练。用Spring Boot做主体框架，把权限、事务、定时任务、数据统计这些真实世界的常见需求亲手过一遍，拿到的不只是一份源码和一篇论文，而是一套"拿到任何业务需求都能快速拆解并落地"的基本功。这套功夫，比任何单一知识点都值钱。
如果你正在做这个题目，我的建议很简单：先理清楚表结构和状态流转，再动手写代码；遇到问题先定位再动手，不要瞎试。按这个节奏走，这个项目不会难倒你。
