最近好多学弟学妹来问我“老哥在线电影购票系统这个毕设能不能做源码加数据库加文档光听着就比别人高一个档次。”我的回答基本是能做而且非常适合拿来当毕业设计。理由很简单这个项目不像电商系统那么庞大也不像管理系统那么简单它刚好踩在选题难度的甜点上——前后端分离、常用框架、业务逻辑有值得讲的点选座、锁座、订单状态流转数据库设计也有一定复杂度无论你未来走Java后端还是前端开发都有拿得出手的简历素材。这篇文章我不打算给你贴一堆没头没尾的代码而是想把我自己跑通这套“springboot vue在线电影购票系统”的完整过程、设计思路和踩坑经历整理出来。你如果已经拿到了源代码包跟着这篇文章能把项目从“能跑”变成“懂跑”你如果是打算自己从零写那这篇文章也能帮你把骨架搭明白。内容涉及后端SpringBoot、MyBatis、JWT、前端Vue Router、Axios、选座组件、数据库初始化、项目部署以及答辩时老师最爱问的细节。全程说人话尽量让基础一般的同学也能复现。1. 项目整体设计与技术选型解读1.1 为什么偏偏是 SpringBoot Vue很多同学选毕设题目时会在SSM、SpringBoot、SpringCloud之间纠结。说实话在线电影购票系统用SpringCloud属实没必要业务没有那么多微服务需求一套后端扛到底反而更稳定。SpringBoot的优势在于“约定大于配置”你不需要像SSM那样写一堆XML配置文件起步成本低遇到问题也更容易在网上搜到答案对于本科毕设来说是容错率最高的选择。前端选Vue而不是React也有很实际的考量Vue的中文文档和社区资源非常丰富从环境搭建到各种组件库语法几乎你每一步会遇到的报错都能搜到现成方案。而且Vue2/Vue3配合Element UI或者Element Plus做后台管理、做前台展示都很快。对于毕业设计这种需要兼顾“工作量”和“完成度”的场景Vue的学习曲线比React要平缓很多小组合作时也容易分工。1.2 在线电影购票系统的核心需求到底有哪些先别急着写代码先把功能边界划清楚。一个合格的在线电影购票系统至少要覆盖三个端用户端、影院后台端、管理员端。很多同学的毕设其实只做了用户端和管理员端影院后台端可以用管理员的一部分功能代替这在答辩时讲清楚也是可以的。核心业务链条非常简单用户注册登录 → 查看正在热映电影 → 选择场次 → 选择座位 → 下单支付 → 生成电子票管理员负责维护电影信息、排片场次、座位状态、订单管理。听起来和卖火车票差不多但有个很关键的区别电影票选的座位是二维的影院每个厅的排布可能不一样这就比普通商品下单多了一层“座位锁定与释放”的逻辑。另外还要考虑“未支付订单怎么处理”。用户占了5个座位但15分钟内不付款这些座位要么一直被占着要么需要设计超时释放机制。很多基础版的毕设不会把这一块做细但如果你做到了答辩时绝对能加分。1.3 项目结构和技术亮点规划如果是从零写建议后端采用标准的MVC分层Controller层接收请求、Service层处理业务逻辑、Mapper层与数据库交互实体类entity、DTO数据传输对象、VO视图对象分开别全堆在一起。前端按照Vue CLI或者Vite创建项目后采用views/components/api/router/store的目录结构一个页面一个目录组件按功能拆分。我拿到过一份还算完整的源码包它的目录结构是类似这样的online-film-ticket ├── backend │ ├── src/main/java/com/example/cinema │ │ ├── controller │ │ ├── service │ │ ├── mapper │ │ ├── entity │ │ ├── dto │ │ ├── config │ │ └── utils │ ├── src/main/resources │ │ ├── mapper │ │ └── application.yml │ └── pom.xml ├── frontend │ ├── public │ ├── src │ │ ├── api │ │ ├── assets │ │ ├── components │ │ ├── router │ │ ├── store │ │ └── views │ ├── package.json │ └── vue.config.js ├── database │ └── cinema.sql └── 文档 ├── 开题报告.md ├── 任务书.md ├── 论文提纲.md └── 答辩PPT.md这个结构最大的好处是前后端分离以后扩展功能和写论文时都能很清楚地说明“我做了什么”。我在实际运行时发现很多版本源码最大的问题不是代码跑不起来而是前端和后端的端口、地址、CORS跨域配置根本没对齐所以后面会专门讲如何把前后端正确对接起来。2. 数据库设计如果建表建得一塌糊涂后面全是坑2.1 核心表结构与关联关系购票系统的数据库设计我建议至少包含以下这些表user用户表存储账号、密码密文、昵称、手机号、余额等。movie电影表存储片名、海报、片长、类型、上映日期、导演、主演、简介。hall影厅表存储影厅名称、影厅类型IMAX/普通/4D、座位行数、座位列数。session场次表也叫排片表关联电影和影厅记录播放时间、语言版本、票价、剩余座位。seat座位表记录每个影厅的座位行、列、状态可以按场次生成座位快照。orders订单表关联用户和场次记录订单号、总金额、状态、创建时间和支付时间。order_item订单明细表把订单和座位关联起来一个订单可能对应多个座位。这里重点提醒一句座位表不要单独只维护“影厅物理座位”因为一个影厅会排很多场次你必须在每个场次下拥有一套独立的座位占用状态。最简单的方法是在座位表中增加session_id字段或者用单独的一张session_seat表来表达某场次的座位售卖情况。我之前看过一个版本座位状态直接写在影厅表里结果用户买了一张票所有场次这个座位都变成已售这是非常典型的错误。2.2 建表SQL参考含关键字段说明下面是简化后的建表SQL你可以根据需求自行扩展字段。这个设计不是唯一标准但作为毕业设计完全够用而且逻辑清晰写论文时也好解释。-- 用户表 CREATE TABLE user ( id BIGINT NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE COMMENT 登录账号, password VARCHAR(255) NOT NULL COMMENT BCrypt加密后的密码, nickname VARCHAR(50) DEFAULT NULL, phone VARCHAR(20) DEFAULT NULL, balance DECIMAL(10,2) DEFAULT 0.00, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; -- 电影表 CREATE TABLE movie ( id BIGINT NOT NULL AUTO_INCREMENT, title VARCHAR(100) NOT NULL COMMENT 电影名, poster VARCHAR(255) DEFAULT NULL COMMENT 海报图片URL, duration INT DEFAULT 120 COMMENT 片长(分钟), type VARCHAR(100) DEFAULT NULL COMMENT 类型动作/爱情/科幻, director VARCHAR(50) DEFAULT NULL, actors VARCHAR(255) DEFAULT NULL, description TEXT, release_date DATE DEFAULT NULL, status TINYINT DEFAULT 1 COMMENT 1热映 0下架, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT电影表; -- 影厅表 CREATE TABLE hall ( id BIGINT NOT NULL AUTO_INCREMENT, name VARCHAR(50) NOT NULL, type VARCHAR(20) DEFAULT 普通, row_count INT DEFAULT 10, col_count INT DEFAULT 12, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT影厅表; -- 场次表 CREATE TABLE session ( id BIGINT NOT NULL AUTO_INCREMENT, movie_id BIGINT NOT NULL, hall_id BIGINT NOT NULL, start_time DATETIME NOT NULL, language VARCHAR(20) DEFAULT 国语2D, price DECIMAL(10,2) NOT NULL, PRIMARY KEY (id), KEY idx_movie (movie_id), KEY idx_hall (hall_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT场次表; -- 场次座位表 CREATE TABLE session_seat ( id BIGINT NOT NULL AUTO_INCREMENT, session_id BIGINT NOT NULL, row_num INT NOT NULL, col_num INT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0可选 1已锁定 2已售出, PRIMARY KEY (id), UNIQUE KEY uk_session_seat (session_id, row_num, col_num) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT场次座位表; -- 订单表 CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL COMMENT 业务订单号, user_id BIGINT NOT NULL, session_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已取消 3已退款, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, pay_time DATETIME DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表; -- 订单明细表 CREATE TABLE order_item ( id BIGINT NOT NULL AUTO_INCREMENT, order_id BIGINT NOT NULL, session_seat_id BIGINT NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细表;很多人拿到数据库文件之后直接整包导入MySQL就能用但我的建议是哪怕你已经导入了也最好对照着把每张表的用途重新理一遍。因为答辩时老师特别喜欢指着某张表问“这个字段是什么意思为什么用tinyint存状态这个外键为什么没有建”你只要答得清楚就比那些只写了“能跑就行”的同学高一个层次。2.3 座位状态设计为什么不推荐简单用一个“已售”字段在线购票的难点就在并发和一致性。最简单的座位方案是只存一个is_sold字段用户在选座时按下单就把is_sold更新为1。这在单机小流量演示时没问题但一旦两个用户同时买最后一张票就可能出现双卖。所以在座位设计上建议区分“可售/锁定/已售”三种状态可选座位还没人占。已锁定用户选完座位进入待支付此时座位暂时不能给别人选。已售出用户支付成功座位正式属于该订单。锁定的好处是给用户留出支付时间比如10分钟或15分钟。订单超时后把座位的状态从“已锁定”改回“可选”再把订单置为“已取消”。这样既不会因为用户卡在下单页面导致座位长期被占也不会出现超卖。从数据库角度要做到这一点最好在“锁定座位”操作时使用事务先检查座位状态若为0则更新为1然后插入订单。如果状态不为0直接抛出异常并回滚。为什么要在事务里做因为“检查更新”是两个步骤如果不加锁或者不加事务并发下依然会出问题。当然在毕设级别你不用去讲分布式锁、Redis原子操作这些但你要能把“为什么用事务”讲明白这就已经是个亮点了。3. 后端核心流程与代码实现思路3.1 登录鉴权JWT是相对省事的方案用户登录功能几乎所有系统都有。这里我建议用JWTJSON Web Token而不是传统Session原因很简单前后端分离后后端不保存会话状态前端拿到token后每次请求放到请求头里后端解析token拿到用户身份。这样部署时不需要考虑Session共享写答辩论文时也好叙述。在SpringBoot里我一般会加一个拦截器HandlerInterceptor拦截需要登录的接口路径。校验逻辑大致是public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { response.setStatus(401); return false; } Claims claims JwtUtil.parseToken(token.replace(Bearer , )); if (claims null) { response.setStatus(401); return false; } request.setAttribute(userId, claims.get(userId)); return true; }这段逻辑并不复杂但你有必要搞清楚几个点token里放什么字段、过期时间怎么设、被拦截的接口前端要如何处理401响应。如果你直接在拦截器里写死所有接口都拦截前端登录页和电影列表页就都进不去了所以一般放行登录、注册、电影查询、场次查询这几个公开接口其余接口校验JWT。还有一个容易被忽略的点前端拿到token后要存到哪建议放localStorage同时用Vue Router的全局前置守卫判断有没有token来决定是否跳转到登录页。但这样做有一个小问题localStorage里的token如果被删除或者过期用户操作时会遇到接口401报错。所以前端axios响应拦截器里最好统一处理401弹出“登录已过期请重新登录”并跳转到登录页面。3.2 电影查询与排片列表接口这部分是用户看得最频繁的功能。电影列表接口一般返回电影基础信息按状态筛选点击电影后要能查看场次列表按日期或者按影院筛选。后端写起来比较直观Service层调用Mapper查两张表关联数据。注意分页我推荐用MyBatis-Plus的分页插件只需要引入Page对象即可避免手写LIMIT偏移量。一个容易写得乱七八糟的地方是场次信息到底返回哪些字段。很多同学直接返回整张session表记录前端拿到的字段名和页面展示对不上然后就开始写一堆判断。我建议后端专门定义一个SessionVO包含sessionId、电影名、海报、影厅名、开始时间、语言版本、价格、余票数。余票数怎么算可以实时统计status0的座位数也可以用冗余字段保存。取实时统计会更准确但是查询压力略大如果选了冗余字段那下单和取消时要同时减/加余票。毕设项目规模不大实时统计没问题实现也简单Integer remainCount sessionSeatMapper.countAvailableBySessionId(sessionId);类似这样的查询在SQL里加一个条件status 0即可。接口返回时展示给前端看用户点进选座页时再单独获取座位布局。3.3 购票下单与锁座事务的关键代码下面这段是整套系统里比较核心的逻辑用户从前端选好若干座位提交时后端需要完成“校验座位可售 → 锁定座位 → 创建订单”这一连串动作。Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { // 1. 校验场次是否存在 Session session sessionMapper.selectById(dto.getSessionId()); if (session null) { throw new BizException(场次不存在); } // 2. 校验座位并批量锁座 ListLong seatIds dto.getSeatIds(); for (Long seatId : seatIds) { SessionSeat seat sessionSeatMapper.selectById(seatId); if (seat null || seat.getStatus() ! SeatStatus.AVAILABLE) { throw new BizException(座位已被选择请刷新后重试); } seat.setStatus(SeatStatus.LOCKED); sessionSeatMapper.updateById(seat); } // 3. 创建订单和订单明细 String orderNo OrderNoGenerator.generate(); Orders order new Orders(); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setSessionId(dto.getSessionId()); order.setTotalAmount(calculateAmount(session, seatIds.size())); order.setStatus(OrderStatus.PENDING); ordersMapper.insert(order); for (Long seatId : seatIds) { OrderItem item new OrderItem(); item.setOrderId(order.getId()); item.setSessionSeatId(seatId); orderItemMapper.insert(item); } return buildOrderVO(order); }这段代码把“事务”体现得很直接只要任何一步失败所有已锁定的座位都会被回滚。需要提醒的是如果在现有的代码里你看到的是“先insert订单再insert订单详情最后再update座位”顺序其实不影响最终结果因为有事务兜底但最好把“锁定座位”的时机放在“创建订单”之前业务语义更顺畅。3.4 订单超时释放别用定时任务死磕先想想业务场景很多同学做完下单功能后会问我“未支付订单怎么自动取消”网上比较流行的是SpringTask定时任务扫描超时订单每30秒扫一次把超时订单置为取消座位状态改回可选。这个方案在毕设项目里完全够用。但是要注意如果订单量大频繁全表扫会有性能问题不过毕设数据量小这个缺点你提都不用提。实现也很简单启动类加EnableScheduling写一个定时任务类扫描创建时间超过15分钟且状态为待支付的订单。注意订单超时时间的配置最好放在配置文件里不要写死。代码大概长这样Scheduled(cron 0 */1 * * * ?) public void handleExpiredOrders() { ListOrders expiredOrders ordersMapper.selectExpiredOrders(LocalDateTime.now().minusMinutes(15)); for (Orders order : expiredOrders) { // 取消订单 order.setStatus(OrderStatus.CANCELED); ordersMapper.updateById(order); // 释放座位 orderItemMapper.selectByOrderId(order.getId()).forEach(item - { SessionSeat seat sessionSeatMapper.selectById(item.getSessionSeatId()); if (seat.getStatus() SeatStatus.LOCKED) { seat.setStatus(SeatStatus.AVAILABLE); sessionSeatMapper.updateById(seat); } }); } }这里有个细节为什么释放座位时要判断当前状态是“已锁定”才释放因为有可能用户已经在定时任务扫描前完成了支付座位状态已经变为“已售出”如果不加这个判断就可能把已经卖出去的座位改成可售造成严重脏数据。这个细节你在答辩时主动讲出来老师会觉得你真的理解业务而不是机械地照搬代码。4. 前端实现与页面联调从“能看”到“好用”4.1 Vue项目初始化与路由配置如果你用的是Vite创建Vue3项目命令一般是npm create vitelatest frontend -- --template vue。但我得提醒一下部分网上的毕设源码用的是Vue2创建方式可能是vue create frontend。你拿到源码之后首先要看package.json里的vite版本或vue版本不要盲目执行命令否则依赖装出来不兼容跑起来全是报错。安装依赖时建议使用npm install。如果下载特别慢或者报错可以切换成淘宝镜像源npm config set registry https://registry.npmmirror.com。不过要注意不同团队维护的镜像源同步速度不同遇到个别包下载不到时可以临时再切回默认源。这个问题我在帮学弟跑项目时遇到过不下十次90%的前端跑不起来都和依赖安装不完整或者Node版本不匹配有关不要一上来就改代码。路由配置比较简单核心就是把登录页、注册页、电影列表页、电影详情页、选座页、我的订单页、后台管理页关联到对应的Vue组件。在做前端时要记得给两个入口加上“路由守卫”router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.path ! /login !token) { next(/login); } else { next(); } });为什么要加这个守卫因为如果你只在后端拦截接口前端页面还是能通过改URL强行跳进去比如直接访问/order会得到一个没有任何数据的空白页面。加上路由守卫后用户体验会好很多也能避免很多“为什么我页面打不开”的尴尬。4.2 封装Axios请求与跨域处理前端请求后端接口最常见的问题是跨域。如果你的前端跑在8080端口后端跑在9090端口浏览器默认会拦截跨域请求。解决方式有两种一种是在后端配置CORS另一种是在前端开发环境配置代理。我建议两个都做因为开发时用代理部署时用CORS。后端CORS配置很简单一个配置类加Configuration注册CorsRegistry允许指定的前端来源和请求方法。前端Vite代理则是在vite.config.js里配置export default defineConfig({ server: { port: 3000, proxy: { /api: { target: http://localhost:9090, changeOrigin: true } } } });这样你在前端所有请求都写成/api/user/loginVite开发服务器会把请求转发到9090端口浏览器的地址栏只看得到前端自己的域名自然不会报跨域错误。注意后端接口路径里如果本身没有/api前缀需要在代理配置里用rewrite重写路径否则会出现404。Axios封装方面建议创建一个request.js统一设置基础URL、超时时间和请求拦截器、响应拦截器。响应拦截器比较实用的逻辑是如果后端返回401就清理本地token并跳转登录页如果返回其他错误码用Element Plus的消息提示展示后端给出的错误信息。这样每个页面只需要调用API方法不需要重复写错误处理代码。4.3 选座页面交互与座位状态映射选座页面是整个前端最核心的部分。很多人以为选座就是一张图片点来点去实际上它背后是二维数组。后端返回的座位数据结构一般是这样的[ { id: 1, rowNum: 1, colNum: 1, status: 0 }, { id: 2, rowNum: 1, colNum: 2, status: 1 } ]前端可以先按行号分组把每行座位渲染成一个flex容器列号对应顺序。座位状态的映射关系用一个对象维护const statusMap { 0: { label: 可选, className: available }, 1: { label: 已锁定, className: locked }, 2: { label: 已售出, className: sold } };用户点击可选座位时把该座位临时加入已选列表再点击一次就取消。选完后提交按钮变成可点击状态同时显示总价和座位信息。这里要注意不要只在前端做“已选”状态后端必须再做一次校验。我之前调试时发现如果用户打开页面后一直不刷新别人把某个座位买走了这个用户本地看到的座位还是“可选”但点提交就会提示“座位已被选择”这是正常现象不是bug。你要把这种情况记录下来答辩时能讲出“为什么会出现这个提示”反而加分。至于前端监听到后端返回座位状态更新后如何重新刷新座位图我的建议是选座页面在创建时拉取一次座位状态在提交订单失败或者被提示“座位被占”时重新调用接口刷新座位。这样可以避免强制让用户手动刷新页面。4.4 播放电影预告片m3u8的一种处理方式有些在线电影购票系统里会带电影预告片播放功能这时候会碰到m3u8格式的视频地址。m3u8本质上是一个索引文件它记录了TS分片视频文件的地址列表浏览器不能直接用video标签播放需要借助hls.js或者video.js配合插件来解析播放。需要注意这只是一个在前端播放视频的技术方案不涉及任何网络访问问题项目里用到的m3u8地址通常直接来自后端配置的视频资源地址。实现思路很简单在电影详情页安装hls.js然后调用Hls.isSupported()判断浏览器是否支持再创建实例绑定video元素import Hls from hls.js; function playM3u8(videoEl, url) { if (Hls.isSupported()) { const hls new Hls(); hls.loadSource(url); hls.attachMedia(videoEl); } else if (videoEl.canPlayType(application/vnd.apple.mpegurl)) { videoEl.src url; } }我实际测试下来本地开发时如果m3u8地址是HTTP协议需要确保页面也是HTTP环境避免混合内容被浏览器拦截。另外有些后端返回的m3u8地址是相对路径前端要拼接完整的视频服务地址。视频播放功能在毕业设计里属于加分项如果时间紧张可以先不做不影响主流程。5. 数据库初始化、源码运行与常见问题排查5.1 拿到源码后第一步先把数据库灌进去不管是从网上下载的源码还是同学拷贝给你的项目第一件事永远是把数据库导起来。找到源码包里的SQL文件通常是.sql结尾用Navicat或者命令行执行导入。导入前建议先创建一个独立的数据库比如cinema_db字符集选择utf8mb4排序规则选utf8mb4_general_ci或者utf8mb4_unicode_ci。utf8mb4可以存Emoji和生僻字电影描述里偶尔会出现特殊符号用utf8mb4更稳妥。导入完成后打开后端application.yml文件检查数据库连接配置server: port: 9090 spring: datasource: url: jdbc:mysql://localhost:3306/cinema_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这里最容易踩坑的是时区问题。MySQL 8以上版本如果不加serverTimezoneAsia/Shanghai连接时大概率会报“The server time zone value”的错误。如果你本机MySQL密码不是123456一定要同步改成自己的。改完配置再启动后端看到控制台打印出Started Application基本就成功了一大半。前端启动相对简单在frontend目录下执行npm install然后npm run serve或者npm run dev根据你的Vite版本决定。启动后访问前端地址如果页面能打开但数据加载不出来就按下面一节的方式排查。5.2 常见报错问题与处理方案速查表现象可能原因解决办法后端启动报“Access denied for user”数据库账号密码错误检查application.yml中username/password确保MySQL里用户存在且允许远程连接后端启动报“Unknown database”数据库没导入或者名称不一致确认已执行SQL文件且库名与URL中一致前端请求接口报跨域后端CORS未配置或前端代理未生效开发环境配置Vite代理生产环境配置后端CORS检查接口路径是否有/api前缀前端显示“Cannot find module”依赖安装不完整删除node_modules后重新npm install页面打开后一直是登录页路由守卫拦截或token过期查看localStorage是否有token请求接口返回401才会被拦截先清除浏览器缓存重试登录成功但获取用户信息失败后端没做token解析或前端没把token放到请求头确认axios请求拦截器里设置Authorization头选座提交报“座位已被选择”座位被其他用户锁定或订单超时未释放等待定时任务释放或重启项目后重新测试也可以直接改数据库座位状态为0播放预告片黑屏视频地址不可访问或m3u8协议问题先用浏览器单独打开m3u8地址测试再检查video播放器配置这张表是我在带学弟跑项目时经常要重复讲的你可以直接当成一个排错清单。遇到问题先对照原因不要一上来就改代码。很多报错Info在控制台已经写得很清楚了只是大家习惯性慌了神。5.3 演示环境准备别在答辩现场翻车答辩现场最怕的不是功能不够多而是演示中途项目挂了。所以正式答辩前建议准备一套“绿色演示环境”提前启动好MySQL、后端、前端确认所有页面都正常甚至可以先录一个操作视频作为plan B万一现场网络波动或者电脑抽风用视频也能完成讲解。数据库里建议预置几组演示数据3-5部电影涵盖不同档期每个电影至少2个场次且场次的时间要设在未来座位的初始状态全部为0方便现场演示选座再预置一个测试账号密码越简单越好比如admin/123456答辩时输入方便。聪明一点的做法是再准备一个“已支付订单”的账号演示时可以立刻切到“我的订单”页面展示历史订单记录不用现场等支付。5.4 答辩时容易被问到的核心点老师不会满足于“你用了SpringBoot和Vue”这种回答他们更关心的是你系统里的业务难点是怎么解决的。结合在线电影购票系统经常被问到的方向有这几个为什么座位状态要分三种直接用一个布尔值可不可以这个问题要结合“锁定”和“释放”的流程回答强调超时订单和并发冲突。并发下单时怎么防止座位超卖答数据库事务、更新前校验状态、唯一索引约束。你不需要说分布式锁但能提到自己的处理已经够了。订单超时取消除了定时任务还有没有更好的办法如果你能说出“可以用消息队列延迟消息但毕设中定时任务足够”这样的答案已经体现你的思考深度了。前端路由和登录状态是怎么保持的答JWT放在localStorage路由守卫判断tokenaxios请求头携带token后端拦截器校验。密码是明文存的吗如果你的源码里密码是明文建议在答辩前改成BCrypt加密至少能问“为什么不用MD5”时答上来MD5容易被彩虹表碰撞BCrypt自带盐值更安全。这些点不一定每个都会被问到但提前准备了现场就能答得自信。就算老师问到一个你完全没准备过的领域也不要慌尽量从“我做的项目里是怎么处理的”“如果未来要扩展我会怎么做”这个角度去圆。5.5 运行中我踩过的一个隐蔽坑MyBatis-Plus下的表名映射还有一个很容易被忽略的小坑就是表名带了s结尾或者关键字冲突的。比如user这张表在MySQL里虽然不算是严格关键字但有些版本会发生兼容问题。如果使用MyBatis-Plus默认会把实体类User映射到user表大部分情况没问题。但要小心订单表orders因为order是SQL关键字如果在SQL里写select * from order绝对会报语法错误。实体类如果用OrderMyBatis-Plus会自动去掉尾部的s映射到order表如果不手动指定TableName(orders)大概率会报表不存在。解决办法很简单在实体类上显式声明TableName(orders) public class Orders {这个问题我在看别人的源码时碰到好几次很多人以为自己SQL写错了实际上就是表名映射规则没搞清楚。你在写论文时如果把这个问题也写进去反而能成为一个小小的踩坑心得。6. 如何把项目包装成更亮眼的作品6.1 三个可以低成本加的亮点功能如果你的时间还算充裕不必只停留在基础功能上可以挑一两个低成本易实现的小功能加上让系统看起来更完整第一个是电影检索和筛选。在电影列表页加入按电影名模糊搜索、按类型下拉筛选、按上映时间排序。前端用el-select和el-input后端在SQL中使用动态条件查询非常简单但能明显提升用户体验。第二个是热映电影的轮播图。很多同学的电影列表只是平铺卡片略显单调。你可以把最近上映的3-5部电影做成首页轮播点击海报跳转详情。Vue里用Element Plus的Carousel组件十分钟能搞定但视觉效果好很多。第三个是订单状态的后台看板。管理员端除了增删改查还可以统计今日订单数、总票房、热门电影Top5。这个功能用几条SQL聚合查询就能实现前端用一个统计卡片展示数字答辩时演示出来相当加分。别把这个做成复杂的报表系统否则容易把自己绕进去只需要简单展示趋势。6.2 论文结构与项目代码怎么配合讲写论文时不要在“系统实现”里贴大段大段的代码老师不爱看查重也难过。更好的做法是核心表结构放E-R图和表设计说明关键业务逻辑比如锁座、订单超时释放画时序图或者流程图配上核心代码片段前端页面放截图标注每一个功能区域。不要直接用UML工具自动生成的大图自己用Visio或者draw.io重新画过一遍图越清楚论文答辩越轻松。另外要注意论文里的“数据库设计”部分千万不要只贴建表SQL语句要把“为什么这样设计”写出来。比如订单和订单明细为什么分成两张表因为一个订单可能包含多个座位不拆分会出现重复订单信息。比如座位表和场次表为什么要关联因为同一个影厅不同时间场次座位状态是独立的。这些内容只要你写清楚论文的查重和盲审都会好过很多。6.3 代码风格与注释一个容易被忽视的细节很多源码包里的代码注释很少或者全是拼音命名。我建议在提交和答辩前花半天时间把代码里明显的拼音包名和变量名改掉比如yonghuMapper改成userMapperdianyingList改成movieList。这个改动不需要改业务逻辑只是全局重命名但会让代码质量观感提升一个档次。同时在核心方法上加一行注释说明这个方法的作用和入参、出参。不要写废话注释比如// 根据id查询电影这种看了方法名就懂的注释没什么价值要写业务含义比如// 锁定座位状态从0改为1开启事务回滚保证并发安全。老师翻阅源码的时候第一眼就会看代码规范你哪怕功能简单但代码清爽印象分也会高很多。写在最后的一点个人体会这个项目我前前后后带人跑了很多次每次遇到的问题都不一样但总结起来就一句话在线电影购票系统的难点并不在于某个单独的技术点有多难而在于把前端交互、后端事务、数据库状态串联起来时不掉链子。你如果只是按照网上的教程敲一遍“增删改查”那项目做完就忘但如果你认真理解了座位状态、订单超时、JWT鉴权这三个关键点哪怕代码是拿别人改的你也已经具备在这个领域做二次开发的基础了。如果你正在准备毕业设计我的建议是先别急着改功能把这些核心流程从头到尾演示三遍确保每一步都知道“现在发出去的是什么请求、数据库里发生了什么变化、为什么页面会这样显示”。能做到这个程度答辩基本上就稳了。最后分享一个小技巧在正式演示之前把浏览器控制台的网络面板打开。答辩时如果某个接口出错你能当场看到是哪个请求失败了、后端返回了什么错误这样即使出了问题也能自然圆场而不是尴尬地刷新页面。项目跑通的成就感很快就会被新需求冲淡但调试这种“报错—定位—解决”的经验才是你真正从毕业设计里带走的东西。
