1. 售票系统的业务拆解它不是单纯的增删改查做这种KPL比赛网上售票系统最容易被低估的地方恰恰是业务本身。很多人一看到售票系统四个字第一反应就是不就是用户表、订单表、赛程表写几个增删改查接口嘛。真动手做起来才知道一个能在课堂上拿得出手、能通过答辩、能跑完整的项目难点根本不在于某个接口怎么写而在于你怎么把现实里的售票规则准确翻译成后端代码。题目里同时挂了源码文档调试vue前后端分离这意味着你拿到的不是一段随手拼出来的代码而是一套能讲清楚、能二次开发、能演示完整流程的项目这套项目里的每一个模块都得有业务逻辑做支撑。1.1 从一张票说起核心流程到底有几步我们先从用户视角走一遍。一个观众想去看某场KPL比赛他打开系统要做的事情是注册登录、浏览赛事列表、查看某场比赛的详情、选一个座位或者票档、下单、支付毕设里通常是模拟支付、拿到电子票。这个流程听起来简单但落到代码层面就非常具体注册登录要区分普通用户和管理员两种角色否则后面的后台管理页面没有权限控制项目深度就不够浏览赛事列表不是查一张表就完事通常要显示是否开售剩余票量比赛时间这些动态数据而这些数据来自不同的表甚至要实时计算选座位属于典型的并发读写场景两个用户同时点同一个座位系统必须保证只有一个人能下单成功订单状态至少要区分待支付已支付已取消已退票已完成每一种状态流转都有对应的接口逻辑。所以真正动手建表、写接口之前我建议先把下面这张流程图画在纸上不是画在代码里是画给自己看用户——选择场次——锁定座位——生成订单——支付——出票。画完之后你会发现订单表其实不是核心座位状态和支付回调才是核心。很多人项目做砸就是因为在订单表上花了大把时间最后座位超卖、订单重复演示现场翻车。1.2 用户端和管理端的功能边界决定了项目的完整度一套合格的毕设售票系统绝对不能只有买票这一半。看别人写的完整源码时你要特别注意管理员端都做了什么因为那才是区分Demo级和项目级的关键。我的建议是把功能拆成两张表来看端核心功能涉及的关键表/字段用户端注册登录、赛事列表、场次详情、选座、下单、模拟支付、订单查询、个人信息用户表、赛程表、场次表、座位表、订单表管理端赛程录入、场次维护、座位区域设置、票价配置、订单管理、退票审核、基础数据统计赛程表、场馆表、座位表、订单表、统计SQL这里有个常见的误解以为管理端就是多几个表格每个表格配一个增删改查接口就完了。实际上管理端最难的是和用户端的联动。比如管理员录入一场比赛的时候要不要初始化全部座位票价改了之后已生成的订单要不要跟着改管理员把赛程删了那些待支付订单怎么办这些问题如果不在设计阶段想清楚写代码的时候你会顾此失彼改一个地方崩三个接口调试起来怀疑人生。1.3 为什么选择Spring Boot Vue 前后端分离从技术选型上说这个组合在目前的学生项目里非常主流选它不只是跟风而是它真的能让你把精力放在业务上而不是放在环境搭建上。后端用Spring Boot是因为它对Web开发做了大量封装一个注解就能搞定路由、参数绑定、JSON序列化。你不需要像Servlet时代那样重写一大堆doGet和doPost。而且Spring Boot自带的依赖管理、内嵌Tomcat让项目在任何电脑上都能以几乎相同的方式跑起来。这对需要反复演示、多人接手、答辩换环境的情况来说太重要了。前端用Vue是因为它用组件化的方式组织页面一个座位图是一个组件一个订单卡片是一个组件复用起来非常方便。再加上Vue生态里的Vue Router、PiniaVuex这些配套工具做单页应用非常顺手。至于前后端分离说到底解决的是职责边界问题。后端只负责算清楚——余票还有多少、订单是否合法、用户有没有权限前端只负责展示好——页面长什么样、点击后调哪个接口。这样以后想换App端、小程序端后端接口可以原样复用不用重写业务。这也是为什么正规项目都愿意用前后端分离的架构。2. Spring Boot 后端的三大硬骨头库存、订单、权限后端开发这件事很多新手喜欢从Controller开始写写完一个查接口就去前端调试一个页面。这个顺序不是不行但很容易让你陷进接口越写越乱、表越改越多的泥潭。我的习惯是先把数据库表结构定死再写service层的业务逻辑最后才写Controller接口。因为Controller本质是薄薄的一层转发真正的业务都该待在Service层里。2.1 数据库表设计从赛程到座位的一整套落库方案项目标题里虽然没有明确说用了什么数据库但Spring Boot项目最常用的组合就是MySQL MyBatis或者MyBatis-Plus。我在设计这套项目的数据模型时一般会拆出下面几张表用户表id、用户名、密码BCrypt加密存储、手机号、角色标识、创建时间赛程表id、赛事名称、比赛时间、比赛地点关联场馆、状态未开售/开售中/已结束场次表id、关联赛程id、开赛时间、售票状态、总票数、已售数量这个字段用来做余票展示加速座位表id、关联场次id、区域、排号、座位号、状态可用/已锁定/已售出、价格订单表id、订单编号、用户id、场次id、座位id、金额、状态、创建时间、支付时间。这个结构看起来普通但其实每一步都有讲究。比如为什么要有已售数量这个冗余字段如果每一次展示余票都去count座位表场次一多、用户一多数据库压力会非常大。冗余一个字段每成交一单就update一次查询时直接读这个字段效率完全不同。再比如订单要关联座位id而不是只存座位号字符串这是为了以后做退票、做座位状态回滚、做统计的时候能精准操作。如果只存一个3排5号这种字符串退票时你还要去解析字符串再回写座位状态给自己找麻烦。2.2 余票扣减和座位锁定乐观锁是保命手段这是整个后端里最核心、也最容易被答辩老师追问的地方。先上一个最典型的错误写法前端点了下单后端就执行先查一下座位状态如果可用再update成已锁定最后插入订单。逻辑看着没问题但两个用户同时发起请求时可能都查到可用然后都执行update最终就超卖了。解决办法并不需要上分布式锁加乐观锁就足够了。最朴素的做法是在座位表加一个version字段或者在update语句的条件里加入原状态条件比如UPDATE seat SET status LOCKED WHERE id #{seatId} AND status AVAILABLE;这行SQL就是核心。Java里用MyBatis写的话返回值是影响的行数如果等于0说明座位已经被别人抢了直接抛业务异常提示该座位已被占用。如果等于1说明这次抢座成功再往下走创建订单。我在这类项目里还喜欢再加一层事务保护。把锁定座位创建订单更新已售数量放在同一个事务里任何一个步骤失败全部回滚。Spring Boot里只需要在Service方法上加一个Transactional注解就行注意rollbackFor要设置成Exception.class否则某些运行时异常不会触发回滚这个细节经常坑人。2.3 Token鉴权和角色权限拦截器决定的访问边界后端权限一般用的是JWT 拦截器方案。登录成功后后端生成一个Token返回给前端前端把Token存在本地往后的每次请求都放在Authorization头里。后端写一个拦截器对请求头取Token、解析、放行。比较关键的两个设计点白名单。登录接口本身不能拦截否则用户压根进不来Swagger接口文档地址、静态资源、前端页面打包后的访问路径都要加到白名单里。拦截器里写死一个list放行这些URL。角色校验。管理员的接口比如赛程录入、订单管理除了判断有没有Token还要判断Token里解析出的角色是不是ADMIN。我通常会在自定义注解RequireAdmin上加一个拦截器处理或者在Controller方法开头手动判断。答辩的时候这个点讲出来老师的印象分明显不一样。Token失效场景也要想好。前端请求时如果后端返回401Vue那边的Axios响应拦截器应该自动清空本地Token并跳转到登录页。这个前后端联动逻辑就是很多项目演示现场登录状态过期卡死问题的关键。2.4 统一返回结构与全局异常让前端少写一百个判断前后端分离的项目最忌讳后端到处散装返回数据。今天我返回{code:200, data:xxx}明天另一个接口返回一个裸数组前端Axios封装就非常痛苦。我的建议是后端固定一个统一的返回体类比如叫ResultT字段就是code、message、data三件套所有Controller方法返回值统一用这个包装。配套还要写一个RestControllerAdvice全局异常处理器。业务异常比如座位已被占用和系统异常空指针、数据库异常分开处理前者返回code500和友好提示后者返回code500和系统异常请稍后重试顺便把异常日志打出来。这样就算你的代码有Bug现场被演示白屏了前端拿到的是明确提示而不是一串吓人的英文堆栈。3. Vue 前端从零到下单组件、路由与接口联调后端接口写得再规整如果前端乱七八糟项目一样立不住。Vue那半边很多人上来就照着某个后台管理模板铺页面把几十个组件一次性摆开结果路由配得迷数据流绕来绕去。其实售票系统的前端不需要那么宏大把几个核心场景定义清楚就成功了一大半。3.1 前端工程化的目录结构从一开始就别乱新建Vue项目之后我习惯先把目录规划好。src/api下面是所有接口请求的封装一个业务模块一个文件比如user.js、match.js、order.jssrc/views是页面级的组件比如MatchList.vue、MatchDetail.vue、SeatSelect.vue、OrderList.vuesrc/router是路由器src/store是全局状态管理如果是Vue3我建议直接上Pinia比Vuex简洁很多。这套结构的好处是每一个页面的代码量都受控不会出现一个.vue文件两千行的恐怖局面。评审老师问你这个项目怎么维护你拿目录结构说话就够了。3.2 路由守卫和Axios封装访客与管理员的分流路由部分要见真章的是路由守卫。用户没登录就想访问我的订单页面要重定向到登录页普通用户想访问后台管理页要直接拦掉。Vue Router 4的写法大致如下router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requiresAuth !token) { next(/login); } else if (to.meta.requiresAdmin localStorage.getItem(role) ! ADMIN) { next(/); } else { next(); } });这个逻辑不难但能写出来说明你理解了前端路由不只是页面切换也是一种权限防线。当然前端守卫只是体验层的保护真正的安全还是靠后端接口拦截这个点答辩时一定要说清楚别给自己挖坑说前端拦住就安全了。Axios封装要做的三件事设置baseURL、请求拦截器里塞Token、响应拦截器里统一处理错误。核心代码不多但非常实用service.interceptors.request.use(config { if (localStorage.getItem(token)) { config.headers.Authorization localStorage.getItem(token); } return config; }); service.interceptors.response.use( res { if (res.data.code 200) return res.data.data; // 业务错误统一弹提示 ElMessage.error(res.data.message || 请求失败); return Promise.reject(res.data); }, err { if (err.response err.response.status 401) { localStorage.clear(); window.location.href /login; } return Promise.reject(err); } );3.3 座位选择组件的实现思路座位图是售票系统里最有辨识度、也最能体现代码功力的功能点。原理其实并不复杂后端从上到下按区域返回座位列表前端用一个二维数组渲染成一个网格每个座位是网格里的一个按钮按钮的颜色由座位状态决定——绿色可买、灰色已售、蓝色选中。点击灰色座位直接禁用点击绿色座位就切换成选中状态。这里有一个非常容易忽略的细节选座之后的锁定是临时的不是永久的。用户选了座位但迟迟不支付座位不能一直锁着。常见做法是给锁定加一个有效期比如5分钟到期自动释放回AVAILABLE。演示的时候讲一讲这个设计项目的真实感会强很多。座位组件的数据流大概是从MatchDetail.vue接收场次id从后端接口拿到该场次的完整座位状态数组渲染出来后维护一个本地已选数组点立即购买时把这个已选数组提交给下单接口。整个组件的核心就是状态映射样式和选中数组的管理两件事。3.4 哪些数据放进全局状态哪些留在组件内部很多初学者喜欢把所有数据都塞进Vuex/Pinia理由是全局都能访问。但状态管理的正确用法是跨页面共享、且会被多个页面修改的数据才值得放。用户信息和角色信息要放因为路由守卫、页面头部、个人中心都要用购物车数据或者本场次已选座位列表就不一定要放因为它在单个页面生命周期里使用组件内部维护反而更清晰、更不容易被别的地方误改。这算是我带人改项目时反复强调的一个理念。数据放得越集中销毁和重置的时机就越难把握出Bug的概率越高。合理私有化才是稳定的起点。4. 前后端分离调试实录跨域、时序与空指针的排错链路前端页面写好了后端接口也写完了接下来才是这个项目真正耗时的地方联调。前后的分离的项目有一个共性——不是自己代码跑不起来而是两边拼在一起时问题一个接一个。这一节我把自己调试过程中印象最深、也最值得记录的几类问题整理出来。4.1 跨域问题的三种解法以及我推荐哪一款前后端分离开发时前端跑在localhost:5173Vite默认端口后端跑在localhost:8080端口不同就被浏览器判断为跨域。解决办法有几种Controller方法上加CrossOrigin注解、写一个WebMvcConfigurer全局配置实现CorsRegistry、后端统一设置响应头。我自己最推荐第二种理由很简单——一个全局配置搞定所有接口不用在每个Controller上重复加注解也不容易漏。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowCredentials(true) .maxAge(3600); } }但这里有个大坑allowCredentials(true)和allowedOrigins(*)不能同时用浏览器会拦截这种配置提示Credentials和通配符不能配对。解决方式是使用allowedOriginPatterns(*)这是Spring提供的一个支持通配符且允许携带凭证的配置项。很多同学按网上老帖子配了allowedOrigins(*)结果前端报错半天找不到原因就是卡在这个细节上。4.2 时间格式LocalDateTime的数组化问题前后端联调时会遇到一个很典型的现象后端接口返回一个时间字段前端打开Network面板一看不是2025-06-15 14:00:00而是[2025, 6, 15, 14, 0, 0]这样一个数组。这不怪前端因为Spring默认对LocalDateTime的序列化方式就是把它当成一个带六个字段的对象。如果项目继承了Spring Boot 2.x我建议直接在application.yml里配一个Jackson全局时间格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8如果项目用的是Spring Boot 3.x光配这个还不够建议额外引入jackson-datatype-jsr310或者在ObjectMapper里单独为LocalDateTime注册JavaTimeModule并设置格式。否则你会在为什么Date能用格式化、LocalDateTime却不生效的问题上浪费一整个晚上。4.3 联调排错的标准链路从Network面板到日志文件联调阶段最怕的是问题报出来两个人互相推——前端说我请求发了啊后端说我没收到啊。我总结了一条比较固定的排错链路先看浏览器Network面板请求有没有发出、状态码是多少、响应体是什么。如果状态码是404多半是路径写错了405是请求方法不匹配GET/POST颠倒了415是Content-Type没对应上比如后端接口需要JSON但前端发的是form格式。再看后端控制台日志看有没有异常堆栈、请求有没有进到Controller。如果日志显示进去了但结果不对问题大概率在Service层逻辑里如果日志根本没打印问题在路由映射或拦截器。最后看数据库里的数据操作一个下单流程但库里订单表没记录就看事务有没有提交、有没有回滚。用MyBatis时建议把控制台开启SQL日志logging: level: com.example.mapper: debug这样能直接看到每一条SQL的执行情况和查询参数很多查不到数据的问题一眼就找到了。4.4 空指针和null传参联调时最常见的后端Bug这类项目里高频Bug非空指针莫属。最常见的场景是前端提交表单时有些字段没填、或者传的字段名和后端实体对不上后端接收到的对象里某个属性就是null接下来代码一执行xxx.getYYY()就直接抛空指针。根本原因是后端少做了参数校验。排查思路其实很简单把异常堆栈往上看找到第一个at com.example.开头的行点过去看一下是哪一行代码调用了空对象的方法然后往前推这个对象从哪里来问题基本就浮出水面了。修复的时候别只在调用处加一个if(xxx ! null)更好的做法是在Controller入口就使用Validated注解配合实体字段上的NotNull、NotBlank这些JSR-303校验注解让非法参数在入口就被挡掉。5. 拿到成套源码后如何快速读懂并完成二次开发最后一个部分说说文档和源码怎么用。你拿到的所谓源码文档调试本质上是别人已经替你走过一遍完整开发流程的产物。在动手改代码之前花两到三个小时把项目结构摸透远比你急着跑起来要划算得多。5.1 快速上手一套Spring Boot项目的阅读顺序我的阅读顺序一般是这样的先看pom.xml或者build.gradle里的依赖知道项目里用了什么框架、什么插件再看application.yml知道数据库配置、端口、日志级别然后找启动类看SpringBootApplication和可能存在的MapperScan注解确认mapper接口的扫描范围接着按着Controller - Service - Mapper这个调用链找一个最简单的功能模块从头到尾读一遍比如查询赛事列表。这个方法的核心思路是从入口往底层走而不是从底层往上猜。先通过Controller知道暴露了哪些API再通过Service知道每个API做了什么业务操作最后通过Mapper或者XML看SQL是怎么写的。三张信息拼起来整个项目在你脑子里就立体了。5.2 数据库初始化脚本和文档是你的第一手资料来源一套完整的项目包里数据库初始化SQL文件往往比代码还重要。你要做的不是看它建了多少张表而是重点关注每张表的字段、主外键关系、初始数据有没有管理员账号。很多项目的后台密码、演示账号密码都在SQL文件里。把数据库导入成功、把默认账号调试通过项目就算能跑了。项目文档一般会包含数据库设计说明、功能模块说明、接口说明。读文档的时候别从头逐字读到尾先看目录找到运行环境部署步骤接口清单这几个部分优先读最后再回来看设计思路。这样能在最短时间内掌握项目的使用边界。5.3 新增一个功能模块的完整思路演示学会二次开发才是你从会抄走向会写的关键一步。假设我要给这个售票系统加一个验票入场功能管理员扫一下观众电子票上的二维码就能把这张票标记为已使用。第一步数据库层面给订单表加一个status的取值比如从已支付流转到已入场再加一个ticketType字段区分电子票类型第二步后端层面写一个验票Service方法接收票码先校验订单是否存在、是否已支付、是否已入场然后更新订单状态第三步Controller层暴露一个POST /admin/ticket/check接口还要走管理员权限校验第四步前端层面在管理端页面加一个二维码扫描区域调接口后提示验票成功/失败。这四步走下来你会发现之前搭建好的项目骨架、统一返回体、全局异常、权限拦截器全部能复用。这也是为什么我一直强调架构设计得好二次开发就是往固定轨道上添车厢而不是另起炉灶铺铁轨。5.4 调试中容易被忽略的三个小技巧最后把这套项目调试过程中三个非常实用的小技巧分享出来。第一前后端分离时接口开发阶段的排错优先用接口测试工具。不需要等前端页面全部写完后端写完一个接口就先用测试工具发一次请求确认返回正确再继续写下一个。这样能保证后端每个接口都是独立验收过的联调时即使出问题也知道问题出在前端。第二事务方法内部不要捕获异常后吞掉。我当时在写退票功能时想在Service里自己try-catch结果事务一直不生效退了票座位状态也没回滚。后来发现Spring事务是通过异常传播触发回滚的你把异常捕获了事务管理器根本感知不到。要么及时抛出异常要么手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()别自己吞。第三Windows环境下Redis、MySQL的路径不要带中文和空格。这个项目如果用到Redis做缓存分布式锁或者MySQL用了自定义配置安装路径里带中文的话经常出现启动好了但是连不上的玄学问题。后来的实践经验是所有中间件尽量装到纯英文无空格的目录下能避开大量莫名其妙的坑。