Spring Boot景区售票系统设计与实现：从数据库到高并发库存方案

毕业设计做景区售票系统，其实是个挺经典的选择。经典意味着参考资料多、网上现成代码多，但也意味着很容易撞题、很容易做得千篇一律。我见过太多同学把“基于SSM的某某管理系统的设计与实现”改个名字就交上去，最后答辩被老师一问“你系统里最核心的技术难点是什么”就卡壳。

这篇博文我想换个思路来聊聊Spring Boot景区售票系统的完整设计与实现。不光是给你一套能跑通的源码，更重要的是把这套系统从业务分析、数据库设计到核心代码实现的完整链路讲清楚，让你交上去的毕设既拿得出手、又经得起问。

先交代一下我自己的情况，带过几届学生的毕设，自己也做过不少企业级的票务类项目。景区售票系统这个题目，看上去简单，但里面涉及的技术点其实很值得展开：库存扣减与超卖问题、订单状态机的设计、多渠道售票（窗口、线上、旅行社）的对账逻辑，以及高峰期高并发下的系统表现。把这些问题想明白、做出来，你的毕设水平会明显比同组的同学高一大截。

1. 为什么选景区售票系统：业务痛点与毕设定位分析

1.1 景区售票场景的特殊性在哪里

景区售票和普通的电商下单差别并不小。电商下单核心是商品加购物车、下单、支付、发货，库存充足且不涉及严格的时效性。景区售票则要面对几个特殊的业务约束。

第一是票种的时间属性。景区的票通常分成人票、儿童票、学生票、老人票，还可能有上午场、下午场之分，甚至特定的日期票价还会浮动。这个“票”本质上绑定了一个时间段，一旦过期作废，不能让游客拿着昨天的票进今天的大门。

第二是库存的实时性。景区的日接待量是有上限的，这个上限可能来自环保部门核定的最大承载量，也可能来自景区自身的运营能力。系统需要在用户下单时实时判断某个日期的某个票种是否还有余票，这就引出了并发控制的问题。

第三是多渠道售票的一致性。窗口售票、官网购票、OTA平台分销，这些渠道共享同一个库存池。如果渠道之间数据不同步，游客在OTA上买到了票，到了景区窗口却说没票了，这种体验会很糟糕。

毕设阶段的系统虽然不需要实现完整的OTA对接，但设计时应该把这些场景考虑进去，至少在自己的系统内做到订单与库存的一致性。

1.2 毕设的定位：功能完整度与创新点的平衡

做毕设和做企业项目有一个很大的不同——毕设要有明确的功能边界和创新点，不能什么都做，更不能什么都做不好。

我建议技术选型放在Spring Boot 2.x + MyBatis Plus + MySQL这套组合上。Spring Boot简化了项目配置，MyBatis Plus让单表CRUD的开发效率提升一个档次，MySQL则足够应对大多数毕设场景的数据存储需求。前端如果精力有限就用Thymeleaf模板引擎或者Vue + Element UI搭建一个简洁的管理后台，重点放在后端业务逻辑的实现上。

创新点可以从下面几个方向里挑一个做深：

• 分布式锁解决库存超卖问题（很多毕设只是嘴上说说，真正实现了的很少）
• Redis缓存热点数据，包括票种信息、余票数量、景区公告
• 使用RabbitMQ削峰填谷，应对抢票高峰期的瞬时流量
• 基于ECharts的售票数据可视化大屏，让数据展示更有说服力

挑一个点做扎实，比每个点都浅尝辄止要强得多。答辩的时候老师问起来，你能把原理和实现细节说清楚，这个毕设就已经成功了一大半。

2. 技术选型背后的逻辑：为什么是Spring Boot + MyBatis Plus + Redis

2.1 技术栈选择的真实考量

很多同学选技术栈的习惯是“看别人用什么我就用什么”，这样其实不太好。选型应该是基于项目需求和自身情况的综合判断。

