简介这是一套基于Spring Boot与MySQL实现的校园在线拍卖系统项目源码主要面向毕业设计、课程设计以及需要完整Web项目练手的Java学习者。系统功能覆盖用户注册登录、个人资料管理、拍卖物品发布与浏览、参与竞拍出价、当前最高价跟踪、管理员后台监督以及数据统计分析等前后端分离结构清晰业务流程贴近真实校园二手交易场景。压缩包共839个文件约17.51MB以Java后端、Vue前端、JavaScript交互、SQL数据库脚本和HTML/CSS页面资源为主附带部署说明、视频演示及安装/启动/构建脚本按目录组织便于快速搭建运行环境。已有174人学习下载。借助源码、数据库表结构说明、项目配置和录屏演示读者可以理解Spring Boot与MySQL整合下的接口设计、竞拍业务逻辑与管理员权限控制适合直接作为课题原型或在此基础上二次开发。1. 校园在线拍卖系统一套能把竞拍主线跑通的 Spring Boot 源码在毕业设计和课程设计里最怕的不是项目不够炫而是临交的时候发现系统只能注册登录、核心业务根本没打通。这套基于 Spring Boot MySQL 的校园在线拍卖系统解决的就是这个痛点拍品发布、竞拍出价、自动成交、订单生成是一条完整闭环不是网上那种只能看不能用的半成品。它适合三类人——拿去做毕设主项目、Java Web 课程设计、或者想快速上手一个完整业务状态机项目的初学者。我拆过一次这套源码的目录结构、数据表设计、部署启动到常见坑下面一条线讲清楚。2. 先读懂骨架模块划分、核心数据表与竞拍出价逻辑拿到源码先别急着跑先花十分钟把结构看完后面部署会省很多事。这套系统的代码分层是标准的 Spring Boot 三层架构Controller 负责接口、Service 负责业务、Mapper 负责数据库访问。打开项目后你大概率会看到 controller、service、mapper或者 dao、entity、config 这几个包有这些就说明结构是完整的不是那种所有代码堆在一个类里的教学 Demo。2.1 模块划分用户端、后台管理与竞拍核心三条线按业务功能我把这套系统拆成了三条线这样读代码时不用从头到尾硬啃。第一条是用户端包括注册登录、浏览拍品、发起竞拍、查看自己的竞拍记录和订单对应的入口一般是 UserController、GoodsController、BidController、OrderController。第二条是后台管理管理员登录后可以管理用户、审核拍品、查看成交记录对应 AdminController 或者通过角色字段在业务层拦截。第三条是竞拍核心这是整个项目最值得看的部分GoodsService 负责拍品上下架与状态流转BidService 负责出价校验、价格更新和成交生成。用户权限的判断逻辑通常写在拦截器里注册用户和管理员的区别就是一个 role 字段普通用户为 0管理员为 1。这个字段在登录成功后放进 session 或 request 作用域访问后台接口时先判断一下角色不是管理员就直接返回错误。很多毕设项目会把角色判断散落在各处代码里到处 if 判断这不是好习惯你读代码时可以去 controller 或 config 包下面找有没有写好的拦截器。读代码有个取巧的顺序先看实体类entity再看 Mapper 接口和对应的 XML SQL最后回到 Service 方法。实体类能告诉你有哪些字段SQL 能告诉你业务实际操作了哪些表Service 才是业务规则的载体。这样三轮下来整个项目在你脑子里的拼图就差不多了。2.2 核心数据表设计拍品、竞拍记录与订单的三张主表我拿到一个项目习惯先看数据库脚本表结构能反映业务完整性。这套系统里最核心的是三张表拍品表goods、竞拍记录表bid_record、订单表orders。以下是建表的关键部分字段和注释可以对照你自己的项目调整CREATE TABLE goods ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 拍品ID, title VARCHAR(100) NOT NULL COMMENT 拍品标题, description TEXT COMMENT 拍品描述, category VARCHAR(50) DEFAULT 其他 COMMENT 分类, start_price DECIMAL(10,2) NOT NULL COMMENT 起拍价, step_price DECIMAL(10,2) DEFAULT 10.00 COMMENT 加价幅度, current_price DECIMAL(10,2) DEFAULT 0.00 COMMENT 当前最高价, start_time DATETIME NOT NULL COMMENT 开拍时间, end_time DATETIME NOT NULL COMMENT 截拍时间, status TINYINT DEFAULT 0 COMMENT 0-待审核 1-拍卖中 2-已截拍 3-已成交, seller_id BIGINT NOT NULL COMMENT 发布人ID, image_url VARCHAR(255) COMMENT 拍品图片路径, version INT DEFAULT 0 COMMENT 乐观锁版本号 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT拍品表;CREATE TABLE bid_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, goods_id BIGINT NOT NULL COMMENT 拍品ID, user_id BIGINT NOT NULL COMMENT 出价人ID, bid_price DECIMAL(10,2) NOT NULL COMMENT 出价金额, bid_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 出价时间, KEY idx_goods_id (goods_id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT竞拍记录表;CREATE TABLE orders ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT 订单编号, goods_id BIGINT NOT NULL, buyer_id BIGINT NOT NULL COMMENT 买方ID, seller_id BIGINT NOT NULL COMMENT 卖方ID, final_price DECIMAL(10,2) NOT NULL COMMENT 成交价, status TINYINT DEFAULT 0 COMMENT 0-待付款 1-已付款 2-已完成, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;这三张表的几个设计点值得单独说一下。第一金额全部用 DECIMAL(10,2)不用 float 和 double浮点精度在金额场景一定会出问题这是 Java 后端的基本常识。第二goods.status 用 TINYINT 表示状态而不是字符串枚举查询快、改状态灵活但代码里必须有对应的常量定义否则后面维护的人看不懂 0、1、2、3 分别是什么。第三goods 表里有一个 version 字段这是为乐观锁预留的。竞拍场景天然存在并发出价这个字段能帮你用低成本解决超卖问题第五节我会专门说。订单表里的 order_no 也是容易被忽略的字段。真实系统里订单号需要保证唯一生成规则一般是时间戳加随机数再拼接用户 ID这套系统里如果直接用自增 ID 做订单号在答辩时容易被老师追问可以提前注意一下。2.3 竞拍出价逻辑为什么必须做“时间校验 价格校验 乐观锁”竞拍接口是整个系统最容易被问到的部分。一个看似简单的出价操作背后至少要做三件事判断当前时间是否在拍卖时间内、判断出价是否高于当前最高价、再判断并发情况下是否只有一个人出价成功。看一下 Service 层出价方法的常见写法Transactional public boolean bid(Long goodsId, Long userId, BigDecimal bidPrice) { Goods goods goodsMapper.selectById(goodsId); // 1. 状态校验只有拍卖中的拍品才能出价 if (goods.getStatus() ! 1) { throw new RuntimeException(该拍品不在拍卖中); } // 2. 价格校验出价必须高于当前最高价且至少加一个最小加价幅度 if (bidPrice.compareTo(goods.getCurrentPrice().add(goods.getStepPrice())) 0) { throw new RuntimeException(出价低于最低加价幅度); } // 3. 乐观锁更新只有当前价格没被别人改过更新才生效 int rows goodsMapper.updateCurrentPrice(goodsId, goods.getCurrentPrice(), bidPrice); if (rows 0) { throw new RuntimeException(价格已被更新请重试); } bidRecordMapper.insert(new BidRecord(goodsId, userId, bidPrice, new Date())); return true; }这段代码有三个关键点。第一个是状态判断直接用 status 字段判断是否在拍卖中而不是再去比较 end_time 和当前时间因为截拍后状态会被定时任务改成 2状态字段比时间判断更可靠。第二个是价格校验这里用了 compareTo 而不是 equalsBigDecimal 是对象equals 比较的是数值和精度两个值相同但 scale 不同的 BigDecimal equals 会返回 false所以金额比较必须用 compareTo。第三个是乐观锁注意上面的 updateCurrentPrice 在 SQL 里带了条件 WHERE current_price #{oldPrice}如果影响行数为 0说明并发下有人抢先更新了价格整个方法会抛出异常并回滚事务。前端调用出价接口的写法也顺带说一下接口路径一般是 POST /bid参数用 JSON 格式传递// 出价请求示例 fetch(/api/bid, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ goodsId: 1, userId: 2, bidPrice: 500 }) })前端拿到返回结果后如果成功就调用刷新拍品详情的接口把当前价和出价记录列表都更新掉。如果后端返回异常信息就用 alert 或弹窗提示给用户不要在前端自己做价格判断前后端双重校验才能兜住并发场景下的漏洞。3. 把项目跑起来环境准备、SQL 导入与启动验证源码结构看明白了接下来就是实际把它跑起来。这一章按“装环境、导数据、改配置、启动验证”四步走每一步都会告诉你卡住的时候看哪里照着做就能少走弯路。3.1 环境准备JDK、Maven、MySQL 的版本怎么选这套系统是 Spring Boot MySQL 的经典组合环境选择比较宽松但最好按下面这张表来配省得后面踩版本坑工具推荐版本说明JDK1.8 或 11Spring Boot 2.x 主流用 JDK 8选 11 也能跑Maven3.6 以上用于依赖管理和打包IDEA 自带 Maven 插件也可以MySQL5.7 或 8.05.7 省事8.0 需要在连接串里加时区参数Navicat任意版本导入 SQL、看表结构方便用命令行也行这里提醒一句MySQL 安装配置本身就是一个常见卡点。Windows 上装 MySQL 8.0 时如果初始化阶段没设置好 root 密码后续连接会报 Access deniedLinux 上 rpm 安装 MySQL 5.7 还需要手动初始化。如果你之前没装过 MySQL建议先用 Navicat for MySQL 连一下本地数据库能连上再继续。另外Spring Boot 版本不要随意换项目里的 pom.xml 写的是哪个版本就用哪个版本。如果你本地 Maven 默认拉的是更新的 Spring Boot 版本可能会出现依赖冲突这种问题定位起来非常费时间属于典型的版本玄学。3.2 数据库初始化导入 SQL 与修改 application.yml项目的 SQL 文件一般放在根目录下的 sql 或 db 文件夹里。打开 Navicat新建一个数据库名字随意比如 auction字符集选 utf8mb4然后右键运行 SQL 文件。命令行导入的方式也可以mysql -uroot -p /path/to/auction.sql导入完成后检查一下表是否都在重点看 goods、bid_record、orders、user 这四张表。接下来打开 src/main/resources/application.yml把数据库连接改成你自己的账号密码server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/auction?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver这个连接串里有三个参数最容易出问题。第一个 useSSLfalseMySQL 8.0 默认开启 SSL不关掉会在控制台看到一堆连接警告甚至直接报错。第二个 characterEncodingutf8 配合 useUnicodetrue 是防止中文乱码注册用户后如果数据库里显示乱码十有八九是这里没配对。第三个 serverTimezoneAsia/ShanghaiMySQL 8.0 必须加不加会报 CST 时区无法识别的错误或者所有时间字段都差 8 个小时竞拍倒计时直接错乱。password 字段改成你自己数据库的密码注意不要加引号YAML 里引号处理不当会导致密码解析错误。3.3 启动项目并验证核心四步流程在项目根目录打开命令行用 Maven 启动mvn spring-boot:runIDEA 里也可以直接运行主类效果一样。启动日志出现 Started Application 就说明成功如果报错优先看红色异常的第一行信息。接下来打开浏览器访问 http://localhost:8080按下面四步走一遍主流程注册一个普通用户登录后确认能进入商品列表页发布一件拍品如果系统设计是用户直接发布待审核要去后台管理入口确认有审核操作再注册第二个账号对这件拍品出价确认当前价格刷新、竞拍记录增加把拍品的结束时间改到过去一分钟触发截拍逻辑确认订单表生成。这四步全部走通说明核心链路没问题。如果发布的商品需要管理员审核记得先去数据库把管理员账号的状态检查一下有些初始化数据里已经写好了管理员的账号密码直接用就行。走流程的过程中不要跳过任何一步很多项目的演示翻车都发生在“我以为这个功能没问题”的地方。4. 部署与常见问题排查局域网访问、时区与重复出价的坑项目能本地跑只是第一步。答辩现场或者给别人演示的时候你不可能一直开着 IDEA。这一章先讲怎么打包部署再讲我拆这个项目时实际遇到的几个典型坑全部是真实会发生的场景。4.1 打包部署从 IDEA 到独立运行的 jarSpring Boot 项目打包部署很简单核心就一条命令。在项目根目录执行mvn clean package -DskipTests打包完成后target 目录下会生成一个 jar 文件。把这个 jar 复制到服务器或者另一台电脑上用 Java 直接运行java -jar auction-system-0.0.1-SNAPSHOT.jar想让宿舍同学或者同一局域网的人也能访问启动时把监听地址设为 0.0.0.0客户端访问 http://你的局域网IP:8080 即可。Windows 下查本机 IP 用 ipconfigLinux 用 ifconfig 或者 ip addr。如果要在 Linux 服务器上长期运行用 nohup 命令挂在后台nohup java -jar auction-system-0.0.1-SNAPSHOT.jar app.log 21 部署到外网就需要云服务器加域名再挂一个 Nginx 反向代理毕设阶段一般不用做到这一步。但有一个点要注意改端口之后前端页面里的接口请求地址如果是写死的 8080需要同步改掉否则页面能打开但数据请求全部失败。4.2 避坑常见问题的现象、原因与解决第一个坑启动时数据库连不上报 Communications link failure 或 Access denied。现象是控制台在网络连接阶段反复重试最终整个应用启动失败。原因分两种一是账号密码写错二是 MySQL 8.0 的时区和 SSL 参数没配。解决方法是先用 Navicat 用同一组账号密码测试连接能连上再看连接串把 useSSLfalse 和 serverTimezoneAsia/Shanghai 加上。这条覆盖了大多数启动失败场景值得最先排查。第二个坑SQL 导入后中文乱码。现象是注册用户后数据库里显示乱码但页面显示正常。原因是导入 SQL 时连接字符集和库表字符集不一致建库时没选 utf8mb4或者 Navicat 连接用的默认编码不是 utf8mb4。解决方法是删库重建字符集选 utf8mb4排序规则选 utf8mb4_general_ci导入前确认连接属性里的编码也是 utf8mb4。这个乱码坑踩的人非常多别用默认的 latin1。第三个坑并发出价时两个账号都提示成功但当前价格只更新了一次。现象是同时用两个浏览器账号抢同一件拍品控制台出现异常但 bid_record 表里可能多了两条记录。原因是 updateCurrentPrice 的 SQL 没带条件更新或者 Service 方法没加 Transactional。解决方法是检查更新 SQL 是否带了 WHERE current_price 旧值方法上必须有 Transactional且异常要继承 RuntimeException 才能触发回滚。这是竞拍系统最核心的并发问题答辩时被追问的概率极高。第四个坑8080 端口被占用启动直接报 Port 8080 was already in use。现象很直接启动日志里会明确提示。解决方法是改 application.yml 里的 server.port或者结束占用进程。Windows 下查端口占用用 netstat -ano | findstr 8080拿到 PID 后 taskkill /PID xxx /F 结束进程。注意改端口之后前端请求路径里的端口也要跟着改。第五个坑页面能打开但上传的图片不显示。现象是上传拍品图片后数据库里 image_url 字段有值但访问图片路径返回 404。原因是上传文件保存到了本地磁盘但 Spring Boot 没有把磁盘目录映射成静态资源导致 Tomcat 找不到这张图。解决方法是增加一个资源映射配置把文件存储目录映射到 /images/**或者直接把图片存到项目的 static 目录下再打包。这个属于配置类问题网上能搜到很多例子改完重新打包就好。5. 不只会启动竞拍主流程验证与两个值得动手的改进项目能跑起来、演示一遍这只是开始。答辩老师最常追问的恰恰是“并发问题怎么解决”“数据一致性怎么保证”。这一章给一个验证思路和两个改动方向改完项目会明显更完整也能体现你真正看懂了这个系统。5.1 用三条 SQL 验证竞拍逻辑是否真闭环在 Navicat 里模拟一次完整竞拍然后验证数据一致性。先把一件拍品的结束时间改成未来状态改成拍卖中用两个账号各出一次价最后用下面的 SQL 检查-- 查看拍品当前价与最高出价是否一致 SELECT g.id, g.current_price, MAX(b.bid_price) AS max_bid FROM goods g JOIN bid_record b ON b.goods_id g.id GROUP BY g.id, g.current_price HAVING g.current_price ! max_bid; -- 检查是否存在同一个用户重复出价且都成功的情况 SELECT goods_id, user_id, COUNT(*) cnt FROM bid_record GROUP BY goods_id, user_id HAVING cnt 1; -- 检查已成交的拍品是否都生成了订单 SELECT g.id, g.status, o.id AS order_id FROM goods g LEFT JOIN orders o ON o.goods_id g.id WHERE g.status 3 AND o.id IS NULL;第一条查价格不一致说明出价并发控制有问题第二条查重复出价说明缺少同一用户重复出价的限制规则第三条查已成交但没生成订单说明截拍逻辑有缺口。这三条 SQL 在答辩现场能当验证依据比口头解释有说服力得多。5.2 两个改进方向定时关拍与密码加密第一个改进是给系统加一个定时任务让拍品到时间自动从“拍卖中”变成“已截拍”再判断是否需要生成订单。Spring Boot 里用 Scheduled 注解就能实现写一个方法每天每分钟执行一次扫描 end_time 小于当前时间且 status 还是 1 的记录批量更新状态。很多毕设项目只在前端判断时间数据库状态根本没有流转这是答辩时容易被老师抓到的点。第二个改进是密码加密。如果你发现数据库里用户密码是明文建议改成 BCrypt 加密。不需要引入整个 Spring Security单加一个 spring-security-crypto 依赖即可。注册时用 BCryptPasswordEncoder.encode() 存密文登录时用 matches() 校验明文和密文是否匹配。改动量不大但属于安全硬伤级别的问题写进论文里也是加分项。从那以后我每次拿到一个 Spring Boot 毕设项目都强制走一遍“看表结构、跑主流程、试并发、查数据一致性”这四步前期就把隐患排掉而不是等答辩现场翻车。这套校园拍卖系统的主线完整、结构清晰适合在上面继续做扩展比如增加保证金、支付模拟、消息通知。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/30 17:16:57 · 阅读 1.2k Spring Boot校园拍卖系统：从数据库设计到并发出价实战解析
简介这是一套基于Spring Boot与MySQL实现的校园在线拍卖系统项目源码主要面向毕业设计、课程设计以及需要完整Web项目练手的Java学习者。系统功能覆盖用户注册登录、个人资料管理、拍卖物品发布与浏览、参与竞拍出价、当前最高价跟踪、管理员后台监督以及数据统计分析等前后端分离结构清晰业务流程贴近真实校园二手交易场景。压缩包共839个文件约17.51MB以Java后端、Vue前端、JavaScript交互、SQL数据库脚本和HTML/CSS页面资源为主附带部署说明、视频演示及安装/启动/构建脚本按目录组织便于快速搭建运行环境。已有174人学习下载。借助源码、数据库表结构说明、项目配置和录屏演示读者可以理解Spring Boot与MySQL整合下的接口设计、竞拍业务逻辑与管理员权限控制适合直接作为课题原型或在此基础上二次开发。1. 校园在线拍卖系统一套能把竞拍主线跑通的 Spring Boot 源码在毕业设计和课程设计里最怕的不是项目不够炫而是临交的时候发现系统只能注册登录、核心业务根本没打通。这套基于 Spring Boot MySQL 的校园在线拍卖系统解决的就是这个痛点拍品发布、竞拍出价、自动成交、订单生成是一条完整闭环不是网上那种只能看不能用的半成品。它适合三类人——拿去做毕设主项目、Java Web 课程设计、或者想快速上手一个完整业务状态机项目的初学者。我拆过一次这套源码的目录结构、数据表设计、部署启动到常见坑下面一条线讲清楚。2. 先读懂骨架模块划分、核心数据表与竞拍出价逻辑拿到源码先别急着跑先花十分钟把结构看完后面部署会省很多事。这套系统的代码分层是标准的 Spring Boot 三层架构Controller 负责接口、Service 负责业务、Mapper 负责数据库访问。打开项目后你大概率会看到 controller、service、mapper或者 dao、entity、config 这几个包有这些就说明结构是完整的不是那种所有代码堆在一个类里的教学 Demo。2.1 模块划分用户端、后台管理与竞拍核心三条线按业务功能我把这套系统拆成了三条线这样读代码时不用从头到尾硬啃。第一条是用户端包括注册登录、浏览拍品、发起竞拍、查看自己的竞拍记录和订单对应的入口一般是 UserController、GoodsController、BidController、OrderController。第二条是后台管理管理员登录后可以管理用户、审核拍品、查看成交记录对应 AdminController 或者通过角色字段在业务层拦截。第三条是竞拍核心这是整个项目最值得看的部分GoodsService 负责拍品上下架与状态流转BidService 负责出价校验、价格更新和成交生成。用户权限的判断逻辑通常写在拦截器里注册用户和管理员的区别就是一个 role 字段普通用户为 0管理员为 1。这个字段在登录成功后放进 session 或 request 作用域访问后台接口时先判断一下角色不是管理员就直接返回错误。很多毕设项目会把角色判断散落在各处代码里到处 if 判断这不是好习惯你读代码时可以去 controller 或 config 包下面找有没有写好的拦截器。读代码有个取巧的顺序先看实体类entity再看 Mapper 接口和对应的 XML SQL最后回到 Service 方法。实体类能告诉你有哪些字段SQL 能告诉你业务实际操作了哪些表Service 才是业务规则的载体。这样三轮下来整个项目在你脑子里的拼图就差不多了。2.2 核心数据表设计拍品、竞拍记录与订单的三张主表我拿到一个项目习惯先看数据库脚本表结构能反映业务完整性。这套系统里最核心的是三张表拍品表goods、竞拍记录表bid_record、订单表orders。以下是建表的关键部分字段和注释可以对照你自己的项目调整CREATE TABLE goods ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 拍品ID, title VARCHAR(100) NOT NULL COMMENT 拍品标题, description TEXT COMMENT 拍品描述, category VARCHAR(50) DEFAULT 其他 COMMENT 分类, start_price DECIMAL(10,2) NOT NULL COMMENT 起拍价, step_price DECIMAL(10,2) DEFAULT 10.00 COMMENT 加价幅度, current_price DECIMAL(10,2) DEFAULT 0.00 COMMENT 当前最高价, start_time DATETIME NOT NULL COMMENT 开拍时间, end_time DATETIME NOT NULL COMMENT 截拍时间, status TINYINT DEFAULT 0 COMMENT 0-待审核 1-拍卖中 2-已截拍 3-已成交, seller_id BIGINT NOT NULL COMMENT 发布人ID, image_url VARCHAR(255) COMMENT 拍品图片路径, version INT DEFAULT 0 COMMENT 乐观锁版本号 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT拍品表;CREATE TABLE bid_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, goods_id BIGINT NOT NULL COMMENT 拍品ID, user_id BIGINT NOT NULL COMMENT 出价人ID, bid_price DECIMAL(10,2) NOT NULL COMMENT 出价金额, bid_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 出价时间, KEY idx_goods_id (goods_id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT竞拍记录表;CREATE TABLE orders ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT 订单编号, goods_id BIGINT NOT NULL, buyer_id BIGINT NOT NULL COMMENT 买方ID, seller_id BIGINT NOT NULL COMMENT 卖方ID, final_price DECIMAL(10,2) NOT NULL COMMENT 成交价, status TINYINT DEFAULT 0 COMMENT 0-待付款 1-已付款 2-已完成, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;这三张表的几个设计点值得单独说一下。第一金额全部用 DECIMAL(10,2)不用 float 和 double浮点精度在金额场景一定会出问题这是 Java 后端的基本常识。第二goods.status 用 TINYINT 表示状态而不是字符串枚举查询快、改状态灵活但代码里必须有对应的常量定义否则后面维护的人看不懂 0、1、2、3 分别是什么。第三goods 表里有一个 version 字段这是为乐观锁预留的。竞拍场景天然存在并发出价这个字段能帮你用低成本解决超卖问题第五节我会专门说。订单表里的 order_no 也是容易被忽略的字段。真实系统里订单号需要保证唯一生成规则一般是时间戳加随机数再拼接用户 ID这套系统里如果直接用自增 ID 做订单号在答辩时容易被老师追问可以提前注意一下。2.3 竞拍出价逻辑为什么必须做“时间校验 价格校验 乐观锁”竞拍接口是整个系统最容易被问到的部分。一个看似简单的出价操作背后至少要做三件事判断当前时间是否在拍卖时间内、判断出价是否高于当前最高价、再判断并发情况下是否只有一个人出价成功。看一下 Service 层出价方法的常见写法Transactional public boolean bid(Long goodsId, Long userId, BigDecimal bidPrice) { Goods goods goodsMapper.selectById(goodsId); // 1. 状态校验只有拍卖中的拍品才能出价 if (goods.getStatus() ! 1) { throw new RuntimeException(该拍品不在拍卖中); } // 2. 价格校验出价必须高于当前最高价且至少加一个最小加价幅度 if (bidPrice.compareTo(goods.getCurrentPrice().add(goods.getStepPrice())) 0) { throw new RuntimeException(出价低于最低加价幅度); } // 3. 乐观锁更新只有当前价格没被别人改过更新才生效 int rows goodsMapper.updateCurrentPrice(goodsId, goods.getCurrentPrice(), bidPrice); if (rows 0) { throw new RuntimeException(价格已被更新请重试); } bidRecordMapper.insert(new BidRecord(goodsId, userId, bidPrice, new Date())); return true; }这段代码有三个关键点。第一个是状态判断直接用 status 字段判断是否在拍卖中而不是再去比较 end_time 和当前时间因为截拍后状态会被定时任务改成 2状态字段比时间判断更可靠。第二个是价格校验这里用了 compareTo 而不是 equalsBigDecimal 是对象equals 比较的是数值和精度两个值相同但 scale 不同的 BigDecimal equals 会返回 false所以金额比较必须用 compareTo。第三个是乐观锁注意上面的 updateCurrentPrice 在 SQL 里带了条件 WHERE current_price #{oldPrice}如果影响行数为 0说明并发下有人抢先更新了价格整个方法会抛出异常并回滚事务。前端调用出价接口的写法也顺带说一下接口路径一般是 POST /bid参数用 JSON 格式传递// 出价请求示例 fetch(/api/bid, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ goodsId: 1, userId: 2, bidPrice: 500 }) })前端拿到返回结果后如果成功就调用刷新拍品详情的接口把当前价和出价记录列表都更新掉。如果后端返回异常信息就用 alert 或弹窗提示给用户不要在前端自己做价格判断前后端双重校验才能兜住并发场景下的漏洞。3. 把项目跑起来环境准备、SQL 导入与启动验证源码结构看明白了接下来就是实际把它跑起来。这一章按“装环境、导数据、改配置、启动验证”四步走每一步都会告诉你卡住的时候看哪里照着做就能少走弯路。3.1 环境准备JDK、Maven、MySQL 的版本怎么选这套系统是 Spring Boot MySQL 的经典组合环境选择比较宽松但最好按下面这张表来配省得后面踩版本坑工具推荐版本说明JDK1.8 或 11Spring Boot 2.x 主流用 JDK 8选 11 也能跑Maven3.6 以上用于依赖管理和打包IDEA 自带 Maven 插件也可以MySQL5.7 或 8.05.7 省事8.0 需要在连接串里加时区参数Navicat任意版本导入 SQL、看表结构方便用命令行也行这里提醒一句MySQL 安装配置本身就是一个常见卡点。Windows 上装 MySQL 8.0 时如果初始化阶段没设置好 root 密码后续连接会报 Access deniedLinux 上 rpm 安装 MySQL 5.7 还需要手动初始化。如果你之前没装过 MySQL建议先用 Navicat for MySQL 连一下本地数据库能连上再继续。另外Spring Boot 版本不要随意换项目里的 pom.xml 写的是哪个版本就用哪个版本。如果你本地 Maven 默认拉的是更新的 Spring Boot 版本可能会出现依赖冲突这种问题定位起来非常费时间属于典型的版本玄学。3.2 数据库初始化导入 SQL 与修改 application.yml项目的 SQL 文件一般放在根目录下的 sql 或 db 文件夹里。打开 Navicat新建一个数据库名字随意比如 auction字符集选 utf8mb4然后右键运行 SQL 文件。命令行导入的方式也可以mysql -uroot -p /path/to/auction.sql导入完成后检查一下表是否都在重点看 goods、bid_record、orders、user 这四张表。接下来打开 src/main/resources/application.yml把数据库连接改成你自己的账号密码server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/auction?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver这个连接串里有三个参数最容易出问题。第一个 useSSLfalseMySQL 8.0 默认开启 SSL不关掉会在控制台看到一堆连接警告甚至直接报错。第二个 characterEncodingutf8 配合 useUnicodetrue 是防止中文乱码注册用户后如果数据库里显示乱码十有八九是这里没配对。第三个 serverTimezoneAsia/ShanghaiMySQL 8.0 必须加不加会报 CST 时区无法识别的错误或者所有时间字段都差 8 个小时竞拍倒计时直接错乱。password 字段改成你自己数据库的密码注意不要加引号YAML 里引号处理不当会导致密码解析错误。3.3 启动项目并验证核心四步流程在项目根目录打开命令行用 Maven 启动mvn spring-boot:runIDEA 里也可以直接运行主类效果一样。启动日志出现 Started Application 就说明成功如果报错优先看红色异常的第一行信息。接下来打开浏览器访问 http://localhost:8080按下面四步走一遍主流程注册一个普通用户登录后确认能进入商品列表页发布一件拍品如果系统设计是用户直接发布待审核要去后台管理入口确认有审核操作再注册第二个账号对这件拍品出价确认当前价格刷新、竞拍记录增加把拍品的结束时间改到过去一分钟触发截拍逻辑确认订单表生成。这四步全部走通说明核心链路没问题。如果发布的商品需要管理员审核记得先去数据库把管理员账号的状态检查一下有些初始化数据里已经写好了管理员的账号密码直接用就行。走流程的过程中不要跳过任何一步很多项目的演示翻车都发生在“我以为这个功能没问题”的地方。4. 部署与常见问题排查局域网访问、时区与重复出价的坑项目能本地跑只是第一步。答辩现场或者给别人演示的时候你不可能一直开着 IDEA。这一章先讲怎么打包部署再讲我拆这个项目时实际遇到的几个典型坑全部是真实会发生的场景。4.1 打包部署从 IDEA 到独立运行的 jarSpring Boot 项目打包部署很简单核心就一条命令。在项目根目录执行mvn clean package -DskipTests打包完成后target 目录下会生成一个 jar 文件。把这个 jar 复制到服务器或者另一台电脑上用 Java 直接运行java -jar auction-system-0.0.1-SNAPSHOT.jar想让宿舍同学或者同一局域网的人也能访问启动时把监听地址设为 0.0.0.0客户端访问 http://你的局域网IP:8080 即可。Windows 下查本机 IP 用 ipconfigLinux 用 ifconfig 或者 ip addr。如果要在 Linux 服务器上长期运行用 nohup 命令挂在后台nohup java -jar auction-system-0.0.1-SNAPSHOT.jar app.log 21 部署到外网就需要云服务器加域名再挂一个 Nginx 反向代理毕设阶段一般不用做到这一步。但有一个点要注意改端口之后前端页面里的接口请求地址如果是写死的 8080需要同步改掉否则页面能打开但数据请求全部失败。4.2 避坑常见问题的现象、原因与解决第一个坑启动时数据库连不上报 Communications link failure 或 Access denied。现象是控制台在网络连接阶段反复重试最终整个应用启动失败。原因分两种一是账号密码写错二是 MySQL 8.0 的时区和 SSL 参数没配。解决方法是先用 Navicat 用同一组账号密码测试连接能连上再看连接串把 useSSLfalse 和 serverTimezoneAsia/Shanghai 加上。这条覆盖了大多数启动失败场景值得最先排查。第二个坑SQL 导入后中文乱码。现象是注册用户后数据库里显示乱码但页面显示正常。原因是导入 SQL 时连接字符集和库表字符集不一致建库时没选 utf8mb4或者 Navicat 连接用的默认编码不是 utf8mb4。解决方法是删库重建字符集选 utf8mb4排序规则选 utf8mb4_general_ci导入前确认连接属性里的编码也是 utf8mb4。这个乱码坑踩的人非常多别用默认的 latin1。第三个坑并发出价时两个账号都提示成功但当前价格只更新了一次。现象是同时用两个浏览器账号抢同一件拍品控制台出现异常但 bid_record 表里可能多了两条记录。原因是 updateCurrentPrice 的 SQL 没带条件更新或者 Service 方法没加 Transactional。解决方法是检查更新 SQL 是否带了 WHERE current_price 旧值方法上必须有 Transactional且异常要继承 RuntimeException 才能触发回滚。这是竞拍系统最核心的并发问题答辩时被追问的概率极高。第四个坑8080 端口被占用启动直接报 Port 8080 was already in use。现象很直接启动日志里会明确提示。解决方法是改 application.yml 里的 server.port或者结束占用进程。Windows 下查端口占用用 netstat -ano | findstr 8080拿到 PID 后 taskkill /PID xxx /F 结束进程。注意改端口之后前端请求路径里的端口也要跟着改。第五个坑页面能打开但上传的图片不显示。现象是上传拍品图片后数据库里 image_url 字段有值但访问图片路径返回 404。原因是上传文件保存到了本地磁盘但 Spring Boot 没有把磁盘目录映射成静态资源导致 Tomcat 找不到这张图。解决方法是增加一个资源映射配置把文件存储目录映射到 /images/**或者直接把图片存到项目的 static 目录下再打包。这个属于配置类问题网上能搜到很多例子改完重新打包就好。5. 不只会启动竞拍主流程验证与两个值得动手的改进项目能跑起来、演示一遍这只是开始。答辩老师最常追问的恰恰是“并发问题怎么解决”“数据一致性怎么保证”。这一章给一个验证思路和两个改动方向改完项目会明显更完整也能体现你真正看懂了这个系统。5.1 用三条 SQL 验证竞拍逻辑是否真闭环在 Navicat 里模拟一次完整竞拍然后验证数据一致性。先把一件拍品的结束时间改成未来状态改成拍卖中用两个账号各出一次价最后用下面的 SQL 检查-- 查看拍品当前价与最高出价是否一致 SELECT g.id, g.current_price, MAX(b.bid_price) AS max_bid FROM goods g JOIN bid_record b ON b.goods_id g.id GROUP BY g.id, g.current_price HAVING g.current_price ! max_bid; -- 检查是否存在同一个用户重复出价且都成功的情况 SELECT goods_id, user_id, COUNT(*) cnt FROM bid_record GROUP BY goods_id, user_id HAVING cnt 1; -- 检查已成交的拍品是否都生成了订单 SELECT g.id, g.status, o.id AS order_id FROM goods g LEFT JOIN orders o ON o.goods_id g.id WHERE g.status 3 AND o.id IS NULL;第一条查价格不一致说明出价并发控制有问题第二条查重复出价说明缺少同一用户重复出价的限制规则第三条查已成交但没生成订单说明截拍逻辑有缺口。这三条 SQL 在答辩现场能当验证依据比口头解释有说服力得多。5.2 两个改进方向定时关拍与密码加密第一个改进是给系统加一个定时任务让拍品到时间自动从“拍卖中”变成“已截拍”再判断是否需要生成订单。Spring Boot 里用 Scheduled 注解就能实现写一个方法每天每分钟执行一次扫描 end_time 小于当前时间且 status 还是 1 的记录批量更新状态。很多毕设项目只在前端判断时间数据库状态根本没有流转这是答辩时容易被老师抓到的点。第二个改进是密码加密。如果你发现数据库里用户密码是明文建议改成 BCrypt 加密。不需要引入整个 Spring Security单加一个 spring-security-crypto 依赖即可。注册时用 BCryptPasswordEncoder.encode() 存密文登录时用 matches() 校验明文和密文是否匹配。改动量不大但属于安全硬伤级别的问题写进论文里也是加分项。从那以后我每次拿到一个 Spring Boot 毕设项目都强制走一遍“看表结构、跑主流程、试并发、查数据一致性”这四步前期就把隐患排掉而不是等答辩现场翻车。这套校园拍卖系统的主线完整、结构清晰适合在上面继续做扩展比如增加保证金、支付模拟、消息通知。希望帮到你。本文还有配套的精品资源点击获取