简介：基于 Spring Boot 与 MySQL 的校园在线拍卖系统，面向高校毕业设计、课程设计及需要快速搭建拍卖类项目的开发者。压缩包共含 839 个文件，其中既包括 131 个 Java 后端类、49 个 Vue 组件、164 个 JavaScript 脚本，也包含 53 个 CSS 样式、162 个 SVG 图标与 79 个 GIF 演示素材，另有 SQL 初始化脚本、HTML 页面、XML 配置及 1-install.bat、2-run.bat、3-build.bat 等一键部署脚本，整体 17.51MB。系统实现用户注册登录、物品发布浏览、竞拍出价跟踪、拍卖管理与数据统计分析等核心功能，界面友好，并提供基础安全与隐私保护；数据库包含用户、物品、竞拍记录等核心表，结构合理，便于二次开发与功能扩展。配合部署说明与视频演示，从环境准备到运行调试均有清晰指引。已有 174 人学习下载，适合具备一定 Java 基础、希望参考完整真实业务代码的开发者快速上手。

1. 校园拍卖系统，为什么值得自己做一套

不知道你见过没有：每年毕业季，宿舍楼微信群里全是“台灯10块、考研笔记五毛一本、小冰箱自提”的接龙消息，价格靠喊，成交靠缘分，没人管售后，更没人管你抢没抢到。所谓“校园在线拍卖系统”，就是把这个场景从聊天记录里搬到Web页面上：买家按时出价，系统按规则撮合，卖家设置起拍价和截止时间，平台留下出价记录，成交之后由买卖双方线下完成交付。这类系统几乎覆盖了Java Web开发的主干知识——用户注册登录、商品上架、定时关单、竞价流水、订单状态流转，是课程设计和毕业设计里出现频率最高的题目之一。

我这个标题里挂的是“源码+部署说明+视频演示”，说明它定位很明确：不是PPT方案，而是一套拿到手就能改、能跑、能演示的完整工程。适合谁？第一类是准备答辩的学生，需要一个说得清数据流和表结构的项目；第二类是刚把Spring Boot学完、想练手真实业务状态的开发者。接下来我按自己做这套东西的顺序，从拆包、建表、写核心逻辑，到避坑和验收，一路讲明白。中间会有可以直接抄的SQL、配置和命令，也会指名几个最容易让新手翻车的点。

2. 技术选型与工程拆包：为什么这套组合在校园场景最好使

2.1 Spring Boot + MySQL：不是最潮，但是最稳

做校园拍卖这种管理系统，最常见的组合就是Spring Boot + MySQL，原因很实在：第一，Spring Boot把配置集中到一个application.yml里，内置Tomcat，不用像传统SSH那样写一堆XML配置，出活快；第二，MySQL是关系型数据库里上手最容易的，而且校园网环境里装MySQL 5.7或8.0都毫无压力——标题里直接写“mysql”，说明它不适合改成文档数据库或无服务架构，这个定位从一开始就是奔着“方便部署、方便答辩演示”去的。

这套系统的核心域模型是用户、商品、出价记录、订单四张主表，天然适合外键加索引来维系关系。出价这种递增竞价的场景，用行锁来防止超卖，也是MySQL的强项，不需要引入Redis。如果你在技术选型答辩里被问到“为什么不加Redis”，可以这样回答：校园系统并发量低，Redis的引入只会增加部署复杂度，数据库事务已经足够保证出价一致性——这个说法在老师那里是站得住的。

2.2 拿到源码包后，先确认这几样东西

解压之后不要急着用IDEA打开就点运行。先核对一遍工程里这几个关键配置，否则后边会连环踩坑。

先看pom.xml里的Spring Boot版本。这一点特别容易被忽略：很多下载的工程用的是Spring Boot 2.x，但你的IDEA里装的JDK是17甚至21。Spring Boot版本太高和JDK版本不匹配，经常出现启动直接报错或者莫名其妙少依赖的情况。我一般建议统一用Spring Boot 2.7.x配JDK 8，这是最稳的组合，如果工程里已经是Spring Boot 3.x，则要配JDK 17。

