SpringBoot+Vue电影售票系统源码实战：从环境搭建到选座订单避坑

简介这是一套面向Java Web全栈学习者与课程设计开发者的电影售票及影院管理系统源码基于SpringBoot与Vue.js前后端分离架构实现适合作为毕业设计、实训项目或技术进阶的参考案例。压缩包共314个文件约16.14MB其中81个Java文件承载后端业务逻辑与接口实现41个Vue组件负责前端页面与交互另有15个XML配置、15个JS脚本、1个SQL建表脚本及大量jpg、png、svg图片资源覆盖海报、图标与界面素材。系统功能涵盖用户注册登录、电影信息维护、影院与放映厅管理、排片场次设定、可视化选座购票、订单生成与支付集成以及管理员权限下的订单与用户管理并涉及Spring Security权限控制、Redis缓存优化等实践点。目前已有71人学习下载读者可借此完整理解前后端分离项目的目录组织、接口设计与组件复用思路快速搭建可运行的购票平台原型。1. 从一份电影售票系统源码说起它到底能跑出什么如果你手头正好有一套基于 SpringBoot Vue 的电影售票及影院管理系统源码第一反应大概率是这东西能不能直接跑起来、能不能改成自己的毕设、能不能拿去交差。我拆过不少这类前后端分离的项目说实话电影售票这个题材在基于 SpringBoot 的毕设里属于「看着简单、细节不少」的那一类——它同时牵扯到座位锁定、场次排期、订单状态流转、支付回调模拟这几条业务线比单纯的管理系统多了一层并发和状态一致性的考量。这套资源的核心价值在于它把影院日常运营里最典型的几个模块——影片管理、影厅与座位、排片场次、在线选座下单、订单核销——用 SpringBoot 做后端接口、Vue 做前端交互的方式串了起来。适合两类人一类是拿它当毕设底座需要快速理解整体结构再改另一类是想练前后端分离实战拿一个业务闭环完整的项目练手。下面我按「先跑通、再拆解、最后避坑」的顺序把这份源码怎么落地讲清楚。2. 环境搭建与项目启动把 jar 和 node_modules 都跑起来2.1 后端 SpringBoot 工程的依赖与配置这类项目后端通常是标准 Maven 结构拿到源码后第一件事不是急着点运行而是先确认 JDK 和 Maven 版本。我一般会先看pom.xml里的spring-boot-starter-parent版本常见的是 2.x 系列。如果你的 IDEA 默认 JDK 是 17 而项目是 SpringBoot 2.3启动时很容易报模块访问相关的错这时候把项目 SDK 降到 JDK 8 或 11 更稳。数据库配置集中在application.yml或application.properties需要改的是连接地址、库名、账号密码。电影售票系统的表一般有十几张影片、影厅、座位、场次、订单、用户、评价这些。导入 SQL 的时候注意字符集用utf8mb4否则影片名里的特殊符号会变问号。# application.yml 关键配置片段 spring: datasource: url: jdbc:mysql://localhost:3306/movie_ticket?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver # 文件上传大小限制海报图容易超默认值 servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true这段配置里有两个参数值得单独说。serverTimezoneAsia/Shanghai不加的话MySQL 8 驱动在写入场次时间时可能整体偏移 8 小时排片时间全乱。map-underscore-to-camel-case: true是 MyBatis-Plus 的驼峰映射开关数据库字段movie_name能自动映射到实体类的movieName不开的话查询结果一堆 null这个坑我见过太多次。启动类上一般有MapperScan注解指向 mapper 包路径。如果启动报「找不到 mapper」先检查这个注解的包名和实际目录是否一致。后端跑起来后访问http://localhost:8080看有没有返回或者直接调一个登录接口验证。2.2 前端 Vue 工程的安装与联调前端是 Vue 项目先看package.json里的 Vue 版本。Vue 2 和 Vue 3 的启动命令、目录结构差别不小Vue 2 常见的是npm run devVue 3 用 Vite 的话也是npm run dev但配置在vite.config.js而不是vue.config.js。# 进入前端目录后 npm install # 安装依赖国内建议配淘宝镜像 npm run dev # 启动开发服务器默认 8081 或 8082npm install这一步是翻车高发区。老项目里经常锁着 node-sass 这种对 Node 版本极其敏感的依赖Node 16 以上直接编译失败。遇到这种情况要么把 Node 降到 14要么把 node-sass 换成 dart-sass。我一般先看报错里是哪个包再决定是降 Node 还是换依赖别一上来就删node_modules重装浪费时间。前端请求后端的地址通常写在.env.development或者src/utils/request.js的baseURL里。前后端分离项目跨域是必然的后端一般会配一个全局 CORS 配置类或者用 Nginx 反代。开发阶段如果前端报跨域先确认后端 CORS 有没有放行前端端口别急着去改前端代理。// request.js 里 baseURL 的常见写法 const service axios.create({ baseURL: process.env.VUE_APP_BASE_API || http://localhost:8080, timeout: 10000 }) // 请求拦截器里通常会带 token service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) config.headers[Authorization] token return config })这段代码说明两件事一是接口基地址可配部署时改环境变量就行二是登录态靠 token 放在请求头里传递。如果你登录后调其他接口报 401先看拦截器有没有把 token 带上再看后端拦截器有没有放行。3. 核心业务模块拆解选座、订单、排片怎么串起来3.1 座位锁定与场次排片的数据结构电影售票系统里最容易出问题的就是选座。表面上看是点一个座位变红背后其实是「场次 座位」的关联表在控制状态。常见设计是schedule场次表关联hall影厅seat座位表记录影厅的物理座位再有一张schedule_seat或者直接在订单里记录已售座位。选座接口的逻辑一般是前端传场次 ID 和座位 ID 列表后端先查这些座位在该场次下是否已被占用没占用就生成订单并锁定座位。这里有个经典坑——两个用户同时选同一个座位如果只是「先查再插」并发下会双双成功。稳妥做法是给座位记录加唯一索引或者在更新时用where status 0这种条件更新靠数据库行锁兜底。-- 座位状态条件更新影响行数为 0 说明被别人抢先了 UPDATE schedule_seat SET status 1, order_id #{orderId} WHERE schedule_id #{scheduleId} AND seat_id #{seatId} AND status 0;这条 SQL 的关键在AND status 0。如果返回的影响行数是 0说明这个座位已经被别人锁定后端就应该回滚整个订单并提示用户重新选座。很多源码在这里只做了查询判断没做条件更新压测时就会出现超卖这是血泪经验。排片模块相对简单就是给影厅分配时间段和影片。要注意的是场次时间不能重叠同一个影厅同一时间段只能有一场。这个约束可以在插入前查一下也可以靠业务层保证。我一般会在 service 层加一段重叠校验避免运营人员手动排片时排重。3.2 订单状态流转与支付回调模拟订单状态一般有待支付、已支付、已取消、已核销、已退款。状态流转必须单向可控不能出现「已取消」又变回「已支付」的情况。常见做法是用状态机或者枚举加校验每次更新前判断当前状态是否允许目标状态。支付这块真实项目接的是第三方支付但课程设计和毕设里通常是模拟支付——点一下「确认支付」直接把订单改成已支付。这里要注意的是即便是模拟也要把「支付成功」和「订单状态更新」放在一个事务里否则可能出现支付了但订单没变的情况。Transactional(rollbackFor Exception.class) public void payOrder(Long orderId) { Order order orderMapper.selectById(orderId); // 只有待支付状态才能支付 if (order.getStatus() ! OrderStatus.UNPAID.getCode()) { throw new BusinessException(订单状态不允许支付); } order.setStatus(OrderStatus.PAID.getCode()); order.setPayTime(new Date()); orderMapper.updateById(order); // 同时更新座位状态为已售 scheduleSeatMapper.confirmSeat(orderId); }Transactional注解保证这两步要么都成功要么都回滚。rollbackFor Exception.class是为了让受检异常也触发回滚默认只回滚运行时异常这个细节很多人忽略。状态判断放在最前面防止重复支付。3.3 前端选座交互与路由参数传递前端选座页面通常是一个影厅座位布局图用 div 或 canvas 渲染。点击座位切换选中状态选好后带着场次 ID 和座位 ID 跳到订单确认页。Vue 路由传参有两种方式query和params。query 会显示在地址栏刷新不丢params 不显示但刷新会丢。选座这种场景我建议用 query 或者把数据存到 Vuex/Pinia别用 params 硬传。// 选座后跳转用 query 传参更稳 this.$router.push({ path: /order/confirm, query: { scheduleId: this.scheduleId, seats: this.selectedSeats.join(,) } })seats用逗号拼接成字符串传递接收端再 split 还原。这样做的好处是刷新页面参数还在用户不会因为误刷新丢掉已选座位。如果座位数量多字符串会很长可以考虑只传场次 ID座位信息存 store。4. 避坑与排查这份源码最容易翻车的五个地方4.1 启动报数据库连接失败现象SpringBoot 启动直接抛Communications link failure或Access denied。原因通常是数据库没启动、库名写错、账号密码不对或者 MySQL 8 的驱动类名还是老的com.mysql.jdbc.Driver。解决确认 MySQL 服务在跑库已创建application.yml里驱动改成com.mysql.cj.jdbc.DriverURL 加上时区参数。4.2 前端 npm install 卡在 node-sass现象安装依赖时 node-sass 编译报错提示 Python 或 node-gyp 相关。原因node-sass 和 Node 版本强绑定Node 16 基本装不上老版本。解决把 Node 降到 14或者把package.json里的 node-sass 换成 sassdart-sass同时把sass-loader升到兼容版本。换完记得删node_modules和package-lock.json重装。4.3 登录后接口全部 401现象登录成功拿到 token但调其他接口都返回 401。原因请求拦截器没把 token 放进 header或者后端拦截器校验的 header 名和前端不一致。解决检查前端拦截器里config.headers[Authorization]的 key和后端拦截器里读取的 key 是否一致。有的项目用token作为 header 名有的用Authorization对不上就全挂。4.4 选座出现超卖现象两个人同时选同一个座位都下单成功。原因座位状态判断和更新不是原子操作中间有时间窗口。解决用条件更新where status 0根据影响行数判断是否抢占成功或者给schedule_id seat_id加唯一索引插入冲突时捕获异常回滚。4.5 场次时间显示偏移 8 小时现象数据库里存的时间是对的前端显示差 8 小时。原因后端返回的是 Date 对象序列化时没指定时区或者数据库连接没配时区。解决application.yml里 JDBC URL 加serverTimezoneAsia/Shanghai实体类时间字段用JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)注解。5. 二次开发与验证怎么确认这套系统真的跑通了改完配置、跑起来之后别急着说「能用了」。我一般会走一遍完整业务链路来验证注册用户 → 登录 → 浏览影片 → 选场次 → 选座 → 下单 → 模拟支付 → 查看订单 → 后台核销。这条链路走通说明核心模块都正常。二次开发时最常见的需求是加一个「退票」功能。实现思路是订单状态从已支付改为已退款同时把对应座位状态改回可售。这里要注意退票时间限制比如开场前 2 小时才能退这个判断放在 service 层。public void refundOrder(Long orderId) { Order order orderMapper.selectById(orderId); Schedule schedule scheduleMapper.selectById(order.getScheduleId()); // 开场前2小时才能退 if (schedule.getStartTime().before(new Date(System.currentTimeMillis() 2 * 3600 * 1000))) { throw new BusinessException(距离开场不足2小时无法退票); } order.setStatus(OrderStatus.REFUNDED.getCode()); orderMapper.updateById(order); // 释放座位 scheduleSeatMapper.releaseSeat(orderId); }验证退票功能时重点看座位有没有被正确释放——退票后再去选同一个座位应该能选中。如果选不了说明座位状态没改回来查一下releaseSeat的 SQL 条件对不对。另一个常见改动是加影片分类筛选。前端加一个下拉框后端接口加一个categoryId参数MyBatis 的 XML 里用if testcategoryId ! null动态拼接。这种改动风险低适合练手。从那以后我每次拿到这类前后端分离的源码都强制先走一遍「注册到核销」的完整链路再动任何代码。因为很多问题不是代码写错了而是配置和版本对不上先跑通再改能省掉大量排查时间。希望帮到你。本文还有配套的精品资源点击获取