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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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, ListString seatIds, Long userId) { // 1. 锁定场次记录防止并发操作 Session session sessionMapper.selectByIdForUpdate(sessionId); // 2. 查询当前场次所有已售锁定中的座位 ListString 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 UPDATEselect idselectByIdForUpdate resultTypecom.example.entity.Session SELECT * FROM session WHERE id #{id} FOR UPDATE /selectFOR 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}一定会自动加上项目上下文路径但如果自己写死了hrefcss/style.css当前URL层级一变路径就废了。第三列表循环和条件渲染的语法。th:each用于循环如果你想在循环里判断座位状态就用th:if。座位图渲染的核心代码思路如下div th:eachrow : ${seatMap} classseat-row span th:text${row.rowNum} 排 classrow-label/span div th:eachcol : ${row.cols} classseat-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:onclickselectSeat( ${row.rowNum} , ${col.colNum} ) /div /div /div第四表单提交。简单的登录注册用th:action{/user/login}配合methodpost。但选座下单这种带动态参数的我更推荐直接用JavaScript发Ajax请求。页面先渲染座位图用户点座位后在JS里维护一个已选座位数组点击提交订单按钮时把数组作为JSON传给后端。这样前端交互更灵动也避免了表单数据拼接的麻烦。3.5 项目打包部署与演示环境准备毕设最终都要部署演示这一步我踩过最大的坑是在IDEA里能跑打包成jar之后反而不行。问题的根源通常有三个。第一个是打包插件缺失。Spring Boot项目必须引入spring-boot-maven-plugin否则打出来的jar不包含内嵌Tomcat跑起来就报没有主清单属性build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId /plugin /plugins /build第二个是数据库连接配置问题。本地开发时数据库地址常常写着localhost但演示环境如果换了一台机器就要改成对应的IP。更推荐的做法是把配置外置通过启动命令传入参数覆盖java -jar cinema.jar --spring.datasource.urljdbc:mysql://xxx:3306/cinema这样就不需要为每个环境改配置再重新打包。第三个是端口占用。默认是8080端口如果演示的电脑上已经有程序占用了8080就会启动失败。启动时通过--server.port8081指定一个备用端口即可。这个小技巧我建议所有同学都记住现场演示时打开不了一定是最尴尬的情况。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上明确指定serverTimezoneAsia/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引擎不支持事务。如果建表时默认引擎是MyISAMTransactional加多少都没用。检查一下建表SQL确保是ENGINEInnoDB。4.4 前端调试三板斧前端页面出问题时不要急着改代码先开浏览器开发者工具F12。我复盘自己调试效率最高的流程顺序是先看Network面板——请求有没有发出去、状态码是多少、后端返回的JSON长什么样再看Console面板——JS有没有报错比如常见的xxx is not defined大概率是拼写错误或者th:inlinejavascript没有启用最后排查元素检查——如果页面结构渲染出来了但样式不对多半是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做主体框架把权限、事务、定时任务、数据统计这些真实世界的常见需求亲手过一遍拿到的不只是一份源码和一篇论文而是一套拿到任何业务需求都能快速拆解并落地的基本功。这套功夫比任何单一知识点都值钱。如果你正在做这个题目我的建议很简单先理清楚表结构和状态流转再动手写代码遇到问题先定位再动手不要瞎试。按这个节奏走这个项目不会难倒你。
Spring Boot电影购票系统毕设实战：数据库设计与选座锁座
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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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, ListString seatIds, Long userId) { // 1. 锁定场次记录防止并发操作 Session session sessionMapper.selectByIdForUpdate(sessionId); // 2. 查询当前场次所有已售锁定中的座位 ListString 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 UPDATEselect idselectByIdForUpdate resultTypecom.example.entity.Session SELECT * FROM session WHERE id #{id} FOR UPDATE /selectFOR 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}一定会自动加上项目上下文路径但如果自己写死了hrefcss/style.css当前URL层级一变路径就废了。第三列表循环和条件渲染的语法。th:each用于循环如果你想在循环里判断座位状态就用th:if。座位图渲染的核心代码思路如下div th:eachrow : ${seatMap} classseat-row span th:text${row.rowNum} 排 classrow-label/span div th:eachcol : ${row.cols} classseat-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:onclickselectSeat( ${row.rowNum} , ${col.colNum} ) /div /div /div第四表单提交。简单的登录注册用th:action{/user/login}配合methodpost。但选座下单这种带动态参数的我更推荐直接用JavaScript发Ajax请求。页面先渲染座位图用户点座位后在JS里维护一个已选座位数组点击提交订单按钮时把数组作为JSON传给后端。这样前端交互更灵动也避免了表单数据拼接的麻烦。3.5 项目打包部署与演示环境准备毕设最终都要部署演示这一步我踩过最大的坑是在IDEA里能跑打包成jar之后反而不行。问题的根源通常有三个。第一个是打包插件缺失。Spring Boot项目必须引入spring-boot-maven-plugin否则打出来的jar不包含内嵌Tomcat跑起来就报没有主清单属性build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId /plugin /plugins /build第二个是数据库连接配置问题。本地开发时数据库地址常常写着localhost但演示环境如果换了一台机器就要改成对应的IP。更推荐的做法是把配置外置通过启动命令传入参数覆盖java -jar cinema.jar --spring.datasource.urljdbc:mysql://xxx:3306/cinema这样就不需要为每个环境改配置再重新打包。第三个是端口占用。默认是8080端口如果演示的电脑上已经有程序占用了8080就会启动失败。启动时通过--server.port8081指定一个备用端口即可。这个小技巧我建议所有同学都记住现场演示时打开不了一定是最尴尬的情况。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上明确指定serverTimezoneAsia/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引擎不支持事务。如果建表时默认引擎是MyISAMTransactional加多少都没用。检查一下建表SQL确保是ENGINEInnoDB。4.4 前端调试三板斧前端页面出问题时不要急着改代码先开浏览器开发者工具F12。我复盘自己调试效率最高的流程顺序是先看Network面板——请求有没有发出去、状态码是多少、后端返回的JSON长什么样再看Console面板——JS有没有报错比如常见的xxx is not defined大概率是拼写错误或者th:inlinejavascript没有启用最后排查元素检查——如果页面结构渲染出来了但样式不对多半是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做主体框架把权限、事务、定时任务、数据统计这些真实世界的常见需求亲手过一遍拿到的不只是一份源码和一篇论文而是一套拿到任何业务需求都能快速拆解并落地的基本功。这套功夫比任何单一知识点都值钱。如果你正在做这个题目我的建议很简单先理清楚表结构和状态流转再动手写代码遇到问题先定位再动手不要瞎试。按这个节奏走这个项目不会难倒你。
