Springboot校园二手交易平台：从技术选型到部署全解析

1. 从毕设选题到上线：这个校园二手交易平台到底解决了什么

每年到了毕设季，总有一批同学在"做什么题目"上反复横跳。管理系统太老套，电商项目又容易被评委追问"你的业务难点在哪"。我之所以对Springboot校园二手物品交易平台这个项目印象很深，是因为它天生自带一个合理的业务场景：高校校园里的闲置物品流转。教材、台灯、自行车、宿舍小冰箱，几乎每一届毕业生离校前都会留下一批成色不错的二手货，而新生入学时又恰好需要——这个供需关系天然成立，不需要编造伪需求。

从技术角度讲，这个项目的定位非常巧妙。它不是一个"玩具级"的CRUD，但又没有高到需要分布式、消息队列、缓存集群才能撑住。用Springboot做后端、MySQL存业务数据、Thymeleaf或Vue做前端渲染，整个技术栈正好踩在Java Web开发的经典路线上。你做的是二手交易平台，核心闭环是"发布商品—浏览检索—发起交易—订单管理—个人中心"，这套流程里既包含常规的增删改查，又涉及图片上传、状态流转、条件检索、会话管理等实用细节，拿去应付开题答辩、中期检查、毕业答辩，业务完整度和技术纵深都够用。

那标题里"955op"是啥意思？像这种编号往往代表项目的版本标识，你可以理解成这是一套开发完毕的成品项目，包含程序源码、数据库脚本、调试部署说明、开发环境配置，还附带一篇上万字的论文文档。对时间紧张的同学来说，它的价值在于"开箱即用"：不用从零搭框架，不用为数据库建表发愁，也不用挣扎在环境变量VUE_APP_BASE_URL报错里出不来——拿到手之后重点放在理解代码逻辑、跑通流程、按自己的想法改业务，这比空对空写一个PPT级别的毕设要踏实得多。

这篇博文我不会给你推荐什么神秘链接，我就以这套项目为样本，把它的技术选型逻辑、模块设计、环境搭建、部署调试、论文写作路线全部拆开讲一遍。你看完之后哪怕不碰这套源码，也能靠这份思路自己从零写一个同级别的项目出来。

2. 技术栈选型的理由：为什么Springboot+MySQL是这类项目的黄金组合

2.1 Springboot在这个项目里到底承担了什么

很多人一看到Springboot，第一反应是"它简化了配置"。这话对，但没有说到根子上。Springboot的本质是"约定大于配置"的自动化框架，它把Spring生态里那些繁琐的XML配置、Bean装配、依赖管理全部收敛成了starter机制。你在pom.xml里引入一个spring-boot-starter-web，内嵌的Tomcat、Spring MVC、Jackson序列化器就全给你配好了，application.yml里写几行数据源信息，跑起来就是一套web服务。

在校园二手交易平台里，Springboot承担的核心工作有四块：请求路由、业务逻辑编排、数据访问整合、异常统一处理。请求路由就是你定义@Controller或@RestController，把前端的每一个操作映射到对应方法上；业务逻辑编排是Service层里完成的，比如下单时需要同时检查商品状态、扣减库存、生成订单记录、清空购物车条目，这一串操作得是一个事务；数据访问整合靠的是MyBatis-Plus或Spring Data JPA，把SQL操作封装成接口方法；异常统一处理则是用@RestControllerAdvice捕获全局异常，返回统一格式的JSON。

2.2 为什么不用更"新潮"的架构

有同学会问：现在微服务这么火，Spring Cloud不香吗？Redis做缓存不是更快吗？我理解这种想上新技术的心情，但这个项目的场景决定了它不需要。校园二手平台的数据量级是"一个学校几千人"，不是"双十一全站秒杀"。单机单库跑这种业务绰绰有余，引入微服务反而会引入服务注册发现、配置中心、分布式事务这些和你业务没有直接关系的问题。毕业设计评委一眼就能看出来你是在炫技还是在解决业务问题。

