最近我把一套 Spring Boot Vue MySQL 的音乐厅订票系统源码完整跑了一遍从数据库初始化到前后端联调最后成功在本地浏览器里完成注册、选座、下单整个流程。这套系统是典型的前后端分离结构后端提供 REST API前端负责页面渲染MySQL 做持久化存储三者拼起来就是一个可以演示、可以答辩、可以二次开发的完整项目。如果你正在找课程设计或毕业设计题目或者想入门 Spring Boot 全栈开发这份源码会是一个很好的参考样本。我也把运行过程中遇到的环境问题、版本坑、拦截器配置、跨域问题都整理出来了希望能帮你少走弯路。1. 项目整体拆解这个音乐厅订票系统到底做了什么1.1 核心业务需求与模块划分音乐厅订票系统的业务场景很清晰用户进入系统后可以查看演出列表点击某个场次查看详情选择座位并提交订单之后能在个人中心看到自己的订单记录。管理员这边需要维护演出信息、管理场次、查看订单列表。这个闭环覆盖了常见的 C 端电商交易流程虽然不涉及真实支付但业务完整性足够支撑一个漂亮的项目演示。我按常见实践把功能拆成两大端再加一个通用模块用户端注册、登录、演出列表、演出详情、场次选择、座位选择、下单、我的订单。管理端管理员登录、演出管理增删改查、场次管理、订单查看、用户概览。通用模块统一返回结果、异常处理、JWT 登录鉴权、跨域配置。前台用户端和后台管理端共用一个 Vue 工程通过路由和权限控制区分入口这样源码结构不会太臃肿也方便评委或老师快速看懂。很多类似的 JavaWeb 项目会把 admin 单独拆一个前端项目但对一个课程设计或小型毕业设计来说维护成本过高没必要。1.2 技术选型为什么是 Spring Boot Vue MySQL这个组合目前几乎成了 Java 全栈项目的默认搭配原因很简单Spring Boot 简化了 SSM 时代的各种 XML 配置内嵌 Tomcat打成 jar 包就能跑Vue 响应式开发体验好组件化让页面维护起来比 JSP 舒服太多MySQL 则是最常见、资料最多、安装部署最方便的数据库。我做选型时考虑过几个替代方案简单对比一下方案优点缺点适用场景Spring Boot Thymeleaf项目简单不用前后端分离页面和 Java 代码耦合重交互复杂时难维护快速做一个小型单体应用Spring Boot Vue前后端职责清晰页面交互流畅简历好看环境配置相对复杂需要处理跨域和打包课程设计、毕业设计、真实项目Spring Cloud 微服务版技术栈更“高级”部署成本高对这规模的项目是过度设计面试展示架构能力我需要补充一点如果你看到类似源码里用的是 Spring Boot 2.3.x 或 2.6.x不要觉得版本旧这两个版本在企业项目里非常稳定。Spring Boot 2.6.x 对 JDK 8 和 JDK 11 都支持配合 Vue 2 或 Vue 3 都能跑。我在初始化这套系统时用的就是 Spring Boot 2.6.x稳定性没问题。1.3 项目目录结构与运行形态拿到源码后第一件事是先看清楚目录结构。正常的“可直接运行”源码应该把后端、前端、数据库脚本三样东西分开放避免混在一起找不到入口。这套系统的目录大致如下sunshine-music-hall/ ├── backend/ # Spring Boot 后端 │ ├── src/main/java │ │ └── com/sunshine/ │ │ ├── controller/ # 接口层 │ │ ├── service/ # 业务逻辑层 │ │ ├── mapper/ # 数据库访问层 │ │ ├── entity/ # 实体类 │ │ ├── config/ # 配置类跨域、拦截器 │ │ └── common/ # 工具类和统一结果 │ ├── src/main/resources │ │ ├── application.yml │ │ └── mapper/ # MyBatis XML 文件 │ └── pom.xml ├── frontend/ # Vue 前端 │ ├── src/ │ │ ├── api/ # axios 请求封装 │ │ ├── router/ # 路由配置 │ │ ├── views/ # 页面组件 │ │ ├── store/ # 状态管理 │ │ └── main.js │ ├── package.json │ └── vue.config.js └── sql/ └── sunshine_music.sql # 建库建表脚本运行形态上后端和前端是两个独立进程后端跑在 8080 端口前端开发服务器跑在 8081 端口前端通过代理把 /api 请求转发到后端。开发阶段这样做非常舒服改前端代码浏览器热更新不用重启后端改后端代码用 devtools 自动重启两不耽误。如果以后要上线执行mvn clean package打成 jar 包前端npm run build生成静态文件放到 Nginx再把 Nginx 反向代理到后端端口一套标准部署流程就出来了。2. 后端设计Spring Boot 的骨架怎么搭2.1 数据库表结构设计MySQL数据库设计决定了一个项目能不能讲出东西。这套音乐厅订票系统我按常见实践拆成四张核心表用户表、演出表、场次表、订单表。由于座位选择不需要精细到每一个座位编号我用数据库行数控制库存用订单字段记录选择的座位文本这样既能演示锁库存逻辑又不会把项目复杂度拉得太高。下面是简化后的建表 SQL重点是注释里的设计思路CREATE DATABASE IF NOT EXISTS sunshine_music DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE sunshine_music; -- 用户表 CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 用户ID, username VARCHAR(50) NOT NULL UNIQUE COMMENT 用户名, password VARCHAR(100) NOT NULL COMMENT 密码BCrypt加密, nickname VARCHAR(50) DEFAULT COMMENT 昵称, phone VARCHAR(20) DEFAULT COMMENT 手机号, role TINYINT DEFAULT 0 COMMENT 0-普通用户 1-管理员, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间 ) COMMENT 用户表; -- 演出表 CREATE TABLE t_concert ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 演出ID, title VARCHAR(100) NOT NULL COMMENT 演出名称, performer VARCHAR(100) DEFAULT COMMENT 演出团体/艺人, venue VARCHAR(100) DEFAULT COMMENT 演出地点, show_date DATE NOT NULL COMMENT 演出日期, duration INT DEFAULT 120 COMMENT 时长分钟, description TEXT COMMENT 演出详情, poster_url VARCHAR(255) DEFAULT COMMENT 海报地址, status TINYINT DEFAULT 1 COMMENT 1-上架 0-下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间 ) COMMENT 演出信息表; -- 场次表 CREATE TABLE t_session ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 场次ID, concert_id INT NOT NULL COMMENT 所属演出ID, session_name VARCHAR(50) DEFAULT 默认场次 COMMENT 场次名称, start_time DATETIME NOT NULL COMMENT 开演时间, price DECIMAL(10,2) NOT NULL COMMENT 票价, total_seats INT NOT NULL COMMENT 总票数, available_seats INT NOT NULL COMMENT 剩余票数, FOREIGN KEY (concert_id) REFERENCES t_concert(id) ) COMMENT 场次表; -- 订单表 CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 订单ID, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单编号, user_id INT NOT NULL COMMENT 下单用户ID, session_id INT NOT NULL COMMENT 购买的场次ID, seat_info VARCHAR(200) DEFAULT COMMENT 座位信息如 A1,A2, ticket_count INT NOT NULL COMMENT 购票数量, total_price DECIMAL(10,2) NOT NULL COMMENT 订单总金额, status TINYINT DEFAULT 0 COMMENT 0-待支付 1-已支付 2-已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, FOREIGN KEY (user_id) REFERENCES t_user(id), FOREIGN KEY (session_id) REFERENCES t_session(id) ) COMMENT 订单表;有几点设计细节值得展开说说。第一密码字段用 BCrypt 加密存储数据库里不要存明文密码这是项目答辩时加分的安全意识。第二t_session 单独拆出来是因为同一场演出可以安排下午场、晚场等多个场次每个场次有不同的价格和库存。第三订单号用唯一索引生成规则可以用时间戳加随机数或 UUID演示时不用太复杂但逻辑上要保证不重复。2.2 后端接口设计从登录鉴权到下单锁票接口设计是后端最直观的体现。这套系统的接口按业务域划分全部返回统一结构包含 code、message、data 三个字段。统一返回结构非常重要前端拿到数据后只需要判断 code不需要每处都写异常解析代码会干净很多。核心接口清单如下接口路径请求方式功能说明是否鉴权/api/auth/registerPOST用户注册否/api/auth/loginPOST用户登录返回 token否/api/concert/listGET演出列表支持分页、关键词否/api/concert/detail/{id}GET演出详情 场次列表否/api/order/createPOST创建订单锁库存是/api/order/myGET当前用户订单列表是/api/order/cancel/{id}PUT取消订单释放库存是/api/admin/concert/savePOST新增/修改演出是管理员/api/admin/concert/delete/{id}DELETE删除演出是管理员/api/admin/order/listGET管理员查看所有订单是管理员接口定义要遵循几个原则路径用名词而不是动词请求方法用 RESTful 语义参数尽量用 DTO 对象而不是散乱的 Map。这套系统里登录成功后后端签发 JWT token前端把 token 存在 localStorage每次请求在 axios 拦截器里加上Authorization: Bearer token。需要权限的后端接口通过拦截器解析 token并在请求上下文中塞入当前用户信息。管理员接口额外检查用户角色不是管理员就返回 403。这个链路虽然简单但把前后端分离项目里的鉴权流程讲清楚了。2.3 核心业务代码逻辑库存扣减为什么会超卖如果只看增删改查这套系统和其他管理系统没什么区别。真正有价值的代码在于“下单”这个动作。音乐厅的场次有总票数和剩余票数两个用户同时抢最后一张票时如果代码只是先查询再更新就会出现超卖问题。我按照最常见的解决方案来写在 Service 里使用Transactional开启事务然后通过一条带条件的 UPDATE 语句完成库存扣减再插入订单记录。更新语句的 WHERE 条件带上available_seats ticket_count如果数据库返回的影响行数为 0说明库存不够直接抛异常回滚事务。对应的核心代码逻辑如下Transactional public Order createOrder(Long userId, Long sessionId, Integer ticketCount, String seatInfo) { Session session sessionMapper.selectById(sessionId); if (session null) { throw new BusinessException(场次不存在); } // 关键条件更新避免超卖 int rows sessionMapper.decreaseAvailableSeats(sessionId, ticketCount); if (rows 0) { throw new BusinessException(余票不足下单失败); } Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setSessionId(sessionId); order.setSeatInfo(seatInfo); order.setTicketCount(ticketCount); order.setTotalPrice(session.getPrice().multiply(BigDecimal.valueOf(ticketCount))); order.setStatus(0); orderMapper.insert(order); return order; }对应的 MyBatis 更新语句update iddecreaseAvailableSeats UPDATE t_session SET available_seats available_seats - #{ticketCount} WHERE id #{sessionId} AND available_seats #{ticketCount} /update这段代码看起来简单但它是整个项目最值得在答辩时讲的点。它用数据库的行锁和原子更新解决并发问题没有引入 Redis 分布式锁也没有使用悲观锁SELECT FOR UPDATE对一个单体项目来说性能足够而且逻辑好解释。如果要继续扩展只需在订单状态变更时反向恢复available_seats也就是取消订单时调用increaseAvailableSeats把库存加回去。2.4 配置文件与启动要点Spring Boot 的配置集中在application.yml。我给的默认配置里端口是 8080数据库连接为jdbc:mysql://localhost:3306/sunshine_music用户名密码是root/123456。实际使用中你只要改成自己机器的数据库密码即可。server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/sunshine_music?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.sunshine.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl jwt: secret: sunshine-music-hall-secret-key expire-days: 7这里的连接串参数值得注意useSSLfalse是因为本地 MySQL 8 如果没配置 SSL 证书直接连接会报SSL connection errorserverTimezoneAsia/Shanghai是因为 JDBC 驱动和 MySQL 服务器的时区不一致不指定的话插入时间会差几个小时。这些都是新手最容易遇到但网上答案又很零散的小问题。IDE 方面用 IntelliJ IDEA 社区版也能启动这个后端不需要专业版。你只需要安装 Lombok 插件然后在启动类SunshineMusicApplication上右键 Run。如果你习惯命令行在 backend 目录执行mvn spring-boot:run也可以。3. 前端设计Vue 页面如何对接后端3.1 前端工程结构与路由设计前端工程用的是标准 Vue 脚手架结构入口文件是main.js通过 Vue Router 配置页面跳转关系。路由对于前端来说等于后端的接口列表我建议先把路由梳理清楚再写页面否则组件多了之后很难导航。这套系统的路由配置大致如下const routes [ { path: /login, component: () import(/views/Login.vue) }, { path: /, component: () import(/views/Layout.vue), children: [ { path: , redirect: /home }, { path: home, component: () import(/views/Home.vue) }, { path: concerts, component: () import(/views/ConcertList.vue) }, { path: concert/:id, component: () import(/views/ConcertDetail.vue) }, { path: orders, component: () import(/views/MyOrders.vue) }, { path: admin, component: () import(/views/admin/AdminDashboard.vue), meta: { role: 1 } } ]} ];这里用了路由懒加载component: () import(...)会让每个页面在访问时才加载减小首屏体积。管理端路由配置了meta.role然后在全局路由守卫里判断登录状态和角色。如果你在源码里看到“动态路由”这个关键词原理就是先登录拿到用户角色再根据角色往路由表里添加对应页面更灵活但中小型项目直接写常量路由也够用。3.2 页面功能拆解列表、详情、选座、订单前端页面最核心的是演出列表页和演出详情页。列表页从/api/concert/list获取数据渲染卡片或表格点击卡片跳转到/concert/:id。详情页通过路由参数拿到演出 id再调用/api/concert/detail/{id}获取演出信息和场次列表。用户选择场次后页面上会生成一个座位示意图。我这里没有做复杂的 canvas 座位图而是按常见方案用二维数组模拟座位行和列。用户点击某个座位后该座位颜色变化再次点击取消选择。每次最多选 4 张票超过限制就弹提示。选中座位后把座位文字拼成“A1,A2”的形式连同场次 id 和数量一起提交给后端。这个交互用 Vue 的实现思路是data 中维护一个selectedSeats数组模板里嵌套v-for渲染行和列用:class动态绑定座位状态。座位状态有三种可选、已选、已售出。已售出的座位由后端返回的售出列表决定前端在加载场次时拿到不可选集合渲染时直接禁用。3.3 axios 请求封装与跨域处理Vue 项目里不会直接用裸 axios 到处发请求而是在src/api/request.js里统一封装一个实例配置基础 URL、超时时间、请求拦截器和响应拦截器。请求拦截器主要负责把 token 加到 header响应拦截器统一处理 code 不等于 200 的错误提示。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( response { const res response.data; if (res.code ! 200) { return Promise.reject(new Error(res.message || 请求失败)); } return res.data; }, error { return Promise.reject(error); } ); export default request;这里baseURL为什么是/api而不是直接写http://localhost:8080因为在开发环境里前端启动在 8081后端在 8080直接请求跨域会报错。我在vue.config.js里配置了 devServer 代理把/api开头的请求转发给后端const { defineConfig } require(vue/cli-service); module.exports defineConfig({ devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } });这样做的好处是浏览器看到的请求路径是同源的/api/xxx浏览器不触发跨域限制代理在 Node.js 层把请求转发出去开发和联调体验非常顺滑。生产环境下Nginx 也会配置同样的/api反向代理规则。3.4 状态管理与登录路由守卫用户登录后前端需要保存用户信息和 token供多个页面共享。源码里用的是 Vuex核心 state 包括 token、userInfomutations 提供 login 和 logout。Vuex 的数据是非持久化的刷新页面就没了所以源码里在初始化时会从 localStorage 读取 token再调用/api/auth/info拉取用户信息。路由守卫实现登录控制非常容易router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.path /login) { next(); return; } if (!token) { next(/login); return; } if (to.meta.role JSON.parse(localStorage.getItem(userInfo)).role ! to.meta.role) { next(/home); return; } next(); });面试时经常问的“Vue 路由守卫有哪些”在这里其实就是简单的应用场景。全局前置守卫 beforeEach 用来做登录校验和角色校验当你跳转到一个需要管理员权限的页面时如果当前用户是普通用户会被弹回首页。这比在每个页面里单独判断登录状态要整洁得多。4. 项目运行部署从零到能跑起来的全过程4.1 环境准备JDK、Maven、Node.js、MySQL这套系统的运行环境要求不复杂但版本要匹配好。我推荐的组合是 JDK 8 或 JDK 11、Maven 3.6、Node.js 14 或 16、MySQL 5.7 或 8.0。如果你用的是 Spring Boot 2.3.xJDK 8 最稳如果源码是 Spring Boot 2.6.xJDK 8 和 11 都支持但别用 JDK 17 以上因为旧版本的某些反射机制在 17 下会有问题。软件推荐版本说明JDK1.8 / 11查看源码说明版本兼容性最关键Maven3.6.3 以上依赖下载和打包Node.js14 / 16避免版本过高导致 node-sass 编译失败MySQL5.7 / 8.08.0 需要配 SSL 参数IDEACommunity 可装 Lombok 和 Vue 插件如果你的电脑上已经有 8 和 17 多个 JDK记得在 IDEA 的 Project Structure 里把 SDK 切换成对应版本。Maven 如果下载依赖慢可以在settings.xml里配置阿里云镜像这一步能省下大量时间。4.2 MySQL 初始化与数据导入数据库初始化是“可直接运行”的关键。源码包里的sql/sunshine_music.sql不只是建表语句还包含几条演示数据和管理员账号。我建议你第一次运行前先执行一遍这个脚本确保数据干净。命令行导入方式mysql -u root -p sql/sunshine_music.sql如果你不习惯命令行用 Navicat 连接 MySQL 后右键运行 SQL 文件也可以。导入完成后登录系统时管理员账号可能是admin/admin123普通用户是user/123456我通常在 README 里写清楚避免使用者还要去看数据库里存的加密密码。有一点要提醒如果导入时提示uef8mb4字符集不支持很可能是你的 MySQL 版本过低5.5 以下不支持 utf8mb4。用 MySQL 5.7 或 8.0 就不会有这个烦恼。4.3 后端启动步骤与常见报错后端启动有两种方式。第一种是在 IDEA 里直接运行启动类适合调试第二种是命令行打包运行cd backend mvn clean package -DskipTests java -jar target/sunshine-music-hall.jar常见报错我在后面第 5 章会详细列表说明这里先说最典型的数据库账号密码不对会报Access denied for user连接串里没加serverTimezone会报The server time zone value ... is unrecognized端口被占用会报Port 8080 was already in use这种时候在application.yml里把server.port改成其他值就行但记得前端 proxy 的 target 也要一起改。4.4 前端启动步骤与代理配置前端安装依赖和启动是我见过问题最多的环节因为每个人的 Node.js 版本和 npm 配置不同。这里给出标准流程cd frontend npm install npm run serve如果npm install卡住或失败先检查网络再把 npm 镜像源切到国内npm config set registry https://registry.npmmirror.com安装成功后在浏览器打开http://localhost:8081。Vue CLI 启动时会随机找一个可用端口如果 8081 被占用会自动跳到 8082这时页面能打开但后端代理地址是根据 8081 配置的建议还是确保 8081 不被占或者在 vue.config.js 里固定端口。4.5 “可直接运行”到底怎么保证市面上很多源码写“可直接运行”结果不是缺脚本就是缺配置。这套系统能做到真正导入即跑靠的是一致性约定后端、前端、数据库脚本都在固定位置默认端口固定数据库名固定初始账号写进 README所有表的字符集统一不存在环境依赖上的灰盒区域。我的建议是拿到源码后先看三样东西README.md、application.yml、vue.config.js。三样确认完再启动基本能一次成功。另外如果你在 IDEA 里打开项目发现 target 目录和 node_modules 缺失这是正常现象它们是构建产物自己本地跑一次就会生成。5. 常见问题与排查技巧实录5.1 后端启动报错集合我实际操作过程中遇到过的后端报错整理成一张速查表错误关键字原因解决方法Access denied for user数据库密码不对修改 application.yml 的 username/passwordUnknown database数据库不存在先执行 sql 脚本创建数据库SSL connection errorMySQL 8 SSL 认证问题连接串加 useSSLfalseServer time zone value时区未指定连接串加 serverTimezoneAsia/ShanghaiPort 8080 was already in use端口被占用换端口并同步前端 proxy程序包 lombok 不存在缺少 Lombok 插件IDEA 安装 Lombok 插件并开启 annotation processing这些坑里时区和 SSL 问题最容易让人懵因为提示信息很长中文搜起来答案千奇百怪。实际上只要你用我前面给的连接串基本不会踩到。还有文件编码问题Windows 上默认 GBK但 Spring Boot 的application.yml里如果有中文注释可能乱码或报错用 IDEA 右下角把文件编码改成 UTF-8 即可。5.2 前端跨域和请求 404前端最常见的问题是控制台报Access-Control-Allow-Origin跨域错误。如果你已经配置了 vue.config.js 的 proxy那这个错误大概率是代理没生效比如修改完配置没有重启npm run serve。vue.config.js 改动必须重启开发服务器才能生效不是保存就热更新。请求 404 则要从两个方向排查。打开浏览器 F12看 Network 里的请求 URL 是什么。如果请求的是http://localhost:8081/api/concert/list并且返回 404那说明后端接口路径不对或者代理没命中。先用 Postman 直接请求http://localhost:8080/api/concert/list如果通问题在前端代理如果不通问题在后端 Controller 的 RequestMapping 路径写错了。5.3 版本兼容性坑很多同学一上来就用最新版 Node 和 Vue 3结果发现源码是 Vue 2 Element UI问题立刻爆炸。Element UI 对 Vue 3 是不兼容的Vue 3 要用 Element Plus。如果这份源码是 Vue 2 写的那么 Node.js 版本太新会导致node-sass编译失败。最快的解决方式是装 Node 14然后在package.json里删除旧的 node-sass 换成 sass。我实测过sass 配 Vue CLI 5 在 Node 16 下没问题。后端同样存在版本兼容问题。Spring Boot 2.6.x 对应 MyBatis-Plus 3.4.x如果随意升级到 3.5.x分页插件包名变了旧代码可能找不到类。所以在没有升级必要的情况下保持源码锁定的依赖版本就是最稳的运行方式。这也是为什么我一直在强调能跑的项目不要乱动 pom.xml。5.4 排错思路和日志技巧遇到问题不要一上来就乱猜要学会看日志。后端日志在 IDEA 的 Console 里如果application.yml配了log-impl: StdOutImplMyBatis 会把每条 SQL 打印出来。我看 SQL 日志能立刻发现查错表、条件拼错、参数没传进去这类低级问题。前端排错就靠浏览器 F12。Network 面板看请求状态码Console 面板看 JavaScript 报错Vue Devtools 看组件数据和 Vuex 状态。找到是请求问题还是渲染问题再动手效率提高很多。这套思路通用于所有前后端分离项目。6. 个人实操心得与后续扩展6.1 这个系统的真实定位从功能体量上说这套系统更接近一个教学演示项目而不是生产级平台。它没有真实支付、没有短信验证、没有严格的权限审计但它的结构和代码风格能让你学到东西统一返回结构、JWT 鉴权、事务回滚、条件更新防超卖、Vue 路由守卫、axios 封装。你给别人讲项目时能把这几个点讲透就已经超过很多照搬 CRUD 的人了。6.2 我踩过的坑和推荐做法我在跑这套源码时最大的感触是“环境一致性比代码本身更容易卡人”。后来我养成一个习惯拿到任何 Spring Boot Vue 项目第一步先看 pom.xml 里 Spring Boot 的版本再看 package.json 里 Vue 的版本和 UI 组件库确认好组合后再动手。这个项目最稳的组合是 Spring Boot 2.6.x Vue 2 Element UI Node 14跑起来几乎零阻力。另外我强烈建议你在本地装一个 MySQL 连接工具无论是 Navicat 还是 DataGrip。跑通项目之后手动查一下 t_session 表里 available_seats 的变化你就能直观理解什么叫“下单扣库存”。这种验证比只看代码要深刻得多。6.3 后续扩展方向如果我想在这个系统上继续迭代第一件事肯定是把选座部分做成真正的可视化座位图用 CSS 或 Canvas 绘制区域和座位而不是简单的二维数组。然后是接入支付宝沙箱或微信支付沙箱让订单状态流转完整起来。后端可以引入 Redis 做热点场次的库存预热和分布式锁前端可以加 ECharts 做一个演出销售统计报表。功能每加一层项目的技术含量和展示效果都会上一个台阶。不过扩展之前先保证当前这套源码能在你电脑上跑通。跑通一次你就能理解前后端是怎么协作的改一个功能你就能建立自己的项目手感。这套流程走下来课程设计或面试准备都会轻松很多。