简介：面向高校学生的大学校园二手书籍拍卖系统微信小程序项目，针对校园二手书交易不便、信息分散等问题，采用Java+Spring Boot作为后端，微信小程序作为用户端，Vue后台管理端配合，以MySQL存储数据，覆盖注册登录、书籍发布、在线竞拍、订单支付等核心环节，适合毕业设计、课程项目及Java/小程序开发进阶参考。压缩包共1301个文件，包含139个Java后端源码、155个Vue管理端组件、54个wxml页面、54个wxss样式、237个js脚本、284个png及50个jpg图片、1个sql数据库脚本和项目功能介绍文档，整体仅19.32MB，目录划分清晰，便于按模块查阅学习。该项目已有2727人学习浏览，在同类毕设中具备良好参考热度。除完整可运行源码与数据库脚本外，还附带项目介绍文档，且经过严格调试，可在JDK1.8、Tomcat7+、MySQL5.7+下稳定运行；通过该项目可深入理解Spring Boot接口开发、小程序前后端交互，以及拍卖系统中出价、竞拍、订单流转等业务逻辑的实现，适合直接作为毕设基础进行二次开发与答辩展示。

1. 校园二手书从「摆摊」到「拍卖」：这个 springboot 系统在解决什么

每学期结束，大学宿舍楼下的二手书摊把《高等数学》按斤称，三块钱一本，新生开学又得花五十块买全新正版。基于微信小程序的大学校园二手书籍拍卖系统，就是把这件线下撮合的事搬到微信里：卖方拍照发布起拍价，买方在详情页里出价，到点截拍，最高价者生成订单。业务主体是一套 springboot 工程，controller、service、mapper 三层结构，MySQL 里存书、存出价记录、存订单。这套东西适合做毕业设计和课程设计，也适合社团或院系在校园里跑一个真实的图书流转试点。和闲鱼式一口价相比，拍卖模式对教材这种「行情不稳定、供需随时变」的商品反而省事——不用反复改价，让出价的人自己把价格喊出来。

2. 先拆清三层结构：小程序端、springboot 服务端、MySQL 数据模型

2.1 为什么是 springboot + 微信小程序，而不是 uni-app 或纯 H5

做校园二手书拍卖，第一反应可能是 uni-app，一套代码跑小程序和 H5，听起来省事。但真落地后你会发现，uni-app 封装层在你使用wx.request、chooseMedia、getPhoneNumber这些原生能力时，会多一层要去对文档的翻译成本，出了问题不好定位；而且这类课设、毕设项目，评审人最常问的是「并发出价怎么处理、表怎么设计、为什么拍卖能成交」，这些和跨端框架没关系，把精力放在服务端才是正事。纯 H5 的问题更明显：学生在微信里点开一个 H5 链接的意愿，远低于从「最近使用的小程序」里点开一张卡片；分享一本《线性代数》给室友，小程序卡片比网址直观得多。uniapp 小程序打包还有一个常见毛病：页面和组件堆多了以后，主包体积很容易超过 2MB，真机预览时不停地删代码降体积，这对一个以信息展示为主的系统来说完全没有必要。

所以这套标题里的组合——微信小程序做前端、springboot 做后端——是这类系统最常见也最省心的路线。它不是玄学，是两边生态都成熟：小程序端只管 UI 和调接口，springboot 负责出价规则、截拍任务、订单状态这些脏活。springboot 项目结构也相对固定，按controller → service → mapper → entity → config分包，这是从图书借阅管理系统到拍卖系统都通用的脚手架写法：

src/main/java/com/campus/bookauction/ ├── controller/ │ ├── BookController.java # 发布、出价、列表 │ ├── OrderController.java # 订单查询、确认收货 │ └── WechatController.java # 登录换 openid ├── service/ │ ├── BookService.java # 发布校验 + 出价事务 │ └── AuctionTask.java # 定时截拍 ├── mapper/ │ ├── BookMapper.java │ ├── BidRecordMapper.java │ └── OrderMapper.java ├── entity/ │ ├── Book.java │ ├── BidRecord.java │ └── Order.java └── config/ ├── WechatConfig.java # appid / secret 注入 └── WebConfig.java # 拦截器、CORS

这个结构不需要一上来就套微服务。校园场景一学期几千本书，单机加单库完全扛得住，拆微服务只会让部署时多踩几个坑。controller只做参数接收和返回包装，别把出价规则写在 controller 里，否则后面加定时截拍时，你会发现同一套规则要在两个地方维护，改漏一个就是线上翻车。