MySQL同样如此。它在中小体量的OLTP场景下成熟可靠，社区资料多，Navicat和Workbench都能可视化操作，出了问题搜一下就是一堆解决方案。你想想如果你选了PostgreSQL或MongoDB，虽然它们也很好，但遇到莫名其妙的环境报错时，你身边能问的同学大概率也没用过，排查成本立刻上来了。

2.3 前端渲染方案：模板引擎还是前后端分离

这是这套项目在技术路线上最大的分岔口。

如果你用Thymeleaf，那么后端Controller返回的是一个包含了渲染后HTML的视图，所有页面逻辑都在服务端拼好。好处是项目结构简单，你只需要掌握一个Springboot工程就能搞定全部功能，对Java基础一般、前端功底薄弱的同学非常友好。坏处是页面交互不够丝滑，局部刷新要靠片段表达式或引入少量jQuery实现。

如果你用Vue+Springboot的前后端分离方案，那么后端只提供JSON接口，前端跑在Node构建的Vite/Webpack环境里。好处是交互体验好，接口风格贴近真实企业开发，简历上写起来也好看。坏处是你需要同时维护两个工程，要考虑跨域配置、Token鉴权、前端打包部署，整体工作量明显增加，排错的复杂度也会上升。

我的建议很直接：如果你的核心目标是顺利毕业、快速把系统跑通并讲清楚，选Thymeleaf；如果你有一到两个月的充裕时间，并且希望简历上多一个"前后端分离项目"的亮点，选Vue方案。这套"955op"项目的标配往往是Thymeleaf为主，因为它的设计目标就是让使用者快速上手、能改能跑。

3. 核心功能模块拆解：从普通CRUD到业务闭环

3.1 用户模块：不只是登录注册那么简单

用户模块是任何系统的基础，但二手交易平台的用户模块有它的特殊之处。除了常规的注册、登录、退出，这里还涉及两个关键的细节：角色区分和登录状态保持。

角色上，系统至少要有"普通用户"和"管理员"两种。普通用户负责发布闲置、购买商品、管理订单；管理员负责审核商品信息、处理违规用户、查看统计数据。在数据库设计上，用户表（t_user）里应该有一个role字段，用tinyint类型，0代表普通用户，1代表管理员。你不需要搞SpringSecurity那套复杂的权限框架，一个拦截器加一个权限判断就足够了——拦截器检查session或token里有没有用户信息，没有就重定向到登录页；在Controller方法上判断当前用户的role值，管理员接口只放行权限匹配的请求。

登录状态保持上有一个非常经典的坑：用HttpSession还是用JWT？如果做的是前后端不分离的Thymeleaf项目，直接用Session是省时省力的选择，服务端Session天然与Cookie联动，不需要额外处理跨域和Token刷新。如果做前后端分离，那就得用JWT或者Token+Redis的方案，前端每次请求在请求头里带Authorization字段，后端解析校验。很多同学在这个选择上犹豫不决，我的看法是跟着架构走，别两个都想要——混用Session和Token是最容易出bug的组合。

3.2 商品模块：表结构设计与查询优化

商品模块是整个平台的核心资产，表结构设计直接决定后续功能好不好写。推荐一张商品表（t_goods）包含以下核心字段：

code复制id            BIGINT        主键，自增
user_id       BIGINT        发布者ID，关联用户表
title         VARCHAR(100)  商品标题
description   TEXT          商品描述
price         DECIMAL(10,2) 价格
original_price DECIMAL(10,2)原价，用于展示折扣信息
category      VARCHAR(50)   分类：教材/数码/生活用品/其他
images        VARCHAR(500)  图片路径，多张用逗号分隔
status        TINYINT      0-在售 1-已售出 2-下架 3-审核中
view_count    INT           浏览量
create_time   DATETIME      发布时间
update_time   DATETIME      更新时间

