毕业设计选“基于Spring Boot的电影院购票管理系统”这个题目的同学我见得太多了。每年到了这个时间点总有人拿着标题来问我“源码我有但是跑不起来怎么办”“代码看不太懂答辩怎么讲”或者说“系统倒是能运行但感觉太简单了怕过不了”。这篇就按我的实际经验把这个项目的核心逻辑、技术选型、数据库设计、业务实现、排坑经验全部走一遍。不是给你贴一大堆代码让你自己琢磨而是告诉你每一块为什么这么设计、运行时会发生什么、答辩时哪里可以当作亮点讲。不管你是准备自己开发还是手里已经有了一份源码想彻底弄懂这篇文章都值得你存下来反复对照。1. 项目定位与需求拆解1.1 毕业设计的“三重任务”很多人一拿到“电影院购票管理系统”这个题目第一反应是“这不就是CRUD吗”。确实最基础的做法确实是CRUD但如果你只交了CRUD的答卷评审老师大概率会追问一句“你这个系统并发卖票会不会超卖”、“用户选完座不付钱座位锁多久”、“你的系统有什么区别于管理系统的技术点”所以我先把结论放在这里毕业设计做这个题目你真正要解决的其实不是“能不能登录、能不能下单”这种基础问题而是三个层次的任务——第一层是系统能跑第二层是核心业务有闭环第三层是至少有一个“可以拿出来单独讲10分钟”的技术点。这篇文章就是按这个层次来拆解的。1.2 功能模块怎么划分才算合理电影院购票系统按用户角色来分标准范式是两套端用户端和管理端。用户端提供的功能通常围绕“发现电影 - 选场次 - 选座位 - 下单 - 支付 - 取票/查看订单”这条完整链路。管理端则是“上架电影 - 排场次 - 维护影厅座位 - 处理订单 - 统计票房”。从多个常见源码和实际项目来看以下功能清单可以覆盖绝大多数毕业设计要求用户端注册、登录、首页电影列表、电影详情、场次选择、座位图选座、订单创建、模拟支付、订单列表与订单详情、个人信息维护。管理端管理员登录、电影管理上下映、影厅管理、场次管理排片、座位管理、订单管理、用户管理、数据统计看板。功能上不建议再加太多“花活”比如盲盒购票、会员积分、优惠券拼团这些看着丰富但实际上难讲清楚而且容易把数据库关系和状态流转搞复杂。毕设的核心是“完整、可运行、能讲明白”不是功能堆砌。1.3 用户角色与权限控制系统里至少要区分两种角色普通用户和管理员。在实现上我会用一张用户表加一个role字段来区分比如0表示普通用户1表示管理员。接口层面用拦截器或者网关统一校验登录状态再根据角色判断是否允许访问管理端接口。这里有一个很多同学会忽略的细节后端接口必须做权限校验不能只在按钮上判断。开发阶段图省事把是否管理员直接写在接口里还硬编码答辩时如果老师随手拿工具调一下你的管理接口看到普通用户的token也能返回所有用户列表这个项目的基本印象分就崩了。所以哪怕只有两个角色也要用拦截器配合一个简单的角色判断把/admin/**这类接口统一保护起来。2. 技术选型与项目搭建准备2.1 前后端分离还是服务端渲染这个题目下的源码方案大致分两类各有优劣。我列出对比你可以直接对照自己的情况选。方案技术栈优势劣势适合人群前后端分离Vue3 Element Plus Axios前端展示效果好动态交互流畅答辩有“现代感”部署麻烦跨域问题要处理项目体量大一倍前端有一定基础或者源码本身就是分离式服务端渲染Thymeleaf Bootstrap工程结构简单不用管跨域一个应用直接跑页面刷新感重交互不如前后端分离后端为主前端较弱想快速跑通我个人带过不少项目给我的建议是如果你手里的源码是前后端分离的不要轻易改成服务端渲染因为工作量完全不是一个量级如果打算自己从零开发前端基础又一般Thymeleaf 也不是不能选但考虑到现在毕设评审的审美分离式方案更容易在演示环节打动老师。2.2 后端框架与依赖版本组合“基于Spring Boot”这个题目最常见的稳定组合是Spring Boot 2.7.x MyBatis-Plus 3.5.x MySQL 8.0 Redis 6.x。为什么不是Spring Boot 3.x不是越新版越好而是Spring Boot 3.x把javax迁移到了jakarta命名空间很多网上能找到的说明书和旧帖子直接不能用同时部分低版本中间件客户端兼容性也有坑。你是在做毕业设计不是在做技术预研稳定性优先。MyBatis-Plus在这个项目里的价值很大单表CRUD基本不需要写SQL自带的分页插件能省很多事。但要注意多表关联查询比如查出订单时带出用户名和电影名还是要手写SQL不要试图用MP的Wrapper硬抱成一团。除了这些项目里还应该加JWT用jjwt或者hutool里封装的JWTUtil做无状态登录比Session方案更适合前后端分离。Lombok简化实体类代码答辩时一句“减少样板代码”就能带过。Swagger或Knife4j生成接口文档不仅平时自测方便答辩时现场打开API文档观感很加分。Hutool包含常用工具、验证码生成、UUID、日期处理等能省大量时间。2.3 Redis 在项目里到底承担什么我建议这个项目一定要用Redis但不要滥用。最合理的四个场景是存储验证码登录或注册时的图片验证码设定有效期校验后删除。存储JWT黑名单退出登录时把token标记为失效而不是单纯依赖前端删除。分布式锁用于选座下单时的并发控制防止同一座位被同时锁定或售卖。这是项目的核心亮点之一。缓存热点数据比如首页的电影列表、轮播图设置缓存5-10分钟减少数据库压力。注意缓存一致性不是本项目的重点能讲清楚失效策略就够了。有的同学会问我只用MySQL行锁能不能控制超卖能但如果你在答辩时说“用Redis分布式锁解决并发问题”老师会更感兴趣。下面我会专门讲实现。2.4 包结构与分层思想合理的后端包结构大致是这样的com.example.cinema ├── common // 通用返回结果、状态码、异常处理、常量 │ ├── Result.java │ ├── ResultCode.java │ └── GlobalExceptionHandler.java ├── config // 配置类拦截器、WebMvc、Redis、Knife4j ├── controller // 接口层接收请求、返回结果 │ ├── admin // 管理端接口 │ └── user // 用户端接口 ├── service // 业务逻辑层事务边界在这里控制 │ ├── OrderService.java │ └── impl ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 与表对应的实体类 ├── dto // 前端传递的请求对象比如选座请求 ├── vo // 返回给前端的视图对象比如订单详情VO └── utils // JWT工具等分成controller、service、mapper三层是Java后端的基本素养也是答辩时必被问到的“你如何理解分层”。这里我提前提醒service层千万不要只是个空壳一定要承载具体逻辑比如事务、并发控制、状态流转。我曾经看过有人提供的所谓源码service层什么业务都没有全是controller直接调用mapper这种代码以毕设交付标准来看经不起任何一句追问。3. 数据库设计与关键表结构3.1 核心实体关系分析电影购票系统的核心表按我常用的设计一共七张表左右就能完成闭环用户表user账号、密码、昵称、角色、创建时间。电影表movie电影名称、封面、简介、时长、上映状态、上映时间。影厅表hall影厅名称、座位行数、座位列数。场次表session关联电影和影厅记录放映时间、语言版本、价格。订单表orders关联用户和场次记录总价、状态、下单时间、支付时间。订单项表order_item一个订单包含多个座位记录场次ID、座位坐标。座位表seat一张预生成的座位清单记录场次ID、行号、列号、状态、锁定时间。这里有一个重要的设计决策到底是“基于场次动态生成座位”还是“座位表直接落地每场次的每个座位”答案是后者。因为后续所有并发控制、座位锁定状态、订单关联座位都需要数据库里有一个能加锁、能更新的“座位记录”。如果你只在前端画一个座位图下单时只存“3排5座”这个字符串那并发和状态就完全没法管理了。3.2 关键字段设计座位表是核心中的核心。建议字段如下字段名类型说明idbigint主键session_idbigint关联场次IDrow_numint排号col_numint列号statustinyint0空闲1锁定2已售lock_timedatetime锁定时间用于超时释放order_idbigint所属订单ID空表示未售versionint乐观锁版本号在场次和影厅维度要加上合理索引。特别是( session_id, row_num, col_num )这三列建议建一个唯一联合索引确保同一场次同一座位不会出现两条物理记录。订单表的状态字段建议用tinyint存枚举值0待支付1已支付2已取消3已退款4已完成。不要用字符串存各种状态因为数字比较快而且语义明确。3.3 数据库层面防止“一座二卖”用数据库层面兜底常见做法有两种。第一种是乐观锁更新座位时带上条件status 0 AND version ?更新成功表示抢到第二种是唯一索引约束在一张“已售座位记录表”里对(session_id, row_num, col_num)设唯一索引插入成功才算占座。这两种方案在毕设里我推荐选乐观锁因为代码逻辑直观讲解时容易画图说明。要注意无论用哪种方案选座操作都必须在事务里执行。先尝试锁定座位再创建订单如果创建订单失败事务回滚座位状态也要恢复。很多同学在开发时发现“座位锁定了但订单没建出来”或者“订单建了但座位还是空闲”就是事务边界没画对。4. 核心业务实现与并发控制4.1 登录鉴权与注册逻辑注册阶段密码不要直接存明文更不要用MD5。业界标准是用BCrypt加盐哈希Spring Security的BCryptPasswordEncoder可以直接复用或者用Hutool的BCrypt工具类。JWT生成的流程很简单用户登录成功后把userId和role放进token设置过期时间为2小时。这里有个小细节token过期时间不要太长也不要太短2小时是个比较稳妥的值如果做完整个项目后你觉得演示时容易超时再放开到24小时也不迟。关于“退出登录”如果你只想在前端删token那不算完整逻辑。更好的做法是把token加入Redis黑名单在黑名单过期时间上保持和token一致这样退出登录接口是有状态的非法化手段答辩提一句“这是无状态会话下的退出方案”观感完全不一样。4.2 选座下单的完整状态流转选座下单的全过程我用文字串一条链路用户进入电影详情页面选择场次。前端请求后端接口查询该场次所有座位status0的显示为空座位status1的显示锁定中status2的显示已售出。用户点击一个或多个空座位点击确认下单。后端接收到选座请求在事务内执行乐观锁更新UPDATE seat SET status 1, lock_time NOW(), order_id #{orderId}, version version 1 WHERE id #{seatId} AND status 0。更新影响行数大于0才算锁定成功。创建订单初始状态为待支付设置订单超时时间比如15分钟。前端跳转到支付页面选择“模拟支付”确认支付。支付成功后更新订单状态为已支付同时更新座位状态为已售。如果超过15分钟未支付订单被标记为取消座位状态释放为空闲。这里有两个状态变化的细节要注意第一初始锁定座位时其实还没创建订单所以order_id可以先填一个待定的占位值或者先创建订单再更新座位。我更推荐的做法是先创建一条状态为“锁定中”的订单记录拿到自增订单ID再拿着这个订单ID去更新座位锁定这样order_id字段始终有真正的订单ID可关联。第二如果第一次更新座位成功了但后面创建订单失败了整个事务会回滚没有脏数据。这就是为什么一定要在同一个Transactional方法里完成所有操作。4.3 座位超时释放的两种实现超时释放这个功能看起来简单但处理方式决定了你能不能在答辩时“加鸡腿”。我见过三种常见做法懒检查每次查座位/订单时顺便扫描当前待支付订单是否超时超时则批量释放。实现简单但超时释放不及时。定时任务Spring的Scheduled每隔30秒扫描一次超时订单执行释放。实现也简单缺陷是存在一个定时窗口期。Redis监听过期键下单时写入一个Redis key设置15分钟过期过期后触发回调释放座位。听起来很高级但实际并不可靠Redis过期回调有时延而且如果正好在回调前服务宕机消息就丢了。在毕设场景下我最推荐的做法是“定时任务 状态校验兜底”每30秒扫描一次状态为待支付且下单时间超过15分钟的订单把它们置为已取消同时把座位释放回空闲。系统并发量很小这种精度完全够用。如果想把细节点讲出来可以提一句“如果未来并发变高我们应该引入消息队列延迟方案这里用定时任务是考虑毕设的工程复杂度”。4.4 防止座位超卖的锁策略细节展开讲一下乐观锁代码因为这是整个项目最有技术深度的地方。在OrderServiceImpl里选座方法的大逻辑是Transactional(rollbackFor Exception.class) public Result createOrder(CreateOrderDTO dto) { // 1. 创建订单状态为待支付记录创建时间 Order order new Order(); order.setUserId(dto.getUserId()); order.setSessionId(dto.getSessionId()); order.setStatus(0); order.setCreateTime(LocalDateTime.now()); orderService.save(order); // 2. 尝试锁定座位 for (SeatRequest seatRequest : dto.getSeats()) { LambdaUpdateWrapperSeat wrapper new LambdaUpdateWrapper(); wrapper.eq(Seat::getId, seatRequest.getSeatId()); wrapper.eq(Seat::getStatus, 0); // 必须空闲才能锁 Seat updateSeat new Seat(); updateSeat.setStatus(1); updateSeat.setLockTime(LocalDateTime.now()); updateSeat.setOrderId(order.getId()); boolean updated seatMapper.update(updateSeat, wrapper) 0; if (!updated) { // 有一个座位锁定失败回滚这次事务 throw new RuntimeException(座位已被他人锁定请重新选择); } } // 3. 计算订单总价 BigDecimal totalPrice ...; order.setTotalPrice(totalPrice); orderService.updateById(order); return Result.success(order.getId()); }依赖MySQL行锁和乐观锁条件更新来保证原子性。这里的门槛其实是“影响行数判断”update返回0表示条件不满足座位已经被卖或被锁这样就不会出现两个人同时下单导致同一座位被卖两次。有的同学想更进一步用Redis分布式锁来锁座位。做法就是在更新数据库之前先获取一个锁String lockKey cinema:seat:lock: seatId; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 10, TimeUnit.SECONDS); if (!locked) { throw new RuntimeException(该座位正在被其他人锁定请稍后重试); }这个可以讲但你要能回答一个问题Redis分布式锁和数据库乐观锁有什么区别为什么有了数据库锁还需要Redis锁实际上这里Redis锁是为了减少数据库层的冲突和提升系统吞吐量在毕设并发量下数据库乐观锁已经足够了Redis锁是锦上添花。答辩时可以说你选择了数据库乐观锁做最终一致性保证同时用Redis锁做并发请求的前置拦截。只要你表达清楚老师不会挑毛病。4.5 支付模块的合理简化方式真实接入微信/支付宝支付需要商户号、证书、回调地址公网映射等一堆条件毕设阶段实操性价比很低也容易因资质问题卡住。因此我力推“模拟支付”方案。并不是让你在代码里直接写死“点击按钮就改状态”而是设计支付页面点击“确认支付”后请求后端支付接口后端模拟“第三方支付回调”处理订单状态变更并把支付流水号生成出来。这样做的优势是业务流程完整代码结构上保留了“回调”这一环节后续如果真要接入真实支付只需要替换回调实现。在答辩现场你甚至可以现场演示一次支付流程完全安全可控不会出现资费风险。5. 从源码到可运行再到二开加点5.1 拿到源码后的运行三步走不管是自己写的还是拿到手的源码跑起来基本按三步走否则会浪费大量时间。第一步准备环境安装JDK 1.8或11、MySQL 8.0、Redis、Maven。JDK版本尽量和源码保持一致不要盲目装最新的。把数据库SQL脚本导入到MySQL里确认表结构和初始管理员账号都存在正常来说会有一张admin表或user表里混着管理员数据。第二步修改application.yml把数据库账号密码、Redis地址改成你自己的。这是漏掉最多的一步网上很多同学私信我说“启动报错Data source rejected establishment of connection”大概率就是这里没改。第三步同时启动Redis和MySQL再运行主启动类。前端如果是Vue项目需要先npm install再npm run serve如果是Thymeleaf项目直接访问后端端口就好。5.2 核心请求流转走读为了让自己真正能讲清楚系统我建议你花一个小时跟一条链路就选“用户查询电影列表”这个最简单的接口。流程是前端发送GET请求/api/movie/list- 后端Controller接收参数 - 调用Service层 - Service调用Mapper - Mapper通过MyBatis-Plus查询数据库 - 数据逐层装填成VO - 返回给前端。你不需要背代码但要在纸上画出这条链路能把Controller、Service、Mapper分别做了什么说清楚。答辩被问“你自己做过什么”时能流畅画出这种调用链比背十页PPT有用得多。5.3 低成本高回报的“加亮点”思路如果本身项目“平平无奇”想在答辩前快速补几个亮点我可以分享三个性价比极高的方向数据统计看板管理员首页统计今日票房、总订单数、热门电影Top5用ECharts画柱状图和饼图。技术上就是几条SQL加一个聚合查询视觉冲击力非常强。Excel导出订单列表加一个“导出Excel”按钮用EasyExcel或者Hutool的ExcelWriter实现。功能实用代码量少演示效果好。参数校验与全局异常处理所有入参用注解校验业务异常用自定义RestControllerAdvice统一返回。这在代码规范层面是一个相当加分的项。不用贪多选其中一个补进去就行。补完之后你要能独立说出这个模块的设计思路这比什么都重要。6. 高频问题排查与避坑汇总6.1 环境级问题速查问题表现原因解决方案启动报“Port 8080 was already in use”端口被占用关闭占用项目或修改server.port报“Unknown database cinema”数据库没建或名字不对执行CREATE DATABASE cinema DEFAULT CHARACTER SET utf8mb4;后导入SQL报“Access denied for user root”数据库密码错误核对application.yml中的用户名密码启动报Redis连接超时Redis没启动或地址错误本地启动Redis检查端口6379Maven依赖下载不下来仓库网络问题换成国内镜像仓库配置环境问题是源码类项目里占比最高的问题我接触的求助里起码有一半卡在这一步。6.2 业务逻辑级问题常见的业务bug有这么几个座位明明选了但下单失败要检查事务回滚后座位状态是否被正确还原订单显示待支付但是座位已经显示已售要检查支付成功后是否忘了更新座位状态用户退出登录后token还能用要检查拦截器是否真的读取了Redis黑名单。还有一个典型问题前后端分离项目跨域报错。解决方式是在后端配置一个实现了WebMvcConfigurer的配置类允许http://localhost:5173这类本地开发地址跨域访问。如果生产环境部署在同一域记得把跨域配置关掉或者限定域名。6.3 演示与答辩层面的避坑建议演示环节的状态数据一定要提前造好而不是现场注册新用户再一整套走下来。准备时至少要有一个管理员账号一个普通用户账号三到五部电影数据当前场次若干条而座位图里最好既有空闲、锁定、已售三种状态这样演示时能很直观地说明状态变化。还要准备几张测试截图首页列表、选座页面、订单支付页面、管理端数据看板万一现场网速不好或前端启动失败你还能用截图把流程讲完。答辩讲解时我建议你把时间比重安排成技术架构讲两分钟数据库设计讲三分钟核心业务选座、锁座位、超时释放讲五分钟亮点模块讲三分钟。千万别花五分钟介绍用户登录这种没人有兴趣的功能。6.4 我踩过的一些坑提前给你排掉第一MyBatis-Plus的save方法返回的id默认会回填到实体主键上前提是数据库主键是自增且实体类标注TableId(type IdType.AUTO)。如果你发现拿不到自增ID第一时间检查这个注解。第二时间字段在前端展示差8小时通常是时区问题。数据库连接串要加serverTimezoneAsia/Shanghai实体用LocalDateTime前端格式化用yyyy-MM-dd HH:mm:ss三处统一。这个问题我见过太多次了。第三锁表容易忽略索引。数据库里对订单表按session_id和status分别建索引不然“扫描超时订单”这个定时任务在数据量稍大时会变得比较慢。毕设数据量小这可能无感但讲出来会显得你想到了这一层。最后再分享一个个人建议不要把“毕设源码”当成一个保密的东西自己闷头看完就完事了。你会遇到很多问题主动把报错信息、关键截图整理出来和同学互相踩坑或者在网上搜索“Spring Boot MyBatis-Plus 电影院选座”之类的关键词组合很多问题真的不是只有你一个人遇到。你在理解系统过程中写出来的笔记最后稍微整理一下就是一份很好的说明文档答辩时讲起来也比临时抱佛脚自然得多。说到这这篇关于电影院购票管理系统的核心拆解和排坑记录就全部讲完了。我见过不少人从“只会跑源码”到“能讲清整个系统”只花了一周时间关键就在于是不是真的沿着购票链路把每一环代码都打开看了、改了一遍。等你把选座、锁座位、超时释放这几块彻底吃透这个题目你就不仅是在交作业而是真的做成一个能放进简历、拿来面试讲的完整项目了。
毕业设计选“基于Spring Boot的电影院购票管理系统”这个题目的同学我见得太多了。每年到了这个时间点总有人拿着标题来问我“源码我有但是跑不起来怎么办”“代码看不太懂答辩怎么讲”或者说“系统倒是能运行但感觉太简单了怕过不了”。这篇就按我的实际经验把这个项目的核心逻辑、技术选型、数据库设计、业务实现、排坑经验全部走一遍。不是给你贴一大堆代码让你自己琢磨而是告诉你每一块为什么这么设计、运行时会发生什么、答辩时哪里可以当作亮点讲。不管你是准备自己开发还是手里已经有了一份源码想彻底弄懂这篇文章都值得你存下来反复对照。1. 项目定位与需求拆解1.1 毕业设计的“三重任务”很多人一拿到“电影院购票管理系统”这个题目第一反应是“这不就是CRUD吗”。确实最基础的做法确实是CRUD但如果你只交了CRUD的答卷评审老师大概率会追问一句“你这个系统并发卖票会不会超卖”、“用户选完座不付钱座位锁多久”、“你的系统有什么区别于管理系统的技术点”所以我先把结论放在这里毕业设计做这个题目你真正要解决的其实不是“能不能登录、能不能下单”这种基础问题而是三个层次的任务——第一层是系统能跑第二层是核心业务有闭环第三层是至少有一个“可以拿出来单独讲10分钟”的技术点。这篇文章就是按这个层次来拆解的。1.2 功能模块怎么划分才算合理电影院购票系统按用户角色来分标准范式是两套端用户端和管理端。用户端提供的功能通常围绕“发现电影 - 选场次 - 选座位 - 下单 - 支付 - 取票/查看订单”这条完整链路。管理端则是“上架电影 - 排场次 - 维护影厅座位 - 处理订单 - 统计票房”。从多个常见源码和实际项目来看以下功能清单可以覆盖绝大多数毕业设计要求用户端注册、登录、首页电影列表、电影详情、场次选择、座位图选座、订单创建、模拟支付、订单列表与订单详情、个人信息维护。管理端管理员登录、电影管理上下映、影厅管理、场次管理排片、座位管理、订单管理、用户管理、数据统计看板。功能上不建议再加太多“花活”比如盲盒购票、会员积分、优惠券拼团这些看着丰富但实际上难讲清楚而且容易把数据库关系和状态流转搞复杂。毕设的核心是“完整、可运行、能讲明白”不是功能堆砌。1.3 用户角色与权限控制系统里至少要区分两种角色普通用户和管理员。在实现上我会用一张用户表加一个role字段来区分比如0表示普通用户1表示管理员。接口层面用拦截器或者网关统一校验登录状态再根据角色判断是否允许访问管理端接口。这里有一个很多同学会忽略的细节后端接口必须做权限校验不能只在按钮上判断。开发阶段图省事把是否管理员直接写在接口里还硬编码答辩时如果老师随手拿工具调一下你的管理接口看到普通用户的token也能返回所有用户列表这个项目的基本印象分就崩了。所以哪怕只有两个角色也要用拦截器配合一个简单的角色判断把/admin/**这类接口统一保护起来。2. 技术选型与项目搭建准备2.1 前后端分离还是服务端渲染这个题目下的源码方案大致分两类各有优劣。我列出对比你可以直接对照自己的情况选。方案技术栈优势劣势适合人群前后端分离Vue3 Element Plus Axios前端展示效果好动态交互流畅答辩有“现代感”部署麻烦跨域问题要处理项目体量大一倍前端有一定基础或者源码本身就是分离式服务端渲染Thymeleaf Bootstrap工程结构简单不用管跨域一个应用直接跑页面刷新感重交互不如前后端分离后端为主前端较弱想快速跑通我个人带过不少项目给我的建议是如果你手里的源码是前后端分离的不要轻易改成服务端渲染因为工作量完全不是一个量级如果打算自己从零开发前端基础又一般Thymeleaf 也不是不能选但考虑到现在毕设评审的审美分离式方案更容易在演示环节打动老师。2.2 后端框架与依赖版本组合“基于Spring Boot”这个题目最常见的稳定组合是Spring Boot 2.7.x MyBatis-Plus 3.5.x MySQL 8.0 Redis 6.x。为什么不是Spring Boot 3.x不是越新版越好而是Spring Boot 3.x把javax迁移到了jakarta命名空间很多网上能找到的说明书和旧帖子直接不能用同时部分低版本中间件客户端兼容性也有坑。你是在做毕业设计不是在做技术预研稳定性优先。MyBatis-Plus在这个项目里的价值很大单表CRUD基本不需要写SQL自带的分页插件能省很多事。但要注意多表关联查询比如查出订单时带出用户名和电影名还是要手写SQL不要试图用MP的Wrapper硬抱成一团。除了这些项目里还应该加JWT用jjwt或者hutool里封装的JWTUtil做无状态登录比Session方案更适合前后端分离。Lombok简化实体类代码答辩时一句“减少样板代码”就能带过。Swagger或Knife4j生成接口文档不仅平时自测方便答辩时现场打开API文档观感很加分。Hutool包含常用工具、验证码生成、UUID、日期处理等能省大量时间。2.3 Redis 在项目里到底承担什么我建议这个项目一定要用Redis但不要滥用。最合理的四个场景是存储验证码登录或注册时的图片验证码设定有效期校验后删除。存储JWT黑名单退出登录时把token标记为失效而不是单纯依赖前端删除。分布式锁用于选座下单时的并发控制防止同一座位被同时锁定或售卖。这是项目的核心亮点之一。缓存热点数据比如首页的电影列表、轮播图设置缓存5-10分钟减少数据库压力。注意缓存一致性不是本项目的重点能讲清楚失效策略就够了。有的同学会问我只用MySQL行锁能不能控制超卖能但如果你在答辩时说“用Redis分布式锁解决并发问题”老师会更感兴趣。下面我会专门讲实现。2.4 包结构与分层思想合理的后端包结构大致是这样的com.example.cinema ├── common // 通用返回结果、状态码、异常处理、常量 │ ├── Result.java │ ├── ResultCode.java │ └── GlobalExceptionHandler.java ├── config // 配置类拦截器、WebMvc、Redis、Knife4j ├── controller // 接口层接收请求、返回结果 │ ├── admin // 管理端接口 │ └── user // 用户端接口 ├── service // 业务逻辑层事务边界在这里控制 │ ├── OrderService.java │ └── impl ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 与表对应的实体类 ├── dto // 前端传递的请求对象比如选座请求 ├── vo // 返回给前端的视图对象比如订单详情VO └── utils // JWT工具等分成controller、service、mapper三层是Java后端的基本素养也是答辩时必被问到的“你如何理解分层”。这里我提前提醒service层千万不要只是个空壳一定要承载具体逻辑比如事务、并发控制、状态流转。我曾经看过有人提供的所谓源码service层什么业务都没有全是controller直接调用mapper这种代码以毕设交付标准来看经不起任何一句追问。3. 数据库设计与关键表结构3.1 核心实体关系分析电影购票系统的核心表按我常用的设计一共七张表左右就能完成闭环用户表user账号、密码、昵称、角色、创建时间。电影表movie电影名称、封面、简介、时长、上映状态、上映时间。影厅表hall影厅名称、座位行数、座位列数。场次表session关联电影和影厅记录放映时间、语言版本、价格。订单表orders关联用户和场次记录总价、状态、下单时间、支付时间。订单项表order_item一个订单包含多个座位记录场次ID、座位坐标。座位表seat一张预生成的座位清单记录场次ID、行号、列号、状态、锁定时间。这里有一个重要的设计决策到底是“基于场次动态生成座位”还是“座位表直接落地每场次的每个座位”答案是后者。因为后续所有并发控制、座位锁定状态、订单关联座位都需要数据库里有一个能加锁、能更新的“座位记录”。如果你只在前端画一个座位图下单时只存“3排5座”这个字符串那并发和状态就完全没法管理了。3.2 关键字段设计座位表是核心中的核心。建议字段如下字段名类型说明idbigint主键session_idbigint关联场次IDrow_numint排号col_numint列号statustinyint0空闲1锁定2已售lock_timedatetime锁定时间用于超时释放order_idbigint所属订单ID空表示未售versionint乐观锁版本号在场次和影厅维度要加上合理索引。特别是( session_id, row_num, col_num )这三列建议建一个唯一联合索引确保同一场次同一座位不会出现两条物理记录。订单表的状态字段建议用tinyint存枚举值0待支付1已支付2已取消3已退款4已完成。不要用字符串存各种状态因为数字比较快而且语义明确。3.3 数据库层面防止“一座二卖”用数据库层面兜底常见做法有两种。第一种是乐观锁更新座位时带上条件status 0 AND version ?更新成功表示抢到第二种是唯一索引约束在一张“已售座位记录表”里对(session_id, row_num, col_num)设唯一索引插入成功才算占座。这两种方案在毕设里我推荐选乐观锁因为代码逻辑直观讲解时容易画图说明。要注意无论用哪种方案选座操作都必须在事务里执行。先尝试锁定座位再创建订单如果创建订单失败事务回滚座位状态也要恢复。很多同学在开发时发现“座位锁定了但订单没建出来”或者“订单建了但座位还是空闲”就是事务边界没画对。4. 核心业务实现与并发控制4.1 登录鉴权与注册逻辑注册阶段密码不要直接存明文更不要用MD5。业界标准是用BCrypt加盐哈希Spring Security的BCryptPasswordEncoder可以直接复用或者用Hutool的BCrypt工具类。JWT生成的流程很简单用户登录成功后把userId和role放进token设置过期时间为2小时。这里有个小细节token过期时间不要太长也不要太短2小时是个比较稳妥的值如果做完整个项目后你觉得演示时容易超时再放开到24小时也不迟。关于“退出登录”如果你只想在前端删token那不算完整逻辑。更好的做法是把token加入Redis黑名单在黑名单过期时间上保持和token一致这样退出登录接口是有状态的非法化手段答辩提一句“这是无状态会话下的退出方案”观感完全不一样。4.2 选座下单的完整状态流转选座下单的全过程我用文字串一条链路用户进入电影详情页面选择场次。前端请求后端接口查询该场次所有座位status0的显示为空座位status1的显示锁定中status2的显示已售出。用户点击一个或多个空座位点击确认下单。后端接收到选座请求在事务内执行乐观锁更新UPDATE seat SET status 1, lock_time NOW(), order_id #{orderId}, version version 1 WHERE id #{seatId} AND status 0。更新影响行数大于0才算锁定成功。创建订单初始状态为待支付设置订单超时时间比如15分钟。前端跳转到支付页面选择“模拟支付”确认支付。支付成功后更新订单状态为已支付同时更新座位状态为已售。如果超过15分钟未支付订单被标记为取消座位状态释放为空闲。这里有两个状态变化的细节要注意第一初始锁定座位时其实还没创建订单所以order_id可以先填一个待定的占位值或者先创建订单再更新座位。我更推荐的做法是先创建一条状态为“锁定中”的订单记录拿到自增订单ID再拿着这个订单ID去更新座位锁定这样order_id字段始终有真正的订单ID可关联。第二如果第一次更新座位成功了但后面创建订单失败了整个事务会回滚没有脏数据。这就是为什么一定要在同一个Transactional方法里完成所有操作。4.3 座位超时释放的两种实现超时释放这个功能看起来简单但处理方式决定了你能不能在答辩时“加鸡腿”。我见过三种常见做法懒检查每次查座位/订单时顺便扫描当前待支付订单是否超时超时则批量释放。实现简单但超时释放不及时。定时任务Spring的Scheduled每隔30秒扫描一次超时订单执行释放。实现也简单缺陷是存在一个定时窗口期。Redis监听过期键下单时写入一个Redis key设置15分钟过期过期后触发回调释放座位。听起来很高级但实际并不可靠Redis过期回调有时延而且如果正好在回调前服务宕机消息就丢了。在毕设场景下我最推荐的做法是“定时任务 状态校验兜底”每30秒扫描一次状态为待支付且下单时间超过15分钟的订单把它们置为已取消同时把座位释放回空闲。系统并发量很小这种精度完全够用。如果想把细节点讲出来可以提一句“如果未来并发变高我们应该引入消息队列延迟方案这里用定时任务是考虑毕设的工程复杂度”。4.4 防止座位超卖的锁策略细节展开讲一下乐观锁代码因为这是整个项目最有技术深度的地方。在OrderServiceImpl里选座方法的大逻辑是Transactional(rollbackFor Exception.class) public Result createOrder(CreateOrderDTO dto) { // 1. 创建订单状态为待支付记录创建时间 Order order new Order(); order.setUserId(dto.getUserId()); order.setSessionId(dto.getSessionId()); order.setStatus(0); order.setCreateTime(LocalDateTime.now()); orderService.save(order); // 2. 尝试锁定座位 for (SeatRequest seatRequest : dto.getSeats()) { LambdaUpdateWrapperSeat wrapper new LambdaUpdateWrapper(); wrapper.eq(Seat::getId, seatRequest.getSeatId()); wrapper.eq(Seat::getStatus, 0); // 必须空闲才能锁 Seat updateSeat new Seat(); updateSeat.setStatus(1); updateSeat.setLockTime(LocalDateTime.now()); updateSeat.setOrderId(order.getId()); boolean updated seatMapper.update(updateSeat, wrapper) 0; if (!updated) { // 有一个座位锁定失败回滚这次事务 throw new RuntimeException(座位已被他人锁定请重新选择); } } // 3. 计算订单总价 BigDecimal totalPrice ...; order.setTotalPrice(totalPrice); orderService.updateById(order); return Result.success(order.getId()); }依赖MySQL行锁和乐观锁条件更新来保证原子性。这里的门槛其实是“影响行数判断”update返回0表示条件不满足座位已经被卖或被锁这样就不会出现两个人同时下单导致同一座位被卖两次。有的同学想更进一步用Redis分布式锁来锁座位。做法就是在更新数据库之前先获取一个锁String lockKey cinema:seat:lock: seatId; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 10, TimeUnit.SECONDS); if (!locked) { throw new RuntimeException(该座位正在被其他人锁定请稍后重试); }这个可以讲但你要能回答一个问题Redis分布式锁和数据库乐观锁有什么区别为什么有了数据库锁还需要Redis锁实际上这里Redis锁是为了减少数据库层的冲突和提升系统吞吐量在毕设并发量下数据库乐观锁已经足够了Redis锁是锦上添花。答辩时可以说你选择了数据库乐观锁做最终一致性保证同时用Redis锁做并发请求的前置拦截。只要你表达清楚老师不会挑毛病。4.5 支付模块的合理简化方式真实接入微信/支付宝支付需要商户号、证书、回调地址公网映射等一堆条件毕设阶段实操性价比很低也容易因资质问题卡住。因此我力推“模拟支付”方案。并不是让你在代码里直接写死“点击按钮就改状态”而是设计支付页面点击“确认支付”后请求后端支付接口后端模拟“第三方支付回调”处理订单状态变更并把支付流水号生成出来。这样做的优势是业务流程完整代码结构上保留了“回调”这一环节后续如果真要接入真实支付只需要替换回调实现。在答辩现场你甚至可以现场演示一次支付流程完全安全可控不会出现资费风险。5. 从源码到可运行再到二开加点5.1 拿到源码后的运行三步走不管是自己写的还是拿到手的源码跑起来基本按三步走否则会浪费大量时间。第一步准备环境安装JDK 1.8或11、MySQL 8.0、Redis、Maven。JDK版本尽量和源码保持一致不要盲目装最新的。把数据库SQL脚本导入到MySQL里确认表结构和初始管理员账号都存在正常来说会有一张admin表或user表里混着管理员数据。第二步修改application.yml把数据库账号密码、Redis地址改成你自己的。这是漏掉最多的一步网上很多同学私信我说“启动报错Data source rejected establishment of connection”大概率就是这里没改。第三步同时启动Redis和MySQL再运行主启动类。前端如果是Vue项目需要先npm install再npm run serve如果是Thymeleaf项目直接访问后端端口就好。5.2 核心请求流转走读为了让自己真正能讲清楚系统我建议你花一个小时跟一条链路就选“用户查询电影列表”这个最简单的接口。流程是前端发送GET请求/api/movie/list- 后端Controller接收参数 - 调用Service层 - Service调用Mapper - Mapper通过MyBatis-Plus查询数据库 - 数据逐层装填成VO - 返回给前端。你不需要背代码但要在纸上画出这条链路能把Controller、Service、Mapper分别做了什么说清楚。答辩被问“你自己做过什么”时能流畅画出这种调用链比背十页PPT有用得多。5.3 低成本高回报的“加亮点”思路如果本身项目“平平无奇”想在答辩前快速补几个亮点我可以分享三个性价比极高的方向数据统计看板管理员首页统计今日票房、总订单数、热门电影Top5用ECharts画柱状图和饼图。技术上就是几条SQL加一个聚合查询视觉冲击力非常强。Excel导出订单列表加一个“导出Excel”按钮用EasyExcel或者Hutool的ExcelWriter实现。功能实用代码量少演示效果好。参数校验与全局异常处理所有入参用注解校验业务异常用自定义RestControllerAdvice统一返回。这在代码规范层面是一个相当加分的项。不用贪多选其中一个补进去就行。补完之后你要能独立说出这个模块的设计思路这比什么都重要。6. 高频问题排查与避坑汇总6.1 环境级问题速查问题表现原因解决方案启动报“Port 8080 was already in use”端口被占用关闭占用项目或修改server.port报“Unknown database cinema”数据库没建或名字不对执行CREATE DATABASE cinema DEFAULT CHARACTER SET utf8mb4;后导入SQL报“Access denied for user root”数据库密码错误核对application.yml中的用户名密码启动报Redis连接超时Redis没启动或地址错误本地启动Redis检查端口6379Maven依赖下载不下来仓库网络问题换成国内镜像仓库配置环境问题是源码类项目里占比最高的问题我接触的求助里起码有一半卡在这一步。6.2 业务逻辑级问题常见的业务bug有这么几个座位明明选了但下单失败要检查事务回滚后座位状态是否被正确还原订单显示待支付但是座位已经显示已售要检查支付成功后是否忘了更新座位状态用户退出登录后token还能用要检查拦截器是否真的读取了Redis黑名单。还有一个典型问题前后端分离项目跨域报错。解决方式是在后端配置一个实现了WebMvcConfigurer的配置类允许http://localhost:5173这类本地开发地址跨域访问。如果生产环境部署在同一域记得把跨域配置关掉或者限定域名。6.3 演示与答辩层面的避坑建议演示环节的状态数据一定要提前造好而不是现场注册新用户再一整套走下来。准备时至少要有一个管理员账号一个普通用户账号三到五部电影数据当前场次若干条而座位图里最好既有空闲、锁定、已售三种状态这样演示时能很直观地说明状态变化。还要准备几张测试截图首页列表、选座页面、订单支付页面、管理端数据看板万一现场网速不好或前端启动失败你还能用截图把流程讲完。答辩讲解时我建议你把时间比重安排成技术架构讲两分钟数据库设计讲三分钟核心业务选座、锁座位、超时释放讲五分钟亮点模块讲三分钟。千万别花五分钟介绍用户登录这种没人有兴趣的功能。6.4 我踩过的一些坑提前给你排掉第一MyBatis-Plus的save方法返回的id默认会回填到实体主键上前提是数据库主键是自增且实体类标注TableId(type IdType.AUTO)。如果你发现拿不到自增ID第一时间检查这个注解。第二时间字段在前端展示差8小时通常是时区问题。数据库连接串要加serverTimezoneAsia/Shanghai实体用LocalDateTime前端格式化用yyyy-MM-dd HH:mm:ss三处统一。这个问题我见过太多次了。第三锁表容易忽略索引。数据库里对订单表按session_id和status分别建索引不然“扫描超时订单”这个定时任务在数据量稍大时会变得比较慢。毕设数据量小这可能无感但讲出来会显得你想到了这一层。最后再分享一个个人建议不要把“毕设源码”当成一个保密的东西自己闷头看完就完事了。你会遇到很多问题主动把报错信息、关键截图整理出来和同学互相踩坑或者在网上搜索“Spring Boot MyBatis-Plus 电影院选座”之类的关键词组合很多问题真的不是只有你一个人遇到。你在理解系统过程中写出来的笔记最后稍微整理一下就是一份很好的说明文档答辩时讲起来也比临时抱佛脚自然得多。说到这这篇关于电影院购票管理系统的核心拆解和排坑记录就全部讲完了。我见过不少人从“只会跑源码”到“能讲清整个系统”只花了一周时间关键就在于是不是真的沿着购票链路把每一环代码都打开看了、改了一遍。等你把选座、锁座位、超时释放这几块彻底吃透这个题目你就不仅是在交作业而是真的做成一个能放进简历、拿来面试讲的完整项目了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
