基于Spring Boot的拍卖系统毕业设计：并发出价与数据库设计实战

1. 为什么毕业设计选“拍卖系统”这个题

1.1 选题的分寸感：刚好卡在“能落地”和“有亮点”之间

每年到了选题季，都会有学弟学妹跑来问我：“学长，毕业设计到底选什么题好？选管理系统怕太简单，选电商系统又怕写不完。”这个问题其实问的不是题目本身，而是分寸感——一个理想的毕业设计题目，应该是功能数量够写论文、业务复杂度够讲亮点、开发工作量够在几个月内做完。

拍卖系统恰好卡在这三点中间。它首先是一个典型的信息管理系统：用户、角色、权限、登录、增删改查、统计报表，这些“毕业设计基本盘”一个不少；它又有一般管理系统没有的业务亮点：竞拍出价、倒计时截止、并发控制、价格状态流转，这几样东西拿出来在答辩现场讲，老师一听就知道你不是只做了个CRUD壳子。

我用一个表格把三类题目的差异列出来，方便你对照着理解：

电商系统看着风光，但购物车、订单状态机、支付回调、库存扣减，每一块都要写得很深才能自圆其说；普通管理系统的报表和权限做完了就没什么可扩展的了。拍卖系统不一样，它的核心业务逻辑（出价）本身就天然带着并发场景，不需要你刻意制造复杂度，而是题目本身就要求你解决这个问题。这就给论文留出了“关键问题分析”的章节，也给代码留出了真正的技术深度。

1.2 技术栈选型：Spring Boot为骨，MySQL为血

我推荐一套非常适合毕业设计、同时能写进简历的技术组合：

• 后端：Spring Boot 2.7.x，JDK 1.8或11
• 数据库：MySQL 8.0
• ORM：MyBatis-Plus 3.5.x
• 权限：Spring Security + JWT，或者直接使用Sa-Token
• 前端：Vue 3 + Element Plus，或者Thymeleaf + Layui二选一
• 缓存：不强制，有Redis更好

先说版本。Spring Boot 2.7是2.x系列的收官版本，网上资料最多，遇到的坑基本都被踩平了，适合求稳的毕业设计。Spring Boot 3.x当然更“新”，但它要求JDK 17以上，而且部分老教程里的写法会失效，如果你不是因为正好熟悉，没必要在毕设阶段给自己加难度。等到工作了，再根据项目需要切换版本也不迟。

为什么不选SSM（Spring + SpringMVC + MyBatis）？太老了，写起来繁琐，配置文件一大堆。为什么不上微服务？因为一个单体系统里没有任何微服务需要拆分的理由，答辩时只会被老师追问：“你拆这个服务的依据是什么？”反而不好回答。Spring Boot的价值在于它把Spring生态里那些繁琐的配置都自动化了，你只需要关注业务本身，这对学生来说是最高效的。

MyBatis-Plus比JPA更贴合国内学生的习惯，因为代码生成器可以一键生成entity、mapper、service、controller的骨架，而且它的Lambda QueryWrapper写起来非常直观，不需要手写大量XML。不过需要提醒一句：代码生成器省时间，但答辩时一定要能说清楚每一张表、每一个核心方法在做什么，别把“会用工具”当成“会开发”。

前端的选择上，我的建议是：如果你有一定Vue基础，就选Vue3 + Element Plus，页面好看、交互流畅、演示效果好；如果你时间紧张或者没学过Vue，就用Thymeleaf + Layui，整个项目都是Java技术栈，部署也简单，不容易翻车。毕业设计拼的是“完整交付”，不是前端炫技。

2. 从数据库设计开始想，不要从页面开始想

2.1 用“角色和动作”推导功能模块

很多同学做需求分析的时候习惯从页面开始：“我要做一个首页、一个列表页、一个详情页……”这样想出来的系统是散的。正确的打开方式是：先列角色，再列每个角色的核心动作，最后把动作翻译成页面和接口。