我在这个表结构里重点强调几个容易被忽略的字段。images字段很多人喜欢建一张单独的商品图片表，从数据库理论上看"更规范"，但在实际业务中会增加查询复杂度。对于个人毕设级别的项目，用逗号分隔存储图片路径，前端拿到后split一下就能渲染轮播图，效率极高。status字段是业务状态机的基础，它的变化路径——"审核中→在售→已售出/下架"——直接对应了前后端展示逻辑，也是论文里能画状态图的核心素材。

商品列表的查询是整个平台最高频的操作。这里一定要考虑两个点：分页和条件组合。分页用MyBatis-Plus的内置分页插件，不需要手写limit计算。条件组合上，你至少要有三种组合方式：按分类筛选、按价格区间筛选、按关键词模糊搜索。MySQL的LIKE '%关键词%'在这种数据量下完全够用，不需要上Elasticsearch。但有一个细节必须注意：用MyBatis-Plus的LambdaQueryWrapper时，多个条件都要判空后再拼上去，不然用户没选分类时SQL会多出一个AND category = null，结果全查不出来。

3.3 交易模块：订单状态流转的设计思路

交易是二手平台和普通信息发布类网站最大的区别。一个完整的交易流程应该覆盖以下路径：买家浏览商品→点击"立即购买"或"加入购物车"→生成订单（订单状态：待支付）→模拟支付成功（订单状态：待发货或待确认）→卖家确认并完成线下交付（订单状态：已完成）；同时还要考虑买家和卖家都可以取消订单、超时未处理自动关闭订单等边界情况。

我建议在订单表（t_order）里设计这几个字段：

code复制order_no      VARCHAR(32)   订单编号，唯一
goods_id      BIGINT        商品ID
seller_id     BIGINT        卖家ID
buyer_id      BIGINT        买家ID
amount        DECIMAL(10,2) 订单金额
status        TINYINT       0-待支付 1-待确认 2-已完成 3-已取消 4-退款中
create_time   DATETIME      下单时间
pay_time      DATETIME      支付时间
finish_time   DATETIME      完成时间

这里我必须提一个在毕设里经常被问到的问题：订单创建时，要不要同时把商品状态改成"已售出"？答案是不要立即改，应该改成"锁定"或等支付成功后再改。在实际项目中这涉及并发问题或超时未支付的问题，防止一个商品被两个人同时下单。简化处理的方式是：下单时先校验商品状态是"在售"，创建订单后把商品状态改为一个"已锁定"状态，比如status=3，表示该商品已被下单暂不可再买。如果订单超时未支付被关闭，再把商品状态恢复成"在售"。

模拟支付这块，很多同学会纠结要不要接第三方支付接口。说实话，毕设项目里接支付宝沙箱是个加分项，但如果是时间紧张、部署环境受限的情况，直接在支付页面做一个"模拟支付成功"的按钮就够了。你完全可以这样设计：点击支付按钮，后端判断用户余额足够，扣钱并更新订单状态——用户余额用一张单独的账户表维护，这样还多了一个账户体系的业务逻辑，论文内容更丰富。

3.4 辅助功能：收藏、留言、公告、数据统计

校园二手交易平台如果只做核心交易流程，功能上显得单薄。我见过不少同学拿到基础版源码后，会选择从下面几个方向加功能，成本低但效果好：

• 收藏功能：一张收藏表t_favorite，字段只需要id、user_id、goods_id、create_time，前后端配合实现"点击红心收藏/取消收藏"，这个功能能明显提升用户体验感。
• 留言/评论：用户可以在商品详情页留言提问，卖家回复。这个表需要关联商品ID和用户ID，本质上是两级评论体系。需要注意的是，评论表要设计parent_id字段，支持回复楼层。
• 公告管理：管理员在后台发布校园交易活动公告或平台规则，前台在首页轮播或列表展示。这个模块逻辑最简单，却是论文里的"信息发布子系统"素材。
• 数据统计：管理员后台展示商品总量、注册用户数、当日成交量、按分类统计商品占比。用ECharts画几个图表放在后台首页，答辩时拉出来非常直观。

