每年到毕业设计选题季总有人来问我做什么题目比较好。管理系统太卷、算法题太难、硬件又没钱买最后很多人会绕到旅游景区门票销售系统这类题目上来。说实话这个题在 Spring Boot 项目里确实算得上性价比很高的一类它既是典型的信息管理系统又带订单、支付、库存这些电商属性还能延伸出扫码验票、余票控制这类有业务深度的功能点用来做毕业设计可深可浅容错率高答辩时候也有东西可讲。这篇文章就围绕我这边带过的一套 Spring Boot 旅游景区门票销售系统附带源码的那版项目编号 38585来写把选题逻辑、功能设计、表结构、关键难点的实现方案以及交付前最容易忽略的细节一次性讲清楚。无论你是正在做毕设的学生还是想快速搭一套同类系统的开发者应该都能直接照着落地。1. 为什么旅游景区门票是毕设选题里的高性价比选择1.1 三类典型毕设题目的复杂度对比Java Web 方向的毕业设计说白了就是三类纯 CRUD 的管理系统、带业务规则的管理系统、以及极少数会碰中间件和并发问题的系统。图书管理宿舍管理这类题目属于第一类做起来快但答辩时很难讲出深度评委问你这个系统难点在哪基本只能答增删改查。而旅游景区门票销售系统天然属于第二类甚至稍微往深做就能碰到第三类。为什么这么说门票销售的背后是库存问题。景区每天的票是有限的用户下单买票、退票、改签后台库存要实时联动这就比普通管理系统的记录增删改查多了一层业务约束。再加上订单有待支付—已支付—已验票—已退款的完整状态流转付款成功之后要生成电子票入园时还要验票核销这些环节连起来就是一个完整的业务闭环而不是孤立的几个页面。1.2 这个题目能展现的能力点从答辩和评审的角度看这个题目能讲的东西非常集中业务流程完整从用户注册登录、选票下单、在线支付到扫码入园链路是通的不是只做一半。有真实业务逻辑余票扣减、订单超时关闭、验票防重这些场景都贴近现实可以展开讲设计思路。技术选型有余地Spring Boot 打底Redis 处理热点票库存JWT 做登录鉴权MyBatis Plus 操作数据库这套组合在简历上也能写。工作量可控单人完成 2 到 3 个月绰绰有余不像大数据、机器学习方向那样有环境依赖和不确定性。所以我的结论很直接如果你是计科、软工、信管这类专业又不想在毕设上冒太大风险这个题完全撑得起一篇合格的毕业论文和一套可演示的系统。2. 系统模块划分与数据库建模把业务讲清楚是答辩第一关2.1 角色与功能边界开始写代码之前先把角色捋清楚。我这边这套系统分了三种角色每种角色的功能边界非常明确游客前台用户注册登录、浏览景区和票型、下单支付、查看订单、申请退款、查看电子票。景区管理员管理景区信息、维护门票类型与库存、处理退票审核、查看销售统计。系统管理员可选管理前端用户、管理景区管理员账号、查看全站数据。这个划分有一个好处前台的销售流程和后台的管理流程完全分离前后端联调时接口边界很干净写论文画用例图也省事。2.2 核心表结构与关键字段设计数据库是这套系统的地基。我常用的核心表大概有这几张表名职责关键字段scenic_spot景区信息id、name、province、city、address、description、cover_image、statusticket_type门票类型与库存id、scenic_id、name、price、stock、sold、limit_per_order、statusorders订单主表id、order_no、user_id、total_amount、status、pay_time、close_time、create_timeorder_item订单明细id、order_id、ticket_type_id、ticket_name、price、quantityticket_code电子票二维码凭证id、order_id、code、status、use_time、use_scenic_idpayment_record支付记录id、order_id、pay_amount、pay_type、pay_status、callback_timeuser前台用户id、username、password、phone、real_name、id_card有几个字段我想单独说一下因为这些是踩过坑之后才加上的ticket_type里的sold字段用来配合stock算实时余票。如果只存stock一个字段每次展示余票要通过总库存减已售来算逻辑上没问题但统计报表时不够直观。orders表里必须有close_time。超时未支付的订单需要定时关单没有这个字段后面做定时任务时连什么时候关都记不下来。每个订单关联的ticket_code建议单独建表而不是把二维码字符串塞在订单表里。因为一个订单可能买了 3 张成人票对应 3 个独立的二维码分开存才能支持单张验票。2.3 订单与库存的关联处理数据库设计里最容易出问题的地方是下单时怎么扣库存。如果简单地在ticket_type表里做UPDATE stock stock - 1高并发下会出现超卖两个用户同时买最后一张票都读到 stock1都更新成功库存变 -1。毕设阶段虽然不会有人真的拿几十万并发来打你的系统但库存扣减的并发安全是评审老师最爱问的问题之一。你至少要能说出一种解决方案后面第 4 节我会专门展开讲这里先记住一个原则库存扣减不能做成先查再改要么用数据库乐观锁要么把库存放到 Redis 里做原子扣减。3. 技术选型的逻辑Spring Boot 为什么够用且合适3.1 后端技术栈组合这套系统的主体技术栈是Spring Boot 2.7.x项目骨架与依赖管理MyBatis Plus数据访问层简化单表 CRUDMySQL 8.0关系型数据存储Redis可选热点门票库存缓存与超时订单处理JWT 拦截器登录认证与接口鉴权Hutool工具库生成订单号、二维码内容时非常方便ZXing生成二维码图片很多学生问我为啥不用 Spring Cloud、不用 Docker、不用 RabbitMQ。我的回答是毕业设计的核心是完整可用逻辑自洽而不是技术堆砌。Spring Boot 单体应用完全撑得起用户订单支付验票这个量级的系统引入微服务只会让部署和调试复杂度成倍上升一旦中间件起不来演示当场翻车得不偿失。3.2 认证方案JWT 与拦截器前端是前后端分离的 Vue 项目所以后端接口需要一套无状态的认证方案。我用的是 JWT用户登录成功后后端生成 token把userId和role写进 token 的 claims 里。前端把 token 存在 localStorage每次请求在 header 里带上Authorization: Bearer token。后端写一个拦截器拦截/api/**下的请求校验 token 是否有效、是否过期。这里有一个容易被忽略的细节token 里不要放敏感信息比如手机号、身份证号。毕设项目虽然不像商业项目那样严谨但论文里如果写了采用 JWT 保障系统安全结果 token 里明文放了身份证号答辩时被追问会很难看。3.3 前端与交互层前端我用的是 Vue 2 Element UIH5 端也可以拆一个轻量页面给游客买票用。移动端页面重点做好三件事景区列表筛选、门票选择与数量加减、订单支付倒计时。PC 后台则重点做数据表格、表单校验和简单的统计图表可以用 ECharts。前后端联调阶段有个小建议接口返回格式统一用{ code: 200, message: ok, data: {} }这种结构拦截器里对401和500做统一处理。不然每个页面各写一套错误提示后期改起来非常痛苦。4. 核心难点一余票扣减与超时关单的实现方案4.1 常见扣减方式与选型前面提到库存扣减不能先查再改。这里给三套方案按复杂度从低到高排列第一种数据库乐观锁。在ticket_type表加一个version字段更新时带上版本号UPDATE ticket_type SET stock stock - #{num}, sold sold #{num}, version version 1 WHERE id #{id} AND stock #{num}这种方式的好处是简单、依赖少stock #{num}本身就是条件天然防超卖。缺点是数据库行锁会带来一定的性能损耗但毕设量级完全感受不到。第二种Redis 原子扣减。把门票库存预热到 Redis用DECR命令扣减减之前判断剩余量。好处是性能高坏处是要处理 Redis 和 MySQL 的数据一致性比如Redis 里扣了但订单最终没创建成功怎么回滚这是一个能写进论文的大话题。第三种分布式锁。用 Redisson 或 Zookeeper 实现复杂度最高毕设阶段真的没必要。我这里默认用的是第一种因为逻辑最直白论文里也好解释。如果你想让项目看起来更有深度可以在论文里提一句后续可引入 Redis 缓存热点票库存不需要真的实现。4.2 超时关单的实现逻辑用户下单后如果一直不付款订单会一直占着库存。所以要做超时关单超过设定时间比如 15 分钟未支付订单自动关闭库存回补。这个功能主流做法有两种一是定时任务扫描。Spring Boot 里用Scheduled注解写一个定时任务每隔一分钟扫描一次orders表把status 0待支付且create_time超过 15 分钟的订单关掉同时回补库存。Scheduled(fixedDelay 60000) public void closeExpiredOrders() { LocalDateTime deadline LocalDateTime.now().minusMinutes(15); ListOrders expiredOrders ordersMapper.selectList( new LambdaQueryWrapperOrders() .eq(Orders::getStatus, 0) .lt(Orders::getCreateTime, deadline) ); // 逐个关单、回补库存 }二是 Redis 过期监听。下单时把订单号写进 Redis 并设置过期时间过期后通过 key 过期事件触发关单逻辑。这个方案依赖 Redis 的keyspace notifications特性配置比较麻烦而且消息可能丢失做毕设不推荐。我实际用的是定时任务方案原因只有一条可解释、可控制、不会丢订单。定时任务的延迟在一分钟以内对用户体验没有实质影响。4.3 支付回调与状态流转毕设项目接真实支付宝或微信支付从申请商户号到完成实名认证周期太长大部分学生走不通。所以我在源码里做的是模拟支付用户点击支付弹出一个支付确认框确认后调用后端接口后端直接把订单状态置为已支付并生成电子票二维码。这个设计在论文里一定要写清楚否则答辩老师会问你的支付接入的是真实通道吗你要能回答由于个人开发者无法申请商户号此处采用模拟支付流程支付接口预留了对接真实支付网关的扩展点。状态流转我用一张图就能说清楚待支付0 - 已支付1 - 已验票2 待支付0 - 已关闭3 已支付1 - 已退款4每一个状态变更都要在payment_record表里留一条记录方便追溯。这是业务系统的基本素养也是论文里可以写系统可追溯性设计的素材。5. 核心难点二电子票二维码与验票流程5.1 二维码内容生成策略支付完成后系统需要生成一张电子票用户拿着它到景区闸机核销。二维码里放什么内容是有讲究的。最直接的做法是把order_id或ticket_code的原始值放进去但这样就有一个问题二维码是可被截屏传播的拿到二维码的人复制一下就能伪造。所以更稳妥的做法是生成一个服务端可验证的密文。我这里的方案是取ticket_code表的自增主键加上一个固定密钥做 AES 加密再把加密后的字符串转成二维码。验票时闸机扫码拿到密文后端解密出主键再查表验证状态。密钥放在后端配置里前端和二维码本身都不暴露原始主键伪造难度大幅提升。5.2 验票端的处理流程验票不一定要做成独立的闸机 App我在源码里做的是一个验票后台页面扫码枪或手机扫码后自动把二维码内容提交到验票接口。接口的处理逻辑是这样的解密二维码内容拿到ticketCodeId。查询ticket_code表判断记录是否存在。判断状态是否为未使用如果已使用返回该票已核销。判断该票对应的订单是否处于已支付状态。全部通过后更新ticket_code状态为已使用写入use_time。这里有一个细节如果一个订单买了 3 张票3 个二维码可以分别核销验票接口每次只处理一个ticketCodeId互不影响。这也是为什么前面强调要把二维码单独建表。5.3 防伪与防重入验票最容易出的问题是重入同一张票被扫两次。这个问题在代码层面就是一个状态判断的事ticket_code表里status从 0 改成 1 后再扫直接拒绝。但这要求更新状态时用条件更新而不是先查再改UPDATE ticket_code SET status 1, use_time NOW() WHERE id #{id} AND status 0如果影响行数为 0说明已经被用过。这个写法和库存扣减是同一个思路用数据库条件更新保证原子性。把这个原理写进论文评委一看就知道你是真做过不是抄的。6. 把一个毕设做成答辩级项目的落地经验6.1 代码之外必须交付的文档源码里只有代码是不够的这也是很多学生最容易翻车的地方。一套完整的毕设项目至少要有这么几个东西sql/目录放建库建表脚本和初始数据。初始数据要包含至少 5 个景区、每个景区 3 到 5 种票型、一个可用的管理员账号、一个可用的用户账号这样演示时不用现场注册。README.md写清楚项目结构、启动步骤、数据库配置、默认账号。很多评委拿到源码后会自己跑一遍跑不起来印象分会打折扣。接口文档至少把登录、下单、支付、验票这几个核心接口的请求和响应示例写清楚。数据库设计说明包含每张表的用途和核心字段的注释可以直接粘贴到论文第三章。6.2 演示时容易被追问的点结合我带毕设的经验评委最喜欢问这几个问题你库存扣减是原子操作吗——用乐观锁方案回答顺便说一句库存字段加版本号更新时校验版本号与库存量。超时订单怎么处理的——讲定时任务说清楚扫描频率和状态回补。二维码如果被复制了怎么办——讲密文加密方案再补一句实际部署可叠加动态令牌定期刷新。为什么用单体不用微服务——答业务规模决定架构复杂度单体架构在保证可用性的前提下最小化运维成本。这些问题没有标准答案但你不能一句话都说不出来。凡是答不上来的点写论文的时候就要提前查好这是最笨也最有效的准备方式。6.3 源码交付前的自检清单最后分享一个我每次交付源码前都会过一遍的自检清单你可以直接抄作业数据库脚本能不能在全新环境一键执行成功有没有写死绝对路径配置文件里的数据库地址、账号密码是否改成通用配置比如localhost和root/123456而不是某个人的本机环境项目能不能用mvn clean package直接打 jar 包打完之后能不能java -jar跑起来有没有遗留的测试数据和调试代码比如System.out.println、写死的 token、注释掉的业务逻辑。前端构建产物是否包含在内还是需要重新npm install npm run build如果重新构建package.json 里的依赖版本是否锁死这些细节看起来不起眼但每年都有学生栽在我本地能跑你那边跑不起来这句话上。源码交付的意义是让别人也能复现你的成果做不到这一点代码写得再漂亮也是零分。关于这套 Spring Boot 旅游景区门票销售系统的完整设计思路到这里该讲的都讲了。如果你正在做这个题目建议先别急着写代码拿着第 2 节的表结构设计去把数据库建好再对照第 4、5 节的核心逻辑把代码骨架搭起来。按这个顺序走整个过程会顺很多。也建议你把这几章内容消化之后结合自己学校的论文模板去组织章节结构会比直接对着代码写论文轻松很多。