1. 项目整体设计与思路拆解1.1 这个题目为什么值得做“SpringBootVue Spring Boot阳光音乐厅订票系统管理平台源码”这个题目放在毕业设计和课程设计里属于典型的“既不过分简单也不复杂到失控”的类型。核心价值在于它把前端、后端、数据库、业务逻辑完整串起来覆盖了软件工程里最常用的一条链路用户注册登录、演出信息展示、在线选座、订单生成、模拟支付、后台管理。很多同学一开始会纠结“是不是做一个商城系统更流行一点”但商城系统在毕设里已经泛滥评委一眼就能看出来。订票系统的好处在于它有一个非常核心的领域概念就是“座位”。座位会牵扯到数据一致性、并发控制、唯一性约束这些点随便拿出来一个都可以在答辩阶段成为你的加分项。而且这个系统的业务边界足够清晰用户端做购票管理端做维护。不会像很多“万能管理系统”一样堆了几十个模块最后哪个都没讲清楚。它是可以一个人独立完成的前后端分离的开发方式也贴近目前真实团队的工作模式。1.2 功能模块怎么划才不至于做成“大杂烩”我在给学生指导这个题目时一般建议第一版只保留以下核心模块先用这个跑通再做扩展。用户端注册、登录、退出登录演出列表、演出详情、演出预告视频预览场馆座位图查看与选座提交订单、模拟支付、取消订单个人中心查看历史订单和票信息管理端仪表盘订单量、票房统计、热门演出排行演出管理新增演出、安排场次、设置演出时间场馆管理维护音乐厅场地、座位布局座位管理设置不同区域票价、上下架座位订单管理查看订单、处理退款、校验异常订单用户管理用户列表、禁用/启用账号为什么这么划因为每个模块都能独立测试又互相有依赖关系。比如场馆先要有才能给演出安排座位有演出用户才可能下单有订单后台才有数据可管。这种依赖关系能让代码分层变得非常清晰不至于写出一个Service类包揽所有逻辑的“上帝类”。第一版不建议碰的商品类型逻辑包括优惠券分摊、会员等级折扣、多级退款、选座超时自动释放、复杂的评价体系。不是说这些东西不能做而是第一版很容易因为状态机太多导致失控光是对“待支付、已支付、已取消、已退款”这几个状态的流转就够忙一阵了。1.3 前后端分离技术选型背后的原因为什么选SpringBootVue而不是传统的JSPServlet最直接的原因是目前毕业设计和求职市场上前后端分离已经成了主流。SpringBoot解决了传统Spring配置繁琐的问题。以前写SSM项目要配一堆XML文件很多人还没开始写业务就被配置文件劝退了。SpringBoot通过自动配置和Starter机制把常用整合直接变成了一个依赖比如引入spring-boot-starter-web就有了内置Tomcat引入mybatis-plus-boot-starter就简化了数据库操作。这对课程设计来说学习成本低出成果快。前端选Vue更简单因为组件化开发特别适合座位图这类交互密集的场景。你要做的是一个选座界面传统JSP里写jQuery操作DOM代码会非常混乱用Vue把座位网格拆成一个SeatGrid组件每个座位作为子组件点击、选中、售出状态管理起来就非常自然。Vue基础上再搭配Vue Router做页面路由搭配Axios做HTTP请求就是一套非常标准的商业项目栈。MySQL也不需要多说免费、通用、查资料方便只要你不在答辩前犯了低级连接错误一般都稳。2. 核心技术栈与数据库设计2.1 后端技术与分层架构后端我不会刻意玩花活标准分层就够了Controller接收请求Service处理业务Mapper负责数据库操作。对应到代码目录大概是这样的。config放跨域配置、JWT拦截器配置、WebMvc配置。controller登录认证、演出查询、订单提交、后台管理接口。service用户服务、演出服务、订单服务、统计服务。mapper对应数据库表的接口继承MyBatis-Plus的BaseMapper。entity用户、演出、场馆、座位、订单、票根、公告这些表对应的实体类。common统一返回结果、异常处理、状态码定义。utilJWT工具类、日期处理工具类。为什么建议用MyBatis-Plus而不是纯MyBatis因为毕设项目大头是时间用MyBatis-Plus的selectById、selectPage、insert这类封装好的方法能省下大量重复SQL。遇到复杂统计再自定义XML里的SQL比如按月份统计票房、按演出分组查销量这样既省事又能体现你“会写SQL”。但有一个细节要注意如果题目明确要求手写SQL加分那么你可以部分使用注解方式写SQL比如Select(select * from user where username #{username})让代码里能看到明显SQL痕迹这也是评分老师比较喜欢看到的。2.2 前端技术栈与页面结构前端我推荐Vue3 Vite Element Plus Vue Router Pinia Axios。很多学校课件还停留在Vue2但Vue3已经是主流你用Vue3反而显得跟得上技术更新。Vite启动快是有决定性优势的npm run dev两秒就能出页面调试体验比Webpack舒服很多。Element Plus提供表格、表单、弹窗、日期选择器、穿梭框这类现成组件后台管理页面的开发效率能提高一大截。用户端的页面则不用全靠组件库像演出列表卡片、座位图、订单状态流完全可以自己写CSS反而更能突出个人工作量。前端工程里典型的目录结构是src/api按模块拆分接口请求比如user.js、concert.js、order.js。src/router配置前端路由同时做登录守卫。src/store用Pinia存用户信息、Token状态。src/views页面组件user下放用户端页面admin下放管理端页面。src/components公共组件座位图组件、分页组件、上传组件等。前端路由有两种模式history和hash。毕设项目我建议直接用history因为URL美观但部署到线上需要注意刷新出现404的问题。如果你不想处理服务器回退配置就用hash模式URL地址带个#丑一点但省心。2.3 数据库表结构怎么设计才合理这是整个系统里最值得花时间设计的地方。表设计合理后面业务代码就好写。我先定义一张用户表核心字段是id主键、username唯一、password加密串、nickname昵称、phone手机号、avatar头像URL、role角色user/admin、status状态、create_time。密码存储一定要用BCrypt加密这是答辩时标准问题之一你要是存明文密码评委大概率会追着问你安全知识。场馆表venueid、name场馆名称、address地址、row_total总行数、col_total总列数、description简介。座位范围放在场馆表里方便管理员配置。演出表concertid、venue_id场馆id、title演出名称、artist演员/团体、cover封面图、video_url预告视频地址、intro演出介绍、session_time演出场次时间、sale_status售票状态。注意这里我把场次直接并入concert字段对于毕设规模够用。如果你想体现更完整的建模能力可以拆schedule表但会增加很多联动逻辑比如同场馆同时段不能安排两场演出这会牵扯到冲突校验。能力强的同学可以试试一般同学我建议先用一个字段搞定。座位表seatid、venue_id、row_no行号、col_no列号、section区域、price票价、status状态这里的status建议区分“可售/锁定/已售/禁用”。座位和演出是什么关系很多同学第一版会设计错他们只建一张座位表认为演出坐席就绑死了。实际上同一个场馆的同一个座位在不同演出场次里是可以分别售卖单独锁定状态的。最合理的设计是把座位票价放在场次关联上。我建议用seat_plan表来承接这个关系id、concert_id场次id、seat_id基础座位id、price该场次下这个座位的售价、status每个场次的独立状态。这样同一个座位在不同演出里的状态互不影响。不过要诚实说如果只想做一个精简版订票系统也可以直接用seat表加concert_id字段每场演出复制一份完整座位数据简单粗暴又满足核心逻辑。缺点是数据冗余但在课程设计的数据量下完全没有性能压力而且查起来反而更直接。订单表ordersid、order_no订单号、user_id、concert_id、total_amount总金额、status、create_time、pay_time。订单号不能纯自增建议写成时间戳用户id随机数的组合这是答辩时能拿出来讲的一个亮点。票根表ticketid、order_id、concert_id、seat_id、seat_code座位编码、price实付金额、status状态。一个订单可以包含多张票这就是订单表和票根表分离的原因。2.4 数据库建表SQL示例建表演示一下核心部分不用全部表都贴出来我挑最关键的CREATE TABLE user ( id bigint NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录名, password varchar(100) NOT NULL COMMENT BCrypt加密后的密码, nickname varchar(50) DEFAULT NULL, phone varchar(20) DEFAULT NULL, role varchar(10) DEFAULT user, status tinyint DEFAULT 1, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE orders ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL, user_id bigint NOT NULL, concert_id bigint NOT NULL, total_amount decimal(10,2) DEFAULT 0, status tinyint DEFAULT 0 COMMENT 0待支付 1已支付 2已取消 3已退款, create_time datetime DEFAULT CURRENT_TIMESTAMP, pay_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单表里唯一索引order_no是必须的防止生成重复订单号。用户查询会高频按user_id搜所以加一个普通索引。3. 实操过程与核心业务实现3.1 从0到1搭建SpringBoot后端工程我习惯用手工方式搭建而不是依赖在线生成器这样能让自己清楚每个文件是干什么的。第一步用IDEA的Spring Initializr创建工程选择Java 8或者Java 11依赖选择Spring Web和MySQL Driver。然后手动往pom.xml里加入MyBatis-Plus、Lombok、JWT、Hutool这些常用库。主配置application.yml长这样server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/sunshine_concert?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/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 log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这里要特别说两个坑。一个是serverTimezoneMySQL 8的时区问题不解决启动就报连接错误。另一个是map-underscore-to-camel-case这个配置开启后数据库的order_no能自动映射到Java的orderNo字段不开启的话你实体类里所有驼峰字段都会查出来是null。工程创建好后先用一个最简单接口验证链路比如新建TestController返回“hello”然后启动。很多失败都发生在这一步先排除端口、数据库连通问题再开始写业务。3.2 登录注册与JWT鉴权用户密码用BCrypt加密注册接口里调用String encodedPwd BCrypt.hashpw(password, BCrypt.gensalt()); user.setPassword(encodedPwd);登录成功后签发JWT。JWT其实就是一个三段的字符串头部、载荷、签名。我用jjwt库实现工具类里包含生成Token和解析Token两个核心方法。签发时把userId和role放进去String token Jwts.builder() .setSubject(user.getId().toString()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();有了Token之后SpringBoot端通过拦截器统一校验。我写一个LoginInterceptor实现HandlerInterceptor在preHandle里从请求头Authorization读取Token解析通过则放行否则返回401。跨域配置则是另一个必经步骤。因为Vue开发服务器跑在5173后端跑在8080端口不同必然产生跨域。在WebMvcConfigurer里实现addCorsMappings允许所有来源和常用请求头要注意allowedHeaders里加上Authorization否则前端带Token的请求会被浏览器拦截。3.3 订票核心流程从选座到下订单这是整个系统最核心的一段逻辑。用户在前端点一个座位执行顺序如下前端获取该场次剩余座位列表渲染座位图。用户点击购买选择多个座位进入确认订单页。前端提交请求参数是演出id和选中的座位id列表。后端生成订单号和总价同时创建票根记录。模拟支付前端调支付接口后端直接修改订单状态为已支付。订单创建方法里有一个关键点就是座位状态的检查和更新必须放在同一个数据库事务里并且要防止别人在你操作的空隙抢走同一个座位。我写的时候用的是乐观锁方案给座位状态增加一个version字段更新时带上version条件UPDATE seat_plan SET status 1, version version 1 WHERE id #{seatId} AND status 0 AND version #{oldVersion}如果更新影响行数为0说明该座位已经被人购买事务直接抛异常回滚前端会提示用户“座位已被锁定请重新选择”。这个方法能挡住大多数并发抢座场景比“先查后改”的安全系数高得多。订单生成后需要注意订单号和用户id的绑定。你不能让用户A拿着用户B的数据去下单后端要根据当前登录用户的id去创建订单而不是信任前端传的userId。我是在JWT拦截器处理完请求后把当前登录用户信息放进ThreadLocalService层取出来用。3.4 前端Vue页面实现与Axios对接前端最核心的组件是座位图。我的思路是用一个二维数组渲染页面行用row_no索引列用col_no索引座位状态从后端接口一次拉取。渲染时按状态来控制样式可售座位显示绿色已售灰色当前选中的高亮橙色。点击座位时做一个临时选中数组再进行下一步操作。选座交互代码大致如下const selected ref([]); function toggleSeat(seat) { if (seat.status 2 || seat.status 3) return; const idx selected.value.findIndex(s s.id seat.id); if (idx 0) { selected.value.splice(idx, 1); } else { if (selected.value.length 5) { ElMessage.warning(一次最多购买5张); return; } selected.value.push(seat); } }座位图右侧同时展示已选座位的合计金额金额要从后端座位的price字段读取前端不要自己写死价格。合计金额实时计算可以在前端做但真正下单金额以后端计算为准。Axios封装方面我在src/api/request.js里创建一个axios实例设置baseURL在请求拦截器里追加Token头service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] token; } return config; });响应拦截器里统一处理后端返回结构常见的是code0代表成功code401表示登录过期此时清除本地用户信息并跳转登录页。3.5 演出预告视频与M3U8播放现在的订票系统如果只是几张海报和文字会显得比较单薄。我建议在演出详情页加上预告视频。视频文件用普通的mp4在Vue里放没问题直接video标签搞定。但如果你接的是流媒体服务拿到的是m3u8格式的直播流或切片视频Vue里就不能直接播放了需要引入hls.js。m3u8本质上是一个媒体播放列表文件里面记录了一串TS分片地址。播放器拿到这个文件后会按顺序请求分片并拼接播放。Vue里的接入方式非常简单import Hls from hls.js; function playVideo(videoEl, url) { if (Hls.isSupported()) { const hls new Hls(); hls.loadSource(url); hls.attachMedia(videoEl); } else if (videoEl.canPlayType(application/vnd.apple.mpegurl)) { videoEl.src url; } }很多闭源视频平台对外就只给m3u8的地址所以花十几分钟了解这个播放流程不仅项目里能用未来工作也大概率会遇到。3.6 后台管理系统实现要点后台管理用Vue Router做一套独立的路由群组路径前缀是/admin并设置访问控制当前用户角色不是admin就直接跳到403页面。菜单用El-Menu组件点击菜单切换内容区。管理端的重点功能是演出和座位管理。演出管理用表单弹窗新增、编辑、删除列表用分页表格。座位管理是典型的“可视化管理”我做成一个座位网格画布管理员点击座位可以切换禁用/启用拖拽或者填表单设置区域和价格。统计仪表盘我建议用ECharts画两个图表一个近30天订单量折线图一个按演出的门票销量柱状图。统计接口后端可以用group by加上日期函数写起来不复杂视觉效果却非常好很多评委就是看到图表才相信这个系统“有真实业务量”。4. 常见问题与排查技巧实录4.1 数据库连接类和端口占用问题后端启动最频繁的报错就是数据库连接失败。你需要注意几点检查MySQL服务有没有启动本地3306有没有被别的程序占用。可以在命令行执行netstat -ano | findstr 3306如果看到非MySQL进程占用要么换端口要么杀掉对应进程。密码有特殊字符时url里要做转义最好在yml配置里不要用符号做密码开头。还有MySQL版本不同驱动名不同MySQL 5.x驱动是com.mysql.jdbc.DriverMySQL 8.x则是com.mysql.cj.jdbc.Driver写错就启动失败。4.2 Maven依赖冲突和版本过高问题SpringBoot不同版本对Java版本有要求比如SpringBoot 2.x对Java 8很好兼容SpringBoot 3.0以上要求Java 17。很多学生电脑装的是Java 8却生成了SpringBoot 3.x的项目一启动就报错。解决方式只有两个一是升级JDK二是创建项目时明确选择SpringBoot 2.7系列。Maven依赖冲突也很常见尤其是MyBatis-Plus版本和SpringBoot版本配合时容易出现方法找不到的情况。一般排查思路是Maven窗口里右键项目选择“参数”看有没有红色波浪线然后mvn clean compile看具体报错。记住一个原则遇到jar包冲突先检查是否有重复依赖比如你自己引入了旧版mysql驱动SpringBoot也自动引入一个新版两相冲突保留版本统一。4.3 跨域、Token失效与会话丢失前后端分离项目里跨域是高频问题。如果前端请求报“CORS error”先看后端有没有配置跨域再看请求头里是不是带了Vue开发环境自动加的自定义头。后端需要把allowedHeaders配成*或者显式加入Authorization。JWT过期是另一个执行点。前端真机测试时因为各种原因电脑时间不准JWT立刻判断过期导致退出登录。排查时可以先打印出验证过程中获得的过期时间查看确实是过期还是解析出错。日常修改Token有效期的时候建议用一个配置项管理不要写死在代码里。另外Vue打包之后部署到一个域名下history模式路由刷新会404。最简单的方案是后端加一个web配置把所有非接口路由转发到index.html或者直接改前端路由为hash模式。这个坑在做联调部署时几乎必踩。4.4 事务失效和并发超卖问题事务失效发生最隐蔽的一种情况是同一个类内部调用另一个方法。Spring的事务是通过AOP代理实现的如果Service内部self调用另一个需要事务的方法代理对象不会生效事务就莫名其妙不起作用。解决方式就是自己注入自己的Mapper或者把内部方法拆到另一个Service里。并发超卖问题在座位表没有做“条件更新”时特别容易复现。两个用户同时看中同一个座位同时发起下单请求如果代码是select拿到status0然后update成已售两个请求都能查到状态为0最后都会更新成功一张票就有两个买家了。用乐观锁的“影响行数为0则回滚”逻辑问题就堵住了。原理上看这就是数据库层面“CAS”思想在业务里的落地。如果你的项目里用了Redis也可以在这块改成Redis分布式锁。不过对于毕设来说MySQL乐观锁已经足够解释清楚你的并发处理思路。答辩时能说明白关系别自己把自己绕晕。4.5 查询慢和列表数据为空问题管理端订单列表数据量如果达到几万条不加分页直接全表查询会卡。MyBatis-Plus提供了分页插件配置一个MybatisPlusInterceptor加上PaginationInnerInterceptor然后在Service里调用page方法前端传当前页码和每页条数一切顺理成章。数据查询结果为空最常见的两个原因一是实体类没有给查询结果字段写getter/setter二是数据库字段命名是蛇形实体类是驼峰但全局map-underscore配置没开。排查方法是在mybatis配置里开启SQL日志看打印出来的SQL语句是否真的执行再检查返回值映射。5. 答辩核心问题与可扩展方向5.1 答辩时容易被追问的六个问题我整理过这个题目答辩时出现频率最高的几个问题。第一个为什么选择前后端分离而不用JSP回答思路前后端分离后端专注提供接口前端专注页面交互开发效率高部署解耦符合现在主流开发方式。第二个JWT和Session有什么区别回答思路Session存在服务端JWT存在客户端JWT天然适合前后端分离、接口无状态。自然要说JWT的缺点比如无法主动过期所以token有效期不能太长。第三个同一个座位被两个人同时购买怎么解决回答思路数据库层使用乐观锁update时带版本号条件影响行数0则回滚同时通过唯一约束保证脏数据不落库。第四个订单状态有多少种每种状态的转变条件回答思路待支付、已支付、已取消、已退款四种。用户提交订单成待支付模拟支付成功变已支付未支付前取消变已取消后台退款变已退款。第五个密码为什么不能明文存储回答思路数据库泄露时明文密码会造成连锁后果用户往往多个平台共用密码所以必须使用BCrypt之类的哈希加盐算法。第六个数据库表为什么要拆得这么细回答思路第三范式要消除冗余例如orders和ticket分离是为了支持一个订单多张票venue和concert分离是为了支持一个场馆多个演出场次。5.2 四个值得扩展的加分方向如果你做完上述基本功能还有余力我个人建议可以按优先顺序挑选以下扩展。一是引入Redis缓存。热门演出的详情和座位状态在用户访问频繁时如果每次都打MySQL性能会很难看。Redis可以做缓存并设置过期时间下单时把Redis里的座位状态当作预热一致性再到MySQL校验。二是接入支付宝沙箱或者微信支付沙箱。沙箱不需要真实营业执照用官方提供的测试账号就能跑通支付流程。接支付这个动作会让项目的完整度直接上升一个维度。三是做数据可视化大屏。用ECharts在管理端首页做一个大屏显示实时候场人数、票档销售进度、按场次占比的饼图视觉冲击很强答辩演示时很加分。四是利用Docker部署。本地开发完成后写一个Dockerfile分别部署前端和后端再用docker-compose同时启动会给你增加“工程化”的质感。不过要小心用Docker部署数据库时宿主机端口和容器端口映射错会导致本地连不上数据库。5.3 一些后知后觉的体会这个题做完我对“小而全”这三个字感受特别深。项目范围不怕小就怕乱。很多同学刚开始做就想着加满所有功能光是做那些半吊子的多余模块就消耗了大量时间到了真正答辩时连一个最核心的订票流程都讲不完整。我在实际指导中反复跟大家强调先把一条主链路彻底跑通再去丰富边缘功能。过程中另外一个深刻的体会是一定要自己动手写核心业务逻辑而不是复制一套源码就结束了。源码可以作为参考但如果你连订单状态流转、事务回滚、跨域配置这些基础部分都没亲手敲过一遍答辩时评委随便追问几个细节很可能就会被看出来。我见过很多拿着网上所谓“完整源码”去答辩的同学最后因为讲不出代码逻辑而重点标高折了。关于项目源码的学习建议再单独聊一下“源码”这件事。这个标题里带“源码”两个字但我的建议是你把下载下来的源码当成教材来对着学而不是当成终极目标。对照源码梳理一遍业务流程和表关系是最快的学习路径但一定要在原版基础上做至少三个小改动改表名、改界面风格、加一个自己的小功能。这样做一来让你深入理解代码逻辑二来避免和同学提交的内容“撞车”。第一步先不看启动代码把数据库建表脚本运行起来。第二步逐表看数据字段画出表关系图再把整个项目跑起来。第三步用基本功能界面一步步跟业务。最后把代码里最核心的订单生成部分完整读懂哪里用了事务、哪里用了乐观锁都要能指出来。这套流程走下来源码才能真正变成你自己的。我在实际项目里额外用了一个很讨巧的习惯把整个项目按照“登录注册、基础管理、订票流程、统计报表”四个阶段做测试登记表每个阶段跑通后记录一条结果。答辩前翻一遍对系统整体的把握会变得特别清楚。这个方法推荐给你亲测高效。
1. 项目整体设计与思路拆解1.1 这个题目为什么值得做“SpringBootVue Spring Boot阳光音乐厅订票系统管理平台源码”这个题目放在毕业设计和课程设计里属于典型的“既不过分简单也不复杂到失控”的类型。核心价值在于它把前端、后端、数据库、业务逻辑完整串起来覆盖了软件工程里最常用的一条链路用户注册登录、演出信息展示、在线选座、订单生成、模拟支付、后台管理。很多同学一开始会纠结“是不是做一个商城系统更流行一点”但商城系统在毕设里已经泛滥评委一眼就能看出来。订票系统的好处在于它有一个非常核心的领域概念就是“座位”。座位会牵扯到数据一致性、并发控制、唯一性约束这些点随便拿出来一个都可以在答辩阶段成为你的加分项。而且这个系统的业务边界足够清晰用户端做购票管理端做维护。不会像很多“万能管理系统”一样堆了几十个模块最后哪个都没讲清楚。它是可以一个人独立完成的前后端分离的开发方式也贴近目前真实团队的工作模式。1.2 功能模块怎么划才不至于做成“大杂烩”我在给学生指导这个题目时一般建议第一版只保留以下核心模块先用这个跑通再做扩展。用户端注册、登录、退出登录演出列表、演出详情、演出预告视频预览场馆座位图查看与选座提交订单、模拟支付、取消订单个人中心查看历史订单和票信息管理端仪表盘订单量、票房统计、热门演出排行演出管理新增演出、安排场次、设置演出时间场馆管理维护音乐厅场地、座位布局座位管理设置不同区域票价、上下架座位订单管理查看订单、处理退款、校验异常订单用户管理用户列表、禁用/启用账号为什么这么划因为每个模块都能独立测试又互相有依赖关系。比如场馆先要有才能给演出安排座位有演出用户才可能下单有订单后台才有数据可管。这种依赖关系能让代码分层变得非常清晰不至于写出一个Service类包揽所有逻辑的“上帝类”。第一版不建议碰的商品类型逻辑包括优惠券分摊、会员等级折扣、多级退款、选座超时自动释放、复杂的评价体系。不是说这些东西不能做而是第一版很容易因为状态机太多导致失控光是对“待支付、已支付、已取消、已退款”这几个状态的流转就够忙一阵了。1.3 前后端分离技术选型背后的原因为什么选SpringBootVue而不是传统的JSPServlet最直接的原因是目前毕业设计和求职市场上前后端分离已经成了主流。SpringBoot解决了传统Spring配置繁琐的问题。以前写SSM项目要配一堆XML文件很多人还没开始写业务就被配置文件劝退了。SpringBoot通过自动配置和Starter机制把常用整合直接变成了一个依赖比如引入spring-boot-starter-web就有了内置Tomcat引入mybatis-plus-boot-starter就简化了数据库操作。这对课程设计来说学习成本低出成果快。前端选Vue更简单因为组件化开发特别适合座位图这类交互密集的场景。你要做的是一个选座界面传统JSP里写jQuery操作DOM代码会非常混乱用Vue把座位网格拆成一个SeatGrid组件每个座位作为子组件点击、选中、售出状态管理起来就非常自然。Vue基础上再搭配Vue Router做页面路由搭配Axios做HTTP请求就是一套非常标准的商业项目栈。MySQL也不需要多说免费、通用、查资料方便只要你不在答辩前犯了低级连接错误一般都稳。2. 核心技术栈与数据库设计2.1 后端技术与分层架构后端我不会刻意玩花活标准分层就够了Controller接收请求Service处理业务Mapper负责数据库操作。对应到代码目录大概是这样的。config放跨域配置、JWT拦截器配置、WebMvc配置。controller登录认证、演出查询、订单提交、后台管理接口。service用户服务、演出服务、订单服务、统计服务。mapper对应数据库表的接口继承MyBatis-Plus的BaseMapper。entity用户、演出、场馆、座位、订单、票根、公告这些表对应的实体类。common统一返回结果、异常处理、状态码定义。utilJWT工具类、日期处理工具类。为什么建议用MyBatis-Plus而不是纯MyBatis因为毕设项目大头是时间用MyBatis-Plus的selectById、selectPage、insert这类封装好的方法能省下大量重复SQL。遇到复杂统计再自定义XML里的SQL比如按月份统计票房、按演出分组查销量这样既省事又能体现你“会写SQL”。但有一个细节要注意如果题目明确要求手写SQL加分那么你可以部分使用注解方式写SQL比如Select(select * from user where username #{username})让代码里能看到明显SQL痕迹这也是评分老师比较喜欢看到的。2.2 前端技术栈与页面结构前端我推荐Vue3 Vite Element Plus Vue Router Pinia Axios。很多学校课件还停留在Vue2但Vue3已经是主流你用Vue3反而显得跟得上技术更新。Vite启动快是有决定性优势的npm run dev两秒就能出页面调试体验比Webpack舒服很多。Element Plus提供表格、表单、弹窗、日期选择器、穿梭框这类现成组件后台管理页面的开发效率能提高一大截。用户端的页面则不用全靠组件库像演出列表卡片、座位图、订单状态流完全可以自己写CSS反而更能突出个人工作量。前端工程里典型的目录结构是src/api按模块拆分接口请求比如user.js、concert.js、order.js。src/router配置前端路由同时做登录守卫。src/store用Pinia存用户信息、Token状态。src/views页面组件user下放用户端页面admin下放管理端页面。src/components公共组件座位图组件、分页组件、上传组件等。前端路由有两种模式history和hash。毕设项目我建议直接用history因为URL美观但部署到线上需要注意刷新出现404的问题。如果你不想处理服务器回退配置就用hash模式URL地址带个#丑一点但省心。2.3 数据库表结构怎么设计才合理这是整个系统里最值得花时间设计的地方。表设计合理后面业务代码就好写。我先定义一张用户表核心字段是id主键、username唯一、password加密串、nickname昵称、phone手机号、avatar头像URL、role角色user/admin、status状态、create_time。密码存储一定要用BCrypt加密这是答辩时标准问题之一你要是存明文密码评委大概率会追着问你安全知识。场馆表venueid、name场馆名称、address地址、row_total总行数、col_total总列数、description简介。座位范围放在场馆表里方便管理员配置。演出表concertid、venue_id场馆id、title演出名称、artist演员/团体、cover封面图、video_url预告视频地址、intro演出介绍、session_time演出场次时间、sale_status售票状态。注意这里我把场次直接并入concert字段对于毕设规模够用。如果你想体现更完整的建模能力可以拆schedule表但会增加很多联动逻辑比如同场馆同时段不能安排两场演出这会牵扯到冲突校验。能力强的同学可以试试一般同学我建议先用一个字段搞定。座位表seatid、venue_id、row_no行号、col_no列号、section区域、price票价、status状态这里的status建议区分“可售/锁定/已售/禁用”。座位和演出是什么关系很多同学第一版会设计错他们只建一张座位表认为演出坐席就绑死了。实际上同一个场馆的同一个座位在不同演出场次里是可以分别售卖单独锁定状态的。最合理的设计是把座位票价放在场次关联上。我建议用seat_plan表来承接这个关系id、concert_id场次id、seat_id基础座位id、price该场次下这个座位的售价、status每个场次的独立状态。这样同一个座位在不同演出里的状态互不影响。不过要诚实说如果只想做一个精简版订票系统也可以直接用seat表加concert_id字段每场演出复制一份完整座位数据简单粗暴又满足核心逻辑。缺点是数据冗余但在课程设计的数据量下完全没有性能压力而且查起来反而更直接。订单表ordersid、order_no订单号、user_id、concert_id、total_amount总金额、status、create_time、pay_time。订单号不能纯自增建议写成时间戳用户id随机数的组合这是答辩时能拿出来讲的一个亮点。票根表ticketid、order_id、concert_id、seat_id、seat_code座位编码、price实付金额、status状态。一个订单可以包含多张票这就是订单表和票根表分离的原因。2.4 数据库建表SQL示例建表演示一下核心部分不用全部表都贴出来我挑最关键的CREATE TABLE user ( id bigint NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录名, password varchar(100) NOT NULL COMMENT BCrypt加密后的密码, nickname varchar(50) DEFAULT NULL, phone varchar(20) DEFAULT NULL, role varchar(10) DEFAULT user, status tinyint DEFAULT 1, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE orders ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL, user_id bigint NOT NULL, concert_id bigint NOT NULL, total_amount decimal(10,2) DEFAULT 0, status tinyint DEFAULT 0 COMMENT 0待支付 1已支付 2已取消 3已退款, create_time datetime DEFAULT CURRENT_TIMESTAMP, pay_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单表里唯一索引order_no是必须的防止生成重复订单号。用户查询会高频按user_id搜所以加一个普通索引。3. 实操过程与核心业务实现3.1 从0到1搭建SpringBoot后端工程我习惯用手工方式搭建而不是依赖在线生成器这样能让自己清楚每个文件是干什么的。第一步用IDEA的Spring Initializr创建工程选择Java 8或者Java 11依赖选择Spring Web和MySQL Driver。然后手动往pom.xml里加入MyBatis-Plus、Lombok、JWT、Hutool这些常用库。主配置application.yml长这样server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/sunshine_concert?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/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 log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这里要特别说两个坑。一个是serverTimezoneMySQL 8的时区问题不解决启动就报连接错误。另一个是map-underscore-to-camel-case这个配置开启后数据库的order_no能自动映射到Java的orderNo字段不开启的话你实体类里所有驼峰字段都会查出来是null。工程创建好后先用一个最简单接口验证链路比如新建TestController返回“hello”然后启动。很多失败都发生在这一步先排除端口、数据库连通问题再开始写业务。3.2 登录注册与JWT鉴权用户密码用BCrypt加密注册接口里调用String encodedPwd BCrypt.hashpw(password, BCrypt.gensalt()); user.setPassword(encodedPwd);登录成功后签发JWT。JWT其实就是一个三段的字符串头部、载荷、签名。我用jjwt库实现工具类里包含生成Token和解析Token两个核心方法。签发时把userId和role放进去String token Jwts.builder() .setSubject(user.getId().toString()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();有了Token之后SpringBoot端通过拦截器统一校验。我写一个LoginInterceptor实现HandlerInterceptor在preHandle里从请求头Authorization读取Token解析通过则放行否则返回401。跨域配置则是另一个必经步骤。因为Vue开发服务器跑在5173后端跑在8080端口不同必然产生跨域。在WebMvcConfigurer里实现addCorsMappings允许所有来源和常用请求头要注意allowedHeaders里加上Authorization否则前端带Token的请求会被浏览器拦截。3.3 订票核心流程从选座到下订单这是整个系统最核心的一段逻辑。用户在前端点一个座位执行顺序如下前端获取该场次剩余座位列表渲染座位图。用户点击购买选择多个座位进入确认订单页。前端提交请求参数是演出id和选中的座位id列表。后端生成订单号和总价同时创建票根记录。模拟支付前端调支付接口后端直接修改订单状态为已支付。订单创建方法里有一个关键点就是座位状态的检查和更新必须放在同一个数据库事务里并且要防止别人在你操作的空隙抢走同一个座位。我写的时候用的是乐观锁方案给座位状态增加一个version字段更新时带上version条件UPDATE seat_plan SET status 1, version version 1 WHERE id #{seatId} AND status 0 AND version #{oldVersion}如果更新影响行数为0说明该座位已经被人购买事务直接抛异常回滚前端会提示用户“座位已被锁定请重新选择”。这个方法能挡住大多数并发抢座场景比“先查后改”的安全系数高得多。订单生成后需要注意订单号和用户id的绑定。你不能让用户A拿着用户B的数据去下单后端要根据当前登录用户的id去创建订单而不是信任前端传的userId。我是在JWT拦截器处理完请求后把当前登录用户信息放进ThreadLocalService层取出来用。3.4 前端Vue页面实现与Axios对接前端最核心的组件是座位图。我的思路是用一个二维数组渲染页面行用row_no索引列用col_no索引座位状态从后端接口一次拉取。渲染时按状态来控制样式可售座位显示绿色已售灰色当前选中的高亮橙色。点击座位时做一个临时选中数组再进行下一步操作。选座交互代码大致如下const selected ref([]); function toggleSeat(seat) { if (seat.status 2 || seat.status 3) return; const idx selected.value.findIndex(s s.id seat.id); if (idx 0) { selected.value.splice(idx, 1); } else { if (selected.value.length 5) { ElMessage.warning(一次最多购买5张); return; } selected.value.push(seat); } }座位图右侧同时展示已选座位的合计金额金额要从后端座位的price字段读取前端不要自己写死价格。合计金额实时计算可以在前端做但真正下单金额以后端计算为准。Axios封装方面我在src/api/request.js里创建一个axios实例设置baseURL在请求拦截器里追加Token头service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] token; } return config; });响应拦截器里统一处理后端返回结构常见的是code0代表成功code401表示登录过期此时清除本地用户信息并跳转登录页。3.5 演出预告视频与M3U8播放现在的订票系统如果只是几张海报和文字会显得比较单薄。我建议在演出详情页加上预告视频。视频文件用普通的mp4在Vue里放没问题直接video标签搞定。但如果你接的是流媒体服务拿到的是m3u8格式的直播流或切片视频Vue里就不能直接播放了需要引入hls.js。m3u8本质上是一个媒体播放列表文件里面记录了一串TS分片地址。播放器拿到这个文件后会按顺序请求分片并拼接播放。Vue里的接入方式非常简单import Hls from hls.js; function playVideo(videoEl, url) { if (Hls.isSupported()) { const hls new Hls(); hls.loadSource(url); hls.attachMedia(videoEl); } else if (videoEl.canPlayType(application/vnd.apple.mpegurl)) { videoEl.src url; } }很多闭源视频平台对外就只给m3u8的地址所以花十几分钟了解这个播放流程不仅项目里能用未来工作也大概率会遇到。3.6 后台管理系统实现要点后台管理用Vue Router做一套独立的路由群组路径前缀是/admin并设置访问控制当前用户角色不是admin就直接跳到403页面。菜单用El-Menu组件点击菜单切换内容区。管理端的重点功能是演出和座位管理。演出管理用表单弹窗新增、编辑、删除列表用分页表格。座位管理是典型的“可视化管理”我做成一个座位网格画布管理员点击座位可以切换禁用/启用拖拽或者填表单设置区域和价格。统计仪表盘我建议用ECharts画两个图表一个近30天订单量折线图一个按演出的门票销量柱状图。统计接口后端可以用group by加上日期函数写起来不复杂视觉效果却非常好很多评委就是看到图表才相信这个系统“有真实业务量”。4. 常见问题与排查技巧实录4.1 数据库连接类和端口占用问题后端启动最频繁的报错就是数据库连接失败。你需要注意几点检查MySQL服务有没有启动本地3306有没有被别的程序占用。可以在命令行执行netstat -ano | findstr 3306如果看到非MySQL进程占用要么换端口要么杀掉对应进程。密码有特殊字符时url里要做转义最好在yml配置里不要用符号做密码开头。还有MySQL版本不同驱动名不同MySQL 5.x驱动是com.mysql.jdbc.DriverMySQL 8.x则是com.mysql.cj.jdbc.Driver写错就启动失败。4.2 Maven依赖冲突和版本过高问题SpringBoot不同版本对Java版本有要求比如SpringBoot 2.x对Java 8很好兼容SpringBoot 3.0以上要求Java 17。很多学生电脑装的是Java 8却生成了SpringBoot 3.x的项目一启动就报错。解决方式只有两个一是升级JDK二是创建项目时明确选择SpringBoot 2.7系列。Maven依赖冲突也很常见尤其是MyBatis-Plus版本和SpringBoot版本配合时容易出现方法找不到的情况。一般排查思路是Maven窗口里右键项目选择“参数”看有没有红色波浪线然后mvn clean compile看具体报错。记住一个原则遇到jar包冲突先检查是否有重复依赖比如你自己引入了旧版mysql驱动SpringBoot也自动引入一个新版两相冲突保留版本统一。4.3 跨域、Token失效与会话丢失前后端分离项目里跨域是高频问题。如果前端请求报“CORS error”先看后端有没有配置跨域再看请求头里是不是带了Vue开发环境自动加的自定义头。后端需要把allowedHeaders配成*或者显式加入Authorization。JWT过期是另一个执行点。前端真机测试时因为各种原因电脑时间不准JWT立刻判断过期导致退出登录。排查时可以先打印出验证过程中获得的过期时间查看确实是过期还是解析出错。日常修改Token有效期的时候建议用一个配置项管理不要写死在代码里。另外Vue打包之后部署到一个域名下history模式路由刷新会404。最简单的方案是后端加一个web配置把所有非接口路由转发到index.html或者直接改前端路由为hash模式。这个坑在做联调部署时几乎必踩。4.4 事务失效和并发超卖问题事务失效发生最隐蔽的一种情况是同一个类内部调用另一个方法。Spring的事务是通过AOP代理实现的如果Service内部self调用另一个需要事务的方法代理对象不会生效事务就莫名其妙不起作用。解决方式就是自己注入自己的Mapper或者把内部方法拆到另一个Service里。并发超卖问题在座位表没有做“条件更新”时特别容易复现。两个用户同时看中同一个座位同时发起下单请求如果代码是select拿到status0然后update成已售两个请求都能查到状态为0最后都会更新成功一张票就有两个买家了。用乐观锁的“影响行数为0则回滚”逻辑问题就堵住了。原理上看这就是数据库层面“CAS”思想在业务里的落地。如果你的项目里用了Redis也可以在这块改成Redis分布式锁。不过对于毕设来说MySQL乐观锁已经足够解释清楚你的并发处理思路。答辩时能说明白关系别自己把自己绕晕。4.5 查询慢和列表数据为空问题管理端订单列表数据量如果达到几万条不加分页直接全表查询会卡。MyBatis-Plus提供了分页插件配置一个MybatisPlusInterceptor加上PaginationInnerInterceptor然后在Service里调用page方法前端传当前页码和每页条数一切顺理成章。数据查询结果为空最常见的两个原因一是实体类没有给查询结果字段写getter/setter二是数据库字段命名是蛇形实体类是驼峰但全局map-underscore配置没开。排查方法是在mybatis配置里开启SQL日志看打印出来的SQL语句是否真的执行再检查返回值映射。5. 答辩核心问题与可扩展方向5.1 答辩时容易被追问的六个问题我整理过这个题目答辩时出现频率最高的几个问题。第一个为什么选择前后端分离而不用JSP回答思路前后端分离后端专注提供接口前端专注页面交互开发效率高部署解耦符合现在主流开发方式。第二个JWT和Session有什么区别回答思路Session存在服务端JWT存在客户端JWT天然适合前后端分离、接口无状态。自然要说JWT的缺点比如无法主动过期所以token有效期不能太长。第三个同一个座位被两个人同时购买怎么解决回答思路数据库层使用乐观锁update时带版本号条件影响行数0则回滚同时通过唯一约束保证脏数据不落库。第四个订单状态有多少种每种状态的转变条件回答思路待支付、已支付、已取消、已退款四种。用户提交订单成待支付模拟支付成功变已支付未支付前取消变已取消后台退款变已退款。第五个密码为什么不能明文存储回答思路数据库泄露时明文密码会造成连锁后果用户往往多个平台共用密码所以必须使用BCrypt之类的哈希加盐算法。第六个数据库表为什么要拆得这么细回答思路第三范式要消除冗余例如orders和ticket分离是为了支持一个订单多张票venue和concert分离是为了支持一个场馆多个演出场次。5.2 四个值得扩展的加分方向如果你做完上述基本功能还有余力我个人建议可以按优先顺序挑选以下扩展。一是引入Redis缓存。热门演出的详情和座位状态在用户访问频繁时如果每次都打MySQL性能会很难看。Redis可以做缓存并设置过期时间下单时把Redis里的座位状态当作预热一致性再到MySQL校验。二是接入支付宝沙箱或者微信支付沙箱。沙箱不需要真实营业执照用官方提供的测试账号就能跑通支付流程。接支付这个动作会让项目的完整度直接上升一个维度。三是做数据可视化大屏。用ECharts在管理端首页做一个大屏显示实时候场人数、票档销售进度、按场次占比的饼图视觉冲击很强答辩演示时很加分。四是利用Docker部署。本地开发完成后写一个Dockerfile分别部署前端和后端再用docker-compose同时启动会给你增加“工程化”的质感。不过要小心用Docker部署数据库时宿主机端口和容器端口映射错会导致本地连不上数据库。5.3 一些后知后觉的体会这个题做完我对“小而全”这三个字感受特别深。项目范围不怕小就怕乱。很多同学刚开始做就想着加满所有功能光是做那些半吊子的多余模块就消耗了大量时间到了真正答辩时连一个最核心的订票流程都讲不完整。我在实际指导中反复跟大家强调先把一条主链路彻底跑通再去丰富边缘功能。过程中另外一个深刻的体会是一定要自己动手写核心业务逻辑而不是复制一套源码就结束了。源码可以作为参考但如果你连订单状态流转、事务回滚、跨域配置这些基础部分都没亲手敲过一遍答辩时评委随便追问几个细节很可能就会被看出来。我见过很多拿着网上所谓“完整源码”去答辩的同学最后因为讲不出代码逻辑而重点标高折了。关于项目源码的学习建议再单独聊一下“源码”这件事。这个标题里带“源码”两个字但我的建议是你把下载下来的源码当成教材来对着学而不是当成终极目标。对照源码梳理一遍业务流程和表关系是最快的学习路径但一定要在原版基础上做至少三个小改动改表名、改界面风格、加一个自己的小功能。这样做一来让你深入理解代码逻辑二来避免和同学提交的内容“撞车”。第一步先不看启动代码把数据库建表脚本运行起来。第二步逐表看数据字段画出表关系图再把整个项目跑起来。第三步用基本功能界面一步步跟业务。最后把代码里最核心的订单生成部分完整读懂哪里用了事务、哪里用了乐观锁都要能指出来。这套流程走下来源码才能真正变成你自己的。我在实际项目里额外用了一个很讨巧的习惯把整个项目按照“登录注册、基础管理、订票流程、统计报表”四个阶段做测试登记表每个阶段跑通后记录一条结果。答辩前翻一遍对系统整体的把握会变得特别清楚。这个方法推荐给你亲测高效。