我之所以强调辅助功能，是因为很多源码项目的核心交易逻辑是相似的，但评委会关注"你有什么独特设计"。收藏、留言、数据统计这类功能代码量不大，但足以体现你对业务完整性的思考，写论文时也能多出几个章节的素材。

4. 数据库设计详解：建表顺序、外键策略与初始化数据

4.1 建表顺序为什么重要

我见过太多同学把Dream里的建表SQL一股脑丢进去执行，然后报"外键关联失败"。实际上建表顺序在MySQL里是硬约束：先建被引用的主表，再建引用它们的外键表。比如你得先有t_user表，才能在t_goods里加外键关联user_id。系统涉及的这几张表的推荐建表顺序是：t_user → t_category（分类表）→ t_goods → t_order → t_favorite → t_comment → t_notice。其中t_category如果你打算把分类写死在枚举里，可以不用单独建表；但如果想让后台可维护分类，那就建表。

4.2 外键到底建不建

这是数据库设计里一个经典的权衡题。在学校学的数据库理论课上，外键约束是必须要的，它保证了引用完整性。但在真实项目开发里，很多团队会刻意不用外键，原因有二：一是外键约束会让表之间的耦合变强，删除一行数据前要先确认有没有子表引用，很容易在日常运维时被锁卡住；二是在高并发写入场景下，外键约束会带来额外的性能损耗。

对于校园二手交易平台这个项目，我的建议是：表结构保留外键关系（画出ER图），但SQL落地时不要使用物理外键，只保留逻辑关联。什么意思？就是你仍然在t_goods里存user_id，但不在建表语句里写FOREIGN KEY (user_id) REFERENCES t_user(id)。这样操作时更灵活，避免删除用户时被外键拦截。论文里的ER图照常画，只不过在数据库设计说明里加一句"出于性能与可维护性考虑，采用逻辑外键设计"，这句话反而能体现你的工程经验。

4.3 初始化数据怎么造

项目跑起来之后一片空白，你演示的时候现注册现发商品，场面会很尴尬。聪明的方法是准备一批初始化数据：10个测试账号（密码统一加密，比如admin123）、20件模拟商品（覆盖教材、数码、生活用品、运动器材等不同分类）、若干条评价和公告。商品图片可以先放网络占位图，等以后替换成真实图片。

密码加密这块不要明文存。Springboot项目里用Spring Security自带的BCryptPasswordEncoder或Shiro的MD5加盐都行。如果你在图省事，也可以用JDK自带的MessageDigest做SHA-256加密——虽然不推荐用于生产环境，但毕设绝对够用。关键是面试或答辩时被问"密码为什么不能明文存储"，你得能说出Hash和加盐的概念。

4.4 一个典型的数据库账号权限设置

项目部署到服务器上时，很多人直接拿root账号连接数据库，这是个很方便但隐患很大的习惯。正确的做法是在MySQL里创建一个专用账号，只授予该数据库的增删改查权限：

sql复制CREATE USER 'campus_trade'@'localhost' IDENTIFIED BY 'YourPassword123';
GRANT SELECT, INSERT, UPDATE, DELETE ON campus_trade.* TO 'campus_trade'@'localhost';
FLUSH PRIVILEGES;

这样即使你的配置文件泄露，对方能影响到的也只是一个数据库，而不是整个MySQL实例。这个细节虽然小，但在答辩演示时如果有老师问到安全相关问题，你能很自然地答上来。

5. 环境准备与调试部署实操：从JDK到Maven到Tomcat

5.1 本机开发环境清单

在你开始"调试部署"之前，得先把整套开发环境理清楚。这套项目建议的版本组合如下：

这里有一个高频坑：Springboot 2.x和JDK版本不匹配。如果你装了JDK17，然后用的是Springboot 2.3的依赖，项目启动大概率会报"UnsupportedClassVersionError"或者莫名的Bean创建失败。反向的，Springboot 3.x强制要求JDK17及以上，如果你沿用JDK8，引入spring-boot-starter-parent 3.0.0就直接编译不过。所以拿到项目第一件事就是看pom.xml里的Springboot版本，再决定装哪个JDK。

