写这套 SpringBoot+Vue 电影院购票系统的过程，我是当成一次完整的产品开发来做的。前后端分离、RESTful 接口、JWT 鉴权、基于状态机的订单流转，每一项都踩过坑，也都有可以直接复用的经验。这篇文章从项目设计到模块拆分，到部署运行，到高频问题的排查思路，把完整的实操过程拆开来讲。无论你是拿它做参考，还是想二次开发，读这一篇基本能把整个项目的来龙去脉和细节吃透。
1. 项目整体设计与架构拆解
1.1 为何选择前后端分离的 SpringBoot+Vue 组合
先聊技术选型。做毕设或者个人项目，最稳妥的组合就是 SpringBoot 做后端、Vue 做前端，这是今天的 Java Web 项目事实上的标准方案，没有之一。理由其实很朴素：
第一，SpringBoot 的自动配置机制和内嵌容器特性，极大降低了工程搭建的成本。过去用 SSM 框架要手写一堆 XML 配置，现在基本上引入依赖、写几个配置项就能把项目跑起来，你只需要把精力集中在业务逻辑层。整个后台的编写成本可以压缩一半以上。
第二，Vue 在前端生态里的学习曲线相对平缓，配合 Element UI 组件库，像管理后台这类以表格、表单、弹窗为核心交互的系统，开发效率和代码可维护性都很高。数据驱动视图的理念在购票选座这类强交互场景下非常有优势。
第三，前后端分离带来的调试便捷性是传统 JSP 模板填没法比的。前端用 Axios 调后端接口，后端通过 Postman 做接口自测，两边可以完全并行开发。
这套系统我采用的是 SpringBoot 2.7 版本，搭配 MyBatis Plus 作为 ORM 框架，JWT 作为无状态登录凭证，MySQL 8.0 存储业务数据，前端则选用 Vue 2 加上 Element UI 2.x。为什么不追 Vue 3 和 Element Plus？这不是保守，而是站在资料丰富度和生态兼容性角度看的，Vue 2 的相关案例和踩坑记录要比 Vue 3 多得多，后续遇到任何问题都更容易搜到解决方案。
1.2 数据库设计：六张核心表如何支撑完整购票链路
数据模型是这类系统最见功夫的地方。影院购票系统的核心链路很清晰：用户消费影片资源，影片在特定场次和影厅中排映，用户为某个场次选定座位并完成支付。围绕这条链路，我设计了以下六张核心数据表：
- 用户表：保存账号、密码、手机号、角色标志。角色分为普通用户和系统管理员，后台上可以直接操作角色权限。
- 影片表：包括电影名称、导演、主演、简介、上映日期、片长、语言版本、海报地址、状态。状态有正在热映、即将上映、已下架三个枚举值。
- 影厅表：保存影厅名称、影厅类型（IMAX/巨幕/普通厅）、座位行数、座位列数。选座页面的座位矩阵完全由这张表驱动。
- 排期表：上映的场次信息，关联影片、影厅、放映时间、结束时间、标准票价。这是整个系统信息密度最高的一张表，也是并发压力集中的位置。
- 订单表：记录用户购票记录，关联用户、排期、观影人姓名电话、下单时间、支付状态、取票码。
- 座位表：记录某个场次的具体座位占用情况，关联排期、行号、列号、锁定状态、所属用户。
这六张表之间存在两个关键联查：一个是排期关联影片和影厅，用来拼装场次列表和座位矩阵；另一个是订单关联排期、影片、影厅和座位，用来拼装用户的历史订单详情。另外我额外设计了一张轮播图表，存放网站首页的轮播图片和跳转链接，将首页展示和后台配置进行解耦。
锁座逻辑是这个项目的灵魂。一个用户在选座操作时，系统会为这个排期的座位创建锁定记录，锁定状态在若干分钟内有效，超时会自动释放。座位表里我设计了一个status字段，取值为0表示可选，1表示锁定，2表示已售出。这种状态流转背后其实对应着一条并发业务链路。
2. 核心功能模块与业务逻辑拆解
2.1 用户认证与权限控制方案
用户认证这块我选择的不是传统 Session 方案，而是 JWT。前后端分离架构下，用 JWT 的直观好处是服务端不需要维持会话状态，用户登录成功以后，后端签发一个带有过期时间的 token 返回，前端每次请求都在请求头里携带这个 token，后端通过拦截器校验 token 的合法性，就能解析出当前用户信息。
用户角色这块需要细致处理。如果只做单管理员，直接在用户表里维护一个role字段就行。但我做的是三层角色模型，普通用户、票务员、系统管理员。票务员可以在后台进行排期管理和订单管理，但不能修改影片信息；系统管理员拥有全部权限。这三层权限通过前端路由拦截和后端接口拦截双层控制实现。
前端用的是 Vue Router 的beforeEach导航守卫，在跳路由时取出本地存储的 token 和角色信息，如果访问的是后台管理页面但不是管理员角色，直接重定向到登录页。后端的实现则是定义了一个自定义注解@RequireRole配合 Spring AOP 做切面拦截，被注解标记的接口只能由指定角色访问。
实际开发过程中，这里最容易被忽视的是 token 过期的处理策略。我设计的流程是拦截器校验 token 和角色两重验证，一旦过期返回 401 状态码，前端 Axios 全局拦截器统一捕获 401，清除本地登录信息并跳转登录页。这种统一处理的方案能避免在每个页面写重复的登录失效判断逻辑，代码干净可靠。
2.2 选座购票的核心流程与状态机设计
选座购票是整个系统最复杂的业务流程，也是我花时间最多的地方。完整的购票流程是这样的：
- 用户在影片详情页点击“选座购票”，进入场次列表，选择时间和影厅。
- 选座页面通过接口获取座位矩阵，座位按行号和列号排布。
- 用户点击可选的座位，选中后座位颜色变化，系统在前后端都暂存这个选座意向。
- 点击“确认购买”，前端携带座位列表、排期 ID、用户 ID 向后端发起下单请求。
- 后端创建订单记录，生成取票码，并对选中的座位进行锁定。
- 用户点击“立即支付”，系统执行虚拟支付逻辑，订单状态改为已支付，座位状态永久变更为已售。
这个流程中的关键是把“选座”和“下单”拆成了两个动作。用户选座的瞬间并不直接锁定座位，而是到点击“确认购买”的时候才真正通知后端锁座。为此我在前端状态管理里维护了一个“正在选座的座位列表”，并在 Vuex 中保存了当前的排期 ID 和影片信息，后端则通过座位锁定的方式防止并发冲突。
后端锁座用的是一个双层保障方案。第一层是应用层锁，用一个ConcurrentHashMap维护排期 ID 到锁对象的映射，同一个场次的锁座请求会在应用层串行化；第二层是数据库层唯一约束，座位表在schedule_id + row + col三个字段上建立唯一索引，避免同一次放映中同一个座位出现两条占用记录。
订单状态我用了一个状态机来管理。初始状态为待支付，订单创建后计时 15 分钟，如果用户未支付，系统在查询接口会判断订单超时，将关联座位状态设置为未锁定，订单标记为已取消。支付成功则进入已支付状态，到用户确认观影后订单完结。
2.3 影片排期与首页推荐逻辑
排期管理是后台使用频率最高的功能，也是信息组织的关键环节。排期操作时，后台管理员选择影片、影厅、放映时间，系统根据影片片长自动计算结束时间。这里我做了两件小事，保证了后续功能的数据完整性：
- 结束时间不允许手动填写。系统根据影片表里的
duration字段自动计算，减少人工误差。 - 同一影厅在时间上不允许重叠排期。新增排期时，后端会对比该影厅已存在的所有排期时间范围，如果时间冲突，直接返回“该影厅在此时段已有放映计划”的提示。
首页推荐不是硬编码的。我在影片表里增加了一个is_recommend字段，后台可以手动标记推荐位。首页按推荐状态和上映状态取数据，推荐影片排在最前，配合轮播图展示。热门影片的排序则通过订单数量实时计算，用一条聚合 SQL 统计每部影片的票房订单数和销张数，按数值倒序排。
3. 工程配置、环境准备与启动运行全流程
3.1 环境配置清单与项目结构
这个项目的同步依赖项不多，底子很干净。以下是实测可用的开发环境清单：
| 环境项 | 版本建议 | 备注 |
|---|---|---|
| JDK | 1.8+ | 推荐 1.8 长期支持版 |
| Maven | 3.6+ | 管理后端依赖 |
| Node.js | 14.x / 16.x | 管理前端依赖 |
| MySQL | 8.0+ | 数据库，5.7 也兼容 |
| Redis | 可选 | 做缓存与分布式锁时使用 |
| IDE | IDEA / VS Code | 后端用 IDEA，前端用 VS Code |
项目整体采用经典的前后端分目录结构。后端部分按controller、service、mapper、entity、config、common分包，前端部分按api、views、router、store、components分包。这种分包方式方便导航，也让代码职责边界清晰。
项目会压缩包中直接提供完整源码和 SQL 脚本，拿到手之后按顺序执行以下步骤即可完成本地部署。首先创建数据库，执行 SQL 脚本。脚本中包含了建库、建表和初始化数据三大部分，初始化数据里内置了若干条影片、影厅、排期示例数据和一个管理员账号。
其次在后端配置文件application.yml中调整数据源信息，包括地址、账号、密码。确认无误后启动 SpringBoot 主类。后端默认端口为8080。
再接着进入前端目录，执行依赖安装命令npm install，安装完成后执行npm run serve启动开发服务器，默认访问地址为localhost:8081。开发环境下前端会通过代理转发/api开头的请求到localhost:8080后端服务。
最后用浏览器访问前端地址，管理员账号登录后即可进入后台管理页面。
3.2 前后端联调时的跨域与代理配置
前后端分离最绕不开的问题是跨域。开发环境下，前端请求后端接口时，由于两个服务属于不同端口，会触发浏览器的跨域限制。解决方案有两种，我在项目里是同时做了，兼顾不同启动方式：
后端的跨域配置是写一个配置类，实现WebMvcConfigurer，在addCorsMappings方法中设置允许来自http://localhost:8081的跨域请求，并允许携带凭证。跨域配置需要放在全局位置，不能只放在单个 Controller 上，那个只是局部方案，容易被后来的接口覆盖遗漏。
前端的代理配置在vue.config.js里的devServer.proxy项，将/api前缀的请求转发到后端实际的地址。这种代理方案不仅让开发环境下的请求路径变得简洁统一，还能避免随意放开跨域限制带来的安全问题。需要注意的是，代理只在开发服务器生效，打包部署到生产环境后就需要用 aingx 等服务器软件的转发能力解决。
3.3 接口文档阅读与调用指南
项目附带接口文档，但很多人拿接口文档不知道从哪里入手。我来说几个我实测后认为最关键的阅读方法。
接口文档按模块分类，涉及影片模块、排期模块、订单模块、用户模块和后台管理模块。每个接口都会标注请求方式、请求路径、请求参数和返回结构。拿到文档后，优先看用户登录和影片列表这两个接口，把请求和响应的结构理解了，其余接口基本可以触类旁通。
文档里的返回结构统一为code、message、data三段式。data字段是业务数据的实体，比如订单列表接口的data是一个包含订单集合和总数的对象。前端 axios 响应的拦截器里如果判断code不为零，会直接弹出对应错误提示，这层封装省去了在每个业务请求中写错误处理。
接口调试推荐使用 Postman 或者 Apifox。文档中每个接口都提供了示例参数值，复制到工具里修改成实际数据就能调用。调试时先不携带 token 测试公开接口，登录成功拿到 token 后，在工具的请求头里添加Authorization字段，从而测试受保护接口。
4. 开发过程中的高频问题与排查实录
4.1 前端页面白屏与路由加载失效
项目在前后端进行整合之时，会遇到前端页面刷新后出现白屏，或者路由跳转后组件渲染不出来的问题。这类问题的排查思路相对固定。
首先是检查 Vue 路由的mode是history还是hash。项目初期选用history模式时，后端没有对前端路由做重定向支持，刷新页面就会被后端 404 拦截，我直接改成了hash模式，开发和部署时都不会再出现刷新白屏的问题，成本最低。
其次是路由懒加载的坑。使用动态 import 语法加载路由组件时，如果代码里引入了错误的路径，Webpack 在编译期不会报错，但运行时组件加载失败就会导致白屏。排查时打开浏览器的开发者控制台，查看 Network 面板中加载失败的 js 文件，再回到路由配置里逐一核对路径。
4.2 数据库时区与时间存储异常
影院购票系统对时间敏感，排期、订单创建时间、支付超时判断都依赖准确的时间数据。开发过程中，我遇到的一个很典型的问题：本地插入数据库的时间比当前时间少了 8 小时。这个问题的根源是 MySQL 连接的时区参数配置。
解决方式是后端 JDBC 连接串中显式声明时区参数。在application.yml的数据库连接 URL 末尾增加serverTimezone=Asia/Shanghai即可解决。如果用高版本的 MySQL 驱动，还要确认数据库服务器的默认时区设置，可以通过 SQL 语句查询当前全局时区。另外，建议数据表的时间字段统一采用datetime类型，与 Java 侧的LocalDateTime字段类型直接映射，省去转换过程，也规避掉java.util.Date的时区陷阱。
4.3 并发抢座超售的隐蔽 Bug
这个小标题值得单独拿出来讲，因为它不是靠代码 review 就能及时发现的，更像是一门并发业务层面的隐性缺陷。
锁座的业务逻辑是：用户提交订单后，后端检查座位状态，若可选则设置为锁定，创建订单。这段逻辑在单机并发量很小的时候不会出问题，但一旦多个用户同时锁定同一个座位，可能会出现两条订单操作同时通过状态检查，进而都执行了更新操作。我在本地用多个浏览器模拟并发请求时复现了这种状况：日志里出现了同一个座位被两次成功锁定的记录。
排查并修复的思路分两层：先在这段业务方法上添加synchronized语义，通过常量字符串对排期 ID 加锁，让同一个场次的锁座操作在内存层串行执行；再在数据库层给座位表加复合唯一索引，从持久层兜底。这个组合方案在本地和测试环境进行并发压测后，没有再次出现超卖问题。
4.4 常见错误速查表
结合项目调试期间的积累，我整理了一个高频问题速查表，能够大幅缩短排查时间：
| 异常现象 | 可能原因 | 解决方案 |
|---|---|---|
| npm install 报错 | Node 版本过高或过低 | 切换 Node 版本至 14 / 16 |
| 前端接口 404 | 代理路径或后端 context-path 不一致 | 检查 vue.config.js 的 proxy 配置 |
| 登录后拿不到用户信息 | 拦截器路径放行配置错误 | 检查后端拦截器 excludePath 配置 |
| 数据库中文乱码 | 数据库连接未指定编码 | URL 添加 characterEncoding=utf8 |
| 座位锁定超时仍不释放 | 定时任务未启用 | 检查主类是否开启 @EnableScheduling |
| 订单支付状态不同步 | 前后端状态码约定不一致 | 统一支付状态枚举值 |
每条问题都对应着一次真实的调试经历。比如座位锁定超时不释放那个，最初查了很长时间，代码逻辑完全正确，但排查到最后才发现是主启动类漏了@EnableScheduling注解，导致定时释放任务压根没被扫描到。这种问题排查的价值就在于，经历的越多，后续踩坑的概率就越低。
5. 项目二次开发与扩展方向建议
项目跑通之后可以考虑二次开发。二次开发并不意味着推翻重来，而是基于现有结构和功能脉络，选择主干链路进行完善。
一个值得做的方向是接入真实支付。当前的支付流程属于模拟支付，即点击后直接更新订单状态、完成座位锁定。如果后续想要接入主流的第三方支付，可以把支付回调接口设计为独立模块，与订单模块解耦。支付回调本质上就是一个状态通知接口，收到回调后更新订单状态、修改座位表状态、向用户推送取票信息。
另一个方向是引入缓存中间件。当前场次列表是直接查询数据库的，访问量增加后，热门影片的场次接口会成为热点数据源。用 Redis 对电影列表、轮播信息、影厅排期做缓存，配合延迟删除策略，能显著提升接口性能。在开发环境引入 Redis 的成本不高，但对架构的完善价值非常大。
另外有人问我这个系统能不能接微信小程序。技术路线上完全可行，小程序的前端表现层换掉，复用现有后端接口即可。在后端接口方面，小程序只需适配登录鉴权方式，把登录逻辑改为 code 换 token 的模式，然后在业务层适配 JSON 返回结构，就能复用当前版本的底层逻辑。
这些扩展方向看起来复杂，其实起点都很小。拿接支付举例，你第一步只需要在订单表中加一个支付流水号字段，再写一个标识支付日志的表，后台异步接收回调数据，原有代码基本不需要改动。
写在最后
做完整套系统，最大的体会是：一个看似普通的毕设项目，真正的价值在于完整走了一遍从库表设计到接口联调的链路。购票链路涉及事务、并发、状态流转，这些在任何生产级项目里都是躲不开的主题，把它们在一套可控规模的代码中亲手实现了一遍，比看多少框架教程都有效。
如果你在用这套项目做参考或者二次开发，建议把完整的部署流程复现一遍，然后把选座锁座部分反复读几遍，理解清楚状态流转这个核心理念，再随手拆掉一个模块试试重新实现一遍。顺利跑通只是第一步，能在这个基础上自由地加功能、改逻辑，才算真正把这个项目的内容吸收进去了。
