简介这是一套基于SpringBoot与Vue前后端分离架构的电影售票及影院管理系统源码面向正在学习JavaWeb开发或以课程设计、毕业设计为目标的学生也适合需要参考完整业务闭环的初级全栈开发者可直接导入开发工具运行调试。压缩包共314个文件大小约16.14MB文件类型以81个Java后端源码、41个Vue单文件组件、15个XML配置、15个JS脚本、11个PNG及102个JPG静态资源为主另有SQL数据库脚本和项目说明文档前后端目录边界清晰具备较好的工程完整性。目前已有71人参与学习覆盖用户注册登录、电影信息维护、影院与排片管理、在线选座、订单生成、支付对接及后台权限管理等核心模块。通过研读这套代码能够掌握SpringBoot自动配置、RESTful接口设计、SpringSecurity鉴权等后端实践同时熟悉Vue路由、Vuex状态管理、Axios请求封装等前端用法是一份可直接复用和二次开发的实战参考资料。1. 一个真正能跑通全链路的 SpringBootVue 项目电影售票及影院管理系统拆之前先理清这几点动手拆这个基于SpringBoot Vue的电影售票及影院管理系统之前先说结论它不是一个只有增删改查的练习而是一套完整的前后端分离业务系统。后端用 SpringBoot 提供 RESTful API前端用 Vue 管理后台和用户购票端MySQL 存数据核心链路覆盖电影上架、影厅排片、在线选座、订单支付状态流转。这个包真正值得看的不是界面而是选座锁座和订单状态怎么对齐——很多类似项目就死在这个环节。适合准备 SpringBoot 毕设的人、正在练全栈实战的人或者想找一套能直接跑起来当骨架改的开发者。2. 先看架构再看表系统分层和六张核心表设计读代码之前先建立全局视图后面联调时找文件会快很多遇到问题也能判断问题处在哪一层。这个项目的整体结构不复杂但把结构关系看懂再动手效率会差好几倍。2.1 前后端分离的分层结构SpringBoot 三层与 Vue 的 views、router、api 一一对应后端是标准三层controller 接收请求、service 写业务逻辑、mapper 做数据库操作。前端则是 views 放页面、router 管路由、api 封装请求。拆源码时抓住“后端一个 controller 对应前端一个 api 模块和一个页面”这条线整套代码很快就能读顺。后端 controller 大致包含这些AuthController登录注册、MovieController电影列表、上架下架、SessionController排片场次、SeatController锁座释放、OrderController创建订单与状态更新、AdminController后台统计。每个 controller 只做参数校验和结果返回业务逻辑全部下沉到 service 层数据库操作在 mapper 层通过 MyBatis-Plus 完成——单表 CRUD 直接用 BaseMapper 内置方法多表关联才写 XML。前端目录结构一般长这样src/api/ 按后端 controller 拆分请求模块axios 实例统一创建baseURL 写 /api登录后从 localStorage 取 token 挂到请求头src/router/ 分 admin 和 user 两套布局登录态用路由守卫控制src/views/ 里 admin 下是电影管理、影厅管理、场次管理、订单管理user 下是电影列表、电影详情、选座页、订单确认、我的订单。联调时最常见的现象是“接口通了但页面数据不对”九成是前端使用的字段名和后端返回的 JSON 字段对不上。所以拿到源码后我的习惯是先找后端返回的 JSON 结构再比对前端页面的 data 绑定确认字段没拼写差异再来跑页面。这个习惯比打开页面直接点点点节省大量时间。2.2 六张核心表用户、电影、影厅、场次、座位、订单的关系设计这个项目没有单独的库存表库存是通过“场次 座位”组合隐式表达的。一部电影可以排到多个影厅的多个场次每个场次创建时生成一批独立的座位记录用户买票就是在某场次的座位记录里改状态。这个设计在中小规模完全够用也直接决定了锁座逻辑该怎么写。核心表结构整理如下不同版本的源码字段可能略有增减但主干基本一致表名核心字段作用sys_userid、username、password、phone、role用户与管理员role 区分 0/1movie_infoid、title、poster、duration、director、type、release_date、status电影元数据与上架状态cinema_hallid、name、seat_rows、seat_cols影厅名称和座位规模movie_sessionid、movie_id、hall_id、start_time、end_time、price、status场次排片关联电影和影厅seatid、session_id、row_no、col_no、status某场次下的座位状态 0/1/2order_infoid、order_no、session_id、user_id、seat_ids、total_price、status订单主表seat_ids 存座位坐标串关系上的核心是 movie_session。它把 movie_info 和 cinema_hall 关联起来seat 挂在 movie_session 下面生成多少座位由 cinema_hall 的 seat_rows 和 seat_cols 决定。order_info 记录 session_id 和 seat_ids查询某个用户的订单时按 user_id 过滤就能拿到该用户买了哪些场次哪些座位。设计上有一个值得留意的点seat 表不是全局座位而是“场次下的座位实例”。同一个影厅、不同场次会有各自的 seat 记录互不影响。这个拆法牺牲了一点存储空间但换来了锁座的简单可靠——每个场次的座位状态独立不需要在锁座时去判断“这个座位在另一个场次是否被占用”。与之相对的是把座位绑在影厅上的做法那种设计在排片交叉时会非常麻烦查状态要额外关联场次并发控制也更绕。另外记住 seat 表的 status 字段0 表示可用1 表示已被锁定未支付2 表示已售出。0 到 1 是用户选座锁单1 到 2 是支付成功1 回到 0 是超时释放。后面章节的锁座、并发控制、定时任务全部围绕这个字段展开。有些版本还会在 order_info 里加 expire_time 或 pay_time用支付截止时间做前端倒计时。如果源码里没有这个字段建议自己加一个后面做超时释放时能把 SQL 写得更精确。3. 把系统在本地跑起来数据库初始化、后端配置与前端联调资源包通常自带 SQL 脚本和前后端两套工程。第一次跑通完整流程需要三个动作建库导数据、启动后端、启动前端。每个环节都有固定配置点改完一次就能稳定联调。3.1 后端启动建库导数据与 application.yml 里的数据源配置先确认资源包里 sql 文件的位置通常在 sql/ 或 db/ 目录下文件名类似 cinema_db.sql。建议用命令行导入避免图形化工具在编码上出意外mysql -uroot -p --default-character-setutf8mb4 -e CREATE DATABASE cinema_db DEFAULT CHARACTER SET utf8mb4; mysql -uroot -p cinema_db --default-character-setutf8mb4 cinema_db.sql第一条命令建库指定默认字符集 utf8mb4第二条导入数据。如果 .sql 文件里已经写了 CREATE DATABASE建库这步可以跳过直接导入即可。导入后先用一条 SELECT 验证表数量比如 SHOW TABLES确认六张核心表都在别急着启动后端。然后改后端的 application.ymlserver: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/cinema_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath:/mapper/*.xml configuration: map-underscore-to-camel-case: true这段配置有三个关键点。url 里的 serverTimezoneAsia/Shanghai 必须保留否则 MySQL 8 的 LocalDateTime 读写会出现 8 小时偏差driver-class-name 用 com.mysql.cj.jdbc.Driver 对应 mysql-connector-java 8.x如果项目里写的是旧的 com.mysql.jdbc.Driver说明依赖版本偏老建议统一升级map-underscore-to-camel-case 必须为 true否则表里的 seat_rows 映射不到实体类的 seatRows 字段查出来的结果全是 null。如果项目用了 MyBatis-Plus 的逻辑删除配置比如全局配置了 logic-delete-field 而表里没有 deleted 字段启动后所有列表查询都会自动追加 AND deleted0结果是什么都查不到。遇到“数据明明在库里但页面空白”的情况优先检查这个开关。启动命令一般是 mvn spring-boot:run 或直接用 IDE 跑 main 方法。注意端口冲突8080 被占用时后端起不来改成 8081 就要同步改前端代理的 target。3.2 前端起步依赖安装、devServer 代理与 axios 请求封装前端目录通常在 vue/ 或 frontend/ 下。先装依赖node 版本较高时经常撞上 peer 依赖问题cd frontend npm install # 如果报 ERESOLVE 错误加 --legacy-peer-deps 重装 npm install --legacy-peer-deps npm run serve项目基于 Vue CLI 的代理配置在 vue.config.js基于 Vite 的在 vite.config.js 的 server.proxy 里。以 Vue CLI 为例module.exports { devServer: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }配了代理后前端 axios 请求直接写相对路径 /api/login开发服务器会把请求转发到 8080浏览器层面不出现跨域。如果前端代码里把 baseURL 写死成 http://localhost:8080代理就不生效跨域问题会原样暴露。axios 封装一般是统一在 src/api/request.js 里创建实例、设置拦截器import axios from axios const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( res { if (res.data.code 200) return res.data.data return Promise.reject(new Error(res.data.msg)) }, err Promise.reject(err) ) export default request这里注意 Authorization 头要不要带 Bearer 前缀取决于后端 JWT 拦截器的写法。拿到源码后搜一遍后端的 token 解析逻辑确认头部格式否则登录成功后所有接口还是报认证失败。项目中如果后端返回结构不是 { code, msg, data }拦截器里对应的取值也要同步改。3.3 双端入口管理员和普通用户两套角色的登录与路由守卫项目通常有一个登录入口提交用户名密码后后端返回 token 和用户信息前端根据角色字段决定跳转方向。数据库里一般预置了管理员账号和测试用户账号先用预置账号登录跑通流程别急着改密码。路由守卫写在 src/router/index.jsrouter.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) return } if (to.path.startsWith(/admin) token) { const userInfo JSON.parse(localStorage.getItem(userInfo)) if (userInfo.role ! 1) { next(/) return } } next() })守卫的逻辑很简单未登录不能进受保护页面普通用户不能进 admin 前缀路由。这里最容易翻车的是 localStorage 里存 userInfo 时格式不统一——存的时候是字符串取的时候按对象 parse或者反过来都会导致页面直接报错。统一写法localStorage.setItem(token, res.data.token) localStorage.setItem(userInfo, JSON.stringify(res.data.userInfo))再确认后端返回的角色字段名。前端对比的是 role后端返回的却是 roles或者字段名是 userType都会导致权限判断永远不通过。搜后端登录接口的返回值就能看到真实字段名前端保持一致。4. 核心业务实现排片建座、原子锁座与前端选座组件这一章是系统含金量最高的部分也是面试或答辩最常被追问的模块。先看后端怎么建座位再看锁座如何防超卖最后看前端怎么渲染座位图和提交选择。4.1 排片与建座一个场次生成独立座位记录的过程新建场次时前端传入 movie_id、hall_id、start_time、price。后端先向 movie_session 插入一条场次记录然后按影厅的 seat_rows 和 seat_cols 批量生成座位。行号和列号从 1 开始不要从 0 开始否则前端展示时容易错位。// SessionService.java Transactional(rollbackFor Exception.class) public Long createSession(SessionDTO dto) { MovieSession session new MovieSession(); session.setMovieId(dto.getMovieId()); session.setHallId(dto.getHallId()); session.setStartTime(dto.getStartTime()); session.setEndTime(dto.getEndTime().plusMinutes( movieService.getById(dto.getMovieId()).getDuration())); session.setPrice(dto.getPrice()); session.setStatus(1); sessionMapper.insert(session); CinemaHall hall hallMapper.selectById(dto.getHallId()); for (int row 1; row hall.getSeatRows(); row) { for (int col 1; col hall.getSeatCols(); col) { Seat seat new Seat(); seat.setSessionId(session.getId()); seat.setRowNo(row); seat.setColNo(col); seat.setStatus(0); seatMapper.insert(seat); } } return session.getId(); }逻辑说明Transactional 保证场次和座位一起成功或一起回滚不会出现场次建好但座位缺一半的脏数据。end_time 不依赖前端传用电影时长推算减少人为录入错误。建座用双重 for 循环座位数量完全由影厅的 seat_rows 和 seat_cols 决定。如果影厅座位数很大循环逐条 insert 会慢可以改成拼接多值 INSERT 一次插入几百行。几百个座位的场景循环写法完全够用报错定位也更直观没必要提前优化。注意 createSession 的入参里如果没有 end_time 字段后端根据 startTime duration 计算是正确做法有的项目让前端传 end_time人工填错会导致排片检查逻辑出错。4.2 锁座接口用一条 UPDATE 语句防并发超卖锁座是整个项目最需要防并发的地方。两个用户同时点同一个座位如果代码是先 SELECT 再 UPDATE两个请求都会看到 status0结果超卖。正确做法是把座位条件和状态变更放到同一条 UPDATE 语句里靠受影响行数判断锁定结果。// SeatService.java public boolean lockSeat(Long sessionId, int rowNo, int colNo) { int affected seatMapper.lockSeat(sessionId, rowNo, colNo); if (affected 0) { return false; } // 锁座成功后生成待支付订单 orderService.createPendingOrder(sessionId, rowNo, colNo); return true; }对应的 SeatMapper XML!-- SeatMapper.xml -- update idlockSeat UPDATE seat SET status 1 WHERE session_id #{sessionId} AND row_no #{rowNo} AND col_no #{colNo} AND status 0 /update这条 SQL 依赖的是数据库行锁同一时间只有一个事务能把这一行的 status 从 0 改成 1另一个事务执行时匹配不到 status0 的行affected 为 0自然被判定为抢座失败。比在应用层加 synchronized 或引入 Redis 分布式锁都简单也是这类单体项目最实用的方案。MyBatis-Plus 的 updateById 达不到这个效果必须用自定义 SQL。seat 表需要额外加一个 lock_time 字段锁座时同时写入锁定时间后续超时释放依赖它。没有这个字段用户选座后不支付座位会永远卡在 status1后台只能手动清数据。orderService.createPendingOrder 内部要注意幂等同一个 sessionId 加同一组座位不应该生成两条待支付订单。常见做法是在 order_info 表对 (session_id, seat_ids) 加唯一索引或者创建前先查是否已有待支付订单。前端用户手抖连点两下提交按钮后端必须兜住这层。4.3 前端选座组件把座位记录映射成二维座位图选座页从场次列表进入拿到 sessionId 后请求后端的座位列表接口返回的是当前场次的全部座位记录。前端把记录按 rowNo 分组渲染成排。template div classseat-map div v-for(row, rIdx) in seatRows :keyrIdx classseat-row span classrow-label{{ rIdx 1 }}排/span div v-for(seat, cIdx) in row :keycIdx classseat :classseatClass(seat) clickchooseSeat(seat) {{ cIdx 1 }} /div /div /div /template// 状态 0 可用、1 锁定、2 已售、3 本地选中 const selectedSeats ref([]) function seatClass(seat) { return { available: seat.status 0, locked: seat.status 1, sold: seat.status 2, picking: seat.status 3 } } function chooseSeat(seat) { if (seat.status 1 || seat.status 2) return if (seat.status 0) { seat.status 3 selectedSeats.value.push({ row: seat.rowNo, col: seat.colNo }) } else if (seat.status 3) { seat.status 0 selectedSeats.value selectedSeats.value.filter( s !(s.row seat.rowNo s.col seat.colNo) ) } }最关键的细节前端选中的状态用 3 表示不能直接把后端返回的 status 改成 1。因为锁定是后端动作前端把 status 改成 3 只是界面高亮点击提交时把选中坐标列表交给后端锁座接口后端成功后刷新座位列表验证状态。如果前端直接改 status1页面刷新后座位真实状态重新拉取会发现界面和实际不符。提交前可以加一层前端校验用户再次点击已选座位时如果座位实际状态变成 1 或 2说明被别人抢先锁了这时前端要提示座位已不可用并刷新数据而不是让请求带着旧数据打到后端被驳回。这个小校验能省很多无谓的接口调用用户的体感也会更好。5. 运行时最常踩的五个坑现象、原因、解决方案逐个说这一章把本地运行里最容易翻车的场景列一遍每条都按“现象 → 原因 → 解决”整理这些都是拆类似项目时反复遇到的问题。5.1 现象前端请求后端报 CORS 跨域或直接 404现象浏览器控制台出现 CORS policy 报错或者请求发出去了但返回 404。原因前端 devServer 端口常见 3000和后端端口8080不同前端 axios 又写了绝对地址浏览器做了跨域拦截如果路径带了 /api 但代理没配上请求会被转发到后端不存在的接口返回 404。解决前端 baseURL 改成相对路径 /api并在 vue.config.js 配好 proxy。后端若想直接解决跨域可以加 CorsFilter 配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(http://localhost:3000) .allowedMethods(GET, POST, PUT, DELETE); } }注意前端代理和后端 CORS 二选一即可。两者同时开时某些浏览器会对预检响应做二次校验反而报错表现问题为“有时候通有时候不通”很容易误判成偶发 bug。选择代理方案更干净因为部署到生产时前端和后端往往同源代理逻辑可以直接淘汰。5.2 现象场次时间显示跟数据库差 8 小时现象数据库 start_time 是 19:00前端页面显示 11:00或者反过来差 8 小时。原因JDBC 连接时未指定 serverTimezone或 Spring Boot 序列化 LocalDateTime 用的时区不是东八区。两处时区不一致数据库时间和接口返回时间就会错位。解决数据源 url 加 serverTimezoneAsia/Shanghai同时 application.yml 配置 Jackson 时区spring: jackson: time-zone: GMT8 date-format: yyyy-MM-dd HH:mm:ss改完重启后端看接口返回 JSON 里的时间字段是否还带 T。不带 T 且对应东八区是正常状态如果带 T 或差了整小时再检查数据库连接参数。这个坑在 MySQL 8 里尤其高发因为它的默认时区设置和旧版本差别很大。5.3 现象两个用户同时抢同一个座位两条订单都建成功现象浏览器开两个窗口用不同账号同时选同一个座位两边都提示下单成功座位图里却只有一个显示锁定。原因锁座逻辑写成了先查再改。并发时两个请求同时读到 status0先后都执行了更新第二个请求没有得到数据库的约束。SELECT 到 UPDATE 之间的时间窗口就是超卖漏洞。解决换成带条件 UPDATE把 status0 条件和座位坐标一起写进 WHERE受影响行数非 0 才算锁座成功update idlockSeat UPDATE seat SET status 1 WHERE session_id #{sessionId} AND row_no #{rowNo} AND col_no #{colNo} AND status 0 /update同时给创建订单方法加 Transactional锁座和订单插入在同一事务任何一步失败整体回滚。更保险的一层是给 order_info 加唯一索引防重订单三层做下来基本没漏洞。5.4 现象前端打包后放进 SpringBoot 的 static 目录刷新页面 404现象npm run build 后的 dist 文件拷贝到 src/main/resources/static 下重新打包启动首页访问正常点击路由跳转也正常但直接刷新 /movie/3 或 /order 页面出现 SpringBoot 的 Whitelabel Error Page。原因Vue 用了 history 模式前端路由路径在浏览器地址栏是真实 URL刷新时浏览器直接请求该路径后端没有匹配的 controller返回 404。hash 模式 URL 带 #刷新不会打到后端但地址栏不美观很多项目还是会开 history。解决后端加一个转发规则非 /api 开头且不带文件后缀的请求统一转发到 index.html交给前端路由接管Controller public class IndexController { GetMapping(value {/{path:[^\\.]*}, /{path:^(?!api$).*}/**/{path:[^\\.]*}}) public String forward() { return forward:/index.html; } }这里的正则特意排除了带点号的路径js、css、图片等静态资源不会被误转发。如果上传后仍然 404确认前端 dist 里的 index.html 真的被放进了 classpath而不是被构建工具清掉或覆盖。这个问题在把前端打包放进 SpringBoot 时几乎必踩一遍记住这个 ForwardController 就能绕过去。5.5 现象数据库导入后中文乱码电影名全部变成问号现象导入 .sql 文件后查询 movie_info 表title 字段显示 ??? 或一堆乱码符号。原因SQL 文件本身的编码不是 UTF-8或 MySQL 连接字符集不对。Windows 环境下很多 .sql 文件默认 GBK 编码直接导入表里落了一堆乱码后面查出来自然也是错的。解决先在 MySQL 侧执行 SET NAMES utf8mb4;再用支持编码转换的方式导入。用文本编辑器打开 .sql 查看右下角编码如果是 ANSI 就另存为 UTF-8 再导入。导入后检查表的字符集ALTER TABLE movie_info CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;然后重新导数据用 SELECT title FROM movie_info LIMIT 5 验证。乱码问题一旦在底层出现不只是导数据的问题字符集不对会导致后续所有中文写入都出问题必须从建库字符集开始统一。6. 进阶实操给这套系统补上缓存和超时释放并验证完整链路系统能跑以后往生产方向推一步还需要两件事热点数据进 Redis、锁座超时自动释放。这两件事在这个业务场景里价值最直接改动量也不大。6.1 缓存热门电影列表五分钟级缓存加手动失效电影列表和场次列表是典型的读多写少适合加缓存。用 StringRedisTemplate 存 JSON 是成本最低的方式不需要引入额外的缓存框架。Service public class MovieService { Autowired private StringRedisTemplate redisTemplate; public ListMovieInfo getHotMovies() { String key hot:movies; String cached redisTemplate.opsForValue().get(key); if (cached ! null) { return JSON.parseArray(cached, MovieInfo.class); } ListMovieInfo list movieInfoMapper.selectList( new LambdaQueryWrapperMovieInfo() .eq(MovieInfo::getStatus, 1) .last(LIMIT 10) ); redisTemplate.opsForValue().set( key, JSON.toJSONString(list), 10, TimeUnit.MINUTES); return list; } }Redis key 命名加业务前缀方便管理比如 hot:movies、session:1:seats不同业务的数据不会互相撞 key。缓存时间设 10 分钟是均衡值电影列表不需要秒级最新。如果管理员后台上架新电影想立即生效在上架接口里手动调用 redisTemplate.delete(key) 删缓存而不是等自然过期。StringRedisTemplate 序列化方式就是字符串JSON 存取不会出现类型转换问题比 RedisTemplate 默认的 JDK 序列化省心很多。6.2 验证完整链路从建场次到锁座、下单、超时释放最后用命令把核心链路验证一遍。这个方法比页面点击可靠能直接看到每个接口的返回状态也方便定位是后端问题还是前端渲染问题# 管理员登录获取 token curl -X POST http://localhost:8080/api/login \ -H Content-Type: application/json \ -d {username:admin,password:123456} # 登录响应里取到 token 后查询场次 curl -X GET http://localhost:8080/api/session/list \ -H Authorization: Bearer token # 对返回的第一场次锁座 3排5座 curl -X POST http://localhost:8080/api/seat/lock \ -H Authorization: Bearer token \ -H Content-Type: application/json \ -d {sessionId:1,rowNo:3,colNo:5}锁座成功后查询订单表确认订单是待支付状态再查 seat 表确认这一行 status 变成 1。超时释放用定时任务或手动执行 SQL 验证UPDATE seat SET status 0 WHERE status 1 AND lock_time NOW() - INTERVAL 15 MINUTE执行后重新查刚才的座位status 应该回到 0前端刷新后座位恢复可用。释放逻辑要注意一个前提释放前确认对应订单仍是待支付状态不能把已支付订单的座位释放掉SQL 里加一个 NOT EXISTS 子查询排除掉已支付订单关联的 seat_id。这套验证流程我每次接手类似项目都强制走一遍先接口层确认后端行为没问题再打开页面看渲染结果。直接点页面遇到问题时会分不清是后端接口返回了脏数据还是前端渲染写错排查成本高很多先 curl 跑通核心链路前端页面再出问题就只可能是渲染层的事定位范围缩小一大半。从那以后我拿到任何 SpringBootVue 源码第一件事永远是先把锁座、下单、释放三个关键接口用 curl 验证一遍再碰页面代码这套习惯让我拆项目又快又稳希望帮到你。本文还有配套的精品资源点击获取