5.2 Maven依赖下载慢的终极方案

国内访问Maven中央仓库的速度大家都有体会，一个项目首次构建下载几百MB依赖，卡上半小时很正常。解决办法是配置阿里云镜像。修改Maven的settings.xml文件中的mirrors节点：

xml复制<mirror>
  <id>aliyunmaven</id>
  <mirrorOf>central</mirrorOf>
  <name>阿里云公共仓库</name>
  <url>https://maven.aliyun.com/repository/public</url>
</mirror>

注意这里mirrorOf不是*，而是central，表示只对中央仓库做镜像覆盖，避免影响其他私有仓库配置。配置完Save后重开IDEA的Maven面板点刷新，速度会明显提升。如果项目里还有别的仓库地址比如jcenter，也可在profiles里加repositories配置，但一般用不到。

5.3 MySQL 8.0的驱动和时区问题

很多同学在本地跑MySQL 5.7的脚本，到部署环境却装的是MySQL 8.0，然后项目启动就报驱动类或时区错误。解决方案是在application.yml或application.properties里确认配置：

yaml复制spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/campus_trade?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true
    username: root
    password: 你的密码

MySQL 8.x的驱动类必须是com.mysql.cj.jdbc.Driver，老版本的com.mysql.jdbc.Driver虽然兼容但会打警告日志。url里必须带serverTimezone，不然默认用服务器时区可能导致时间差了8小时；allowPublicKeyRetrieval=true是解决连接8.0时出现的公钥检索异常，这个参数很多人都会漏掉。

5.4 打包部署的两种模式

本地调试没问题之后，你要考虑"怎么把这个项目给别人看"。打包部署有两种常见模式，我在实战中强烈建议你两种都掌握，因为评委可能任选一种提问。

第一种是本地运行演示：在IDEA里直接右键Application类运行，访问http://localhost:8080即可。这种方式优点是热部署方便，改代码立刻生效；缺点是只能在你自己的电脑上跑，发给别人看就得让TA也装一套JDK和MySQL，对非技术用户不友好。

第二种是服务器部署：先用Maven的package命令打成jar包：

bash复制mvn clean package -DskipTests

如果项目是Springboot默认打包方式，target目录下会生成一个可执行jar包。上传到服务器后，用一行命令启动：

bash复制java -jar campus-trade-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

生产环境的数据库地址、账号密码可以通过application-prod.yml单独配置，也可以用--spring.datasource.password=xxx在命令行覆盖。后台运行建议使用nohup：

bash复制nohup java -jar campus-trade.jar > app.log 2>&1 &

查看日志要抓取异常时，用tail -f app.log监控输出。这种部署方式的好处是只需要服务器上有JDK即可，不需要安装Tomcat——Springboot内嵌了Tomcat。如果你需要部署在外部Tomcat里（比如学校服务器强行要求war包），那还需要改打包方式为war并重写SpringBootServletInitializer，这个操作相对繁琐，我不建议主动选择war方式。

5.5 调试部署中最常见的报错清单

我把这套项目在部署过程中最关键的几类报错做个汇总：

其中8080端口被占用是本地调试最常见的坑。你之前可能启动过一个别的Java进程一直没关，Springboot启动时直接abort。Windows下用netstat -ano | findstr 8080找出PID，再用taskkill /PID xxx /F强制关闭即可。注意：如果占用8080的是一个系统服务，那别强杀，直接改项目端口绕开它更安全。

6. 论文文档的写作路线：如何把项目讲成一篇合格的毕业设计

6.1 论文整体结构怎么搭

标题里写着"带论文文档1万字以上"，很多同学拿到范文后容易犯一个错误：直接复制粘贴，把名字和学校一改就交。这种套模板的做法风险极高，且不说查重系统一查一个准，答辩时老师问了任何一个细节你都答不上来。正确用法是拿范文做骨架，理解它每个章节为什么这么写，然后用自己的语言重写。