单体应用足够吗？对于景区售票系统这个量级，答案是足够的。选择微服务架构虽然听起来更“高级”，但在毕设阶段反而会引入服务拆分、分布式事务、服务治理这些额外复杂度，如果没有足够的精力很容易翻车。Spring Boot的单体架构加上合理的模块划分，完全能够支撑起一个逻辑完整、可扩展性良好的系统。

持久层框架方面，MyBatis和MyBatis Plus是目前的主流选择。MyBatis Plus在我实际开发中的体会是，基础的增删改查几乎不用写SQL，加上条件构造器可以直接实现动态查询，这一点对于开发效率的提升非常明显。复杂的手写SQL在需要多表联查、报表统计的时候再用，两者配合起来效率很高。

缓存组件选Redis没什么悬念。余票数量这类热点数据的读取频率极高，每次都去查数据库会给数据库造成不必要的压力。把余票数量放在Redis里，配合定时任务或事件机制同步到数据库，是实际项目里非常成熟的做法。

2.2 项目结构的分层设计

项目结构遵循标准的Controller - Service - Mapper三层架构，再加一个config包放配置类、一个common包放统一返回结果和异常处理。

code复制src/main/java/com/example/ticket
├── controller        // 接口层
├── service           // 业务逻辑层
│   └── impl          // 业务实现
├── mapper            // 数据访问层
├── entity            // 实体类
├── dto               // 请求响应对象
├── config            // 配置类
├── common            // 公共类（返回结果、常量、异常）
└── utils             // 工具类

这个结构是经过大量项目验证的成熟方案。controller层只做参数接收和结果封装，不写业务逻辑；service层承载核心业务逻辑，事务控制也在这里；mapper层只负责数据交互。各层职责单一，出了问题定位也容易。

2.3 环境准备中的常见坑

开发环境建议使用JDK 1.8、Maven 3.6+、MySQL 5.7+、Redis 5.0+。这个组合兼容性最稳定，网上遇到问题也容易搜到解决方案。

IDEA中创建Spring Boot项目时，Spring Initializr选择Spring Boot 2.7.x版本即可。这里有个小提示——国内访问Spring Initializr有时候比较慢，可以换成阿里云的镜像地址。Maven的settings.xml里配置阿里云镜像源，依赖下载速度会提升很多。

Redis在Windows下的安装方式要注意一下。官方其实不提供Windows版本，GitHub上有微软维护的开源版本可以下载。用起来没什么问题，但注意Redis服务需要手动启动，而且不会开机自启。本地开发的时候每次要先启动Redis，否则项目启动会报连接超时的错误，这个很多人踩过坑。

3. 数据库设计的核心：从景区承载量到订单状态流转

3.1 核心表结构设计

景区售票系统至少需要设计景区信息表、票种表、库存表、订单表、订单明细表、用户表和支付记录表。这些表共同构成了系统的数据基础。

景区信息表（scenic_spot）用来存储景区的基本信息，包括景区名称、地址、开放时间、联系电话、景区简介、每日最大承载量。每日最大承载量这个字段很关键，它是后续票种库存校验的基础约束。

票种表（ticket_type）定义景区有哪些类型的门票。核心字段包括票种名称、票种类型（成人票、儿童票、学生票、老人票等）、价格、适用说明。这里要注意做个逻辑判断：票种和景区是多对一的关系，票种必须挂在某个景区下面；另外票种的价格应该使用DECIMAL(10, 2)类型，直接用DOUBLE会出现精度丢失问题。

库存表（ticket_stock）是这张设计的核心，也是区分“做过实际项目”和“只是抄了套代码”的分水岭。它的核心字段包括景区ID、票种ID、销售日期、总库存、已售数量、剩余库存。为什么要单独建一张库存表而不是直接在票种表里存一个库存数字？因为景区的票是分日期的。一个“成人票”在10月1日和10月2日可能库存完全不同，游客买任何一张票都精确到具体日期。库存表的主键逻辑由景区、票种、销售日期三个维度共同确定。

