简介一套基于Spring Boot与Vue 3构建的全栈影院票务系统面向影院运营人员、开发学习者与毕业设计使用者覆盖电影排片、在线选座、会员积分、票房统计与多终端适配等核心业务。资源共310个文件、约16.23MB以Java后端源码、Vue前端页面、XML及JS配置脚本为主辅以图片素材和项目说明文档目录结构清晰便于导入与二次开发。已有78人学习浏览。压缩包内含系统前后端完整代码、环境配置、说明文档与附赠资料可帮助读者理解从排片到购票、会员和票房统计的完整链路也适合作为相关课程设计、毕业设计或中小型影院信息化建设的参考。 最近把一套影院电影售票管理系统完整地捋了一遍技术栈是很经典的 SpringBoot Vue3 前后端分离功能覆盖电影排片管理、在线选座购票、会员积分、票房统计分析、后台管理、移动端响应式适配这一整套闭环。如果你正在找全栈实战项目练手或者小团队想快速搭建一个票务类平台这篇文章应该能帮你避开不少弯路。我不打算讲那种“照着敲一遍就完事”的教程而是把这类系统最容易被忽视的设计决策和踩坑记录摊开聊。这个项目从表面看是“卖电影票”但实际做下来你会发现它更像一套需要同时处理好库存、并发、权限、统计、多端适配的中型业务系统。下面按我当时的设计顺序把这套系统拆开讲清楚。1. 项目拆解五大业务域是如何串起来的1.1 从“卖票”到“经营”模块之间到底在流转什么很多初学全栈的人会把“售票系统”理解成一张订单表加一个座位表真正画实体关系图的时候才发现核心数据模型远比想象中复杂。在这套系统里最基础的域是影院和影厅。影厅不能只记一个名字它需要携带座位模板也就是几排几列、哪些座位是情侣座或无障碍座、哪些位置被柱子遮挡不售卖。座位模板是后续排片和选座的基础建议单独建一张seat_layout表不要把座位信息直接塞进影厅表里否则后面做排片、锁座、统计都会非常别扭。在影厅之上是排片域。排片做的事是“把某部电影在某个影厅的某个时间段变成一场可售卖的场次”。这里的核心不是简单的增删改查而是冲突检测同一个影厅在同一段时间里不能排两场连换场保洁时间也要考虑进去。排片域产出的schedule表是后面所有业务的数据源头。再往外是交易域也就是选座购票。用户看中某一场次后系统要锁定具体座位、生成订单、处理支付并把座位状态从“可售”改成“已售”。这个域的难点在并发控制也是后面我会单独展开的部分。交易产生数据之后会员域和统计域才有意义。会员域管积分获取和消耗统计域从订单数据里提炼出票房、上座率等经营指标。所以你可以把整个系统看成一条单向链路影厅座位 - 排片场次 - 选座订单 - 积分与票房。模块之间通过订单号、场次ID、用户ID这些外键关系串联任何一环数据不规范下游统计就会跟着错。1.2 为什么是 SpringBoot Vue3而不是其他组合选型这种事没有绝对标准但在这个项目场景下SpringBoot 加 Vue3 是最稳的组合原因有三。第一SpringBoot 的生态可以把后端开发成本压到很低。你需要用户认证引入 Spring Security 或 Sa-Token需要操作数据库JPA 或 MyBatis-Plus 随便挑需要缓存热点场次数据Spring Data Redis 直接接入。这就是为什么标题里会强调“SpringBoot”而不是“SSM”——虽然 SSM 也能做但配置成本摆在那里中小型全栈项目真没必要跟配置文件较劲。网上一堆“SpringBoot版本太高”的问题本质也是因为它迭代快、生态复杂但这恰恰说明用的人多踩坑资料也全。第二Vue3 的组合式 API 对这种多业务模块的系统非常友好。排片管理、会员积分、票房统计各有各的逻辑如果用 Options API 很容易在几十个组件里写出一堆 mixin 纠缠不清。Vue3 的setup语法配合 TypeScript可以把每个业务模块的逻辑收敛成独立的 composable比如useSchedule.ts、useSeatPicker.ts维护体验比 Vue2 时代好太多。另外现在 Vite 几乎是 Vue3 项目的标配开发服务器启动速度快到离谱热更新也顺滑。第三前后端分离后后台管理和移动端可以共用同一套接口。后端起 SpringBoot 提供 REST API前端一个 Vue3 项目里同时搞定 PC 后台和移动端页面只是通过路由和响应式布局区分设备界面。这套模式很成熟也方便以后如果要做小程序或 App直接复用同样的后端接口。2. 排片管理与在线选座两个最容易出事故的模块2.1 排片冲突检测一张场次表里面的时间计算排片管理表面上只是做schedule表的增删改查真正棘手的是冲突检测。打个比方1号厅在 14:00 到 16:00 放《流浪地球3》你就不该再往 1号厅塞一个 15:50 开场的《满江红》哪怕它的时长只有90分钟也不行因为同一影厅同一时间段只能有一场。更麻烦的是跨天场次比如一部电影从 23:50 放到第二天 02:10如果结束时间直接用DATE类型而不是DATETIME跨天判断就会崩。我当时设计的schedule表大致长这样CREATE TABLE schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, film_id BIGINT NOT NULL COMMENT 影片ID, hall_id BIGINT NOT NULL COMMENT 影厅ID, start_time DATETIME NOT NULL COMMENT 开场时间, end_time DATETIME NOT NULL COMMENT 预计结束时间, status TINYINT DEFAULT 1 COMMENT 1待开场 2已开场 3已结束 4已取消 );在新增或编辑排片时后端要做一次重叠区间查询SELECT COUNT(*) FROM schedule WHERE hall_id #{hallId} AND status IN (1, 2) AND start_time #{newEndTime} AND end_time #{newStartTime}这个判断逻辑是“新场次开始时间早于已有场次结束时间且新场次结束时间晚于已有场次开始时间”只要查询结果大于0就说明存在重叠。需要额外留意的是这个条件天然覆盖了包含、部分重叠、完全重叠三种情况比单纯比较start_time是否在后一场次区间内要严谨。2.2 在线选座的并发与一致性锁座、扣库存、订单状态选座是整个系统里并发压力最大的地方。同一场电影开票时几百个用户同时盯着一个座位谁先下单谁得。最粗暴的做法是给整张schedule表加锁但这会让同一场次的所有用户互相阻塞体验极差。我的方案是分三层处理。第一层用 Redis 做分布式锁或原子扣减座位库存。注意这里的“库存”不是普通数字而是座位级状态。更常见的做法是直接把座位放入 Redis Hash选座时用 Lua 脚本原子地把座位状态从available改成locked这个操作可以保证同一座位不会被两个用户同时锁定。第二层数据库乐观锁兜底。即使 Redis 层出现极端异常数据库更新时也要带上状态条件UPDATE seat_occupancy SET status LOCKED, lock_user_id #{userId}, lock_expire_time #{expireTime} WHERE schedule_id #{scheduleId} AND seat_code #{seatCode} AND status AVAILABLE这个UPDATE的WHERE status AVAILABLE就是乐观锁的关键。如果返回的影响行数为0说明座位已经被别人锁走前端会立刻提示“座位已被选中”。第三层订单过期自动释放。锁座不能永久锁我设置了5分钟支付倒计时超时未支付会把座位状态改回AVAILABLE。这里需要有一个定时任务扫描超时订单并回滚库存同时把订单状态改成CANCELLED。这个环节最容易出现的坑是异步任务把刚支付成功的订单也取消了所以扫描时需要判断订单的支付状态和更新时间不能只凭创建时间。还有一点必须提醒支付回调要加上订单状态校验。一定要避免用户支付成功后因为回调延迟导致订单被当超时取消。通常的做法是支付回调更新订单状态时只允许“待支付 - 已支付”这个方向流转从业务层面堵住状态回退。3. 会员积分与票房统计业务规则要可配置数据要算得准3.1 积分系统把规则从代码里拆出来会员积分看起来简单无非是买票送积分、积分抵现但真正做进去就会发现业务规则变化比想象中快。今天买票送票价的10%明天可能改成定额赠送后天又加一个首单双倍积分。如果这些规则写死在业务代码里每次调整都要改逻辑发版本非常痛苦。我当时的做法是建一张积分规则表CREATE TABLE points_rule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, rule_name VARCHAR(64) NOT NULL, rule_type VARCHAR(32) NOT NULL COMMENT BUY_TICKET, REGISTER, RECHARGE, calc_type VARCHAR(16) NOT NULL COMMENT PERCENT, FIXED, calc_value DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 1, effective_start DATETIME, effective_end DATETIME );业务层只需要找到当前生效的规则按calc_type执行百分比或固定值计算即可。这样运营如果想做活动后台就能配置规则不用动代码。规则设计上我建议把积分获取和积分消耗做成两条链路避免“获取积分时把消耗积分也查出来”导致逻辑混乱。积分还有一个容易忽略的坑防重。用户注册送积分、购票送积分如果接口被重复调用就会产生重复积分流水。我当时在积分流水表加了唯一索引(user_id, biz_type, biz_id)biz_id就是订单ID或注册事件ID这样即使接口被并发调用数据库也能挡住重复发放。3.2 票房统计实时是面子准确是里子票房统计是这套系统的“经营仪表盘”但很多人的第一反应是直接对订单表做SUM和COUNT。小数据量时没问题一旦订单量上来后台首页每次打开都实时聚合数据库压力会非常大。这里的取舍是实时统计用于查看单场次、单订单这样的明细级数据汇总统计用于看经营趋势和排行榜。后者更适合通过定时任务或异步事件做聚合。我设计了一张box_office_daily表每个影片每天一条汇总记录字段包括影片名、当日票房、当日出票数、场均上座率。数据来源是订单支付成功事件通过消息队列异步更新这样既保证最终一致又不会因为统计逻辑拖慢主流程。统计维度要提前想到三个按影片、按影厅、按时间段。按影片能看出哪部片子是票房主力按影厅能发现哪个厅利用率低按时间段能够分析高峰时段方便排片调整。报表接口我建议设计成可组合的条件查询不要一个接口一把梭。这里还有一个容易尴尬的细节时区。如果服务器是 UTC数据库存的是DATETIME且不带时区统计“今日票房”时很可能把昨天晚上的订单丢出去。我当时统一要求所有时间字段用LocalDateTime配合系统时区并在 SQL 查询时显式指定日期范围才没有在最后联调时被财务数据坑到。4. 多终端适配与后台管理前端核心问题不只是样式4.1 移动端响应式别把“手机能打开”当成适配完成标题里写了“移动端响应式设计”很多人第一反应就是媒体查询换断点。实际做完这个项目我的体会是移动端适配的最大难点在交互重构不在样式。以选座页面为例PC 端可以用大屏展示整个影厅座位矩阵鼠标悬停还能显示座位号。到了手机上屏幕宽度只有不到400像素如果只是把座位格子等比缩小用户根本看不清座位位置手指点选也很容易误触。我当时针对移动端做了两个关键调整。第一座位矩阵增加缩放和拖拽平移能力默认展示影厅中间区域用户可双指缩放查看边缘座位。第二选座完成后底部固定一个订单确认栏显示已选座位和金额。Vue3 里实现这些交互组合式 API 写起来很顺畅把手势状态放在ref里再把计算逻辑集合成 composable组件的模板区会非常干净。另一个实际细节是安全区适配。iPhone 的底部小黑条会遮挡固定栏需要在页面底部加上env(safe-area-inset-bottom)的 padding。这个问题不跑真机很难发现但在移动端实际用户里非常常见。还有移动端网络环境波动大选座接口请求时要做好 loading 和错误重试不能出现用户点了座位请求挂了界面却毫无反馈的情况。Vue3 里用v-loading指令或者自定义 composable 管理请求状态都可以关键是所有接口的 pending、success、error 三个状态都要有明确UI反馈。4.2 后台管理权限动态路由和按钮权限要一起做后台管理这块光有菜单栏布局是不够的权限模型才是核心。这套系统的用户身份分三类超级管理员、影院运营、普通售票员。超级管理员能配置影厅和排片运营能改影片信息和活动售票员只能办理线下取票和退票。如果用简单的v-ifrole admin去做后期角色一多就全是屎山。推荐用 RBAC 模型把权限点落到菜单和按钮上。前端登录后拿到用户角色再从后端请求动态路由表用 Vue Router 的addRoute把有权限的页面动态注册进去。这样用户没有权限的菜单不会出现在侧边栏而且直接手敲 URL 也无法访问因为没有对应路由。但注意前端动态路由只是用户体验优化真正的安全边界必须靠后端。我在后端的每个管理接口上都加了PreAuthorize或类似的权限注解比如删除排片的接口只有ADMIN能调。为什么必须这样因为前端路由再花哨也挡不住有人直接伪造请求调接口。别把权限安全寄托在前端隐藏菜单上。动态路由还有一个细节刷新页面后Vuex 或 Pinia 里的路由信息会丢失需要重新拉取。我当时在pinia里存了一个isRoutesLoaded标志位在路由全局守卫里判断如果为false就先请求动态路由再放行。这个逻辑不写用户一刷新就跳回登录页体验非常糟糕。5. 版本、打包与部署从版本过高到 Docker 落地5.1 SpringBoot 版本与 JDK 的匹配关系先看清楚再开工网上关于“SpringBoot版本太高”的吐槽我这次也真实遇到了。新项目如果直接拉最新的 SpringBoot 3.x需要 JDK 17 起步而很多团队的生产服务器还在用 JDK 8。如果公司强制 JDK 8你就只能选 SpringBoot 2.7.x。这本身没有对错但动手前一定要先确认目标运行环境。这里顺便给一个简单的版本对照参考SpringBoot 版本最低 JDK 版本适合场景2.7.xJDK 8老项目兼容、公司强制 JDK 83.0.xJDK 17新项目、想用 Jakarta EE 命名空间3.2.xJDK 17 / 21新项目、追求较新的生态如果你从 SpringBoot 2.x 升到 3.x还有一个隐藏变化javax.*包全部改成了jakarta.*。这意味着很多老依赖要跟着升级比如springfox可能直接不兼容得换成springdoc-openapi。所以如果不是必须要用 SpringBoot 3不建议在生产环境为了“新”而升级。5.2 前后端分离部署CORS、Dockerfile 和配置隔离前后端分离后第一个要解决的是跨域。开发环境可以用 Vite 的proxy把/api代理到后端地址这样浏览器看到的请求是同源的。但生产环境如果前端和后端域名不同还是得靠后端配置 CORS。最省事的写法是后端加一个配置文件里的白名单cors: allowed-origins: - http://localhost:5173 - https://admin.example.com不推荐直接用allowed-origins: *因为涉及到登录态的 Cookie 跨域时通配符会导致浏览器拒绝携带凭证。部署打包这里SpringBoot 官方场景一般会用 Maven 打成可执行 JAR然后用 Docker 运行。网传“SpringBoot JDK1.8 打包到 Docker Desktop”本质上就是多阶段构建FROM maven:3.8-openjdk-8 AS build WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM openjdk:8-jre-slim WORKDIR /app COPY --frombuild /app/target/cinema-system.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]多阶段构建的好处是最终镜像里不包含 Maven 和源码体积能小一大半。如果你用的是 SpringBoot 3.x把基础镜像换成eclipse-temurin:17-jre就行。最后一个实践建议把环境配置外置。数据库连接、Redis 地址、积分开关这些配置都通过环境变量注入不要在 JAR 包里写死。比如spring: datasource: url: jdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME}这样同一套打包产物开发、测试、生产三个环境直接用不同环境变量跑不用每个环境重新打包。我在做这个影院系统时光是“为了多环境配置频繁改代码重新打包”这个事就折腾过很久后面彻底改成环境变量注入才消停。最后再分享一点实在的完整跑通一套 SpringBoot Vue3 全栈项目最大的收获其实不是“把功能做完了”而是理解了模块之间如何协同。排片数据有一点异常选座页面就会出问题订单状态有并发漏洞票房统计就会对不上权限模型没想清楚后台管理上线就是事故现场。这些东西在单个技术点教程里很难体会到只有亲手把一条完整业务链路串起来才会真正形成全栈思维。如果你也打算照着类似标题的项目去练手我的建议是从业务模型梳理入手先画清楚表结构和状态流转再写代码。排片、选座、积分、票房的顺序也很适合当作开发路线每完成一个模块都能立刻看到业务效果。希望这篇复盘能帮你少走几步弯路。本文还有配套的精品资源点击获取