拍卖系统里，我建议只保留两个角色：用户和管理员。不要再加“卖家”角色，不然你的业务链条会变成用户-卖家-管理员三方流转，复杂度立刻上升。毕业设计的评分点不在角色数量，在于每个角色的功能是否完整。

用户端的核心动作：

• 注册、登录、修改密码、查看个人信息
• 浏览拍品列表、查看拍品详情
• 查看进行中的拍卖场次
• 对心仪的拍品出价
• 查看我的出价记录、竞拍状态
• 查看我拍下的订单（成交记录）
• 账户余额充值、资金流水查看

管理员端的核心动作：

• 后台登录（独立登录入口）
• 用户管理：查看用户列表、禁用/启用用户
• 拍品管理：新增、编辑、上下架拍品
• 拍卖场次管理：创建场次、设置起止时间、启动场次
• 订单管理：查看成交订单列表、核销订单
• 公告管理：发布系统公告
• 数据统计：成交金额统计、热门拍品排行

把这张表画出来，你的系统模块就出来了：认证模块、用户模块、拍品模块、场次模块、出价模块、订单模块、资金模块、公告模块。接下来再做数据库设计，心里就非常有数了。

2.2 十张核心表的结构拆解

数据库是整系统的地基，表结构设计的质量直接决定业务逻辑能不能写干净。我给出一个典型的拍卖系统核心表设计，实际开发中你可以按需调整。

关于角色表，我用的是折中方案：sys_user直接加一个role字段，raml值就是ROLE_USER和ROLE_ADMIN。如果你想让权限设计看起来更“正规”，可以拆成sys_role和sys_user_role两张表，回答“RBAC权限模型”的时候也有话说。但对这个系统的规模来说，一张role字段足够，我建议把精力留给真正的业务逻辑。

给你看一段拍品表的核心建表SQL，注意我特意标出的那几个字段：

sql复制CREATE TABLE auction_item (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    category_id BIGINT,
    round_id BIGINT,
    title VARCHAR(200) NOT NULL,
    description TEXT,
    img_url VARCHAR(500),
    start_price DECIMAL(10,2) NOT NULL,
    increment DECIMAL(10,2) NOT NULL DEFAULT 100.00,
    current_price DECIMAL(10,2),
    max_bid_user_id BIGINT,
    status TINYINT NOT NULL DEFAULT 0,
    version INT NOT NULL DEFAULT 0,
    create_time DATETIME,
    update_time DATETIME
);

status字段用TINYINT，0表示待上架、1表示竞拍中、2表示已成交、3表示流拍、4表示已下架。version字段是给乐观锁用的，后面讲并发控制的时候会用到。current_price一开始等于start_price，每次出价成功后更新。

特别注意：金额单位用DECIMAL(10,2)，绝对不要用float或double。二进制浮点数在十进制小数表示上有天生缺陷，0.1在double里存的是一个近似值，累计起来会产生打印都看不出来的误差。凡是涉及钱的地方，Java代码里用BigDecimal，数据库里用DECIMAL，传输时用字符串或保留两位小数，这是死规矩。

2.3 状态流转：拍卖场次和拍品的生命周期

拍卖系统里有两条状态机，你必须在设计阶段就把它们定死，否则写代码的时候会在各种if判断里迷路。

第一条是拍卖场次（auction_round）的状态：

• 待开始（PENDING）——管理员创建好了场次，还没到开始时间
• 进行中（RUNNING）——开始时间到了，用户可出价
• 已结束（ENDED）——结束时间到了，系统结算所有拍品

第二条是拍品（auction_item）的状态：

• 待竞拍（PENDING）——场次还没开始，或者拍品配置好了但没上场
• 竞拍中（BIDDING）——场次进行中，这个拍品可以被出价
• 已成交（SOLD）——场次结束后，存在最高有效出价
• 流拍（FLOW）——场次结束后，没有有效出价

两条状态机通过round_id关联，拍品必须挂在某个场次下。竞价逻辑围绕“场次是否在进行中 + 拍品是否在竞拍中”这个组合来判断。这样的设计可以让代码里的状态判断非常简洁：先看场次，再看拍品，两个都合法才允许出价。