订单表（orders）记录每一笔订单的核心信息。包括订单编号、用户ID、订单总金额、订单状态、支付方式、支付时间、创建时间。订单状态建议用整数来存储，0表示待支付、1表示已支付、2表示已使用、3表示已取消、4表示已退款。用整数而不是字符串，是为了后续状态流转的判断更加方便高效。

订单明细表（order_item）存储订单中的每一张票的信息。一个订单可以包含多种票种，每种票种对应一条订单明细记录。字段包括订单ID、票种ID、销售日期、购票数量、单价、小计金额。

用户表（user）的字段相对标准——用户名、密码、手机号、昵称、角色。角色字段区分管理员和普通游客，管理员可以登录后台系统进行票务管理，游客通过前台系统进行购票。

3.2 订单状态机的设计思路

订单状态是整个系统最核心的业务逻辑之一。状态机设计得好，后续的支付回调、订单取消、退款流程都会顺畅很多。


四个核心状态描述一下：

• 待支付：用户提交订单后进入的状态，此时需要锁定库存。如果30分钟内未支付，系统自动取消订单并释放库存。
• 已支付：用户支付成功后由支付回调触发状态变更，此时正式扣减库存。
• 已使用：游客到景区后核销门票，门票的状态从已支付变为已使用。
• 已取消/已退款：用户主动取消或者超时未支付系统自动取消，需要释放库存；已支付订单申请退款审核通过后进入已退款状态。

这里有一个设计细节值得展开：下单时先锁定库存还是支付成功后再扣库存？两种方案都有实际项目在用。我建议采用“下单时锁定库存、支付成功时正式扣减、取消时释放库存”的方案。这样做的好处是用户在支付倒计时内，这个票是被占住的，其他用户买不到，保证了用户体验。坏处是如果有人恶意下单不付款，会有部分库存被浪费，但可以通过超时取消机制来回收。

3.3 为什么要用逻辑删除而不是物理删除

景区数据、票种数据这类基础信息表，建议使用逻辑删除。具体做法是给表加一个deleted字段，默认值为0，删除操作执行时改为1，查询时自动过滤掉已删除的数据。

逻辑删除的价值主要体现在两个场景。第一个场景是数据的可追溯性——比如某个票种被删除了，但历史订单里还要能查到当时的票种信息。如果物理删除，订单明细表里的价格信息倒是还在，但票种信息就查不到了。第二个场景是误操作恢复——管理员不小心删掉了一个票种，如果是逻辑删除，一条SQL就能恢复，物理删除就得靠数据库备份了。

MyBatis Plus对逻辑删除有原生支持，在application.yml里配置一下，实体类字段加上@TableLogic注解，删除操作和查询操作会自动带上逻辑条件，非常方便。这项配置虽然不起眼，但是能让你的表设计看起来更专业，答辩时也是一个小小的加分项。

4. 库存扣减与超卖防护的完整实现

4.1 超卖问题是怎么发生的

现在开始进入这个项目的核心难点——库存扣减与超卖防护。这也是答辩时最容易被提问的地方。

先解释一下为什么会出现超卖。假设系统用以下逻辑完成一次购票：

1. 查询剩余库存，判断余票是否充足
2. 如果充足，生成订单
3. 扣减库存

这段逻辑在单线程下完全没有问题，但在高并发场景下就会出状况。想象一下10月1日还剩最后1张票，此时有10个用户同时发起购票请求。10个请求同时执行第1步，查询到的剩余库存都是1，都判断为“有票”，然后10个请求都走到了扣减库存的环节。最终的结果就是卖出去了10张票，但库存只有1张，这就是超卖。

这个问题的根源在于“判断”和“扣减”不是原子操作，两个动作之间出现了时间窗口，多个请求同时穿过了这个窗口。

4.2 基于数据库行锁的防超卖方案

最朴素的方案是让“判断库存”和“扣减库存”变成一个原子操作。在SQL层面，可以使用带条件的UPDATE语句：