提示：先按这个官方推荐分层写，等代码长到一定规模再拆更细的包。很多二手工程把 SQL 全写在 controller 里，这种代码是不敢直接拿去答辩的。

2.2 二手书籍拍卖的核心数据表：书籍、拍卖记录、订单、用户

先把用户表和书表立住。用户表用openid做唯一键，书表里冗余一个current_price字段，不算严格范式，但在拍卖场景下它能让「出价」变成一条 UPDATE，避免每次出价都去子查询最高价。这是刻意的反范式，值得写进设计说明里。

CREATE TABLE `user` ( `id` INT NOT NULL AUTO_INCREMENT, `openid` VARCHAR(64) NOT NULL COMMENT '微信 openid', `nickname` VARCHAR(64) DEFAULT '', `phone` VARCHAR(20) DEFAULT '', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `book` ( `id` INT NOT NULL AUTO_INCREMENT, `seller_id` INT NOT NULL COMMENT '发布人 user.id', `title` VARCHAR(128) NOT NULL, `author` VARCHAR(64) DEFAULT '', `publisher` VARCHAR(128) DEFAULT '', `original_price` DECIMAL(10,2) DEFAULT 0, `start_price` DECIMAL(10,2) NOT NULL COMMENT '起拍价', `current_price` DECIMAL(10,2) NOT NULL COMMENT '当前最高出价', `bid_count` INT NOT NULL DEFAULT 0, `image_url` VARCHAR(255) DEFAULT '', `start_time` DATETIME NOT NULL, `end_time` DATETIME NOT NULL, `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0 竞拍中 1 已截拍 2 已成交 3 流拍', PRIMARY KEY (`id`), KEY `idx_status_end_time` (`status`, `end_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

idx_status_end_time是给每分钟截拍任务用的索引，没有它，当书表到了几万本时定时任务会扫全表，MySQL 的 CPU 直接被打满。图书借阅管理系统的书表通常只要一个status表示「在馆/借出」，而拍卖系统的书表需要一整套竞拍状态机，这是两类系统在设计上最明显的分叉点。

出价记录单独建表，这是拍卖系统和普通交易系统最大的区别：

CREATE TABLE `bid_record` ( `id` INT NOT NULL AUTO_INCREMENT, `book_id` INT NOT NULL, `user_id` INT NOT NULL, `bid_price` DECIMAL(10,2) NOT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_book_id` (`book_id`, `bid_price`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `orders` ( `id` INT NOT NULL AUTO_INCREMENT, `book_id` INT NOT NULL, `buyer_id` INT NOT NULL, `seller_id` INT NOT NULL, `deal_price` DECIMAL(10,2) NOT NULL, `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0 待付款 1 已付款 2 已发货 3 已完成', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_book_id` (`book_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

为什么拍卖记录不能只存最高价？因为截拍后要回溯「最后一分钟谁出了价」，如果只存一个最高价，最后几秒的连续出价没法追溯；同一价格谁先出谁赢，只能靠bid_record.create_time排序。orders表上的uk_book_id唯一键是硬约束，保证一本书只能成交一次，这个约束比任何业务代码都可靠。到这里，四张表已经把一条拍卖闭环的主干搭完了。

2.3 小程序端 pages 目录的最小划分：首页、详情、发布、我的

小程序端不用一上来就堆十几个页面。经常见到有人把「公告」「意见反馈」「关于我们」全建上，结果 app.json 注册表越来越长，支付、登录、分包全挤在一起。核心链路只有四条：看列表、看详情出价、发布书、看我的订单。我一般会砍成下面这个最小划分：

pages/ ├── index/ # 首页：竞拍中列表、筛选 ├── detail/ # 详情：出价、倒计时 ├── publish/ # 发布：拍照、起拍价、截止时间 ├── mine/ # 我的：我发布的、我拍到的、我卖出的 │ └── order/ # 订单列表 ├── login/ # 登录 └── components/ └── countdown/ # 倒计时组件

新手最容易在「我的」页面里迷失，又是收藏、又是足迹、又是设置，但拍卖系统的「我的」只需要聚合三类数据：我发布的、我拍到的、我卖出的。每加一个新页面，都要回答「用户不挂在这个页面上，能不能完成核心动作」，答不上来就不建。倒计时组件单独抽出来，因为首页列表、详情页都会用，两个地方各写一份setInterval，后面改样式要改两处，纯属给自己挖坑。

3. 跑通「发布 + 出价 + 截拍」：最小接口与并发规则

3.1 服务端：BookController 与 BookService 的最小实现

发布接口没什么特别的，校验完参数就落库；出价接口才是拍卖系统的命门。先看 controller 层，注意userId不从请求体里拿，而是从拦截器放行的RequestAttribute里取：

@RestController @RequestMapping("/api/book") public class BookController { @PostMapping("/publish") public Result publish(@RequestBody Book book, @RequestAttribute("userId") Long userId) { book.setSellerId(userId); book.setCurrentPrice(book.getStartPrice()); book.setStatus(0); bookService.save(book); return Result.ok(book.getId()); } @PostMapping("/bid") public Result bid(@RequestBody BidDTO dto, @RequestAttribute("userId") Long userId) { int updated = bookService.placeBid(dto.getBookId(), userId, dto.getBidPrice()); if (updated == 0) { return Result.fail("出价未成功：价格过低或拍卖已结束"); } return Result.ok(); } }

BidDTO里只有bookId和bidPrice两个字段，不要接收userId和bookId以外的任何东西。然后是核心的 service 实现：

@Service public class BookService { @Autowired private BookMapper bookMapper; @Autowired private BidRecordMapper bidRecordMapper; @Transactional public int placeBid(Long bookId, Long userId, BigDecimal bidPrice) { int updated = bookMapper.updateCurrentPrice(bookId, bidPrice); if (updated == 0) { return 0; } BidRecord record = new BidRecord(); record.setBookId(bookId); record.setUserId(userId); record.setBidPrice(bidPrice); bidRecordMapper.insert(record); return 1; } }

出价的 SQL 是关键，它把「校验价格」和「更新价格」合并成了一条原子操作：

<update id="updateCurrentPrice"> UPDATE book SET current_price = #{bidPrice}, bid_count = bid_count + 1 WHERE id = #{bookId} AND status = 0 AND end_time > NOW() AND current_price < #{bidPrice} </update>

逻辑说明：两个同学同时出 15 元，A 先执行 UPDATE 成功，B 的语句因为current_price < 15不再成立，更新 0 行直接失败，不会再走后面的insert。这个乐观锁写法比 synchronized 或「先 SELECT 再 UPDATE」可靠得多，也省掉了事务里最容易出现的死锁。bidPrice用BigDecimal，不要用Double，拍卖价格精度和四舍五入是答辩时最喜欢追问的点。拦截器里把 openid 换成 user 表主键放进RequestAttribute，前端就不要传 userId 了，那是能被改的。

3.2 小程序端：wx.request 出价的标准写法

小程序的出价按钮，最重要的不是 UI 多好看，而是防重复点击。先在整个 app 里维护一个baseUrl：

// app.js App({ globalData: { baseUrl: 'http://192.168.1.100:8080/api' } });

详情页的出价方法：

// pages/detail/detail.js Page({ data: { bookId: '', currentPrice: 0, bidPrice: '', bidding: false }, placeBid() { const { bookId, currentPrice, bidPrice, bidding } = this.data; if (bidding) return; const price = Number(bidPrice); if (!price || price <= Number(currentPrice)) { wx.showToast({ title: '出价需高于当前价', icon: 'none' }); return; } this.setData({ bidding: true }); wx.request({ url: `${getApp().globalData.baseUrl}/book/bid`, method: 'POST', timeout: 10000, data: { bookId, bidPrice: price }, header: { 'Content-Type': 'application/json' }, success: (res) => { if (res.data.code === 0) { wx.showToast({ title: '出价成功', icon: 'success' }); this.refreshDetail(); } else { wx.showToast({ title: res.data.msg || '出价失败', icon: 'none' }); } }, fail: () => wx.showToast({ title: '网络请求失败', icon: 'none' }), complete: () => this.setData({ bidding: false }) }); } });

参数说明：bidding置灰是最重要的——连点两下出价，乐观锁会拦掉第二笔，但你先收到两个「处理中」的反馈，用户会以为系统卡了。timeout: 10000是 10 秒超时，食堂、图书馆这些角落信号差，默认 60 秒超时会让用户以为页面死了。success回调里res.data是服务端返回的 JSON，如果后端统一返回{code:0,data:{...}}，前端就只读res.data.code，不要一会儿res.data.data一会儿res.data混着读。baseUrl开发期用电脑局域网 IP，真机预览必须和电脑连同一个 Wi-Fi；上线前再换成 https 域名。

注意：不要把http://localhost写死在代码里，真机上 localhost 指的是手机自己，不是开发机。这大概是联调阶段最高频的错误。

3.3 起拍价、加价幅度、截止时间：参数设计的三个边界

拍卖系统最怕的是参数设计得花里胡哨，最后没人出价。教材这种标品，起拍价按原价的三到五折就够了：

拍卖周期不是越长越好。超过三天，学生早就忘了这本书；少于一天，看到消息的人还没掏手机就结束了。加价幅度建议在发布页做成下拉选择而不是输入框，让用户填「0.05」这种数字，只会制造脏数据。

截拍不能靠用户手动刷新，必须有个后台任务兜底。常见做法是 springboot 的@Scheduled做每分钟扫描：

@Component public class AuctionTask { @Scheduled(cron = "0 * * * * *") public void closeExpired() { List<Book> expired = bookMapper.findExpired(100); for (Book book : expired) { try { int updated = bookMapper.closeBook(book.getId()); if (updated == 0) continue; // 已被其他任务处理 BidRecord top = bidRecordMapper.findTopByBookId(book.getId()); if (top != null) { orderService.createFromAuction(book.getId(), top.getUserId(), top.getBidPrice()); } else { bookMapper.markFlop(book.getId()); } } catch (Exception e) { log.error("close auction failed, bookId={}", book.getId(), e); } } } }

逻辑说明：closeBook要用条件更新（UPDATE book SET status=1 WHERE id=? AND status=0 AND end_time<=NOW()），这样截拍任务和出价接口并发时，谁先执行谁成功，不会重复创建订单。定时任务内每本书包一层 try-catch，单本脏数据不能让整批任务停摆。findExpired(100)做分批拉取，避免一次捞几万本把内存撑爆。常见误用是自己在 controller 里开线程池跑截拍，JVM 一重启任务全丢，老老实实用@Scheduled。

4. 微信小程序接入 springboot 的避坑与排查：5 个高频翻车点

这类系统的业务代码其实不复杂，交付前的晚上往往都耗在联调上。下面 5 条按「现象 → 原因 → 解决」写，都是我反复见过的血泪经验。

4.1 真机上 wx.request 报错，开发者工具却一切正常

现象：开发者工具里点「预览」，手机打开后接口全挂，fail 回调里报request:fail，常见伴随errno 10002或 timeout；工具里同样的路径却能通。

原因：两个点。一是baseUrl用了http://localhost:8080，真机上的 localhost 是手机自己，不是电脑；二是微信对 request 合法域名有强校验，没在后台配置域名，或开发期没勾「不校验合法域名」。

解决：开发期把baseUrl换成电脑局域网 IP，在「详情—本地设置」里勾选「不校验合法域名」，这一步只影响开发工具和真机调试，不影响正式发布。上线前在小程序管理后台把 https 接口域名配置进 request 合法域名。排查时先在开发者工具的 Network 面板看请求是否发出，再看真机调试的 Console，基本五分钟内能定位是域名问题还是网络问题。

4.2 wx.login 换来的 openid 对不上，用户数据串号

现象：同一个人发布的书，换个手机登录后「我的发布」里看不到；更严重的，两个微信号出现互相看到对方订单。

原因：开发者工具里wx.login返回的是模拟 openid，真机上才是真实 openid；更常见的是前端每次需要登录态就调一次wx.login，而后端的session_key换一次就失效。还有直接把 openid 当成业务外键存到 book 表，不同环境下 openid 对不上。

解决：小程序启动时只调一次wx.login，把 code 发给后端换 openid；后端在 user 表里按openid查找或创建用户，返回自增主键 id；前端把 id 存进wx.setStorageSync，后续请求用 token 或 header 携带。后端拦截器用 token 还原 userId，而不是每个接口都传 openid。记住 openid 只是身份凭证，不是业务主键。

4.3 获取手机号：个人主体的小程序调不通

现象：照着旧教程写<button open-type="getPhoneNumber">，真机点击后拿不到手机号，回调里只有 errMsg，后端拿 code 去换也报错。

原因：微信在 2023 年后把手机号能力收紧了，只有完成认证的非个人主体小程序才能调用手机号快速验证组件，个人主体直接没有权限。另一个常见坑是旧接口的 code 必须由后端去换手机号，前端自己解密不了加密数据。

解决：先确认小程序主体资质。个人主体做校园项目，老老实实让用户手动输入手机号，或者干脆只用微信昵称和 openid；企业主体再用open-type="getPhoneNumber"，拿到 code 后由后端调官方接口换取手机号。换到的手机号只用于订单联系，不要打明文日志，更不要存到前端 storage。这个坑最容易在答辩前一天爆发，因为开发工具里权限校验不严格，真机上一测就翻车。

4.4 springboot 版本太高，javax 包全部标红

现象：下载的工程用 Spring Boot 3.x，本机 JDK 还是 8，启动直接报NoClassDefFoundError；或者照博客写拦截器、过滤器，一堆类 fromjavax.servletimport 不出来。

原因：Spring Boot 3.x 要求 JDK 17，并且命名空间从javax.*整体换成了jakarta.*。大量教程和模板停留在 2.x 写法，不是你的代码写错，是版本代差。

解决：这个项目直接用 Spring Boot 2.7.x 配 JDK 8 跑，是校园部署最常见也最不折腾的组合。如果确实要用 3.x，把拦截器、过滤器里的javax.servlet全部换成jakarta.servlet，MyBatis-Plus 至少用到 3.5.3 以上。排查时先执行mvn -v看 JDK 版本，再看mvn dependency:tree | grep spring-boot确认 parent 版本，两步就能判断是 JDK 问题还是依赖坐标问题。

4.5 自定义导航栏高度写死，iPhone 和安卓错位

现象：iPhone 上标题垂直居中，安卓上标题明显偏上，或者胶囊按钮压住了标题文字。

原因：状态栏高度和胶囊按钮在不同机型上不一样，写死 44px 或 64px 都会错。这也是「微信小程序顶部导航栏高度」每次被反复问的原因。

解决：用wx.getWindowInfo()拿statusBarHeight，用wx.getMenuButtonBoundingClientRect()拿胶囊按钮的位置，然后动态计算：

const windowInfo = wx.getWindowInfo(); const menuRect = wx.getMenuButtonBoundingClientRect(); const navBarHeight = (menuRect.top - windowInfo.statusBarHeight) * 2 + menuRect.height; const totalHeight = windowInfo.statusBarHeight + navBarHeight;

逻辑说明：navBarHeight是导航栏内容区的可视高度，totalHeight是包含状态栏的整条导航高度。小程序页面自定义导航栏时把这个值设置到style上，所有机型都是动态适配的，不用再为某个安卓机单独调样式。老基础库里wx.getWindowInfo()可能不存在，此时回退用wx.getSystemInfoSync()取同名字段。

5. 服务端打包与部署：从「本地能跑」到「真机能用」的 4 个参数

5.1 application.yml：端口、数据库连接池、时区

本地跑通不代表真机能用，部署阶段最先要看的就是配置文件。下面这一份是这类工程最常见的起步配置：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/book_auction?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 wx: appid: your_appid secret: your_secret

参数说明：serverTimezone=Asia/Shanghai必须写，否则 MySQL 驱动默认用 UTC，数据库里存的截止时间和小程序上显示的倒计时会差 8 小时，用户看到「还剩 2 分钟」，后端已经结束，这是最隐蔽的翻车点。HikariCP 的maximum-pool-size在校园一两百人同时使用时 20 足够，不需要调到 100，连接池不是越大越好，反而会拖垮 MySQL。wx.appid和wx.secret只能放服务端配置文件，绝不能写进小程序前端代码，secret 进了小程序包，别人反编译一下就拿到了。如果你用的是 MyBatis-Plus，逻辑删除、驼峰映射这些按自己工程实际配置为准，不要照抄网上不完整的片段。

5.2 定时截拍任务：先验证日志，再谈分布式

部署后第一件事不是立刻上线，而是确认截拍任务真的在跑。springboot 的@Scheduled默认是单线程调度，每分钟整点触发一次。查看日志：

# 确认截拍任务是否每轮都执行 grep "closeExpired" app.log | tail -20 # 查看是否有任务异常堆栈 grep "close auction failed" app.log | tail -20

逻辑说明：@Scheduled(cron = "0 * * * * *")的0 *表示每秒的第 0 秒触发，即每分钟一次；如果误写成0 0 * * * *，那是每小时整点跑一次，拍卖会延迟一小时截拍。生产环境单实例部署时，@Scheduled完全够用；如果哪天上了多实例，每个实例都会跑一遍截拍任务，虽然数据库条件更新保证不会重复生成订单，但通知消息会发两遍。到那时再考虑 ShedLock 或 xxl-job，校园项目起步阶段不需要为这个提前买单。

5.3 打 jar 与部署：mvn package、nohup、日志

这套系统内嵌了 Tomcat，直接打 jar 就行，不用打 war 塞进外部容器。常见做法是本地执行打包，然后用 scp 上传到服务器：

mvn clean package -DskipTests scp target/book-auction.jar root@your-server:/opt/app/ cd /opt/app nohup java -Xms256m -Xmx512m -jar book-auction.jar \ --spring.profiles.active=prod > app.log 2>&1 &

参数说明：-Xms256m -Xmx512m对这类项目足够，别一上来就是 1G，服务器内存还要留给 MySQL 和图片文件。--spring.profiles.active=prod对应application-prod.yml，里面放生产数据库地址和正式 appid，开发和部署共用一套 jar，只切换 profile，这是最不容易出错的配置方式。日志重定向到app.log，排查问题只用tail -100 app.log。如果你用宝塔面板的 Java 项目管理器，本质也是执行这个 jar 命令，但注意宝塔默认 JDK 版本，必要时在/etc/profile里显式配置 JDK 8 的JAVA_HOME。

5.4 上线前检查清单

与其上线后被用户告状，不如花半小时过一遍清单：

关于主体认证，个人主体的小程序不收费但能力受限，比如微信支付和手机号快速验证都不可用；企业主体需要按微信官方标准缴纳认证费，具体金额以官方说明为准，别信二手消息。校园项目如果只是试点，个人主体加手动输入手机号，完全能把流程跑通。

6. 让它从「能跑」变成「能验收」：三件小事和一个并发验证技巧

6.1 三件小事：轮询刷新、倒计时、数据统计

拍卖页最怕的情况是别人出价了，你这边的价格纹丝不动。最轻量的方案不是引入 WebSocket，而是每 5 秒轮询一次详情接口，离开页面时清掉定时器：

pollCurrentPrice() { clearTimeout(this._timer); this._timer = setTimeout(() => { wx.request({ url: `${getApp().globalData.baseUrl}/book/${this.data.bookId}`, success: (res) => { const data = res.data.data; this.setData({ currentPrice: data.currentPrice, bidCount: data.bidCount }); }, complete: () => this.pollCurrentPrice() }); }, 5000); }

轮询加一个「5 秒」的固定节奏，不要用while死循环。列表页再给每本书加一个秒级倒计时，到 0 自动置灰「本场已结束」。最后在「我的」页面统计三组数字：在拍、成交、流拍，这组数据能让答辩或汇报时把系统说成「完成实际交易闭环」，而不是只有增删改查。

6.2 一个验证技巧：两个账号同时出价

准备两个微信号，同一本书：A 先出 10 元，B 立刻出 15 元，再让 A 也出 15 元。最终期望是成交价 15 元、bid_count为 2 而不是 3、订单只有一笔。这一步验证的是乐观锁是否真的拦截了同价重复出价。另一个边界测试是把书的end_time设成一分钟后，等定时任务跑完，再查订单表，确认成交的是最高出价那本。这两个场景是整个系统里唯一真正需要「并发」的地方，也是老师最喜欢追问的地方，建议放在答辩前一周做。

6.3 一点交付习惯

我在交付这类源码工程时吃过最大的亏，是没在文档里写清楚「默认账号是什么、怎么改 appid、怎么导入数据库」。验收的人拿到工程第一句话往往不是「代码写得好不好」，而是「这个怎么跑起来」。我会在 README 里按顺序写：导入 SQL、改 application.yml、小程序后台配域名、开发者工具导入项目根目录、替换 appid，五步跑通。这个习惯比任何一个功能都值钱。

我自己在这个系统上翻过最大的车，是把 MySQL 时区漏配了，导致截拍时间整整早了一小时，用户在群里吵着说「还没到截止就被切了」。后来才明白，这类项目大多数问题根本不是 springboot 的代码逻辑，而是 JDK 版本、MySQL 时区、小程序域名三处环境对不上。三处一致，系统就顺了。希望帮到你。

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