基于SpringBoot的校园二手交易平台：数据库设计与核心接口实现

简介这是一套基于SpringBoot框架的校园二手交易平台Java项目源码面向计算机相关专业高年级学生适用于课程设计、毕业设计及项目实战训练难度中等。系统采用模块化架构涵盖用户管理、商品展示、交易撮合、订单处理等核心模块技术栈包括SpringBoot 2.x、MyBatis Plus、Redis缓存与Shiro权限控制实现前后端分离数据库遵循第三范式使用MySQL存储前端为响应式布局支持多终端适配。资源包共262个文件约3.88MB包含34个java源文件、24个js脚本、17个html页面、7个css样式及xml配置、sql数据库脚本等另附系统设计说明书、数据库设计文档、部署指南与API接口文档。代码结构清晰、注释完整便于二次开发与功能扩展。目前已有80人学习下载适合需要完整项目参考与实战练习的学习者。1. 校园二手交易平台为什么 SpringBoot 是这类课设与副业项目的最优解每年毕业季宿舍楼下堆成小山的教材、台灯、自行车和新生群里刷屏的「求购二手显示器」构成了一个天然的双边市场。校园二手交易平台要解决的就是这个信息不对称问题让卖方三分钟挂出商品让买方按分类和关键词精准找到再通过站内沟通完成线下交割。它不像电商那样涉及支付和物流但用户体系、商品管理、订单状态流转、图片存储一个都不能少是一个麻雀虽小五脏俱全的 Java Web 项目。这也是为什么「基于 SpringBoot 的校园二手交易平台 Java 项目源码与数据库设计」常年霸占课程设计和 Java 面试项目经验的高频选题。SpringBoot 把传统 SSM 里繁琐的 XML 配置、Tomcat 部署、依赖版本冲突全部收进 starter 和自动配置让开发者能把精力放在业务表设计和接口逻辑上。对新手来说它是能跑通完整链路的第一个真实项目对熟手来说它是验证分页插件、全局异常处理、文件上传安全这些细节的练兵场。接下来我会按「数据库怎么设计 → 后端怎么搭 → 接口怎么写 → 坑在哪」的顺序把一套可复现的方案讲透。2. 数据库设计从用户信息表到订单状态机的表结构落地2.1 校园二手场景下需要哪几张核心表很多同学一上来就打开 Navicat 建表结果写到一半发现订单表没法关联商品快照或者用户表缺少学院字段导致无法按校区筛选。校园二手交易平台的表设计要围绕「人、货、单、聊」四条线展开常见做法是拆成七张表用户表、商品分类表、商品表、商品图片表、订单表、收藏表、留言/私信表。其中用户表是地基对应热搜里提到的「数据库表设计 - 用户信息表」它决定了后续所有业务的外键关系。用户表不要只放账号密码。校园场景下学号、学院、校区、联系方式是筛选和信任建立的关键字段。学号可以唯一约束防止重复注册学院和校区用于商品列表的默认过滤联系方式在订单生成后才对交易双方可见。密码字段必须存 BCrypt 哈希而不是明文长度给到 60 位以上因为 BCrypt 输出固定 60 字符。下面这张表是我一般会用的用户表结构字段类型和索引都经过实际查询验证。字段名类型约束说明idBIGINT主键自增用户唯一标识student_noVARCHAR(20)唯一非空学号登录账号passwordVARCHAR(100)非空BCrypt 哈希nicknameVARCHAR(30)非空昵称collegeVARCHAR(50)可空学院campusVARCHAR(30)可空校区phoneVARCHAR(20)可空联系方式avatarVARCHAR(255)可空头像 URLstatusTINYINT默认 11 正常 0 封禁create_timeDATETIME默认当前时间注册时间商品表的设计有个容易被忽略的点价格用 DECIMAL(10,2) 而不是 FLOAT因为浮点数在金额比较时会出现 0.10.2 不等于 0.3 的玄学问题。商品状态用 TINYINT 枚举表示1 在售、2 已售、3 下架。订单表则要记录商品快照也就是下单时的商品标题和价格防止卖家事后改价导致纠纷。订单状态机建议用 0 待确认、1 已确认、2 已完成、3 已取消四个状态状态流转只能单向推进取消操作要判断当前状态是否允许。2.2 建表 SQL 与索引设计把上面的设计落成可执行的 SQL注意字符集统一用 utf8mb4否则用户昵称里的 emoji 会插入失败。索引方面商品表的 campus 和 status 组合查询频率最高建联合索引订单表的 buyer_id 和 seller_id 分别建索引因为「我买到的」和「我卖出的」是两个高频列表页。-- 用户表校园场景核心字段 CREATE TABLE user ( id BIGINT NOT NULL AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL COMMENT 学号登录账号, password VARCHAR(100) NOT NULL COMMENT BCrypt哈希, nickname VARCHAR(30) NOT NULL, college VARCHAR(50) DEFAULT NULL, campus VARCHAR(30) DEFAULT NULL, phone VARCHAR(20) DEFAULT NULL, avatar VARCHAR(255) DEFAULT NULL, status TINYINT DEFAULT 1 COMMENT 1正常 0封禁, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_student_no (student_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 商品表价格用DECIMAL状态用TINYINT CREATE TABLE product ( id BIGINT NOT NULL AUTO_INCREMENT, seller_id BIGINT NOT NULL, category_id INT NOT NULL, title VARCHAR(100) NOT NULL, description TEXT, price DECIMAL(10,2) NOT NULL, campus VARCHAR(30) DEFAULT NULL, status TINYINT DEFAULT 1 COMMENT 1在售 2已售 3下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_campus_status (campus, status), KEY idx_seller (seller_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表记录商品快照状态单向流转 CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, product_id BIGINT NOT NULL, buyer_id BIGINT NOT NULL, seller_id BIGINT NOT NULL, snapshot_title VARCHAR(100) NOT NULL COMMENT 下单时商品标题, snapshot_price DECIMAL(10,2) NOT NULL COMMENT 下单时价格, status TINYINT DEFAULT 0 COMMENT 0待确认 1已确认 2已完成 3已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_buyer (buyer_id), KEY idx_seller (seller_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;执行顺序上先建 user 再建 product 和 orders因为后两者有外键依赖逻辑。参数说明DECIMAL(10,2) 表示总共 10 位、小数 2 位最大能存 99999999.99足够校园商品定价。联合索引 idx_campus_status 的顺序不能反因为查询条件里 campus 是等值匹配、status 也是等值匹配但 campus 区分度更高放前面能更快缩小范围。如果后续要加全文搜索再单独给 title 建 FULLTEXT 索引不要和普通索引混用。3. SpringBoot 工程搭建依赖选型与分层结构3.1 用 Spring Initializr 生成骨架时勾哪些依赖打开 IDEA 的 Spring Initializr或者用 start.spring.io 网页版Java 版本选 8 或 11 都行SpringBoot 选 2.7.x 这个稳定分支。热搜里有人提到「springboot版本太高」确实 3.x 要求 Java 17 且部分旧教程的 javax 包名改成了 jakarta新手跟着老视频做容易在导入包时翻车。所以课设和练手项目我一般建议锁 2.7.x等把整套链路跑通再考虑升级。依赖勾选清单Spring Web 提供 REST 接口能力MyBatis Framework 做数据库映射MySQL Driver 连接数据库Lombok 减少 getter/setter 样板代码Spring Boot DevTools 做热部署。文件上传不需要额外依赖Spring Web 自带 MultipartFile 支持。如果要加登录鉴权再补一个 jjwt 或者用 Session 方案校园项目用 Session 足够不必上 Spring Security 增加复杂度。生成后的目录结构要按分层来组织controller 层只做参数校验和响应封装service 层写业务逻辑和事务mapper 层对应数据库操作entity 放实体类dto 放前端传参对象vo 放返回给前端的视图对象。很多课设源码把逻辑全塞在 controller 里后期加一个「取消订单要恢复商品状态」的需求就得改三处这就是分层没做好的代价。3.2 application.yml 的关键配置与连接池参数配置文件里数据库连接、MyBatis 映射、文件上传大小限制是三块必须调的地方。连接池用 SpringBoot 默认的 HikariCP它比老牌的 Druid 轻量校园项目的并发量完全够用。下面这份配置可以直接抄注意把 url 里的库名和账号密码换成自己的。server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/campus_trade?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: your_password hikari: maximum-pool-size: 10 # 校园项目10个连接足够 minimum-idle: 2 connection-timeout: 30000 servlet: multipart: max-file-size: 5MB # 单张商品图上限 max-request-size: 20MB # 一次最多传4张 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.campus.trade.entity configuration: map-underscore-to-camel-case: true # 下划线转驼峰参数说明serverTimezone 必须显式指定否则 MySQL 8 驱动会报时区错误这是新手最常见的启动失败原因。map-underscore-to-camel-case 开启后数据库的 create_time 会自动映射到实体的 createTime省去手写 resultMap。maximum-pool-size 不要盲目调大校园项目日活几百人10 个连接绰绰有余调太大反而浪费数据库资源。文件上传限制要和前端的上传组件提示保持一致否则用户传 6MB 图片时前端不报错、后端抛异常体验很差。4. 核心接口实现商品发布、分页查询与订单状态流转4.1 商品发布接口与图片上传的落盘策略商品发布是写操作里最复杂的一个因为它同时涉及商品表插入和图片表批量插入必须放在同一个事务里。图片存储有两种常见做法存本地磁盘路径或者存对象存储。校园项目没有云资源预算我一般用本地磁盘按日期分目录存放避免单目录文件过多导致 ls 卡顿。上传接口先保存文件拿到 URL再把 URL 列表随商品信息一起提交。PostMapping(/product/publish) Transactional(rollbackFor Exception.class) public Result publish(RequestBody ProductPublishDTO dto, HttpServletRequest request) { // 从Session取当前登录用户 User user (User) request.getSession().getAttribute(loginUser); if (user null) { return Result.fail(请先登录); } // 参数校验标题、价格、分类必填 if (dto.getTitle() null || dto.getPrice() null) { return Result.fail(标题和价格不能为空); } Product product new Product(); product.setSellerId(user.getId()); product.setTitle(dto.getTitle()); product.setPrice(dto.getPrice()); product.setCategoryId(dto.getCategoryId()); product.setCampus(user.getCampus()); product.setStatus(1); productMapper.insert(product); // 插入后product.getId()回填 // 图片URL列表批量入库 if (dto.getImages() ! null !dto.getImages().isEmpty()) { for (String url : dto.getImages()) { ProductImage img new ProductImage(); img.setProductId(product.getId()); img.setUrl(url); imageMapper.insert(img); } } return Result.success(product.getId()); }逻辑说明Transactional 保证商品插入和图片插入要么全成功要么全回滚避免出现商品存在但没有图片的脏数据。rollbackFor 指定 Exception 而不是默认的 RuntimeException是因为文件 IO 异常属于受检异常不指定的话事务不会回滚。参数说明ProductPublishDTO 是前端传参对象只包含 title、price、categoryId、images 四个字段不要直接用 Product 实体接收否则前端可以伪造 sellerId 和 status。图片上传接口单独写一个 /upload/image返回可访问的 URL前端拿到后再调发布接口。4.2 商品列表分页查询与 MyBatis 分页插件列表页是读操作里压力最大的必须分页。热搜里提到「mybatis的分页插件的用法 springboot」这里用 PageHelper 最省事。引入 pagehelper-spring-boot-starter 依赖后在查询前调 PageHelper.startPage(pageNum, pageSize)紧跟其后的第一条查询会自动被拦截改写。注意 startPage 只对最近一次查询生效中间不能插入其他查询语句。public PageInfoProductVO listProducts(ProductQuery query, int pageNum, int pageSize) { PageHelper.startPage(pageNum, pageSize); // 紧跟其后的查询才会被分页 ListProductVO list productMapper.selectByCondition(query); return new PageInfo(list); }对应的 XML 查询要动态拼条件校区、分类、关键词都是可选的。关键词用 LIKE CONCAT(%, #{keyword}, %)不要用字符串拼接防止 SQL 注入。参数说明pageNum 从 1 开始pageSize 建议限制在 20 以内前端传 1000 的话要在 controller 层拦截否则一次查全表会拖垮数据库。PageInfo 返回的 total、pages、list 三个字段前端分页组件直接能用。4.3 订单状态流转与并发下单的防重订单状态流转要写成状态机不能随便改。买家下单时商品必须是「在售」状态下单成功后商品变「已售」防止同一商品被两个人同时买走。这里有个并发问题两个请求同时读到商品状态为 1都执行更新就会产生两个订单。解决办法是用乐观锁更新时带上 status 条件。// 下单乐观锁防止并发重复下单 int rows productMapper.updateStatusById(productId, 2, 1); // 目标状态2原状态1 if (rows 0) { throw new BizException(商品已被抢购或已下架); } // 更新成功才创建订单 Order order new Order(); order.setOrderNo(generateOrderNo()); order.setProductId(productId); order.setBuyerId(buyerId); order.setSellerId(product.getSellerId()); order.setSnapshotTitle(product.getTitle()); order.setSnapshotPrice(product.getPrice()); order.setStatus(0); orderMapper.insert(order);逻辑说明updateStatusById 的 SQL 是 UPDATE product SET status #{newStatus} WHERE id #{id} AND status #{oldStatus}数据库行锁保证只有一个请求能更新成功返回影响行数为 0 就说明被别人抢先了。参数说明generateOrderNo 用时间戳加随机数生成保证唯一即可校园项目不需要分布式 ID 方案。订单取消时要把商品状态改回 1同样用乐观锁且只有 status 为 0 的订单才能取消。5. 避坑与排查校园二手项目最容易翻车的五个地方5.1 图片上传后访问 404现象文件上传成功数据库也存了 URL但前端 img 标签加载不出来。原因SpringBoot 默认不会把本地磁盘目录映射成静态资源路径上传的文件虽然在磁盘上但 HTTP 请求找不到。解决写一个 WebMvcConfig 实现 WebMvcConfigurer重写 addResourceHandlers把上传目录映射到 /upload/** 路径。Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { // 把磁盘路径映射为HTTP可访问路径 registry.addResourceHandler(/upload/**) .addResourceLocations(file: System.getProperty(user.dir) /upload/); } }注意 addResourceLocations 的路径必须以 file: 开头且以斜杠结尾Windows 下路径分隔符要统一处理否则映射不生效。5.2 跨域请求被浏览器拦截现象前端用 Vue 跑在 5173 端口后端跑在 8080调接口时报 CORS 错误。原因浏览器同源策略限制协议、域名、端口任一不同就跨域。解决在后端加全局跨域配置或者在 controller 上加 CrossOrigin。全局配置更省事写一个 CorsFilter 或者实现 WebMvcConfigurer 的 addCorsMappings。Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowCredentials(true) .maxAge(3600); }注意 allowedOriginPatterns 和 allowCredentials 同时使用时不能用 allowedOrigins(*)否则会报错这是 Spring 的安全限制。5.3 事务不生效导致数据不一致现象商品发布时图片插入失败但商品记录已经进库了。原因Transactional 注解失效常见于方法被同类内部调用、方法不是 public、异常被 catch 吞掉。解决确保注解方法为 public同类调用要注入自身代理或者把方法拆到另一个 servicecatch 块里如果要回滚必须重新抛出异常。5.4 分页查询总数不对现象PageHelper 分页后 total 始终等于当前页条数。原因startPage 之后执行了多条查询或者返回的 list 被重新包装过。解决startPage 必须紧贴目标查询中间不能有其他 mapper 调用如果 service 里做了数据转换要保证 PageInfo 包装的是原始 mapper 返回的 list。5.5 学号重复注册未拦截现象同一个学号能注册两次。原因数据库加了唯一索引但代码里没捕获 DuplicateKeyException或者注册前只查了一次、并发下两个请求都查到不存在。解决依赖数据库唯一索引兜底service 层 catch DuplicateKeyException 返回友好提示不要只靠 select 判断。6. 进阶技巧用接口文档和压测把项目从能跑变成能讲项目能跑通只是及格线面试或答辩时真正拉开差距的是你能不能讲清楚接口设计和性能边界。我一般会加两个东西Swagger 接口文档和一轮简单压测。Swagger 用 springfox 或者 knife4j引入依赖后加一个配置类controller 上的注解会自动生成在线文档前端同学不用再追着你要接口说明。压测用 JMeter 或者 ApacheBench对商品列表接口发 500 个并发请求观察响应时间和错误率。验证项工具合格标准不达标先查接口文档完整性knife4j所有接口有参数说明controller 注解是否遗漏列表接口响应JMeter 500 并发平均响应 500ms索引是否命中、分页是否生效下单并发安全JMeter 100 并发无超卖、订单数正确乐观锁条件是否带上原状态文件上传手动传 5MB 图成功且可访问大小限制和资源映射压测时重点看数据库慢查询日志如果商品列表在 500 并发下平均响应超过 500ms大概率是 campus 和 status 的联合索引没命中用 EXPLAIN 看一下执行计划type 出现 ALL 就说明全表扫描了。另一个技巧是把热门分类的商品列表加一层本地缓存用 Caffeine 或者简单的 ConcurrentHashMap设置 60 秒过期能扛住大部分重复查询。最后说个血泪经验数据库设计阶段多花两小时想清楚状态流转和快照字段比后期改表加字段省两天。我见过太多项目因为订单表没存商品快照卖家改价后买家投诉无门最后只能加字段做数据迁移。把用户表、商品表、订单表这三张的地基打牢后面加收藏、加私信、加评价都是顺水推舟的事。希望帮到你。本文还有配套的精品资源点击获取