一个合格的Java Web毕设论文结构通常包含六大章：

1. 绪论：背景与意义、国内外研究现状、主要工作
2. 相关技术介绍：Springboot、MyBatis-Plus、MySQL、Thymeleaf，每项技术一节
3. 系统分析：可行性分析、需求分析（功能需求+非功能需求）、用例图
4. 系统设计：总体架构图、功能模块设计、数据库设计（ER图+表结构）
5. 系统实现：按模块贴核心代码并解释逻辑
6. 系统测试：测试用例设计、功能测试、性能测试简述

"论文文档1万字"绝对不是让你堆文字，合理的分布大概是绪论1800字、相关技术1500字、系统分析1500字、系统设计2500字、系统实现2500字、系统测试1000字。用Visio或ProcessOn画好用例图、流程图、ER图、时序图，这一万字的内容量看起来就很扎实。

6.2 需求分析章节怎么写才不虚

很多同学的需求分析写出来就是"用户需要登录、用户可以发布商品、用户可以购买商品"，这种口水话的清单没有任何信息量。一个真正有说服力的需求分析应该包含角色分析和用例描述表。

角色分析可以这样写：系统包含未注册游客、注册买家、注册卖家和系统管理员四种角色。这里注意，在二手交易平台里一个注册用户同时具备买家和卖家的双重身份，他只是在自己发布商品时是卖家，购买商品时是买家，因此数据库用户表不需要区分买家表和卖家表，而是通过操作行为来识别身份。把这层逻辑讲清楚，论文的深度立刻和那些按角色建表的"表面功夫"拉开了距离。

用例描述表则要按"用例名称、参与者、前置条件、基本流程、异常流程、后置条件"的模板来写。以"发布商品"为例：前置条件是用户已登录且账号状态正常；基本流程是填写商品信息、上传图片、提交审校、系统生成在售状态商品；异常流程是图片格式不支持或标题超长时系统给出提示。这种描述方式可以直接转化为软件工程课上学过的用例图，论文里的图为什么有"设计感"，就是靠这些规范化的表支撑起来的。

6.3 系统实现章节：代码不要全贴，贴"关键片段"

这里是我看毕设论文时最烦躁的部分——有些同学把Controller里所有方法体粘贴上去，洋洋洒洒十几页，看着很唬人，实际含金量极低。评审老师要的不是代码托管站，而是你能解释核心逻辑是什么、为什么这么设计。

好的实现章节，每一小节围绕一个功能点展开，先写业务逻辑描述，再贴一段核心代码并加注释说明，最后写这段代码遇到的问题和优化点。比如订单模块可以写："为提高并发下单场景下的安全性，这里使用synchronized关键字配合Redis分布式锁对商品状态进行锁定。核心代码如下……"这样一个"业务逻辑+代码+设计理由"的闭环，才算合格。

另外一点：论文里的代码缩进、注释风格要和项目源码一致，千万不要为了省事从别的博客复制代码块，一眼就能看出来不协调。

6.4 测试章节：说清测试用例和执行结果

测试章节是最容易注水也最容易拿分的地方。系统测试不需要你写一套完整的自动化测试框架，但要有一张规范的测试用例表，包含用例编号、测试模块、测试步骤、预期结果、实际结果、是否通过。选8到12个代表性用例就行，覆盖登录、用户注册、商品发布、商品浏览、商品购买、订单管理、收藏、评论、管理员审核、数据统计等核心功能。

这里有一个小技巧：把测试执行结果用截图的方式展示，每个功能点的截图对应表格里的一行。论文中呈现的测试过程应该体现出"发现问题—修复—回归验证"的思路，比如"在测试商品发布功能时，发现当用户上传超过5MB图片时页面报错，排查发现是Springboot的默认multipart文件大小限制导致的，在application.yml中配置spring.servlet.multipart.max-file-size=10MB后问题解决"。这种真实的排错经历，比一百句"系统运行稳定"都更有说服力。

7. 进阶修改建议：如何让这套项目在答辩时更出彩

