又是一年毕业季，后台收到好多私信问Java毕设怎么选题。沟通下来，很多人卡在同一个地方：既要技术栈拿得出手、能写进简历，又担心工作量太大做不完，最后还要能顺利通过答辩。今天聊的这个“基于SpringBoot的前后端分离电影购票系统”，算是这几年里我见过最“稳”的选题之一。它不是那种烂大街的管理系统，又比电商、社交这类项目好驾驭得多，技术点覆盖得非常典型。
这个项目说白了就是模拟猫眼、淘票票的购票流程，前端用Vue这类框架做页面，后端用SpringBoot提供接口，两边通过JSON数据交互。你可以实现浏览电影、查看场次、选座、下单支付（模拟）、出票，以及后台的影片管理、场次安排、订单统计这些功能。适合Java基础还行、想通过一个完整项目把SpringBoot、MyBatis、Redis、JWT这些知识点串起来的人，也适合拿它当毕业设计直接交付。
我后面所有内容都会基于这个项目的实际开发过程来写，包括为什么这么设计、具体怎么实现、哪些地方容易踩坑，以及答辩时老师大概率会问什么。如果你正在为选题发愁，或者已经确定做这个但没理清头绪，这篇内容应该能帮你省下不少时间。
1. 为什么电影购票系统是毕设里的“稳赢”选题——选题逻辑与前期调研
1.1 从技术栈匹配度看选题：SpringBoot+前后端分离正是行业标配
先说结论：电影购票系统这个业务场景，几乎是为SpringBoot+前后端分离这套技术栈量身定制的。原因有三点。
第一，业务链路完整且有深度。它不是一个简单的增删改查，而是包含了“浏览影片→查看场次→选座→锁定座位→生成订单→模拟支付→出票→检票”这样一条完整的主链路。每多一个环节，就意味着多一次状态流转、多一张数据表、多一组接口设计，这对体现你对业务的理解非常有帮助。很多同学做的系统之所以被答辩老师质疑“太简单”，就是因为业务只有一层，没有体现“流程”和“状态”。
第二，技术难点可控。相比秒杀系统要处理超高并发，或者电商系统要对接真实支付、物流，电影购票的并发量级没那么夸张，但又有“选座锁座”这种天然的并发问题可以聊。你能在论文和答辩里讲清楚“如何防止一票多卖”，这就是一个不错的亮点，而且实现起来比你想的简单，后面我会细说。
第三，前后端分离的优势能充分体现。因为页面是动态数据驱动的——同一个页面组件要根据不同影片ID渲染不同信息，所以天然适合用接口驱动前端渲染。你可以在项目里名正言顺地用上Vue Router做路由、Axios做请求、Vite或Webpack做构建，这些都是在简历上能写一行、面试时能聊两句的东西。
1.2 功能规模与工作量预估：一个学生能驾驭的“小而美”系统
很多人一看“前后端分离”就觉得工程量大，其实拆开看，工作量完全在可控范围内。我按正常开发速度给你算一笔账。
如果做两个端——用户端和管理端，核心功能我建议这样划分：
用户端：注册登录、影片列表与详情、场次查询、选座、订单确认与支付（可模拟）、订单列表与详情、个人中心。
管理端：管理员登录、影片管理、场次管理、影厅与座位管理、订单管理、基础数据统计（如每日票房曲线）。
这套功能如果代码结构清晰，后端大概20到25张表（含中间表），接口数量在40到60个之间。按每天写5到8个接口的进度，工作量基本在两周到三周。前端Vue部分，如果直接用Element Plus这类组件库搭后台，再用Vant或原生CSS写用户端，再多一周也够了。加上写文档和准备答辩，一个半月的准备周期是足够的。
但这里有个提醒：我不建议功能做得太泛。比如你要接真实支付（支付宝/微信），反而不适合毕设——申请商户号的门槛、回调逻辑的复杂度，都不适合在有限时间内搞定。模拟支付就很好，在答辩时跟老师说清楚“真实支付的下一步接入流程”即可。类似的，像电影资讯、评论评分这类锦上添花的功能，如果时间不充裕，直接砍掉，别让边缘功能拖累核心链路。
1.3 毕设答辩的隐藏加分点：从需求分析到落地全链路
毕设评分通常看的不只是“东西能不能跑”，更多的是你有没有“完整走完一个项目的生命周期”。电影购票系统的好处在于，它的需求分析阶段有太多可写的素材。
比如，你可以做用例图、ER图、流程图。这些图在论文里非常出效果，而且都有现成的业务逻辑支撑。用户从“选座”到“生成订单”，中间经历什么状态？订单有“待支付”“已支付”“已取消”几种状态？这些在你设计数据库和接口的时候就已经确定了，画图只是把思路可视化而已。
再比如，你可以在这套业务上自然地引出一些“听起来很专业”的话题：座位的状态怎么在“可用/锁定/已售”之间流转？多个用户同时选同一排座位怎么办？用户下单后一直不支付，锁定的座位什么时候释放？这些既是技术点，也是答辩时老师最喜欢追问的深度问题。提前把这些问题想明白，比到时候支支吾吾强得多。
2. 系统整体设计与技术选型——架构搭建的第一步
2.1 前后端分离架构怎么理解：一个馆子两个后厨
给还不熟悉前后端分离的同学打个比方。传统单体开发，相当于一个小饭馆，前台服务员和后面炒菜的师傅在同一个屋里，菜单上写什么，后厨就得照着炒什么，改个菜谱得全店一起动。而前后端分离，相当于把饭馆拆成了“点餐前台”和“中央厨房”两个独立门店，两者之间通过一份“标准菜单”（也就是接口文档）来协作。前台可以随时换装修、改菜单样式，只要菜品编号不变，后厨照样出菜；后厨也可以换设备、升级流程，只要出菜标准不变，前台不需要跟着改。
放到这个项目里，前端是一套独立工程，跑在8080或5173这类端口上，负责渲染页面和交互；后端是另一套独立工程，跑在8080端口上，只提供JSON接口。前端通过HTTP请求拿到数据，自己决定怎么展示。两边只认接口约定，不直接操作对方的文件。
这种架构的实战价值在于团队协作和部署灵活，但对毕设来说，最大的意义在于：你能把“前端展示逻辑”和“后端业务逻辑”的职责边界分得很清楚，代码结构自然就清晰了。
2.2 技术栈清单与版本选择：JDK 8还是17？
这是很多新手前期就会卡住的地方，因为网上教程版本五花八门。我给一套目前比较稳妥的组合，照着配基本不会出大问题：
后端：JDK 8或11，Spring Boot 2.7.x，MyBatis-Plus 3.5.x，MySQL 5.7或8.0，Redis（用于验证码缓存和座位锁定），JWT（用于登录鉴权），Maven做依赖管理，打包成JAR。
前端：Vue 2或Vue 3 + Element Plus + Axios + Vue Router。如果你对Vue不熟，Vue 3的生态更主流，但Vue 2的中文教程更多，选哪个都行，关键是前后端接口对接逻辑要理清。
这中间有一个最常见的坑：很多人直接下载了Spring Boot 3.x，配合JDK 8，结果启动直接报错。因为Spring Boot 3.x强制要求JDK 17及以上，同时javax.相关的包名改成了jakarta.，很多老教程的写法在Spring Boot 3里就废了。如果你是第一次做项目，图省心，就用Spring Boot 2.7.x配JDK 8或11，问题最少。如果你非要上Spring Boot 3，记得把JDK升到17，同时检查所有依赖包的版本兼容性，不要混着用。
2.3 数据库设计：几张大表撑起一个影城
数据库设计是整个项目的根基。表设计好了，后面的接口、前端、论文都好写；设计不好，后期改表结构会改到怀疑人生。我按核心链路给你梳理一遍需要哪些表，以及每张表的职责。
影片表（film）：存电影标题、海报URL、导演、主演、简介、时长、上映状态。
影厅表（hall）：存影厅名称、座位排数、每排座位数。
场次表（session）：存哪个影厅在什么时间放映哪部电影，票价多少。这里注意，场次跟“日期+时间段”绑定，同一影厅在同一个时间段只能有一个场次，这是个重要的唯一性约束。
座位表（seat）：存每个影厅有哪些座位，通常用“排号+列号”标识，比如3排5座。座位属于物理座位，不针对某一场次。
场次座位表（session_seat）：这是核心表，存某一个具体场次中每个座位的状态——是否可用、是否已锁定、是否已售出。为什么要单独一张表而不是直接在座位表上加状态？因为同一个座位在不同场次里的状态是独立的，1号厅3排5座在上午10点那场可能已经被买了，但在下午2点那场还是空的。
订单表（orders）：存用户下的单，关联场次、总价、下单时间、订单状态（待支付/已支付/已取消）。
订单明细表（order_item）：一个订单可能买了多张票，每张票对应一个场次座位。这里用来记录每个座位对应的情况。
用户表（user）：存账号、密码（要加密存储，别用明文）、昵称、手机号、角色（普通用户/管理员）。
这8张表是核心骨架，像验证码表、操作日志表这类辅助表按需添加。设计时遵循一个原则：能用外键逻辑关联就用逻辑关联（也就是在代码里维护关联关系），不一定非要在数据库里建物理外键。很多企业项目反而不爱用物理外键，因为影响插入性能和删除灵活性，这个习惯在毕设里反而是加分项，老师问起来你能说出理由。
2.4 接口设计规范：RESTful风格与统一返回体
前后端分离项目里，接口就是前后端之间的“合同”，接口设计得好不好，直接影响联调效率。建议用RESTful风格设计URL：用名词表示资源，用HTTP方法表示操作。比如GET /api/films 表示获取影片列表，POST /api/orders 表示创建订单，GET /api/orders/{id} 表示获取某个订单详情。
与此同时，一定要设计一个统一的返回体。别让每个接口返回的JSON结构都不一样，不然前端处理起来会非常痛苦。我常用的统一返回结构是这样的：
{ "code": 200, "message": "操作成功", "data": { ... } }code表示业务状态码，200是成功，401表示未登录或登录过期，500表示服务器异常。message是给前端提示文案用的，data才是真正的业务数据。前端在Axios的响应拦截器里统一判断code，如果是401就跳登录页，如果是500就弹错误提示，这样每个接口的异常处理逻辑只需要写一遍。
统一返回体还有一个好处：遇到业务异常时，不需要通过HTTP状态码来表达，而是返回code=500之类的业务码加具体的message。因为HTTP状态码语义有限，无法覆盖所有业务场景，而业务码可以自己定义、自己扩展。这个设计在答辩时也是一个可以拿出来讲的点。
3. 核心功能模块拆解——从登录到选座一笔一笔写出来
3.1 用户认证与JWT鉴权：前后端分离最绕不开的坎
传统单体项目用Session保存登录状态，但在前后端分离架构下，前端可能部署在一台服务器、后端在另一台，Session共享是个麻烦事。所以现在主流方案是JWT（JSON Web Token）。
JWT的思路是：用户登录成功后，后端生成一个加密的Token字符串返回给前端，前端存在localStorage里，之后每次请求都在请求头里带上它（通常是Authorization: Bearer ）。后端每次收到请求，先验证Token是否合法、是否过期，验证通过再从Token里解析出用户身份。
在电影购票系统里，JWT主要做两件事：一是拦截未登录用户，比如下单、查看订单中心这些接口必须登录后才能访问；二是做角色权限控制，比如管理员的相关接口只允许管理员角色访问。
实现在SpringBoot里一般这么搭配：写一个拦截器或过滤器，实现HandlerInterceptor接口，在preHandle方法里校验Token。为了避免每次都要手写校验，可以配合Spring MVC的拦截器注册，把需要拦截的路径配好。
还有一个很容易被忽略的点：JWT的密钥不要硬编码在代码里。建议放到application.yml配置文件中，用@Value注解或者@ConfigurationProperties读取。如果答辩时老师问“Token被别人拿到怎么办”，你可以从这几个角度回答：一是设置合理的过期时间，缩短Token有效期；二是使用HTTPS传输，防止中间人截获；三是服务端可以维护一个Token黑名单或Redis中的会话状态，在用户修改密码或退出登录时让旧Token失效。
3.2 电影与场次管理：日期排片的时间段思维
做一个购票系统，一旦涉及“场次”，时间维度就特别重要，这是很多新手不太容易理解透彻的部分。
一个场次（session）需要记录：放映的影片ID、所在影厅ID、放映开始时间。放映结束时间通常不用存，因为可以根据影片时长推算出来，但这里有个细节：你需要在代码里校验“同一影厅的场次不能时间冲突”。比如1号厅14:00放的电影时长120分钟，那么16:30之后的场次才能排进来，16:00就不能再加一场了。
这个校验收在哪一层？我建议在后端做，因为前端校验容易被绕过。具体实现时，查询该影厅所有场次，遍历判断“新场次的开始时间”是否落在“已有场次的放映时间区间”内。简单说就是两个区间不能有交集：
if (newStart < oldEnd && newEnd > oldStart) { // 时间冲突，不能新增 }在展示层，前端会按日期维度加载影片和场次，比如选择“今天”或“明天”，按时间排序展示。场次列表的接口设计可以考虑：GET /api/sessions?filmId=xx&date=2025-XX-XX，后端根据日期和影片ID查场次，并且对应查询影厅名称、放映时间、票价等并封装返回。这类“联表查询后二次加工”的结构，在项目里会大量出现，建议熟练掌握MyBatis-Plus的LambdaQueryWrapper或写自定义SQL。
3.3 选座与订单：库存扣减与座位锁定的并发问题
选座购票的核心是“锁座”。如果两个用户同时选中同一个座位，系统必须保证只能有一个人下单成功。这一块用数据库层面来处理最稳妥，也是答辩时最值得展开讲的部分。
我推荐的方案是“状态机+乐观锁”：在session_seat表里给每个座位设置状态字段（可用/锁定/已售），并且加一个version字段（或用状态本身做条件更新）。用户点击选座时，前端展示“可用”状态的座位；用户确认座位后，后端执行这样一条更新语句：
UPDATE session_seat SET status = 1 WHERE id = ? AND status = 0这里的关键是WHERE条件里带上status = 0。如果update影响行数为1，说明座位锁定成功；如果影响行数为0，说明座位已经被别人抢了，此时返回“座位已被选，请重新选择”。
这套写法比“先查询再判断再更新”的三步操作更安全，避免了并发场景下“两个人都查到可用、然后都更新成功”的脏数据问题。本质上利用的是数据库的行级锁和原子更新，实现成本极低，但效果非常好。答辩时讲这个点，老师一般都会认可。
订单生成流程可以这样设计：用户选好座位后，先锁定座位（更新状态），然后生成一条“待支付”状态的订单，同时设置一个过期时间，比如15分钟。如果15分钟内未支付，订单变为“已取消”，释放座位。释放座位的逻辑可以写成定时任务（Spring的@Scheduled注解）或者懒取消——也就是每次查询座位状态时，顺便把超时未支付的订单对应座位改回可用。懒取消对小项目更简单，不需要额外引入任务调度，查询时捎带处理即可。
3.4 后台管理模块：角色权限与数据统计
后台管理模块在毕设里的作用，是向老师展示一个相对完整的系统应该有的样子。它至少包括影片管理（增删改查、上架下架）、排片管理（新增影厅场次）、订单管理（查看所有订单、手动退款或取消）、基础统计（每日票房、热门电影排名）。
权限控制要说的就是角色。用户表里用role字段区分“admin”和“user”，后端JWT里带上role信息，然后在接口上做角色判断。这里可以用Spring Security，也可以不用——如果你对Spring Security不熟，直接用拦截器判断role也完全没问题。毕设不是生产项目，重点是代码清晰、逻辑合理，而不是用了多少框架。
数据统计这块，别一上来就引入复杂报表工具。最简单的方案是：统计每个影片的订单数量和总销售额，SQL里用GROUP BY + COUNT + SUM就能搞定。比如“热门电影TOP10”：
SELECT f.film_name, COUNT(o.id) AS order_count, SUM(o.total_price) AS total_sales FROM orders o JOIN session s ON o.session_id = s.id JOIN film f ON s.film_id = f.id WHERE o.status = 1 AND o.create_time BETWEEN #{startDate} AND #{endDate} GROUP BY f.id ORDER BY total_sales DESC LIMIT 10这个统计结果用接口返回，前端用ECharts画柱状图或折线图，效果非常直观。在演示时，把“每日票房曲线”一拉，视觉上就很成熟。
4. 前后端联调实操过程——从零跑通第一个接口
4.1 先把后端跑起来：SpringBoot项目初始化与配置
我第一次做前后端分离项目的时候，最崩溃的不是代码写不出来，而是环境配置在捣乱。后来我把步骤固定下来，每次都按这个顺序来，基本不会再出问题。
第一步，用IDEA创建一个Spring Initializr项目，Group填com.example，Artifact填movie-ticket，语言选Java，打包方式选Jar，Java版本跟本机JDK对应。依赖先勾选Spring Web、MyBatis Framework、MySQL Driver、Lombok，Redis和JWT的依赖后面手动加。
第二步，修改application.yml，配置数据源和MyBatis。这里有个坑：MySQL 8和MySQL 5.x的驱动类不一样，新版是com.mysql.cj.jdbc.Driver，老版是com.mysql.jdbc.Driver，而且新版URL里最好加上serverTimezone=Asia/Shanghai，不然日期时间容易差8小时。
第三步，创建数据库。在MySQL里执行建库语句，然后创建表。建议直接写好一份init.sql脚本，包含所有建表语句和少量测试数据，以后无论换电脑还是部署到服务器，执行一遍就够了。测试数据很重要，至少准备3到5部电影、2个影厅、未来三天的场次以及每个场次的座位数据，不然前端跑起来全是空白页面，很影响调试心情。
4.2 前端Vue项目的联调配置：跨域与代理
前端项目创建好之后，我一般会先配Axios。推荐在src目录下建一个utils/request.js，封装一个Axios实例，设置baseURL和拦截器。baseURL怎么配是联调阶段最大的坑。
开发阶段，前端跑在localhost:5173，后端跑在localhost:8080，端口不同，浏览器默认会拦截跨域请求。常见的解决方案有两种：一是在后端加CORS全局配置，允许指定来源跨域；二是在前端用Vite或Webpack的代理配置，把/api开头的请求转发到8080端口。
我更推荐第二种，因为前端代理在开发阶段非常省心，而且上线后只需要把构建好的静态文件部署到和后端一样的域名下，或者用Nginx反代，就不会有跨域问题。在Vite里配置代理很简单：
// vite.config.js export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })这样前端页面里请求“/api/films”就会自动转发到“http://localhost:8080/api/films”，不需要在请求里写完整域名。
解决跨域还有一种偏方：在开发时不改任何配置，前端直接把请求发到“http://localhost:8080/api/xxx”，然后靠后端CORS放行。这种做法也能跑通，但上线后如果前端静态文件不在同一个源上，还是会遇到问题。所以我建议一开始就用代理，养成好习惯。
4.3 登录流程全链路调试：从表单到Token落地
联调阶段的第一个完整功能，通常是登录。成功跑通登录，意味着前后端的请求链路、数据格式、Token传递方式全部验证过了，后面就是复制粘贴式的开发。
登录的完整流程是这样的：前端用户填写用户名和密码，点击提交，请求POST /api/auth/login，后端去数据库比对用户信息（密码用MD5加盐或BCrypt加密对比），比对成功，生成JWT返回。前端拿到Token后存到localStorage，然后跳转首页。之后每次请求，Axios请求拦截器在config.headers里加上Authorization: Bearer 。
还有个细节：JWT过期后，前端请求接口会收到401，这时应该统一跳转登录页并清除本地Token。这个逻辑写在Axios响应拦截器里：
// 响应拦截器 instance.interceptors.response.use( response => response.data, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } return Promise.reject(error) } )如果你在联调时发现“登录成功但获取用户信息失败”，大概率是请求头里Token没带对，或者后端拦截器里Token解析失败。建议先用浏览器开发者工具的Network面板查看请求头，确认Authorization字段是否正常。
5. 部署与配置难题——环境差异与踩坑实录
5.1 本地IDEA运行：Maven依赖与Lombok问题
项目启动报错这块，最常遇到的就是Lombok相关的问题。Lombok是简化JavaBean代码的工具，用几个注解就能自动生成getter/setter/构造方法，但它需要在编译阶段做手脚，所以跟JDK版本、编译器的兼容性很敏感。
最常见的报错是：
java: you aren't using a compiler supported by lombok, so lombok will not work这句话的意思是Lombok版本太低，跟你当前用的JDK不兼容。解决办法很简单：把pom.xml里的Lombok版本升级到1.18.30或更高，同时在IDEA里检查是否安装了Lombok插件，并打开“Enable annotation processing”选项。“不兼容”问题大概率是注解处理没开启。
如果遇到“程序包lombok不存在”，先检查pom.xml里是否引入了依赖，再检查Maven的仓库有没有下载成功。IDEA里右键项目→Maven→Reimport，把依赖重新拉一遍，很多时候就能解决。
5.2 跨域与Cookie/Session：带Token的请求为什么老失败
还有一个容易让新手懵的场景：前端请求能到后端，后端也返回了数据，但在浏览器里看到的是“CORS error”或者预检请求失败。这是因为跨域请求不只是简单请求，当请求头里带了Authorization字段，浏览器会先发一个OPTIONS预检请求，确认服务端是否允许这个跨域访问。
如果你在后端加了拦截器，拦截器里可能把OPTIONS请求也拦截了，导致预检请求没有得到预期的响应，前端就会报跨域错误。解决办法是：在拦截器里直接放行OPTIONS请求，或者在CORS配置里允许所有OPTIONS请求。
@Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } // 校验Token... }这个坑排查起来特别隐蔽，因为后端日志里看不到任何异常，前端却一直报跨域。遇到这种疑似跨域的问题时，第一件事不是改代码，是先到浏览器Network里看看是不是有红色状态的OPTIONS请求，有的话基本就是这个原因。
5.3 JDK版本与SpringBoot版本匹配：源发行版17需要目标发行版17
编译报错“java: 警告: 源发行版 17 需要目标发行版 17”是我见过出现频次最高的错误之一。原因很简单：项目的编译级别设置成了17，但本机JDK是8，或者IDEA里项目SDK选错了。
排查步骤也很固定：打开Project Structure，检查Project SDK是不是本机安装的JDK版本；再检查Settings→Build Tools→Maven→Runner→JRE，确保Maven用的也是同一个JDK版本；最后检查pom.xml里spring-boot-maven-plugin和java.version配置是否一致。这三处只要有一处不一致，就会出现上面那个报错。
如果你用的是Spring Boot 3.x，那JDK必须是17或更高，这一点没法降级迁就。如果你用的是JDK 8，就只能用Spring Boot 2.x。这个选择在项目初始化时就要定好，不然后面所有的依赖版本都要跟着改，非常费时间。
5.4 服务器部署与打包：Docker Desktop或云主机的选择
项目做完以后，很多人会把项目部署到云服务器上，让答辩老师扫码访问，效果确实好。部署方案我建议按这个顺序考虑。
最简单的方案是：后端打包成JAR，服务器上装JDK和MySQL，然后java -jar app.jar启动。前端构建成静态文件，用Nginx托管。用Nginx做反向代理，把/api请求转发到后端的8080端口。这个方案对服务器配置要求不高，2核4G的入门云主机就够了。
如果想展示一下容器化技能，可以用Docker。服务器上装Docker和Docker Compose，写一份docker-compose.yml，包含MySQL、Redis、后端应用、前端Nginx四个容器。Docker部署的好处是环境隔离，换一台服务器也不会因为环境差异启动失败。但要注意，如果本机是Apple Silicon芯片，用Docker Desktop打包镜像时要注意架构问题，服务器是Linux amd64的话，需要构建对应架构的镜像，否则会有“exec format error”。
还有一个细节：数据库里的数据。你写好的测试数据要导出成SQL文件，部署到服务器后导入。很多同学在本地运行得好好的，部署到服务器后页面空白，查一下发现是数据库里没数据。提前把数据导入的步骤写进部署文档，后面能少很多麻烦。
如果你不想买云服务器，也可以用内网穿透工具把本地端口映射到公网，这样答辩时老师也能通过临时地址访问你的项目。不过这种方式取决于工具稳定性，演示前一定要提前测试好。
6. 答辩与演示准备——给“过审”加一道保险
5.5 演示脚本怎么设计：先跑通核心链路
毕设答辩的现场演示时间通常只有5到10分钟，不算长，但如果你现场演示时手忙脚乱地打开一堆页面、一直调试，观感会非常差。我强烈建议你写一份演示脚本，把最核心的链路提前走一遍、截好图甚至录好视频作为备用。
演示的主线，我建议就走“用户购票全流程”这一条：注册/登录→浏览影片→选择场次→选座→下单→模拟支付→在订单中心看到电子票。这条链路能跑通，整个项目就立住了。
演示时不要喧宾夺主。像影片管理的增删改查这种后台功能，用一分钟带过就行，重点放在前面那条购票链路上。如果时间充裕，再展现一下“并发锁座”——开两个浏览器窗口同时选同一个座位，一个成功另一个提示失败，这个画面非常能说明你考虑了并发问题，比说十句话都管用。
在演示前，把测试账号准备好。一个管理员账号、一个普通用户账号，提前登录过一遍，确保密码正确、Token没过期。千万别在现场输入密码时搞混角色，这种小失误也很影响状态。
5.6 哪些地方最容易成为答辩老师的提问点
答辩老师的提问通常围绕几个方向：设计合理性、技术深度、边界情况、你的理解程度。结合电影购票系统的业务，我整理了下面几个高频问题，你可以提前准备：
第一，“订单超时未支付，你怎么处理？”这个问题很经典。你要能说清楚：座位锁定是有时效的，超时后订单取消、座位释放，具体用的是定时任务还是懒取消。同时说清楚为什么选这个方案。
第二，“如何防止一个人买很多张票然后不支付，占用大量座位？”这个问题考察业务边界。你可以从“限制单笔订单最多购买票数”和“短时间内的下单频率限制”两个角度回答，前者在订单确认接口里校验，后者可以用Redis做简单的限流。
第三，“项目里有几张核心表？订单和场次座位的关系是什么？”这是纯数据库设计问题，你要能脱口说出表名、关键字段、表之间的关联关系，最好在白板上直接画出ER图。
第四，“JWT和Session登录有什么区别？为什么选JWT？”回答要点是：Session状态存在服务端，需要Session共享；JWT是无状态的，服务端不保存会话信息，适合前后端分离和分布式部署。同时也要坦然说出JWT的缺点，比如无法主动失效，需要黑名单辅助。承认缺点反而让回答更可信。
第五，“如果用户量变成十万级、百万级，你这个系统哪里会瓶颈？”这个问题很能区分“会做项目”和“只做了项目”。你可以说：数据库的订单和场次座位表会成为热点，选座写入压力大；方案是引入Redis缓存热点数据、把座位锁定改成Lua脚本或分布式锁、数据库读写分离、分库分表。不用答得太深，但一定要让对方知道你有这个意识和思考方向。
这些问题在论文里其实也有对应的章节，答辩前把逻辑理顺，别临时组织语言，现场发挥会从容很多。
写在最后的个人体会
做了这么多年的项目，我越发觉得毕设选题不是越难越好，而是越“对口”越好——跟你的技术栈匹配、跟你的时间匹配、跟你的答辩展示匹配。电影购票系统恰好在这三者之间找到了一个平衡点：技术上覆盖了主流Java后端工程师日常要用的东西，业务上又是一个完整闭环，既不会让你每天只写增删改查，又不至于让你被复杂需求压到崩溃。
如果你决定做这个系统，我给你的顺序建议是：先花一整天把数据库表全部设计好，再花两三天把后端核心链路跑通，然后再开始写前端页面。千万不要边写前端边改表结构，那样你会被前后端的耦合折腾得心态爆炸。做的时候每一步都多想一步“答辩时老师问起这个功能，我该怎么解释”，你会发现写代码和写论文其实是同一件事。
希望这篇内容能帮你少走一点弯路。有问题随时在评论区交流，祝毕设顺利。
