又是一年毕业季后台收到好多私信问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或11Spring Boot 2.7.xMyBatis-Plus 3.5.xMySQL 5.7或8.0Redis用于验证码缓存和座位锁定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状态码来表达而是返回code500之类的业务码加具体的message。因为HTTP状态码语义有限无法覆盖所有业务场景而业务码可以自己定义、自己扩展。这个设计在答辩时也是一个可以拿出来讲的点。3. 核心功能模块拆解——从登录到选座一笔一笔写出来3.1 用户认证与JWT鉴权前后端分离最绕不开的坎传统单体项目用Session保存登录状态但在前后端分离架构下前端可能部署在一台服务器、后端在另一台Session共享是个麻烦事。所以现在主流方案是JWTJSON 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?filmIdxxdate2025-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.exampleArtifact填movie-ticket语言选Java打包方式选JarJava版本跟本机JDK对应。依赖先勾选Spring Web、MyBatis Framework、MySQL Driver、LombokRedis和JWT的依赖后面手动加。第二步修改application.yml配置数据源和MyBatis。这里有个坑MySQL 8和MySQL 5.x的驱动类不一样新版是com.mysql.cj.jdbc.Driver老版是com.mysql.jdbc.Driver而且新版URL里最好加上serverTimezoneAsia/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 arent 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后端工程师日常要用的东西业务上又是一个完整闭环既不会让你每天只写增删改查又不至于让你被复杂需求压到崩溃。如果你决定做这个系统我给你的顺序建议是先花一整天把数据库表全部设计好再花两三天把后端核心链路跑通然后再开始写前端页面。千万不要边写前端边改表结构那样你会被前后端的耦合折腾得心态爆炸。做的时候每一步都多想一步“答辩时老师问起这个功能我该怎么解释”你会发现写代码和写论文其实是同一件事。希望这篇内容能帮你少走一点弯路。有问题随时在评论区交流祝毕设顺利。