7.1 功能扩展：捡漏式加分项

拿到了基础源码，完全可以动手往里面加功能。选扩展功能的原则是"成本低、看得见、能讲3分钟"。下面几个方向是我认为性价比最高的：

• 商品自动下架：如果商品发布超过30天仍未售出，每天执行一个定时任务（@Scheduled注解）自动将状态改为"已下架"，释放视觉资源。这个功能用到的技术点就是Spring的定时任务，代码十行以内，但能体现你对系统的深度思考。
• 买家卖家互评：交易完成后，买卖双方可以互相对对方做信用评价（好评/中评/差评加文字）。在用户表加一个credit字段用于记录信用分，交易闭环后多了一个"评价"环节，这个是真实电商平台的标配功能，也是论文里可画的时序图素材。
• 商品浏览量统计和热门推荐：商品表中已有view_count字段，每次请求详情页时自增。你可以在首页增加一个"热门推荐"模块，按浏览量倒序取前六件商品展示。这个功能涉及ListView排序，代码量很小，演示效果却很亮眼。
• 验证码登录：在登录页加入Kaptcha或Hutool的图形验证码，避免机器人批量注册。这能体现安全意识，答辩时问"如何防止恶意注册"就能顺势答上。

7.2 性能优化：让评委眼前一亮

如果你的项目演示时操作流畅、响应快速，通常没人会追问性能问题。但如果被问到了，以下几个优化点你要能说清楚：

• 数据库索引：在goods表的title、category、status字段上建组合索引，在order表的buyer_id、seller_id上建索引。你可以用EXPLAIN验证查询是否走索引。
• 静态资源缓存：Springboot默认有静态资源配置，可以设置浏览器端缓存时间为7天，减少对服务器静态资源的请求次数。
• SQL优化：避免在MyBatis-Plus的LambdaQueryWrapper里做大于数据量的模糊搜索，可以用"前缀匹配"代替"包含匹配"，让查询能利用索引前缀优化的特性。

7.3 答辩前必练的三个"灵魂拷问"

最后一个环节，帮你提前准备最可能被追问的问题。

• "你这个系统怎么防止一个商品被两个人同时购买？"——答：下单时先通过UPDATE语句（UPDATE t_goods SET status=3 WHERE id=? AND status=0）将商品状态从在售改为锁定，这里用到了更新语句自身的行锁机制，数据库层面保证只有一个线程能成功，然后才创建订单。
• "会话过期了怎么办？"——答：前端页面通过拦截器在跳转任何受限页面前判断session中的用户对象是否为null，为空则重定向到登录页面并携带超时提示。如果使用JWT方案，则在前端路由守卫里检查Token是否过期，过期就跳转并清空本地存储。
• "系统如果上线，你觉得最大的风险是什么？"——答：最大的风险是信任问题，因为校园二手交易买卖双方不见面、商品品质无法标准化，容易出现纠纷。所以平台需要身份认证、信用评价、举报申诉机制，未来可以加入芝麻信用或校园卡绑定来提升信任度。

第一个问题尤其重要，因为并发安全是每个电商类毕设都绕不开的核心考点。你能从"数据库行锁"的角度回答，就比背"我用Redis锁"这种说法要有底气得多——因为你实际用的就是MySQL，没必要去背一个项目中不存在的技术方案。

我在给这套项目做环境验证和二次开发的过程中，最大的感受是：它不像那些纯PPT项目一样离真实工程太远，也没有复杂到让人望而却步。核心交易闭环是真实的、表结构是合理的、常见部署坑也都能在文档里找到对应方案。对时间紧的毕设党来说，"拿到手先跑通，再理解，再扩展"是最高效的路径；对想深挖技术的同学，这套代码作为Springboot实战的入门样本也足够扎实。最后给大家一个非常实在的建议：不管你是自己从头写，还是基于现有源码改，都尽量把项目里的每个功能模块的"输入—处理—输出"链路讲清楚，能做到这一点，你的毕设答辩就已经成功了大半。