然后看application.yml里的数据源配置。下面是一个典型配置骨架：

spring: datasource: url: jdbc:mysql://localhost:3306/campus_auction?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver jpa: hibernate: ddl-auto: update show-sql: true

这段配置里有几个容易出问题的地方，说明一下：serverTimezone=Asia/Shanghai必须加，MySQL 8默认时区不是中国时区，不加会报错；useSSL=false也必须加，否则MySQL 8会报SSL连接错误；allowPublicKeyRetrieval=true是配合MySQL 8的caching_sha2_password认证方式加的，不加的话新版连接驱动可能连接失败。至于ddl-auto: update，开发阶段可以用，但演示前建议改成none或validate，避免Hibernate自动改动表结构。

2.3 初始化SQL：建库建表和演示数据一步到位

这套系统里一定带一个.sql文件，通常是campus_auction.sql。用Navicat for MySQL导入时，注意先创建好数据库再导入，不要直接双击运行。以下是一个完整的初始化脚本核心部分，涵盖用户表、商品表、出价记录表和订单表：

CREATE DATABASE IF NOT EXISTS campus_auction DEFAULT CHARACTER SET utf8mb4; USE campus_auction; -- 用户表 CREATE TABLE `user` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '用户ID', `username` VARCHAR(50) NOT NULL COMMENT '学号/工号', `password` VARCHAR(255) NOT NULL COMMENT 'BCrypt加密后的密码', `nickname` VARCHAR(50) DEFAULT NULL, `role` TINYINT DEFAULT 0 COMMENT '0-普通用户 1-管理员', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; -- 商品表 CREATE TABLE `product` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `seller_id` BIGINT NOT NULL COMMENT '卖家ID', `title` VARCHAR(100) NOT NULL, `description` TEXT, `category` VARCHAR(30) DEFAULT NULL, `start_price` DECIMAL(10,2) NOT NULL COMMENT '起拍价', `current_price` DECIMAL(10,2) DEFAULT NULL COMMENT '当前最高价', `start_time` DATETIME DEFAULT NULL, `end_time` DATETIME NOT NULL COMMENT '拍卖截止时间', `status` TINYINT DEFAULT 0 COMMENT '0-待审核 1-拍卖中 2-已成交 3-已流拍 4-已下架', PRIMARY KEY (`id`), KEY `idx_seller` (`seller_id`), KEY `idx_status_endtime` (`status`, `end_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='拍卖商品表'; -- 出价记录表 CREATE TABLE `bid_record` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `product_id` BIGINT NOT NULL, `user_id` BIGINT NOT NULL, `bid_price` DECIMAL(10,2) NOT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_product` (`product_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='出价记录表'; -- 订单表 CREATE TABLE `orders` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `product_id` BIGINT NOT NULL, `buyer_id` BIGINT NOT NULL, `seller_id` BIGINT NOT NULL, `final_price` DECIMAL(10,2) NOT NULL, `status` TINYINT DEFAULT 0 COMMENT '0-待付款 1-已付款 2-已完成 3-已取消', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_buyer` (`buyer_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

导入SQL后，顺手写条验证语句确认数据进去了，别到启动时报Table doesn't exist才知道表没建上：

SELECT COUNT(*) FROM `user`;

说明一下为什么用utf8mb4而不是utf8：商品描述里经常有人写Emoji表情，utf8存不了4字节字符，会直接报错。这是个很隐蔽的坑，很多人Debug半天都没想到是字符集的问题。外键我建议只在逻辑上保留字段关联，不建物理外键，理由是在线拍卖有频繁的并发写入，物理外键在批量操作时会拖慢性能，用应用层保证完整性就好。这一点和教学里的范式设计不太一样，但更贴近生产习惯。

3. 本地把工程跑起来：JDK、Maven、MySQL 8的配置与启动顺序

3.1 JDK版本和Maven构建

启动之前先做好三个环境变量的检查。第一，JDK的版本要和Spring Boot匹配，建议JDK 8；第二，Maven要用3.6以上版本，太低会不认Spring Boot 2.7的插件；第三，JAVA_HOME必须指向你解压的JDK路径，而不是IDEA自带的JBR（JetBrains Runtime）。很多新手在这一步出问题，明明点运行的是“18”，结果强行走JDK 17编译，报一堆莫名的错。

确认完后，在IDEA里打开工程，等待Maven下载依赖。注意第一个坑是Maven仓库可能在国内拉包慢，我一般直接换阿里云镜像，在settings.xml里加这一段，属于政治正确且绝对有效的常规操作：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>Aliyun Maven Mirror</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

依赖下载完成后，如果是在命令行构建，用这个命令打包：

mvn clean package -DskipTests

这个命令里-DskipTests的意思是跳过单元测试，只打包。打包完成后target目录下会生成一个campus-auction-0.0.1-SNAPSHOT.jar的jar包。如果你只是想快速启动，也可以直接在IDEA里运行主类CampusAuctionApplication，效果一样，但先走一遍命令行构建能确认工程没有隐藏的编译依赖问题。

3.2 启动Spring Boot服务的两种方式和端口修改

五一类的老式做法是直接在IDEA里右键运行，但这样只能看到控制台日志，不容易模拟部署环境。无论是用哪种方式，启动时如果看到Tomcat started on port(s): 8080这行日志，就说明服务起来了。如果端口被占用，比如你电脑上有其他程序占了8080，会在日志里看到端口冲突的报错。这时有两个选择：关掉占用程序，或者在配置文件里改端口。

server: port: 8080

如果改了8081端口，注意前端页面的请求地址也要跟着改，否则会产生一个很尴尬的场景——后端在8081，前端却还在请求8080，登录接口全是404。在这个系统里，前后端通常一起打包放在static目录下，不涉及跨域问题，但改端口后要确认所有访问链接都保持一致。

3.3 数据库连接自检：连接不上时先看这四行日志

Spring Boot启动时报数据库连接错误，是新手遇到最多的故障之一。典型的错误信息是Access denied for user 'root'@'localhost'或者Communications link failure。前者说明账号密码不对或者MySQL没开远程访问权限，后者说明MySQL服务根本没启动，或者端口不是3306。

我自己的排查套路是这样的，也是写给自己备忘用的：

# 检查MySQL服务状态（Windows/Linux通用思路） mysqladmin -u root -p status # 测试能否连上数据库 mysql -u root -p -e "SELECT VERSION();"

如果命令行能连上，但Spring Boot连不上，问题通常出在配置文件的URL写法上。注意看localhost:3306这一段，别多写空格，也别把密码带中文引号。如果是从压缩包里直接解压的MySQL 8，初始化后默认密码是随机生成的，在data目录下的.err日志里能找到，但更常见的做法是直接用以下命令重置为指定密码：

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456'; FLUSH PRIVILEGES;

注意这个mysql_native_password是MySQL 8为了兼容旧客户端加的一个插件。你的系统如果是用caching_sha2_password，Spring Boot连接驱动版本不够旧也会报错，所以很多源码包都会建议用mysql_native_password兜底，但若驱动是8.x以上，直接保持默认加密方式加上allowPublicKeyRetrieval=true就能连上，不必强改加密规则。

3.4 首次启动成功的验证清单

不能说日志里没报错就算成功了。我把“跑起来”拆成了四个验证步骤，缺一步都不算启动成功：

第一，打开浏览器访问http://localhost:8080，能看到登录页面，且页面样式加载正常；第二，用SQL里预设的管理员账号登录，能进到商品管理页面；第三，注册一个新用户，数据库中user表新增了一条记录，且密码是加密存储的（不是明文）；第四，创建一个拍卖商品并设置截止时间，在外网用手机访问同一个页面也能看到这个商品。前三条是基础，第四条尤其重要，很多人只在localhost下看过效果，换了局域网IP访问就发现CSS全丢，那是因为前端资源写了绝对路径，这个细节对答辩演示来说杀伤力极大。

4. 核心业务逻辑：登录鉴权、上拍、出价与定时关单

4.1 基于JWT的用户登录：为什么不用Session

校园拍卖系统涉及买卖双方，需要区分管理员和普通用户，所以登录鉴权是第一个核心点。传统的Java Web教学项目习惯用Session存登录态，但这里建议用JWT——因为它无状态，前端存Token，后端不用记录会话，部署到服务器后也不需要考虑Session共享问题。

登录接口的逻辑是：接收用户名和密码，用BCryptPasswordEncoder验证密码，验证通过后生成一个带用户ID和角色信息的Token返回给前端：

@Service public class AuthService { @Autowired private UserRepository userRepository; @Autowired private JwtUtil jwtUtil; private final BCryptPasswordEncoder encoder = new BCryptPasswordEncoder(); public String login(String username, String rawPassword) { User user = userRepository.findByUsername(username); // 用户不存在或密码不匹配，统一报错，避免暴露哪个账号存在 if (user == null || !encoder.matches(rawPassword, user.getPassword())) { throw new BusinessException("用户名或密码错误"); } // 生成有效期24小时的Token return jwtUtil.generateToken(user.getId(), user.getRole()); } }

这段代码里有两个容易被忽略的细节。第一，密码校验用的是matches方法，不是equals，因为数据库里存的是BCrypt哈希串，每次加密的盐不同，直接比字符串永远比不出相等结果；第二，用户不存在和密码错误必须抛同一个异常，否则接口就成了账号枚举器，别人可以靠报错提示来试探哪个学号已注册。生成Token时把role放进去，后续接口用拦截器解析Token判断是否有管理员权限，比每次查数据库要高效得多。

4.2 商品上架：状态机设计取代拍脑袋写if

商品表里的status字段是整个系统最核心的状态机。新手会在这里犯一个典型错误：把状态搞成一个散落的int，每个Service方法都是“根据情况改状态”，最后发现商品可以从“已成交”跳回“待审核”，整个系统的数据可信度就崩了。

正确做法是把状态流转固定死：

待审核(0) -> 拍卖中(1) -> 已成交(2) -> 已流拍(3) 待审核(0) -> 已下架(4)

管理员审核通过后，商品才进入拍卖中状态，同时记录开始时间；到达截止时间后，如果有最高出价就生成订单置为已成交，否则置为已流拍。这个状态机的判断集中在AuctionService里，任何对状态的改动都走对应方法，禁止在Controller里直接setStatus。

商品创建接口和审核接口可以这样实现：

@Service public class AuctionService { @Transactional public void createProduct(Product product, Long sellerId) { product.setSellerId(sellerId); product.setStatus(ProductStatus.PENDING.getCode()); // 新增时把当前价格初始化为起拍价 product.setCurrentPrice(product.getStartPrice()); productRepository.save(product); } @Transactional public void approve(Long productId, Long adminId) { Product product = getProductById(productId); // 只有待审核状态才能审核通过 if (product.getStatus() != ProductStatus.PENDING.getCode()) { throw new BusinessException("当前状态不可审核"); } product.setStatus(ProductStatus.AUCTIONING.getCode()); product.setStartTime(new Date()); productRepository.save(product); } }

这里用@Transactional的原因是“修改状态+写入时间”必须是一个原子操作，任何一步失败都要整体回滚，不能出现状态改成拍卖中但起始时间为空的脏数据。New手上路时最容易犯的错是忘了加这个注解，最后出价记录和商品状态不一致，查半天还怀疑是MySQL的问题。

4.3 出价逻辑：事务加行锁，防止超卖和低价竞拍

出价是拍卖系统的灵魂，也是并发控制的核心考点。常见面试会问：两个用户同时出价，最终价应该取哪个？如果不用锁，两个请求同时读到当前价100元，一个出101，一个出102，后提交的会覆盖先提交的，最后价变成102，但出价记录里却有两条101和102的记录，那101的用户就白白被覆盖了。

正确的服务层实现是这样的：

@Service public class BidService { @Autowired private ProductRepository productRepository; @Autowired private BidRecordRepository bidRecordRepository; @Transactional public void bid(Long productId, Long userId, BigDecimal price) { // 悲观锁锁定商品行，防止并发下两个出价同时读到旧价格 Product product = productRepository.findByIdForUpdate(productId); if (product.getStatus() != ProductStatus.AUCTIONING.getCode()) { throw new BusinessException("商品不在拍卖中"); } if (price.compareTo(product.getCurrentPrice()) <= 0) { throw new BusinessException("出价必须高于当前价"); } if (new Date().after(product.getEndTime())) { throw new BusinessException("拍卖已截止"); } product.setCurrentPrice(price); productRepository.save(product); BidRecord record = new BidRecord(); record.setProductId(productId); record.setUserId(userId); record.setBidPrice(price); bidRecordRepository.save(record); } }

注意这里的关键是findByIdForUpdate，它对应JPA里的@Lock(LockModeType.PESSIMISTIC_WRITE)或Mapper里的SELECT ... FOR UPDATE。这段SQL执行后，这一行商品记录会被锁住，直到事务提交，期间其他事务更新同一行都会被阻塞。使用行锁避免并发冲突，是这个项目里最有亮点的功能，答辩时候很容易出彩。但它的前提是productRepository操作的是同一个数据库同一个表，如果你把代码拆成两个库或者两个表，锁就不生效了，这点务必注意。

4.4 定时关单：Spring Task与兜底扫描双保险

拍卖到达截止时间后，系统需要自动把“拍卖中”改成“已成交/已流拍”并对已成交商品生成订单。实现方式有几种：拿Timer写死循环、用Quartz、用Spring自带@Scheduled。最推荐@Scheduled，它不需要额外引入依赖，Spring Boot本身就内置支持。

@Component public class AuctionScheduler { @Autowired private ProductRepository productRepository; @Autowired private OrderService orderService; // 每30秒扫描一次已截止但仍处于拍卖中的商品 @Scheduled(fixedRate = 30000) @Transactional public void closeExpiredAuctions() { List<Product> expiredList = productRepository.findExpiredAuctioning(new Date()); for (Product product : expiredList) { BidRecord latestBid = bidRecordRepository.findTopByProductIdOrderByBidPriceDesc(product.getId()); if (latestBid != null) { orderService.createOrder(product.getId(), latestBid.getUserId(), latestBid.getBidPrice()); product.setStatus(ProductStatus.SOLD.getCode()); } else { product.setStatus(ProductStatus.FAILED.getCode()); } productRepository.save(product); } } }

这里的关单逻辑有几个细节要说明。第一，扫描间隔定为30秒，是因为拍卖截止时间没有精确到秒的价值，30秒内的延迟对学生线下交易场景毫无影响；第二，查询条件是end_time < now AND status = 1，所以必须给(status, end_time)建复合索引，否则这张表数据量一大，扫描就会拖慢其他操作；第三，找“最高出价”我写的是按价格降序取第一条，这是为了可读性，如果用SQL的MAX函数也可以，效果相同。注意这里没有人工干预“关单后再追加出价”的逻辑，如果你要做得更严谨，可以再加一个状态校验：拍卖结束后，新出价一律触发“拍卖已截止”提示，而不是直接拒绝，这样前端能给出更友好的反馈。

4.5 订单生成：事务里同步扣减库存还是发消息之后再处理？

小型系统里我建议直接用同步事务，不做MQ。原因是出价记录已经落库，生成订单只是查记录加插入一条数据，操作量很小，没有异步的必要。MQ只在峰值流量极高时才需要考虑，校园拍卖这种日活几百的场景，引入消息队列只会增加部署和排错成本。

因此，OrderService.createOrder里的逻辑就是：校验商品是已成交状态、校验买家不是卖家本人——别小看这条，很多人忘了加，最后出现卖家自己拍下自己的商品，虽然后端能查到，但逻辑上非常丢分——然后插入一条订单记录，初始状态为待付款。这里也顺带提醒一句：为避免一门课设里出现“两个订单对应同一个商品”，product_id字段在orders表里应该加UNIQUE约束作为双保险。

5. 避坑：部署与演示最容易翻车的7个现场

5.1 数据库连接报SSL错误：别改驱动，先看URL参数

现象：Spring Boot启动时直接报SSL connection error或者Communications link failure，MySQL客户端能连上但Java连不上。原因：MySQL 8.0默认开启SSL，而你的连接URL里没有关闭选项，驱动在和服务器握手时失败。解决：在JDBC URL末尾加useSSL=false，顺手加上allowPublicKeyRetrieval=true。这个参数只影响连接握手，不影响数据加密要求，放心加。

5.2 时区报错导致商品上下架时间多了8小时

现象：商品截止时间明明设置的是当晚12点，实际关单却在第二天早上8点执行。原因：MySQL的JDBC连接里没有指定serverTimezone，默认取的是服务器零时区，而你的机器是东八区，时间源不同源。解决：URL里加serverTimezone=Asia/Shanghai，同时确认MySQL所在机器时区也是同样设置，或者MySQL连接后执行SET time_zone = '+8:00'看是否能对上。

5.3 前端页面能打开但接口全部404

现象：浏览器能打开登录页，但点登录后一直是转圈或弹“请求失败”。原因：前端请求了错误的后端地址，常见是写了http://localhost:8080，但你的后端实际跑在8081，改端口后前端没同步。解决：前端代码里找baseURL或axios.defaults.baseURL，改成和server.port一致；如果前后端同端口部署，直接改成相对路径/api。这个坑在我手上踩过的次数不下三次，血泪经验。

5.4 文件上传图片能存不能显示

现象：商品图片上传成功，数据库里有路径，但页面上图片裂了。原因：图片被保存到了本地绝对路径如D:/upload/xxx.jpg，而网页只能访问工程的静态资源目录，你存的路径不在Spring Boot的静态资源映射范围里。解决：在配置里加一个本地资源映射，把/upload/**映射到你的图片存放目录：

spring: web: resources: static-locations: file:D:/upload/

或者用代码注册一个WebMvcConfigurer，addResourceHandlers方法里把/upload/**映射到file:${upload.path}。注意这个方案只是演示级别的，真实云服务器上应该上对象存储，但课设阶段映射成本地目录完全够用，答辩被问也能接得住。

5.5 系统跑起来但数据库表结构对不上

现象：明明导入了SQL，但点击某个功能时报“字段不存在”或“Unknown column”。原因：ddl-auto是update，Hibernate在你运行期间自动修改了表结构，可能加了字段也可能改了类型，最后和你的代码对不上。解决：开发阶段可以用update，但导入完成、功能验证无误后，把ddl-auto改成none或者validate，锁住表结构。尤其在答辩前，一定要改。

5.6 删除用户时外键报错

现象：管理员想删除一个测试用户，结果MySQL报外键约束失败，删除不了。原因：你建表时用了物理外键，而用户表被商品表引用。解决：在删除前先处理关联数据，或者在建表时干脆只保留逻辑外键不加物理约束。我前面建表语句就没加物理外键，就是为了一劳永逸地避免这种问题。

5.7 演示时突然白屏，控制台报静态资源404

现象：刚才还好好的，突然页面打不开，刷新后CSS全丢。原因：多半是你改动了target目录下打包好的静态资源，或者把static文件夹放在了错误位置。解决：始终确保前端资源放在src/main/resources/static下，每次修改后重新mvn clean package。如果用了Vue打包再嵌入Spring Boot的思路，注意Vue的publicPath必须设为相对路径./，否则打包出来的JS加载不到。这个细节在“vue打包放进springboot中”的热搜里反复出现，可见踩的人真的很多。

6. 验证与上线：从接口自测到答辩展示的完整收尾

6.1 用curl自测核心接口，不用打开页面也能验证

系统开发到后期，很多问题出现在“浏览器里点起来没问题，但接口实际返回的字段和前端预期不一致”。我给一个后端自测的命令集合，直接用curl跑一遍核心接口，省去开前端调试的时间：

# 登录，拿到Token curl -X POST http://localhost:8080/api/auth/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"123456"}' # 创建商品（把上一步返回的token替换到下面） curl -X POST http://localhost:8080/api/products \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{"title":"考研数学全书","startPrice":20.00,"endTime":"2025-06-30 20:00:00"}' # 模拟出价 curl -X POST http://localhost:8080/api/bids \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{"productId":1,"price":25.00}'

这三条命令能验证核心链路是否通畅。注意看返回状态码：200是正常，401说明Token失效，500说明后端异常——去查控制台报错，而不是去前端打断点。

6.2 答辩前自测清单，按这个顺序过一遍

我习惯在答辩前一天按顺序做一轮完整回归，防止现场翻车。第一，注册一个全新账号走完整流程：注册→登录→上架商品→等待管理员审核→自己出价→到达截止时间后查看是否生成订单；第二，测试边界情况：出价低于当前价会被拒、拍卖结束后出价会被拒、重复登录旧Token是否还能访问受保护接口；第三，把MySQL服务手动停掉，再访问页面，看报错是否友好——如果直接暴露一堆堆栈信息，说明异常处理还有遗漏；第四，用手机连同一个局域网访问服务，确认静态资源和接口都正常，这一步能暴露所有绝对路径写死的问题。

6.3 备份数据库，给演示上一个后悔药

演示最怕的就是现场数据被搞乱，或者某次操作后数据库状态不对。我最后的习惯是演示前先导出一份干净数据库备份，把拍卖商品调成一个马上要到达截止时间的状态，让评委能看到定时关单的自动执行过程。备份命令很简单：

mysqldump -u root -p campus_auction > backup_before_demo.sql

恢复时执行：

mysql -u root -p campus_auction < backup_before_demo.sql

如果现场把数据搞乱了，一条命令还原，心态完全不慌。这个操作十分钟内能搞定，但给你的安全感是巨大的。另一个建议是：把spring.jpa.show-sql改成false，演示时控制台不要刷出一大堆SQL，那场面看起来很像没清理干净的调试代码，印象分瞬间减半。

6.4 上线的安全收尾：改默认密码、关调试信息、锁表结构

毕业后想把这个系统挂到公网服务器上作为作品展示，有三件事必须做：把MySQL的root密码换成强密码，同时新创建一个业务账号，只授权campus_auction库，给根账号设置网络访问白名单；application.yml里server.address不设成0.0.0.0就固定内网访问，如果要公网演示，至少把密码和Token密钥换成复杂字符串，别用代码里的默认值；把ddl-auto改成validate，并确认启动时能通过校验，防止Hibernate乱动表结构。这三件事做完，这个项目才能从“能跑”变成“能拿得出手”。

最后说说我自己的习惯：每次拿到新的源码包，我不会先急着跑起来，而是先花半小时把表结构和状态流转画出来，理解清楚再动代码。因为校园拍卖系统这类课设源码，业务本身不复杂，最大的优势是结构清晰、流程完整。如果你只是跑通就交差，那收获极其有限；但如果你把它当作一个真实业务系统，把出价并发、定时关单、订单状态流转这几个点吃透，这个项目带给你的价值会远超一份PDF论文，甚至能在面试里完整地讲十分钟。希望帮到你。

本文还有配套的精品资源，点击获取