3. 出价这个动作，藏着整个系统最棘手的并发问题

3.1 出价接口的完整校验流程

出价是拍卖系统的灵魂动作，逻辑上并不复杂，但每一步校验都不能少。一个标准的出价接口应该走完下面这一整条链路：

1. 参数校验：出价金额不能为空、必须是正数、不能超过合理范围
2. 用户登录状态校验：未登录直接拒绝
3. 场次状态校验：场次必须处于RUNNING状态
4. 拍品状态校验：拍品必须是BIDDING状态
5. 价格校验：出价必须大于当前价 + 加价幅度（例如当前价1000，加价幅度100，则最低出价1100）
6. 资金校验：用户可用余额必须大于等于本次出价金额
7. 重复出价校验：同一个人不能连续两次出价（可选项，看你想不想做）
8. 写入出价记录，更新当前价、最新出价人
9. 冻结用户资金

每一步看起来都很好写，问题出在“同时出价”这个事上。如果两个用户同时点了出价，都读到当前价1000，都觉得自己出1100是合法的，那系统里就会出现两条价格相同的出价记录，拍品的最新出价人也乱了套。这是经典的并发场景，也是答辩老师最喜欢追问的点。

3.2 并发出价为什么会翻车

我们先复现一下翻车过程。假设当前价是1000，加价幅度100。用户A和用户B同时出价1100：

• A的请求进来，SELECT了一下拍品，看到当前价1000，判断1100 > 1000+100，成立
• B的请求进来，也SELECT了一下拍品，看到当前价1000，判断1100 > 1000+100，也成立
• A写入出价记录，update当前价=1100
• B写入出价记录，也update当前价=1100

结果就是有两条价格一模一样的出价记录，拍品的状态维护也就崩了。这就是典型的“检查与执行之间没有原子性”。你去搜“超卖问题”，本质和这是一模一样的：先查库存、判断够不够、再扣库存，三个动作之间一旦并发插入，数据就错了。

3.3 解决并发出价的两种可靠方案

我推荐第一种方案，因为代码写起来最直观，答辩时也最好解释：先锁住拍品行，再做判断和写入。

方案A：悲观锁（SELECT ... FOR UPDATE）

在事务内，先通过SELECT * FROM auction_item WHERE id = ? FOR UPDATE把拍品这一行锁住，锁住之后，其他事务想再锁同一行就必须等待。这时候你再做价格校验和写入，就是串行的，不会出现两个人同时读到旧价格的问题。

java复制@Transactional
public void bid(BidRequest request) {
    // 先锁拍品行，这里必须使用 via FOR UPDATE
    AuctionItem item = auctionItemMapper.selectByIdForUpdate(request.getItemId());
    if (item == null) {
        throw new BusinessException("拍品不存在");
    }
    // 校验场次和拍品状态
    // 校验出价是否符合加价规则
    BigDecimal minPrice = item.getCurrentPrice().add(item.getIncrement());
    if (request.getBidPrice().compareTo(minPrice) < 0) {
        throw new BusinessException("出价低于当前最低加价");
    }
    // 校验用户余额（这一步可以在事务内重新查用户账户并锁行）
    // 写入出价记录
    // 更新拍品当前价、最新出价人
    // 记录资金流水
    auctionItemMapper.dao...
}

用FOR UPDATE要注意：这个方法必须使用@Transactional，而且锁要尽早拿到、事务要尽快结束。锁的时间越长，并发性能越差，但毕业设计并发量几十人足够了，这个方案完全没问题。

方案B：乐观锁（用version字段）

在拍品表上加一个version字段，更新时带上版本条件：

java复制UPDATE auction_item 
SET current_price = #{newPrice}, max_bid_user_id = #{userId}, version = version + 1
WHERE id = #{itemId} AND version = #{oldVersion}

如果影响行数为0，说明version被别的线程改了，这次出价失败，让它重新查一遍再出价。乐观锁适合读多写少的场景，但这里有一个问题：同一件拍品同时出价时，后到的请求会失败，用户体验上需要重试，代码逻辑上没有悲观锁那么直观。