sql复制UPDATE ticket_stock 
SET sold_count = sold_count + 1, 
    remaining_count = remaining_count - 1 
WHERE scenic_id = #{scenicId} 
  AND ticket_type_id = #{ticketTypeId} 
  AND sale_date = #{saleDate} 
  AND remaining_count > 0

这条SQL的关键在于WHERE条件里的remaining_count > 0。如果剩余库存为0，这个UPDATE语句影响的行数就是0，代码里根据影响行数判断是否扣减成功。在InnoDB引擎下，UPDATE语句会对命中的行加行锁，并发执行时后面的请求会被阻塞，等锁释放后发现剩余库存已经是0，UPDATE影响行数为0，就会返回“库存不足”的提示。

这种方案实现简单、不需要额外的中间件，但并发性能一般。行锁会让请求排队执行，如果QPS比较高，响应时延会明显上升。用在毕设系统里是够用的，但如果想在答辩时展示一些更亮眼的方案，可以引入Redis分布式锁。

4.3 基于Redis分布式锁的优化方案

Redis分布式锁解决的是同一个问题——让请求互斥地访问库存资源。这里的思路是给库存扣减操作加一把锁，保证同一时间只有一个请求能够执行“判断库存 + 扣减库存”的完整流程。

引入Redis分布式锁的场景，是在数据库无法承受较高并发时，用Redis把流量挡在数据库外面。实际的业务流程是：读余票数量时优先走Redis，Redis没数据或者数据过期时才回源查数据库。扣减库存时通过Redis的原子操作或者严格序列化的更新逻辑，把超卖风险控制在入口处。

在Spring Boot项目中，实现Redis分布式锁的方式有两种。一种是直接用RedisTemplate调用setIfAbsent方法实现一个简单的锁，另一种是引入Redisson框架使用封装好的RLock。Redisson是更加推荐的选择，它自带看门狗机制的锁自动续期，避免了锁超时导致业务还没执行完就被释放的问题。

java复制@Autowired
private RedissonClient redissonClient;

