SpringBoot3+Vue3校园旧书漂流系统：状态流转与预约并发实现

校园旧书漂流交易系统放在 Java 技术栈里最典型的实现是SpringBoot3 提供后端接口Vue.js3 提供前端页面MySQL 负责把用户、书本和订单记录持久化。这个题目真正值得做的点不是把增删改查写完而是让一本旧书从发布、浏览、预约、线下交接、确认完成再到下一次被上架的整个过程都有清晰状态和可查记录。适合正在做 JavaWeb 课程设计、想练全栈项目的人如果你想把这个项目写进简历也要优先把“书的状态流转”和“重复预约并发处理”讲清楚而不是只强调页面多漂亮。下面我按实际落地的顺序拆一遍先聊业务设计再讲表结构和后端接口接着给 Vue3 前端实现思路最后补运行步骤和常用的排查顺序。全程不追求大而全只保证按这个思路能把旧书漂流的主流程跑起来。1. 先想清楚旧书漂流和普通二手商城差在哪1.1 “漂流”不是换了一个名字而是多了一条时间线很多项目把旧书做成普通二手商品用户上传图片、标价、下单、支付流程结束。这种系统叫二手交易平台没问题但叫“漂流”就不太准确。“漂流”的核心特征是同一本书可以在不同学生之间连续流通。大三学生用完高等数学教材卖给大二学生大二学生用完之后又可以在学期末重新上架继续传给下一个人。系统不能只记录一次交易还要能回答一个问题这本书之前被谁持有过经过几次流转当前状态是什么。所以我的建议是不要一开始就把数据表按“商品表 订单表”这种常规电商模型建。要提前给每本实体书一个稳定的记录标识在书表里保存当前持有人、当前状态和可读的流转记录。1.2 核心业务流程应该覆盖哪些环节如果要做一个可演示、可答辩、可往简历上写的系统至少要把下面的主流程走通学生注册登录校内学号作为账号密码做加密存储。学生发布旧书填写书名、作者、ISBN、教材类别、价格、笔记程度、封面和使用说明。其他学生通过关键词或分类搜索到这本书。二手书不需要线上支付重点是“预约”和“线下交接确认”。买家确认拿到书后系统把书本当前持有人改成买家。买家以后可以把自己的书再次上架让书继续漂流。在这个流程里用户、书本、订单、漂流记录是系统的主干。点赞、收藏、评论、管理后台都是加分项但不是决定项目能否成立的部分。2. 这套技术组合的真正版本卡点JDK、Node 和 MySQL82.1 SpringBoot3 最低要求 JDK17SpringBoot3 和 SpringBoot2 最大的区别之一就是基础运行环境从 JDK8 切换到了 JDK17。如果你本机还只装了 JDK8直接创建 SpringBoot3 项目会遇到UnsupportedClassVersionError或者启动直接失败。所以在开始项目之前先确认环境java -version mvn -version node -v mysql --version我实际看到比较多的情况是JDK 装了 8 和 17 两个版本但 IDEA 或命令行里没有把 JDK17 设置为默认或者 Maven 的JAVA_HOME还指向 JDK8。SpringBoot3 项目启动报版本问题时第一反应不是重装依赖而是看JAVA_HOME是否真的指向 JDK17。如果你只能使用 JDK8那就不要硬上 SpringBoot3老老实实退回 SpringBoot2.x。这不是技术退步是环境约束下的正确选型。2.2 Vue3 前端建议用 Vite setup 语法Vue3 项目使用 Vite 构建已经是常见选择。创建项目时可以直接执行npm create vitelatest frontend -- --template vueVue3 页面我建议统一使用script setup语法代码比 Options API 短很多而且更适合把页面拆成多个小组件。如果你的电脑 Node 版本偏旧Vite 可能会在npm run dev时直接提示版本不支持。安装依赖后第一件事不是写页面而是先跑起一个初始页面确认前端脚手架本身没问题。2.3 MySQL 8.0 和连接串细节MySQL 用 8.0 比较省心。字符集在建库时直接设置为utf8mb4避免中文乱码。数据库名可以叫campus_book。如果你本机没有现成 MySQL也可以先用 Docker 起一个临时 MySQL 8 容器做开发。但课设提交时最好把启动命令和初始化脚本都写清楚不然别人想复现你的项目会卡在数据库环境上。3. 表结构设计先建四张核心表再谈页面和接口3.1 用户、书、订单、漂流记录怎么关联我建议把数据库表分成四张主表加一张可选收藏表t_user用户/学生信息。t_book每本实体书的当前状态和当前持有人。t_book_order每次预约或交接记录。t_book_flow这本书每次被发布、预约、完成、取消的轨迹。t_favorite可选收藏不在核心流程内。t_book和普通二手商品表最大的不同是字段里要有一个owner_id表示“当前持有人”。订单完成后不是把书删掉而是更新owner_id为买家状态改成“已售出”。这样一本书的主键可以一直稳定存在所有漂流记录都挂在同一个book_id上。下面是简化版初始化 SQL可以作为起步结构CREATE DATABASE IF NOT EXISTS campus_book DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE campus_book; CREATE TABLE t_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL UNIQUE COMMENT 学号/登录账号, password VARCHAR(100) NOT NULL COMMENT BCrypt加密后的密码, nickname VARCHAR(30) NOT NULL, campus VARCHAR(50) COMMENT 校区或学院, phone VARCHAR(20), role TINYINT NOT NULL DEFAULT 1 COMMENT 1学生 2管理员, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_book ( id BIGINT PRIMARY KEY AUTO_INCREMENT, book_no VARCHAR(40) NOT NULL UNIQUE COMMENT 书本编号用于展示漂流轨迹, owner_id BIGINT NOT NULL COMMENT 当前持有人, title VARCHAR(100) NOT NULL, author VARCHAR(50), publisher VARCHAR(80), isbn VARCHAR(20), category VARCHAR(30) COMMENT 如高数、英语、计算机, original_price DECIMAL(10,2), price DECIMAL(10,2) NOT NULL, book_condition TINYINT NOT NULL DEFAULT 2 COMMENT 1全新 2较新 3有笔记 4有破损, cover_url VARCHAR(255), description TEXT, status TINYINT NOT NULL DEFAULT 1 COMMENT 1在售 2已预约 3已售出 4已下架, view_count INT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_owner (owner_id), KEY idx_status (status), KEY idx_category (category) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_book_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(40) NOT NULL UNIQUE, book_id BIGINT NOT NULL, seller_id BIGINT NOT NULL COMMENT 发布人/当前持有人, buyer_id BIGINT NOT NULL COMMENT 预约人, status TINYINT NOT NULL DEFAULT 1 COMMENT 1待交接 2已完成 3已取消, complete_time DATETIME, cancel_reason VARCHAR(255), create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_book (book_id), KEY idx_buyer (buyer_id), KEY idx_seller (seller_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_book_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, book_id BIGINT NOT NULL, from_user_id BIGINT COMMENT 原持有人首次发布可为空, to_user_id BIGINT COMMENT 到达人, action VARCHAR(20) NOT NULL COMMENT PUBLISH/RESERVE/CONFIRM/CANCEL, remark VARCHAR(255), create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_book_time (book_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;第一版不需要把字段铺得非常大。重点是把owner_id、status和book_flow建好后面做状态流转和轨迹查询时会少走很多弯路。3.2 状态不要散在代码里要建统一字典旧书从发布到最后再次漂流会经过多个状态。实际编码时最容易出的问题是每个开发者在不同地方写不同的魔法数字前端又猜含义。建议在建表文档或后端常量类里统一定义。我用的状态值可以这样约定t_book.status含义可执行动作1在售可被搜索、预约2已预约不能被其他人预约3已售出订单完成等待新主人重新上架4已下架卖家中途取消或管理员下架订单表状态对应t_book_order.status含义可执行动作1待交接等待双方线下交书2已完成已完成交接书本持有人改变3已取消预约取消书回到在售状态前后端约好这些状态码接口返回给前端时前端只需要做一次映射查询表不需要在页面里到处写if (status 3)。3.3 为什么不建议滥用真实外键课程设计里常见做法是用ManyToOne/OneToMany和真实外键。如果团队已经约定好必须用 JPA那没问题。但如果是带订单流转的业务表我更建议只保留逻辑关联不建物理外键。原因是订单状态变更时经常要同时更新书表、插入流水表真实外键容易造成锁竞争也会让批量操作和测试数据清理变得麻烦。面试时被问到“为什么不用物理外键”可以回答业务状态由应用服务和事务控制物理外键会影响扩展性和性能最终以逻辑外键维护一致性。4. 后端核心流程发布、预约、交接和再次上架4.1 后端目录结构建议无论用 MyBatis-Plus 还是 Spring Data JPA目录结构都不建议把 Controller 写得特别厚。一个可维护的 SpringBoot3 项目结构可以是这样src/main/java/com/campus/book ├── BookApplication.java ├── common │ ├── Result.java │ ├── BusinessException.java │ └── GlobalExceptionHandler.java ├── config │ ├── WebConfig.java │ └── SecurityConfig.java ├── controller │ ├── AuthController.java │ ├── BookController.java │ └── OrderController.java ├── service │ ├── BookService.java │ └── OrderService.java ├── mapper │ ├── UserMapper.java │ ├── BookMapper.java │ └── BookOrderMapper.java ├── entity │ ├── User.java │ ├── Book.java │ ├── BookOrder.java │ └── BookFlow.java └── dto ├── LoginDTO.java ├── BookPublishDTO.java └── OrderConfirmDTO.javaController 里只做参数接收和结果包装真正的校验、状态判断、事务在 Service 层。这不是洁癖而是后续调试和扩展的刚需。4.2 发布旧书时的接口设计核心接口只需要先做这些方法地址说明POST/api/auth/register学生注册POST/api/auth/login登录并返回 tokenGET/api/books分页搜索书列表GET/api/books/{id}书本详情和漂流轨迹POST/api/books发布一本书POST/api/books/{id}/orders预约下单POST/api/orders/{id}/complete确认完成交接POST/api/orders/{id}/cancel取消预约POST/api/books/{id}/relist当前持有人再次上架发布书的时候要注意owner_id从当前登录用户取不要从前端传。宁可后端自己从 token 或 Session 中解析用户也不要在提交参数里让前端随便传userId。这个点虽然不是业务难点但写进简历时可以在“权限控制”部分提一句。4.3 预约下单防止两个学生同时约到同一本书旧书交易和电商下单最像的部分就是同一本书不能被两个人同时预约。如果只是先查状态判断状态是“在售”然后插入订单高并发时会出现两个用户都查到“在售”同时下单成功的情况。更稳妥的做法是在事务里锁定这本书的行或者使用条件更新。示意代码Transactional public Long createOrder(Long bookId, Long buyerId) { // 1. 锁定书行避免并发读到同一个可售状态 Book book bookMapper.selectByIdForUpdate(bookId); // 2. 核心校验 if (book null) { throw new BusinessException(书本不存在); } if (book.getOwnerId().equals(buyerId)) { throw new BusinessException(不能预约自己发布的旧书); } if (!BookStatus.ON_SALE.equals(book.getStatus())) { throw new BusinessException(这本书当前不可交易); } // 3. 生成订单号 String orderNo BK System.currentTimeMillis() RandomUtil.randomNumbers(4); // 4. 插入订单 BookOrder order new BookOrder(); order.setOrderNo(orderNo); order.setBookId(bookId); order.setSellerId(book.getOwnerId()); order.setBuyerId(buyerId); order.setStatus(OrderStatus.WAIT_DELIVERY.getCode()); bookOrderMapper.insert(order); // 5. 更新书本状态为“已预约” book.setStatus(BookStatus.RESERVED.getCode()); bookMapper.updateById(book); // 6. 写入漂流记录 bookFlowMapper.insert(BookFlow.builder() .bookId(bookId) .fromUserId(book.getOwnerId()) .toUserId(buyerId) .action(BookFlowAction.RESERVE) .remark(发起预约) .build()); return order.getId(); }这段代码的关键是selectByIdForUpdate。它在事务内锁定对应行另一个用户再执行同样的查询时只能等第一个事务结束。只有等到预约成功的人把状态改成“已预约”后面的人进来才能看到“不可交易”。如果不想用行锁也可以直接用更新语句UPDATE t_book SET status 2 WHERE id #{bookId} AND status 1判断返回值大于 0再插入订单。这种方式在单表单行场景下很有效也适合大多数课设。4.4 确认交接更新当前持有人并写入轨迹线下交易不需要太复杂的支付回调。最简单的方式是买家拿到书后在订单列表里点“确认收到”后端做两个操作把订单状态改成“已完成”记录完成时间。把t_book.owner_id改成买家把t_book.status改成“已售出”同时在t_book_flow写一条CONFIRM记录。如果担心买家乱点可以让卖方也确认一次或者用一个取书码。对于课程设计来说先做“买方确认”就能把流程闭环。不要为了模拟真实电商强行引入微信支付或支付宝支付复杂度会瞬间起来。4.5 再次漂流功能它是这个项目的点睛笔当一本书状态为“已售出”且当前持有人是登录用户时详情页要出现一个“再次上架”按钮。用户点击后价格、描述、新旧程度可以重新填写然后后端把owner_id保持不变status从“已售出”改成“在售”并生成一条新的PUBLISH漂流记录。这一步做出来后整个系统的业务含义就和普通二手商城彻底区分开了。面试官问到“为什么要单独建book_flow表”你就可以很自然地解释同一本书会有多轮漂流从一本书被首次发布开始到最后可能存在多个订单和多次转让记录光靠订单表不能回答“这本书目前到谁手里了”。5. Vue3 前端页面要按业务流而不是按接口堆5.1 页面与路由怎么拆先别急着写几十个组件。先把页面按用户操作路径拆分登录/注册页学号、密码、昵称。书墙首页搜索栏、分类 tab、书本卡片列表。发布页旧书表单重点突出新旧程度和教材类别。图书详情页书本信息、当前状态、漂流轨迹、预约按钮。我的漂流页我发布的、我买到的、我预约中的订单列表。个人中心页头像、昵称、联系方式。对应路由可以设计成/login /register / /book/:id /publish /orders /profile“我的漂流页”是这个项目比较值得讲清楚的地方。它不是简单做两个列表而是要把“我发布的书”“我约到的书”“我买到的书”合并考虑。用户关心的不只是订单状态更关心某本书现在到谁手里了、后面还能不能再次上架。5.2 前端的接口请求层建议单独封装在实际项目里我见过很多把axios.get直接写在页面里的写法。如果是 5 个小页面勉强能忍一旦加登录、刷新 token、权限提示就会到处补代码。建议创建src/api/http.js统一封装 Axios 实例import axios from axios const http axios.create({ baseURL: /api, timeout: 10000 }) http.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) http.interceptors.response.use( response response.data, error { if (error.response error.response.status 401) { localStorage.removeItem(token) window.location.href /login } return Promise.reject(error) } ) export default http页面里再按业务模块拆api/book.js、api/order.js每个模块只导出对应接口函数。后期调整接口路径时只需改一个文件比在页面里逐个改更省事。5.3 前端不要把状态码硬编码得到处都是后端返回的status是数字或字符串前端最好抽一个常量映射。比如src/constants/bookStatus.jsexport const BOOK_STATUS { 1: { text: 在售, type: success }, 2: { text: 已预约, type: warning }, 3: { text: 已售出, type: info }, 4: { text: 已下架, type: danger } }页面里只通过映射取文案和标签颜色。这样后端换状态名时只用改一处前端也不会到处都是难以维护的if (status 2)。6. 本地运行步骤从数据库到前后端启动6.1 MySQL 初始化和数据准备先启动 MySQL执行上面的建表 SQL。执行方式可以用 Navicat、DataGrip 或命令行mysql -u root -p schema.sql执行之后用 SQL 查一下表是否存在SHOW TABLES;这一步能更早暴露数据库连接、权限、表名大小写等问题。如果项目里配置了spring.jpa.hibernate.ddl-autoupdate也要先手动建库不要让 Hibernate 在第一次启动时帮你创建一堆省略了索引的表。6.2 后端配置和启动后端配置文件建议放在src/main/resources/application.yml基础配置类似server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/campus_book?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: your_password如果你的 MySQL 用户使用的是caching_sha2_password认证连接串里加上allowPublicKeyRetrievaltrue可以避免部分连接时报Public Key Retrieval is not allowed。启动后端cd backend mvn spring-boot:run如果项目里带了 Maven Wrapper也可以./mvnw spring-boot:run看到类似Started BookApplication的日志再继续下一步。6.3 前端启动前端项目单独放在frontend目录cd frontend npm install npm run dev如果本地有多个 Node 版本启动前先确认当前 Node 版本。不要在前端依赖都没装完时急着调后端接口否则会把“安装失败”误判成“代码问题”。在开发阶段可以在vite.config.js里配置代理把/api转发到后端 8080 端口import { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样前端请求/api/books时浏览器访问的是 Vite 的 5173 端口再由 Vite 代理转发到后端能省掉不少开发环境的跨域配置。6.4 联调验证顺序完成启动后不要直接开始点随机功能。我一般会按这个顺序验证浏览器打开前端首页确认页面能渲染。注册一个测试学生账号。登录成功后发布一本“测试教材”。退出当前账号再注册另一个账号。第二个账号在书墙搜索到这本书进入详情点击预约。第一个账号在订单列表里看到订单状态。第二个账号确认收到后查看书本状态是否变成“已售出”。第二个账号再次点击“再次上架”确认书墙能搜到这本书。这一套能通过核心业务就算闭环了。后面的收藏、评论、管理后台都是在这个主流程上做加法。7. 实际开发中最容易踩的坑和排查顺序7.1 SpringBoot3 启动失败优先查 JDK 和依赖启动失败日志是最直接的。常见错误有UnsupportedClassVersionError说明编译或运行版本不匹配检查 JDK 版本。ClassNotFoundException: com.mysql.cj.jdbc.Driver说明 MySQL 驱动没引入或者用了旧版本驱动。Invalid value type for attribute factoryBeanObjectType通常是 SpringBoot 3 和 MyBatis 老版本插件冲突升级 MyBatis 相关依赖版本。排查顺序应该是先看第一行异常是什么再去查依赖版本不要一看到BeanCreationException就觉得是业务代码问题。7.2 前端能启动但请求不到数据先看网络面板浏览器里按下 F12看 Network 里的请求请求有没有发出。请求地址是不是/api/books或正确的后端地址。状态码是不是 401、403、404、500。响应 JSON 里的message是什么。如果是 404大概率是接口路径或代理前缀不匹配。如果是 500再去后端控制台看异常。很多联调问题不是后端代码完全不能跑而是前端访问的地址和后端接口路径对不上。7.3 数据库乱码、时区、连接失败出现中文乱码时按顺序检查建库字符集是否为utf8mb4。连接串有没有characterEncodingutf8。请求和响应是否都设置了 UTF-8。MySQL 表本身是否已经是正确的字符集。出现时区相关报错可以在连接串里加serverTimezoneAsia/Shanghai。出现连接失败先确认 MySQL 服务启动了没有、端口是不是 3306、用户名密码是否正确不要直接怀疑代码。7.4 业务层的隐性 bug下单成功后状态没更新有一种很隐蔽的问题订单插入成功但book.status没从“在售”改成“已预约”。原因是有些开发者把bookMapper.updateById(book)写成了bookMapper.insert(book)或者实体里status字段没有被 MyBatis-Plus 正确映射。验证方法很简单查询数据库SELECT id, title, owner_id, status FROM t_book WHERE id 1; SELECT id, order_no, book_id, buyer_id, status FROM t_book_order WHERE book_id 1;如果数据库状态和后端返回不一致优先查实体映射和更新语句不要反复在前端调试。8. 想让项目从“能跑”升级到“像作品”优先做哪些扩展8.1 封面图上传旧书交易和普通商品一样封面图很重要。第一版可以直接用 URL 或上传到本地目录但如果要放服务器运行更好的方式是把图片传到对象存储服务并限制文件大小和图片格式。课设阶段可以先把图片上传接口做成单文件接口返回一个可访问 URL再在发布页表单里回显预览。8.2 消息提醒当用户发布的旧书被别人预约时原持有人需要尽快知道。传统做法是给订单页加红点也可以用一个简单的站内信表记录“谁预约了你的书”“订单已完成”“书本再次上架成功”等消息。这个功能不复杂但对演示效果提升很大因为用户能看到系统在主动通知操作结果。8.3 书单收藏和浏览记录收藏功能可以做成t_favorite表记录用户和书的关系。浏览记录则可以在详情接口里把view_count 1不需要额外建表。这个扩展很容易实现也能让首页推荐稍微有一点数据依据。8.4 补基础测试很多课程设计项目没有测试这其实是可以拉开差距的地方。不需要写特别多至少把最核心的“预约书”服务测试补上。测试时可以考虑三种场景正常学生预约一本“在售”的书能成功。同一本书被预约后再被第二个学生预约第二次失败。用户不能预约自己的书。这类业务逻辑测试写起来不复杂但问“这个项目有什么难点”时你能拿出可复现的测试会比单纯说“我做了预约功能”可信很多。8.5 面试时要能讲清楚的技术点如果这个项目最后写进简历建议把注意力集中在以下问题旧书状态为什么这样设计为什么要有独立漂流记录表怎么防止同一本书被多人重复预约订单确认时书本持有人怎么变化前端为什么用 Pinia 或 Vuex 保存登录状态如果并发量大这个系统的瓶颈会在哪每一条都不需要说得很玄能结合自己的表和代码讲清楚就行。比起“我用了最新技术”面试官更想听到的是你理解一个业务状态如何被数据模型和事务正确表达。最后一个建议不要在第一版就把所有网红功能都塞进去。先把一本书从发布到再次漂流的闭环跑稳让界面上的状态和数据库记录完全一致这个项目就比大多数只堆页面的旧书系统要耐看很多。