我给学生的建议是：DBA问起来就用悲观锁，代码简单、逻辑清晰、容易解释；想show并发优化就用乐观锁+唯一约束。后者需要你在bid_record表上建一个联合唯一索引，比如(item_id, bid_price)，从数据库层面堵死同价重复记录，两条方案可以叠加，但解释成本高一点。

我更推荐你选中一种方案，然后把它写透。在论文的“核心问题解决方案”章节里，专门用一张表对比两种方案的优缺点，这种内容老师看了是会加分的。

另外，资金冻结也必须在同一个事务里完成。我建议出价时就把本次出价金额冻结住，而不是等到成交后再扣款。怎么冻结？看用户账户表的三字段设计：

• balance：总余额
• frozen：冻结金额
• available：可用余额 = balance - frozen

出价成功时，假设用户余额10000，已冻结2000，可用8000，本次出价1100，则先校验可用户可用余额 >= 1100，然后冻结，frozen变为3100，可用变为6900。当这个用户被更高价超过时，释放这笔冻结：frozen减1100，可用增加1100。这样设计的好处是：恶意出价的人会一直被占着资金，直到有人出更高价才能解套，天然遏制了乱出价行为。

3.4 用并发测试验证你的方案真的有效

写完代码，必须自己制造并发压测，不然答辩现场可不敢保证不出问题。最简单的办法是写一个Jmeter脚本，或者直接写一个Java多线程demo，模拟100个线程同时出价：

java复制int threadCount = 100;
CountDownLatch latch = new CountDownLatch(threadCount);
for (int i = 0; i < threadCount; i++) {
    new Thread(() -> {
        latch.await();
        restTemplate.postForEntity(url, request, String.class);
    }).start();
    latch.countDown();
}

跑完之后去数据库查一下bid_record，看看有没有同一件拍品出现重复价格、有没有current_price超出所有合法出价、有没有用户资金被重复冻结的异常数据。这一步是答辩前必须做的自测，也是论文中“系统测试”章节里最漂亮的一张成绩单。

4. 到期结算：任务调度与订单生成的细节

4.1 场次结束：定时任务还是懒触发

拍卖场次有结束时间，到时间后系统要干两件事：把场次状态置为ENDED；把所有拍品从BIDDING转为SOLD或FLOW；为SOLD的拍品生成订单并处理资金。

最简单靠谱的方案是用Spring自带的@Scheduled注解写一个定时任务，每隔30秒扫一次所有运行中的场次，找出已经过了结束时间的场次处理掉。代码样子大致是：

java复制@Scheduled(fixedDelay = 30000)
public void settleExpiredRounds() {
    List<AuctionRound> runningRounds = roundDao.selectRunningExpired();
    runningRounds.forEach(round -> {
        round.setStatus("ENDED");
        // 遍历该场次所有拍品，逐个结算
        settleItems(round);
    });
}

定时任务方案的优点是实现简单、逻辑直观、便于测试，缺点是存在最多30秒的延迟。但拍卖系统本身的语义是“到了截止时间就不能出价了”，30秒的误差在毕业设计场景下完全可接受。

另外我会加一道保险：用户在查看“我的竞拍”时，如果发现关联的场次已经结束但还没结算，就现场触发一次结算逻辑。这种“懒结算”思路可以保证即使定时任务在答辩现场出了bug，页面刷新时也能自动修复，演示不至于尴尬。

4.2 成交后的资金处理：冻结释放与订单生成

到了结算环节，资金处理的细节最容易写乱。我梳理一下正解的流程：

1. 对每个拍品，找最高有效出价记录
2. 如果没有有效出价：拍品置为FLOW（流拍），把该拍品所有相关出价记录里冻结的资金全部释放
3. 如果有最高出价：生成order_info订单，状态设为“待支付”或“已支付”（看你是否模拟支付环节），拍品置为SOLD
4. 对该拍品的所有出价记录逐个处理：
   • 最高出价者：冻结资金正式扣减，作为成交付款，写一条“成交支付”流水
   • 其他出价者：解冻他们的冻结资金，写一条“冻结释放”流水