public boolean deductStock(Long scenicId, Long ticketTypeId, String saleDate, Integer count) {
    String lockKey = "ticket:stock:" + scenicId + ":" + ticketTypeId + ":" + saleDate;
    RLock lock = redissonClient.getLock(lockKey);
    try {
        // 尝试获取锁，最多等待3秒，锁有效期30秒
        if (lock.tryLock(3, 30, TimeUnit.SECONDS)) {
            // 查询当前剩余库存
            Integer remaining = getRemainingStock(scenicId, ticketTypeId, saleDate);
            if (remaining < count) {
                return false;
            }
            // 扣减库存
            updateStock(scenicId, ticketTypeId, saleDate, count);
            return true;
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } finally {
        // 释放锁
        if (lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    }
    return false;
}

这里有一个并发控制的细节值得说一说。Redisson的tryLock方法有三个参数——等待时间、锁有效期和单位。等待时间3秒意味着如果拿不到锁，最多等待3秒就放弃，不会让请求无限阻塞下去。锁有效期30秒是给业务执行加了一个最长时限，防止业务线程因为某些异常一直持有锁。看门狗机制会在锁快要过期时自动续期，所以正常情况下不会出现锁还没执行完就过期的问题。

4.4 乐观锁方案作为对比

还有第三种方案——乐观锁。这种做法是在库存表上增加一个version字段，更新库存时带上version条件：

sql复制UPDATE ticket_stock 
SET sold_count = sold_count + #{count},
    remaining_count = remaining_count - #{count},
    version = version + 1
WHERE id = #{id} AND version = #{version}

如果影响行数为0，说明version不匹配，有其他请求已经修改过这条数据，需要重新查询库存、重试更新。乐观锁适用于读多写少、并发冲突较少的场景，实现也简单，但冲突频繁时会导致大量重试，反而影响性能。

三种方案各有利弊，核心对比我用表格整理一下：

毕设系统建议至少实现数据库条件更新这一种方案，如果学有余力再完成Redis分布式锁。答辩时如果你能把这三种方案、各自的优缺点对比讲清楚，导师一定会认为你真的理解了这个问题。

5. 售票核心流程的实现：从选票到出票的完整闭环

5.1 查票流程：按日期查余票

售票系统的第一步是查票。用户选择景区、期望游玩日期和票种类型，系统查询该日期下各票种是否有余票，返回票价、剩余数量等信息。

查票接口的设计有几个要点。第一，日期参数校验。游客选择的游玩日期必须是今天或未来某天，过去的日期不能售票。第二，库存信息的来源。由于库存是强实时数据，这里建议直接查数据库，尤其是支付前最后一次校验库存时绝对不能查缓存，否则可能把已售罄的数据返回给用户。第三，返回数据的结构设计。查询结果应该包含景区信息、票种列表以及每个票种在目标日期的剩余库存和价格。

前端页面通常展示为一个票务日历，点击日期后下方展示当日可售票种。数据接口返回的JSON结构大概是：

json复制{
  "scenicId": 1,
  "scenicName": "西湖景区",
  "visitDate": "2024-06-01",
  "ticketTypes": [
    {
      "ticketTypeId": 101,
      "ticketName": "成人票",
      "price": 45.00,
      "remainingStock": 256,
      "soldOut": false
    },
    {
      "ticketTypeId": 102,
      "ticketName": "儿童票",
      "price": 20.00,
      "remainingStock": 0,
      "soldOut": true
    }
  ]
}

5.2 下单流程：事务与库存锁的配合

用户选定票种、数量、游玩日期后，点击“立即购买”进入下单流程。这个流程是整个系统业务逻辑最复杂的环节，涉及订单创建、订单明细创建、库存锁定三个操作，而且这三个操作必须在同一个事务中完成——要么全部成功，要么全部失败，不能出现订单建了库存没锁定的情况。

完整的下单逻辑是这样的：

java复制@Transactional(rollbackFor = Exception.class)
public OrderVO createOrder(CreateOrderRequest request) {
    // 1. 参数校验：日期合法性、购票数量、用户登录状态
    validateCreateOrderRequest(request);
    
    // 2. 加分布式锁，防止并发超卖
    String lockKey = buildStockLockKey(request);
    RLock lock = redissonClient.getLock(lockKey);
    lock.lock(30, TimeUnit.SECONDS);
    
    try {
        // 3. 查询库存，判断余票是否充足
        TicketStock stock = getStock(request.getScenicId(), 
                                       request.getTicketTypeId(), 
                                       request.getVisitDate());
        if (stock == null || stock.getRemainingCount() < request.getBuyCount()) {
            throw new BusinessException("余票不足");
        }
        
        // 4. 锁定库存
        int updated = decreaseStock(request.getScenicId(), 
                                     request.getTicketTypeId(), 
                                     request.getVisitDate(), 
                                     request.getBuyCount());
        if (updated == 0) {
            throw new BusinessException("余票不足，请重新选择");
        }
        
        // 5. 创建订单
        Order order = buildOrder(request);
        orderMapper.insert(order);
        
        // 6. 创建订单明细
        OrderItem item = buildOrderItem(order, request);
        orderItemMapper.insert(item);
        
        return OrderVO.fromEntity(order);
    } finally {
        lock.unlock();
    }
}

这里有一个容易踩的坑要提醒一下。@Transactional注解默认只对RuntimeException回滚，如果业务代码里抛出自定义的BusinessException，而这个异常不是RuntimeException的子类，事务就不会回滚。所以自定义业务异常一定要继承RuntimeException，或者在@Transactional注解里显式声明rollbackFor = Exception.class，否则会出现库存扣了但订单没建成的数据不一致问题。

5.3 支付回调与订单状态变更

用户下单后进入待支付状态，页面跳转到支付页面。毕设阶段的支付功能一般通过第三方支付沙箱环境模拟，最常见的做法是接入支付宝沙箱或微信支付沙箱。

支付完成后，第三方支付平台会异步通知我们的后端接口。这个异步通知接口的设计特别重要，是整个支付流程能否闭环的关键。

收到支付通知后的处理流程是：验证签名 → 检查订单状态 → 更新订单为已支付 → 更新支付记录 → 返回成功应答。

java复制@PostMapping("/notify/pay")
public String payNotify(HttpServletRequest request) {
    // 1. 获取支付宝异步通知参数
    Map<String, String> params = extractParams(request);
    
    // 2. 验签
    boolean signVerified = alipayService.verifySign(params);
    if (!signVerified) {
        return "failure";
    }
    
    // 3. 获取订单信息
    String outTradeNo = params.get("out_trade_no");
    String tradeStatus = params.get("trade_status");
    
    // 4. 防止重复通知：幂等处理
    Order order = orderMapper.selectByOrderNo(outTradeNo);
    if (order == null) {
        return "failure";
    }
    // 如果订单已经是支付成功状态，直接返回成功，避免重复处理
    if (order.getStatus() == OrderStatus.PAID.getValue()) {
        return "success";
    }
    
    // 5. 只有交易成功才更新订单状态
    if ("TRADE_SUCCESS".equals(tradeStatus) || "TRADE_FINISHED".equals(tradeStatus)) {
        order.setStatus(OrderStatus.PAID.getValue());
        order.setPayTime(new Date());
        orderMapper.updateById(order);
        
        // 创建支付记录
        paymentService.createPaymentRecord(outTradeNo, params);
    }
    
    // 6. 返回成功应答给支付平台
    return "success";
}

幂等处理是支付回调里最重要的一个细节。第三方支付平台可能会因为网络波动等原因多次发送相同的异步通知，如果接口不做幂等处理，订单状态就可能被重复更新。这里的做法是在更新前先检查当前订单状态，如果已经是已支付，直接返回成功，不再做任何更新。

5.4 订单取消与退款

订单取消分两种情况：待支付订单的取消和已支付订单的退款。

待支付订单的取消通常由两个触发条件引起——用户手动取消和超时系统自动取消。用户手动取消时，前台接口收到请求后，需要将订单状态从待支付改为已取消，同时释放锁定的库存。超时自动取消则通过定时任务扫描超过30分钟未支付的订单，批量将状态改为已取消并释放库存。

定时任务的实现可以用Spring自带的@Scheduled注解。在启动类上加上@EnableScheduling，在具体方法上配置cron表达式：

java复制@Scheduled(cron = "0 */5 * * * ?")
public void autoCancelExpiredOrders() {
    LocalDateTime deadline = LocalDateTime.now().minusMinutes(30);
    List<Order> expiredOrders = orderMapper.selectExpiredOrders(deadline);
    for (Order order : expiredOrders) {
        // 释放库存
        releaseStock(order);
        // 更新订单状态
        order.setStatus(OrderStatus.CANCELLED.getValue());
        orderMapper.updateById(order);
    }
}

这里要注意定时任务和用户手动取消可能同时触发同一个订单。解决的办法是在数据库层面做一个条件更新——UPDATE orders SET status = 3 WHERE id = #{id} AND status = 0。如果影响行数为1，说明本次成功取消；如果影响行数为0，说明状态已经被其他事务修改了，本次取消放弃处理。这个条件更新的操作本质上就是前面讲的乐观锁思路。

已支付订单的退款流程相对复杂一些，建议实现为：用户发起退款申请 → 后台管理员审核 → 审核通过后调用支付平台退款接口 → 收到退款成功通知后更新订单状态为已退款 → 释放库存。毕设阶段可以把审核和退款操作放在管理后台手动完成，方便演示。

6. 管理后台的关键功能与数据可视化

6.1 后台管理页面设计

景区售票系统除了用户端的前台购票功能，还需要一个功能完善的管理后台。管理后台的服务对象是景区运营人员，需要覆盖基础数据管理、订单管理、统计分析和系统配置几大模块。

基础数据管理包括景区管理、票种管理、库存管理和公告管理。景区管理维护景区的基本信息，票种管理配置哪些票种在售、价格是多少，库存管理直接操作每日各票种的库存数量——比如遇到恶劣天气核减接待量，运营人员可以直接在后台调整。公告管理发布系统公告，比如节假日开放时间调整、临时闭园通知等。

订单管理模块用于查询和处理所有订单。后台需要支持按订单编号、用户手机号、订单状态、游玩日期等多维度条件查询，方便运营人员快速定位问题订单。对于需要人工介入的退款申请，也在这个模块里完成审核。

统计报表模块是后台的加分项。通过ECharts实现售票数据的可视化呈现——按日统计售票数量、按票种统计销售占比、按周统计营收趋势。我建议把统计报表做得直观一点，因为答辩时演示效果会非常好，也便于发挥讲讲数据是怎么从数据库查出来、聚合、再渲染到前端的完整链路。

6.2 日售票量统计的实现思路

日报表统计是后台报表模块的基础功能之一。核心逻辑很直接：按销售日期分组统计订单明细表中已支付订单的购票数量，再乘以对应票价得到营收。

sql复制SELECT 
    DATE_FORMAT(o.create_time, '%Y-%m-%d') AS sales_date,
    SUM(CASE WHEN o.status IN (1, 2, 3) THEN o.total_amount ELSE 0 END) AS daily_revenue
FROM orders o
WHERE DATE_FORMAT(o.create_time, '%Y-%m-%d') BETWEEN #{startDate} AND #{endDate}
GROUP BY DATE_FORMAT(o.create_time, '%Y-%m-%d')
ORDER BY sales_date

这里有一个统计口径的问题需要留意：统计营收时订单状态应该限定在已支付、已使用、已退款这三种。而真正计算收入时已退款的订单需要排除，否则会出现营收虚高的情况。实际项目中通常会把“订单金额”和“退款金额”两个维度分开统计。

6.3 前端框架与对接方式

毕设项目的前端有两种常见方案：服务端渲染和前后端分离。

服务端渲染方案使用Thymeleaf模板引擎，页面直接在后端渲染，数据通过Model对象传递到前端模板。这种方案的好处是无需额外部署前端项目，一个Spring Boot应用就能跑通所有功能，部署和演示都很方便。缺点是前后端耦合度高，页面交互体验相对一般。

前后端分离方案使用Vue + Element UI搭建管理后台和前台页面，通过Axios调用后端接口，数据以JSON格式传输。这种方案的优点是交互体验更好、技术栈更新，简历上写起来也更有吸引力；缺点是需要额外维护一个前端项目，对前端不太熟悉的同学来说学习成本略高。

如果时间和精力允许，我推荐选择前后端分离方案。原因很简单——当前企业开发的主流模式就是前后端分离，毕设采用这个模式，在技术面试时能加不少分。具体实现上用Vue 3 + Element Plus + Vite，网上的脚手架很成熟，半天时间就能把项目骨架搭起来。自己写前端页面虽然会花一些时间，但写完之后你对系统全局的掌控度会好很多。

7. 部署、调试与答辩准备中的经验总结

7.1 本地联调的关键配置

项目开发完成后，联调阶段有几个配置问题需要处理好，否则前端和后端之间很容易出各种连接问题。

第一个是端口与上下文路径。Spring Boot默认端口是8080，前端项目通过代理访问后端时，需要正确配置代理地址。Vite开发服务器默认运行在5173端口，跨域请求8080端口时需要在Vite配置文件里加代理：

js复制server: {
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true
    }
  }
}

