滑雪场管理系统：Spring Boot+MyBatis+MySQL设计实战

简介管理系统是Java Web开发中的经典场景其核心在于数据建模与业务逻辑分层。Spring Boot作为主流框架简化了配置与部署MyBatis则让SQL可控且便于优化而MySQL以其事务和约束能力支撑订单、库存等核心数据。在滑雪场业务中票务、租赁、会员、日结等流程天然适合CRUD系统但并发超卖、日期库存、按小时计费等细节又对设计和编码提出更高要求。本文以滑雪场管理系统为例介绍从数据库表设计、Spring Boot工程搭建到并发安全扣库存、营收统计的完整实践适合毕业设计、课程设计或Java Web初学者参考。1. 基于Java的滑雪场管理系统为什么这个选题到现在还值得做很多同学做毕业设计或课程设计时听到“某某管理系统”就条件反射地觉得烂大街但滑雪场管理系统其实是个被低估的方向。它本质上是一个典型的 Java Web CRUD 系统业务上却带着门票计费、雪具租赁、会员折扣、节假日限流这些真实运营逻辑比图书管理、酒店管理更不容易撞车。系统要解决的痛点很直接收银台卖票退票、雪具借还计时、每天营收汇总对账。做这个项目你能把 Java 基础、Spring Boot、MyBatis、MySQL 串成一条完整链路难度不高又能写进简历适合做毕业设计、课程设计或者刚入门的练手项目。2. 先把业务流程拆开再建表这套系统不是简单的“增删改查”做管理系统的第一步永远不是写代码而是先确认“谁在用、每天发生什么”。滑雪场一天的业务可以画成一条时间线游客到店买票或验票进场之后去雪具大厅租板、租鞋玩完归还雪具晚上收银员做日结。中间穿插会员充值、教练预约、商品销售。毕业设计不用贪全抓住“票务 租赁 会员 日结”四条主线系统就已经有说服力了。2.1 三个角色、五条业务线滑雪场一天是怎么运转的我把系统里的用户先分成三类游客/会员、收银员、管理员。游客和会员在售票处买票在雪具大厅租赁雪具收银员负责收款、录入租赁单管理员维护价格、查看营收报表。这样权限就自然出来了收银员只能操作业务单据管理员才能改价格和看统计。角色核心需求对应功能会员买票享受折扣、充值登录、购票、租借、充值收银员快速卖票、登记租赁、收押金下单、租赁登记、归还结算管理员维护票价、查看每日营收票种管理、雪具管理、报表在这五条业务线里最容易做深的是两个一个是“雪票按日期限量”因为周末和夜场经常售罄需要控制库存另一个是“雪具按时计价”因为超时归还涉及额外费用。这两块我会在第 4 章给出可复现的实现。2.2 从运营流程拆数据表核心 7 张表就够了我第一次带人做这个选题时对方一口气建了二十多张表光“商品分类”就拆了三层最后连自己都分不清哪张是主表。后来我建议他按业务单据来收敛最后落成了 7 张表。表名作用关联对象sys_user员工/收银员/管理员登录账号登录member会员档案与余额购票、租赁ticket雪票类型与价格票种维护ticket_daily_stock某天某票种的库存与已售数量防超卖ticket_order雪票销售订单主表销售流水rental_item雪具类型、单价与库存雪具维护rental_order租赁单记录借出与归还时间租赁流水这种拆法背后的原则是一张业务单据对应一张主表主表只记“人和时间”金额细节放在关联表或者直接用冗余字段存快照。雪票订单和租赁单是两条独立流水不混在一张表里。别小看这一点很多新手把卖票和租板写在一个 order 表里后面统计营收时被迫用 type 字段去区分SQL 会越写越长。下面是三张关键表的建表 SQL可以直接粘到 MySQL 里跑。先看 ticket 表CREATE TABLE ticket ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, name VARCHAR(50) NOT NULL COMMENT 票种名称例如“平日成人日场票”, session_type VARCHAR(20) NOT NULL COMMENT 场次day日场night夜场, ticket_type VARCHAR(20) NOT NULL COMMENT 人群ADULT成人 CHILD儿童, price DECIMAL(10,2) NOT NULL COMMENT 标准售价, discount_rate DECIMAL(3,2) NOT NULL DEFAULT 1.00 COMMENT 会员折扣率0.85表示85折, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT雪票类型表;这里把“票种名称”和“场次”“人群”拆成独立字段是为了后面能按session_type统计夜场和日场的营收占比而不是靠字符串模糊匹配。discount_rate没有做成会员等级关联而是直接冗余在票种上简化计算报表查询时少一次 join适合这种体量的系统。再说每天的库存表ticket_daily_stockCREATE TABLE ticket_daily_stock ( id BIGINT NOT NULL AUTO_INCREMENT, ticket_id BIGINT NOT NULL COMMENT 关联ticket.id, business_date DATE NOT NULL COMMENT 营业日期, total_qty INT NOT NULL DEFAULT 200 COMMENT 当天放票数量, sold_qty INT NOT NULL DEFAULT 0 COMMENT 已售数量, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, PRIMARY KEY (id), UNIQUE KEY uk_ticket_date (ticket_id, business_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT雪票按日库存表;注意两个设计点一是UNIQUE KEY uk_ticket_date(ticket_id, business_date)保证同一票种同一天只有一条库存记录二是version字段这是后面处理并发不超卖的关键先记住它。总库存total_qty默认 200表示某天某个票种的放票上限节假日可以在后台单独调大。租赁相关的rental_item和rental_order这样建CREATE TABLE rental_item ( id BIGINT NOT NULL AUTO_INCREMENT, item_name VARCHAR(50) NOT NULL COMMENT 雪板/雪鞋/雪杖/护具, spec VARCHAR(50) COMMENT 规格成人双板/儿童单板, unit_price DECIMAL(10,2) NOT NULL COMMENT 每小时租金, deposit DECIMAL(10,2) NOT NULL COMMENT 押金归还时退还, stock_qty INT NOT NULL DEFAULT 0 COMMENT 当前可借数量, status TINYINT NOT NULL DEFAULT 1 COMMENT 1可租 0停用, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT雪具库存表; CREATE TABLE rental_order ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 租赁单号如RT20260210001, member_id BIGINT COMMENT 关联member.id游客可为空, item_id BIGINT NOT NULL COMMENT 关联rental_item.id, quantity INT NOT NULL DEFAULT 1 COMMENT 租借数量, start_time DATETIME NOT NULL COMMENT 借出时间, end_time DATETIME COMMENT 归还时间归还时写入, amount DECIMAL(10,2) NOT NULL COMMENT 实际租金, status TINYINT NOT NULL DEFAULT 1 COMMENT 1租赁中 2已归还 3超时未还, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT雪具租赁单;rental_order的表结构其实已经把计费核心问题摆出来了start_time和end_time都有一旦归还时回填end_timeamount就能算出来。押金单独放在deposit字段而没做流水表是因为实际场景里押金在归还时原路退回的概率极高一笔租赁单一个押金字段足够不需要额外记账。2.3 为什么把“票库存”单独拆一张表应付周末和夜场的“售罄”很多管理系统项目里库存就是商品表上的一个数字下单时减一。但雪票有个特殊点同样的“成人日场票”2 月 10 日和 2 月 14 日卖的是两张不同的票价格也可能不同所以库存必须带上日期维度。如果你把库存直接放在ticket表上改一天的价格就要改一整行查某天还能不能买票就得另想办法。拆成ticket_daily_stock后售票逻辑变成先定位ticket_id business_date的库存记录再扣减sold_qty。扣减的 SQL 也不是先 select 再 update而是用一条原子更新UPDATE ticket_daily_stock SET sold_qty sold_qty 1, version version 1 WHERE ticket_id 1 AND business_date 2026-02-10 AND sold_qty 1 total_qty;这条UPDATE的巧妙之处在于最后那个sold_qty 1 total_qty条件两个收银员同时卖最后一张票时数据库的行锁会让第二条 UPDATE 等到第一条提交然后发现sold_qty 1 total_qty影响行数是 0程序就知道票卖完了直接抛“当日库存不足”。在这里还额外增加version version 1是为了后面做乐观锁版本校验时能定位是哪次操作把库存扣减的。如果你执意用“先查再用 Java 判断后更新”的写法也就是先查sold_qty在代码里判断小于total_qty后执行更新那并发压测下必然出现超卖。原因很简单两个线程同时查到了sold_qty 199、total_qty 200都认为还能卖 1 张然后各自执行 update最后卖出去 2 张。这个坑我在第 5 章还会展开一次因为它在答辩里几乎是必问题。3. 技术选型和工程骨架用 Spring Boot 把项目立起来滑雪场管理系统的技术栈选得“稳”比选得“新”重要。教室里的 JDK、机房里的 MySQL、老师答辩时可能临时打开的浏览器这三件事决定了你没必要引入微服务、Redis 这些重组件。一套 Spring Boot 2.7 MyBatis MySQL 的经典组合足够把系统跑起来也足够在答辩时讲清楚每一层在干什么。3.1 为什么是 Spring Boot MyBatis而不是其他组合先说为什么不是 Spring MVC 手写配置Spring Boot 内嵌 Tomcat双击就能启动不用再为 IDEA 里的 Artifact 配置头疼这对新手友好太多。再说为什么用 MyBatis 而不是 JPA管理系统的报表和统计 SQL 占一半以上MyBatis 允许你直接维护 XML 里的 SQL查询逻辑可复制、可解释答辩时你可以指着 SQL 讲“这里为什么用 LEFT JOIN”。如果用 JPA生成的 SQL 不够直观反而增加解释成本。组件我用的版本说明JDK1.8最稳教材和机房普遍支持Spring Boot2.7.x内嵌 Tomcat依赖管理省心MyBatismybatis-spring-boot-starter 2.3.x与 Boot 2.7 兼容好MySQL5.7 或 8.05.7 不需要处理太多时区问题8.0 注意驱动名Maven3.6项目构建如果你的学校要求用 JDK 17也可以把 Spring Boot 升到 3.x但 3.x 对 MyBatis starter 版本要求是更高版本配置方式有明显变化。为了避免第一次跑不起来我建议默认按 JDK 8 Boot 2.7 这套来等系统能跑通了再考虑升级。3.2 pom.xml 与 application.yml最小可跑工程工程骨架的第一份文件是pom.xml。下面这段是我每次新建项目都会先贴进去的最小依赖集合parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.2/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-thymeleaf/artifactId /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies说一下每个依赖是干什么的spring-boot-starter-web提供 MVC 和 Tomcat后端接口全靠它mybatis-spring-boot-starter把 MyBatis 自动装配进 Spring 容器你不用手写SqlSessionFactorymysql-connector-j是 MySQL 驱动注意 8.x 版本里驱动类是com.mysql.cj.jdbc.Driver这一点很多人翻车thymeleaf用来渲染后台页面如果你只会 JSP可以把页面资源换成传统 JSP 方式但 Boot 对 JSP 支持有限我推荐直接用 Thymeleaf语法和 JSP 差异不大。然后是application.ymlserver: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/ski_resort?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 thymeleaf: cache: false mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true这里每个参数都是踩过坑换来的serverTimezoneAsia/Shanghai不写MySQL 8 连接时会报“The server time zone value is unrecognized”characterEncodingutf8不写中文写入数据库变成问号map-underscore-to-camel-case设为 true 后数据库字段sold_qty会自动映射到 Java 属性soldQty省掉一大片resultMap。mybatis.mapper-locations指定 Mapper XML 放哪扫不到 XML 时控制台会报Invalid bound statement。3.3 Controller / Service / Mapper 三层划分与统一返回体工程目录我一般按controller、service、mapper、entity、config来分。很多课程设计会要求“MVC 分层”这三层是最直接的对应Controller 只接收参数和返回结果不写业务Service 写订单、计费、库存扣减这些核心逻辑Mapper 只操作数据库。为了前端拿到统一的数据格式我还会加一个Result类Data public class ResultT { private Integer code; // 200 成功500 失败 private String message; // 给前端的提示信息 private T data; // 业务数据 public static T ResultT ok(T data) { ResultT r new Result(); r.setCode(200); r.setMessage(success); r.setData(data); return r; } public static T ResultT error(String msg) { ResultT r new Result(); r.setCode(500); r.setMessage(msg); return r; } }这个类看着简单却能避免一个常见问题有的同学每个接口返回类型都不一样有的返回Map有的返回Entity前端根本不知道什么时候解析成功什么时候弹错误提示。统一成Result后页面只需要判断code是否等于 200错误信息统一取message排查问题也快很多。3.4 Mapper XML 的完整样例报错了你知道去哪查MyBatis 的 XML 是新手最容易栽跟头的地方。下面是一个按日期查库存的完整示例?xml version1.0 encodingUTF-8? !DOCTYPE mapper PUBLIC -//mybatis.org//DTD Mapper 3.0//EN http://mybatis.org/dtd/mybatis-3-mapper.dtd mapper namespacecom.skiresort.mapper.TicketDailyStockMapper select idselectByTicketAndDate resultTypecom.skiresort.entity.TicketDailyStock SELECT id, ticket_id, business_date, total_qty, sold_qty, version FROM ticket_daily_stock WHERE ticket_id #{ticketId} AND business_date #{businessDate} /select /mappernamespace必须跟 Mapper 接口的全限定名一致id必须和方法名一致否则启动时不会立刻报错但运行时抛Invalid bound statement。#{ticketId}是预编译占位符会生成?参数不会拼接 SQL这也是防注入的基本姿势。如果你连resultType都不写MyBatis 会返回一个Map字段名是数据库列名Java 里取值时大小写很别扭。4. 把核心功能做通登录、卖票、租赁计费骨架立起来之后真正决定项目能不能演示的是三个功能点登录权限能拦住未授权访问卖票和租赁能正确走到结算每天的营收能在报表里对上。这一章给出这三块的完整实现思路和代码。4.1 登录拦截用 Session HandlerInterceptor 做最小可用的权限控制毕设级别的系统不必上 Spring Security 全家桶用拦截器加 Session 就能解决。拦截器的核心逻辑就一句话检查 Session 里有没有登录用户的标识没有就踢回登录页。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object loginUser request.getSession().getAttribute(loginUser); if (loginUser null) { response.sendRedirect(/login); return false; } return true; } }这段代码有两个细节要注意sendRedirect之前不用再 setContentType因为它是告诉浏览器跳转不是直接输出页面返回false是阻止请求继续往后走否则你拦截了还会被 Controller 处理一次。写完后要把拦截器注册进 Spring 容器Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/**) .excludePathPatterns( /login, /logout, /css/**, /js/**, /img/** ); } }addPathPatterns(/**)的意思是拦截所有路径excludePathPatterns里放行登录页和静态资源。这里有个惯性坑很多人忘记放行静态资源结果登录页能打开但页面里的 CSS/JS 全部 404页面样式“裸奔”。排查时先看浏览器 Network 面板里是不是有/css/**的请求返回 302。4.2 雪票下单一张订单走三个动作卖票是整个系统最核心的写操作。下订单时Service 里要完成三件事算价格、扣库存、生成订单记录。我习惯把这三件事放在一个Transactional方法里保证要么全成功要么全回滚。Service public class TicketOrderService { Autowired private TicketDailyStockMapper stockMapper; Autowired private TicketOrderMapper orderMapper; Autowired private TicketMapper ticketMapper; Transactional(rollbackFor Exception.class) public void createOrder(TicketOrderRequest req) { // 1. 查票价与会员折扣 Ticket ticket ticketMapper.selectById(req.getTicketId()); BigDecimal price ticket.getPrice(); // 会员从 session 或参数里带过来折扣率直接乘上 if (req.getMemberId() ! null) { price price.multiply(ticket.getDiscountRate()); } // 2. 扣当日库存使用原子 UPDATE返回影响行数 int rows stockMapper.deductStock( req.getTicketId(), req.getBusinessDate(), req.getQuantity()); if (rows 0) { throw new RuntimeException(当日该票种库存不足请更换日期或票种); } // 3. 生成订单 TicketOrder order new TicketOrder(); order.setOrderNo(buildOrderNo(req.getBusinessDate())); order.setMemberId(req.getMemberId()); order.setBusinessDate(req.getBusinessDate()); order.setTotalAmount(price.multiply(BigDecimal.valueOf(req.getQuantity()))); order.setStatus(1); orderMapper.insert(order); } }Transactional(rollbackFor Exception.class)是必须的注意rollbackFor指定了 Exception 而不是默认只在 RuntimeException 下回滚。这样库存扣减后如果orderMapper.insert抛了异常扣掉的库存也会跟着回滚不会出现“库存没了但订单没生成”的脏数据。deductStock对应的 Mapper SQL 就是第 2 章里那条原子 UPDATE参数传的是票种 ID、日期、购买数量。这里又回到那个关键点永远不要先 select 出来判断库存再 update一定要让数据库在这一步挡住超卖。4.3 雪具租赁计费按小时计费与超时费雪具租赁比卖票多一个时间维度计费规则一般是不足 1 小时按 1 小时算超时归还追加费用。我建议在归还接口里动态计算金额而不是借出时就写死因为谁也无法预测客人几点回来。public BigDecimal computeRentAmount(RentalItem item, LocalDateTime startTime, LocalDateTime endTime) { // 计算两个时间点之间的分钟数 long minutes Duration.between(startTime, endTime).toMinutes(); if (minutes 0) { throw new RuntimeException(归还时间必须晚于借出时间); } // 不足 1 小时按 1 小时计费 long hours (minutes 59) / 60; BigDecimal amount item.getUnitPrice() .multiply(BigDecimal.valueOf(hours)) .multiply(BigDecimal.valueOf(item.getQuantity() null ? 1 : item.getQuantity())); return amount; }这里解释三个边界(minutes 59) / 60是向上取整的小技巧61 分钟会算成 2 小时item.getUnitPrice()是每小时租金所以要乘以小时数quantity是租了几件租金要乘上数量。如果你做超时费只需在计算出的hours超过预设值后把超出部分乘以一个更高的单价比如基础价 1 倍、超时价 1.5 倍。归还时更新rental_order的end_time、amount和status同时把rental_item.stock_qty加回来。押金不退时不走这里的金额另做一条押金扣除流水。4.4 给管理员的日营收看板三行 SQL 算出今天的数后台首页一般要放一个今日营收卡片。这条 SQL 我用得最多也建议你直接抄SELECT COUNT(*) AS order_cnt, SUM(total_amount) AS total_revenue FROM ticket_order WHERE status 1 AND created_at CONCAT(CURDATE(), 00:00:00) AND created_at DATE_ADD(CURDATE(), INTERVAL 1 DAY);筛选区间用 当天零点和 明天零点能完整覆盖当天 24 小时不会漏掉 23:59:59 的订单也比DATE(created_at) CURDATE()写法更省索引。status 1只统计已支付订单避免退款订单把营收拉低。如果需要按票种分组的日报补一个GROUP BY ticket_id就是最简版本。5. 避坑/常见问题清单从启动到结算的五个血泪经验这一章写的每一条都是我或者带过的同学真实踩过的按“现象 - 原因 - 解决”整理。你可以把它当成排错手册遇到一样的报错直接照做。5.1 启动直接失败8080 端口被占用或数据库连不上现象启动 Spring Boot 项目控制台后半段输出Web server failed to start. Port 8080 was already in use项目卡死在启动流程换 IDE 或者重启电脑也不管用。原因上一次启动的进程没有完全退出或者本机其他服务占用了 8080。Spring Boot 的内嵌 Tomcat 默认监听 8080一旦端口被占就会直接抛异常。解决优先换端口而不是杀进程。在application.yml里把server.port改成 8081Spring Boot 会自动换端口。如果你必须用 8080在 Windows 命令行执行netstat -ano | findstr 8080找到占用进程的 PID再用taskkill /F /PID pid杀掉。macOS 或 Linux 上用lsof -i:8080查看。5.2 MySQL 8 连不上驱动类不存在或时区报错现象启动报Failed to configure a DataSource: url attribute is not specified或者连接时报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized或Public Key Retrieval is not allowed。原因三种情况很常见——driver-class-name还写着老旧的com.mysql.jdbc.DriverMySQL 8 驱动类已经改名com.mysql.cj.jdbc.Driver连接 URL 少了serverTimezone参数MySQL 8 默认 caching_sha2_password 加密插件导致驱动拒绝返回公钥。解决把 yml 里的驱动名改成com.mysql.cj.jdbc.DriverURL 末尾补上serverTimezoneAsia/Shanghai如果还报公钥错误就再补一个allowPublicKeyRetrievaltrue。改完配置后记得mvn clean一下再启动避免旧的编译产物影响。5.3 页面提交中文乱码半个问号最常见现象管理员后台新增票种“平日成人日场票”保存后数据库里变成“ƽÈÕ³ÉÈËÈÕ³¡Æ±”前端显示乱码。原因请求到 Controller 之间、Controller 到数据库之间、数据库存储三处有一处的字符集不一致。常见的是数据库表用了latin1或者连接 URL 没带characterEncodingutf8。解决建库时指定DEFAULT CHARSETutf8mb4已经建错的表用ALTER TABLE ticket CONVERT TO CHARACTER SET utf8mb4;转换连接 URL 带上characterEncodingutf8。对于 POST 表单提交Spring Boot 默认请求编码是 UTF-8不用额外加过滤器。注意如果之前已经有乱码数据转换表结构后新写入的正常历史脏数据仍需要手工 UPDATE。5.4 Thymeleaf 页面 404 或 500Controller 返回的不是页面现象访问/admin/index时浏览器显示 404或者提示Whitelabel Error Page但接口在 Postman 里测着没问题。原因Controller 用了RestController返回字符串Spring 认为你要返回 JSON而不是找到templates/index.html渲染或者模板文件放错了位置。解决页面跳转的 Controller 用Controller接口数据的用RestController两者不要混。页面的 HTML 放在src/main/resources/templates/下Controller returnindex时 Spring Boot 会自动定位到templates/index.html。如果你在 Thymeleaf 模板里用了th:each等语法注意 HTML 标签要闭合否则解析直接 500。5.5 并发超卖与重复下单事务里藏着大坑现象压测工具同时发 10 个买票请求库存只剩 10 张结果 10 个请求全部下单成功数据库里sold_qty变成了 20库存被超卖。原因下单逻辑写成了“先查询 sold_qtyJava 里判断是否小于 total_qty再 update”并发时多个线程同时读到旧的库存值各自判断“还有库存”于是都执行了扣减。解决把扣库存改成我前面给出的原子 UPDATE用WHERE sold_qty #{quantity} total_qty作为条件影响行数为 0 时抛异常。另一个隐藏问题是事务注解失效同一个类里一个方法调用另一个Transactional方法事务不会生效必须通过 Controller 调用 Service 方法的入口进。排查时可以在日志里看有没有Rolling back transaction的语句。6. 从能跑到能答辩三个动作让系统经得起提问系统能跑只是第一步答辩时老师往往会追问“你这个系统怎么验证、和别人的有什么区别”。这里给三个可以直接照做的动作。6.1 用一个脚本验一遍主流程项目做完后不要只在页面上点点点我一般会写一组接口验证脚本答辩前跑一遍证明核心链路是通的。用 curl 就能完成# 1. 买 2 张“平日成人日场票” curl -X POST http://localhost:8080/ticket/order \ -H Content-Type: application/json \ -d {ticketId:1,businessDate:2026-02-10,quantity:2} # 2. 租赁雪板 1 件借出 2 小时 curl -X POST http://localhost:8080/rental/borrow \ -H Content-Type: application/json \ -d {itemId:1,quantity:1,memberId:1} # 3. 查今日营收 curl http://localhost:8080/admin/report/today三个请求对应系统的最核心链路购票、租赁、营收。跑完看返回结果的code字段全部为 200 就说明系统主流程通。6.2 用 Scheduled 定时生成营业日报想拉开和普通 CRUD 项目的差距可以加一个每日零点定时任务把前一天各票种的销售数据汇总到一张日报表里Component public class DailyReportJob { Autowired private TicketOrderMapper orderMapper; Scheduled(cron 0 5 0 * * ?) public void generateDailyReport() { MapString, Object report orderMapper.selectDailyRevenue(); // report 里含 biz_date、order_cnt、total_revenue // 可以写入日报表或日志作为管理员第二天上班的核对依据 } }cron 0 5 0 * * ?表示每天零点 05 分执行避开零点整的数据库高峰。注意在主启动类上要加EnableScheduling否则任务不会运行。这个功能麻雀虽小却能在答辩时展示你对“定时任务框架”的理解。6.3 答辩前把这三个技术点背熟最后是三个高频追问的简短答案。为什么用 MySQL 作为数据库业务是典型的关系型数据模型订单、库存、会员都需要事务和约束MySQL 部署简单、成本低。为什么用乐观锁而不是悲观锁雪票库存的并发冲突集中发生在同一票种同一天悲观锁用SELECT ... FOR UPDATE会对这一行持续加锁高峰期收银台操作容易互相等待我用的原子 UPDATE 在校验库存的同时扣减只在冲突时重试或报错吞吐更好。为什么用 MyBatis 而不是 JPA这套系统里超过一半的 SQL 是统计和复杂的条件查询MyBatis 的 XML 让 SQL 明确可控也便于你把优化过的 SQL 直接拿给老师看。我自己的习惯是把这些回答写进项目的 README 里答辩前再对着代码把关键路径跑一遍。尤其要亲手制造一次“库存不足”的报错演示给老师看系统确实挡住了超卖——这个动作比背十页论文都有说服力。希望这些方案和踩坑记录能帮你把这个选题顺利落地做得比预期更扎实。本文还有配套的精品资源点击获取