sql复制-- 资金流水表结构：type字段区分
-- 1-充值, 2-出价冻结, 3-冻结释放, 4-成交支付

这里最容易踩的坑是：释放冻结资金时忘了校验“这个人当前的冻结资金还在不在”。如果前面并发控制没做好，可能出现A用户已经因为被超过而解冻了，结算时又解冻一次，导致资金变成负数溢出。所以资金流水表务必留下每一次变更的痕迹，事务里每一步都要反复校验当前余额和冻结余额是否够扣。

订单号生成也要注意。不要用数据库自增id直接当订单号，答辩的时候老师一眼就能看出来你对“业务单号”没有概念。至少用一个yyyyMMddHHmmss + 随机数或者UUID去掉横线的方式生成订单号，同时在order_info表加唯一索引防止重复。

4.3 流拍拍品的处理：管理员重新上架

流拍是拍卖系统里必然存在的业务状态，别把它当成纯失败。结算后，流拍拍品可以进入管理员后台的“流拍列表”，管理员把它重新挂到下一场次，或者选择下架。如果拍品的状态机和场次状态机设计得足够清楚，这只是一个简单的状态更新操作：

java复制item.setStatus("PENDING");
item.setRoundId(newRoundId);
item.setCurrentPrice(item.getStartPrice());

重新上架前，别忘了把出价记录清空或者标注为“历史记录”。我建议保留历史出价记录用于论文分析，只重置拍品的竞价状态字段即可。

5. 工程实现：代码结构、最容易翻车的地方和答辩准备

5.1 推荐的包结构和服务分层

很多同学在写毕业设计代码的时候，喜欢把逻辑全塞在Controller里，几千行代码堆在几个方法中。我建议你从第一天就按下面这个包结构来写：

code复制com.example.auction
├── controller        // 接口层：接收参数、返回结果
├── service           // 业务层：核心逻辑
│   ├── impl
├── mapper            // 数据访问层
├── entity            // 数据库实体
├── dto               // 请求/响应对象
├── common            // 统一结果封装、异常处理、常量
└── config            // 配置类

几个实用的约定：

• 返回结果统一用Result封装，不要直接返回裸的List或String。这样前端处理逻辑简单，接口报错信息也统一。
• 业务异常主动抛出，不要返回null或false让调用方猜原因。global exception handler里去拦截BusinessException并转成统一格式。
• Controller里只做参数接收和结果返回，所有业务判断都在Service层。
• 事务注解只加在Service层方法上，不要直接加在Controller方法上。

这套规范看起来基础，但很多在校生写代码时不注意。到了答辩的时候，老师翻代码最先看的就是Controller层有没有写成一坨屎，分层清晰能让你在第一印象上就赢一半。

5.2 实际开发中最容易翻车的5个细节

**细节一：时区问题。**Spring Boot连接MySQL时，连接字符串里没有配置serverTimezone，启动后你会发现所有时间都差了8小时。正确写法是jdbc:mysql://localhost:3306/auction?serverTimezone=Asia/Shanghai。

**细节二：跨域问题。**如果你前端用Vue开发并且单独部署，后端必须配置跨域过滤器，否则浏览器会报CORS错误。用Spring Security的话还需要单独放行OPTIONS预检请求。

**细节三：密码加密。**不要把用户密码明文存数据库，哪怕毕业设计也要用BCrypt加密。Spring Security自带BCryptPasswordEncoder，直接用就行，答辩时这也算一个安全加分点。

**细节四：BigDecimal比较。**比较两个BigDecimal不要用a.equals(b)，equals会比较小数位，应该用a.compareTo(b) == 0。这个细节很多人到了工作之后还在踩坑。

**细节五：同一个类内部调用事务方法会失效。**因为Spring的事务是基于AOP代理实现的，同类方法调用是this.xxx()，直接绕过代理。如果需要在内部调用带事务的方法，要么拆成两个Bean，要么用事务模板。很多同学把事务写在Controller方法上，然后report“事务不生效”，大概率就死在这里。

5.3 演示数据和部署准备