这样前端发往/api的请求会被代理到后端8080端口，绕开了浏览器跨域限制。如果是Thymeleaf方案本身就不存在跨域问题。

第二个是数据库时区配置。MySQL连接串建议增加serverTimezone=Asia/Shanghai参数，避免日期时间在数据存储和读取时出现8小时的偏移。

第三个是Redis的序列化配置。如果用默认的JDK序列化方式存储对象，数据在Redis客户端里会是一串不可读的二进制内容，排查问题很不方便。建议配置通用的StringRedisSerializer和Jackson2JsonRedisSerializer组合，存进去的数据可以直接查看，便于调试。

7.2 常见启动与联调问题排查

项目启动时最常见的报错就是无法连接MySQL或者Redis。这种问题八成是服务没启动或者配置的端口、密码不对。排查的思路是先确认MySQL、Redis进程是否在运行，再检查application.yml里的host、port、username、password是否和实际环境一致。

另一个高频报错是引入依赖后项目启动报ClassNotFoundException或NoClassDefFoundError。这种情况通常是依赖冲突或者版本不兼容。Spring Boot的依赖管理已经帮我们锁定了大部分第三方库的版本，但有些库（比如Druid的连接池或者一些工具包）需要手动指定版本，最好看看你引入的依赖官方推荐搭配哪些Spring Boot版本，避免版本差异过大带来问题。