答辩前一天最紧张的事情就是：数据库里没数据、演示的时候场次已经过期、或者页面白屏。所有问题都可以靠“准备工作做得足够细”来规避：

• 准备一个初始化SQL脚本，包含管理员账号、5个测试用户、10个拍品、1个正在拍卖中的场次。
• 演示用的场次时间要刻意安排在答辩时间之后至少30分钟。比如你下午3点答辩，就把场次截止时间设为下午4点，这样演示到“正在出价”环节时，场次仍然是运行中状态。
• 本地起一个jar包就行，前端资源如果打不进Spring Boot的static目录，就单独起一个Nginx或直接用开发服务器。最稳的做法是把前端打包后的dist目录复制到Spring Boot的src/main/resources/static下，一个jar包全搞定。
• 数据库导一份备份文件放在项目目录里，万一答辩现场数据被弄坏了，一条命令恢复原状。

部署方案不用整太复杂。你只要证明“系统能在服务器的环境中运行起来”就行，云服务器跑jar + MySQL或者直接在笔记本上跑都行。CICD那些是工作里的东西，毕业设计提一句“可以后续扩展”就够了，别硬上Docker K8S，把答辩时间浪费在环境问题上。

5.4 答辩时老师最常问的5个问题

我把往年被老师高频追问的问题列出来，每个给出一个相对稳的回答思路。

问题一：为什么用Spring Boot，相比Spring MVC有什么优势？
回答重点：Spring Boot是Spring MVC应用的快速开发框架，不是替代品。它的核心优势是自动配置和起步依赖，内置Tomcat、简化部署。对于快速交付、独立运行的Web项目来说，开发效率和运维难度都更低。

问题二：你怎么处理并发出价的？
回答重点：讲清楚你选的是悲观锁还是乐观锁，再说明为什么选它。悲观锁就说“我用SELECT FOR UPDATE锁住拍品行，让同一件商品的出价操作串行化，保证价格判断和资金冻结不会因为并发而冲突”，最后补一句“并发量大时可以用乐观锁+版本号代替，但本项目并发场景有限，所以优先选择逻辑更直观的悲观锁”。

问题三：你如何保证出价记录不能重复？
回答重点：从三层说：数据库层面用唯一索引拦截同价重复记录；service层通过锁保证同时间只有一个事务在修改同一拍品；业务层对用户重复出价做校验。分层防御，不是只靠一个地方。

问题四：系统中有没有用到缓存？如果不用缓存，并发出价时数据库不会被压垮吗？
这个问题有点送命题的意思。回答思路是：当前系统的并发规模远没有到数据库瓶颈，拍卖系统的核心瓶颈在于一致性而不是吞吐量，所以优先保证数据准确；后续如果需要提升并发，可以引入Redis做拍品详情缓存、接口限流、出价请求的分布式锁等。

问题五：你的用户余额从哪来？有没有对接真实支付？
按你做的方式回答。如果你做了模拟充值（管理员后台给测试用户充钱），就直接说明“本系统面向教学演示场景，采用模拟充值机制，真实支付可以对接微信/支付宝，但涉及商户资质和安全要求，不在毕设范围内”。这样回答既诚实又显示了边界意识。

写在最后的一点体会

拍卖系统这个题目能做到什么程度，完全取决于你在“出价并发”和“资金流转”这两个核心问题上投入了多少思考。把这两块啃下来，剩下的增删改查只是体力活。

我自己做完这个项目之后最大的体会是：毕业设计与其说是写一个系统，不如说是完整地走一遍“需求分析 → 设计 → 编码 → 测试 → 交付”的工程流程。你现在在数据库设计阶段多想一个字段，写代码的时候就能少写十个if；在并发方案上多花一天论证，答辩的时候就能少挨十分钟追问。

最后分享一个小技巧：开始写代码之前，先写一份技术方案文档，哪怕只写给自己看。把表结构、状态流转、出价流程、资金处理画清楚，再动手写Spring Boot代码。我带的每一个项目，凡是做到了这一步的，最后基本都没有在答辩时翻车。