前端联调阶段出现接口返回401或者404，通常不是代码逻辑问题而是配置问题。401一般是因为登录拦截器拦截了未登录请求，需要放行登录接口和静态资源。404要先确认接口路径是否正确，再去确认是否有上下文路径前缀。

7.3 答辩准备：如何把系统讲到关键点上

毕设做完只是第一步，答辩时讲清楚、展现出自己的思考才是关键。我参加过的答辩现场，不少同学PPT讲到一半就被老师打断提问，结果支支吾吾回答不上来，场面非常尴尬。

准备答辩时需要在以下技术点上做到能够不看稿子说清楚的程度：

• 项目架构：Spring Boot三层架构，Controller - Service - Mapper每一层各司其职
• 超卖问题的解决思路：为什么会出现超卖，如何通过数据库条件更新或Redis分布式锁来保证库存不超卖
• 订单状态机的流转：待支付、已支付、已使用、已取消、已退款五种状态之间的合法流转路径，以及在哪些业务节点上会发生这些流转
• 支付回调的幂等处理：第三方支付平台为什么会重复通知，系统如何通过先查后改的方式保证幂等
• 事务边界：下单流程中哪些操作在同一个事务内，事务回滚的触发条件是什么

还有一个容易被问到的问题——系统能支撑多大的并发量？这个问题没有标准答案，但至少要能说清楚你的系统瓶颈在哪里。比如数据库行锁方案下单接口的QPS大概在几百量级，加上Redis缓存后读接口的吞吐量能提升到几千。用数据说话比空谈架构要可信得多。

8. 写在最后的个人体会

景区售票系统这个题目，我在带学生毕设的过程中接触过不少次，每次看到有同学能把库存控制、订单状态机、支付回调这些核心问题想清楚并实现出来，我都会觉得这个毕设是有质量的。

回想我自己当年做毕设那会儿，最深刻的教训就是“贪多求全”。总想把各种技术都往系统里堆，结果功能做了不少，但没有一个深入下去，答辩时被问到底层原理就露怯了。现在回头看，一个系统有几个技术亮点并且自己彻底吃透了，比功能面面俱到但每个都很浅要重要得多。

这个项目的扩展空间还是不小的，比如可以对接第三方的OTA平台实现分销，可以增加团队票的预约与审批流程，可以引入消息队列处理更大规模的抢票场景。但这些都是后话，先把当前这套系统踏踏实实跑通、把每行代码的逻辑弄明白，才是拿到一个好成绩的脚踏实地路线。

如果这篇内容对你有帮助，建议先搭建项目骨架、把核心表和订单流程跑通，再逐步完善后台和统计报表。过程中遇到具体的报错或者逻辑问题，可以多翻翻官方文档和社区帖子，大部分别人踩过的坑都有解决方案。希望你的毕设顺利通过。