Nicholas Qin每年到这个时间点，后台总会收到一堆类似的私信：“学长，Java毕设选什么题好？”“SpringBoot的项目有没有推荐的？”“有没有带源码和文档的，最好能直接跑起来改一改”。说实话，Java + SpringBoot 这个组合，放到今天依然是绝大多数高校毕设的首选，而“闲置用品交易平台”这类题目，更是被无数人做过、问过、也答辩过。今天就把这个项目的里里外外掰开揉碎讲一遍，从选题逻辑、技术选型、功能拆解、数据库设计，到真正落地时的那些坑和答辩经验，一次性说清楚。
这个项目说白了就是解决一个很真实的需求：每个人的宿舍里、家里都有吃灰的旧书、旧电器、吉他、自行车，扔了可惜，留着没用，而校园里正好有人在找这些东西。闲一品交易平台就是把供需两端用一套Web系统接起来，实现注册、发布商品、浏览搜索、下单支付、订单管理、评价等完整闭环。它覆盖的知识点非常全：SpringBoot、MyBatis或MyBatis-Plus、MySQL、Vue或Thymeleaf、JWT鉴权、文件上传、订单状态机，随便拿一个点出来都能写成答辩PPT里的核心技术。所以这个题不仅好做，更好讲，尤其适合那些想在答辩时“有话可说”的同学。
我在后面会把自己实际操作中的配置、写过的代码逻辑、踩过的坑全部整理出来，尽可能还原一组真实可复现的方案。如果你正对着开题报告发愁，或者在开发中卡在某个环节，这篇文章应该能帮你省下不少时间。
1. 项目整体定位与设计思路拆解
1.1 为什么是“闲置品交易平台”，而不是老掉牙的“图书管理系统”
先聊选题。很多同学选毕设题目的时候有个误区，觉得越“稳妥”越好，于是选什么图书管理、学生选课、员工考勤……这些题目不是不能做，而是有个致命问题——太常见了。答辩老师一年要看几十份论文，你一开口说“图书管理系统”，他脑子里已经有全套模板了，接下来的提问会精准到令人窒息：为什么用这个框架？数据库为什么这么设计？你的并发考虑过吗？你很难答出新意。
闲置品交易平台就不一样。它本质上是一个“轻量级电商系统”，但场景比标准电商更有学生气息，功能上比那些管理系统复杂一个档次、又比真正的商城系统简单不少，处于一个“跳一跳刚好够得着”的位置。从功能维度看，它天然覆盖了C端（买家/卖家）和B端（管理员）两条业务流程线，涉及用户注册登录、商品信息发布、分类检索、下单交易、订单状态流转、评价体系等，几乎把Web开发的主要知识点全串起来了。从技术亮点看，你可以讲JWT无状态鉴权、Redis缓存热点商品、订单状态机设计、文件上传与静态资源映射。这些词任何一个都能让答辩老师觉得“这学生是真做了东西的”。
1.2 面向人群和适用场景
这个项目和这篇分享适合谁？三类人。
第一类是准备Java方向毕设但还没定题的学生，可以把这篇文章当成选题参考和开题报告素材；第二类是已经选了或打算选“闲置品交易平台”“二手商城”“C2C小电商”这类题目的同学，可以直接照着我后面的设计思路去搭项目，省掉从零到一摸索的时间；第三类是复习Java后端知识准备实习面试的人，因为交易平台涉及的状态流转、并发扣减、权限控制等，恰好是面试中经常问到的业务场景。
和项目配套的源码、数据库脚本、文档，我这里本身就是随项目一起交付的，但光拿代码没有用，你得理解每一行配置、每张表为什么这么设计。接下来我会从技术选型开始，一点一点把这个项目的骨架讲透。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型分析：这些框架不是“选”出来的，是算出来的
2.1 SpringBoot版本：别一上来就追求最新版
项目标题里写的是“基于Java+SpringBoot”，但SpringBoot本身有大版本差异，且影响深远。结合热词里出现“springboot版本太高”这个信息，我猜不少人已经栽过这个跟头了。这里必须把话说清楚。
现在的SpringBoot主要分两条线：Spring Boot 2.x 和 Spring Boot 3.x。Spring Boot 3.0 开始强制要求 JDK 17+，同时底层从 javax.servlet 迁移到了 jakarta.servlet 规范。如果你的运行环境是学校机房或者老电脑上装的 JDK 1.8，直接选 Spring Boot 3.x 就意味着要么换JDK，要么在很多老教程里遇到的依赖导入全会报错。所以我的建议非常明确：除非你的机器能顺畅使用JDK 17+，否则一律选 Spring Boot 2.7.x（2.7是2.x系列的最后一个稳定大版本）。
我自己在这类毕设项目里用的组合是这样的：JDK 1.8 + Spring Boot 2.7.18 + Maven 3.8.x。这套组合最大的好处是生态兼容性极好，网上搜到的绝大多数教程、博客、博客源码都能直接跑起来。你要是学着学着发现“为什么我的代码和教程一样但就是报错”，大概率就是版本匹配出了问题，先检查JDK和SpringBoot大版本再说。
2.2 持久层框架：MyBatis-Plus 比 JPA 更适合毕设选手
Java后端的数据持久化方案，主流就两块：Spring Data JPA 和 MyBatis/MyBatis-Plus。选哪个？我的倾向非常明显——MyBatis-Plus。
原因有三点。第一，国内企业，尤其是中小型公司，用MyBatis体系的占比非常高，你简历上写“熟悉MyBatis-Plus”比写“熟悉Hibernate”更实用。第二，MyBatis-Plus提供了一套非常接近“开箱即用”的CRUD接口：BaseMapper里已经帮你写好了增删改查、分页查询、条件构造器。你不需要像原生MyBatis那样每写一个查询都要去维护一份XML映射文件，开发速度会快很多。第三，对于毕设来说，MyBatis-Plus的文档和社区资料非常丰富，任何报错基本都能搜到解决方案。
举个例子，用MyBatis-Plus查询某个分类下的商品列表，代码就几行：
java复制LambdaQueryWrapper<Goods> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(Goods::getCategoryId, categoryId)
.eq(Goods::getStatus, 1)
.orderByDesc(Goods::getCreateTime);
List<Goods> goodsList = goodsMapper.selectList(wrapper);
而原生MyBatis你需要先写Mapper接口方法，再去resources下的XML文件里写 resultMap、写 SELECT 语句、手动映射下划线字段到驼峰属性，一套流程下来工作量翻倍不止。当然，如果你希望论文里多一个“我深入理解了SQL映射机制”的亮点，那用原生MyBatis也完全可以，只是开发周期会变长。说到底，毕设项目拼的是“你能否在有限时间内交付一个完整可演示的系统”，而不是重构一个ORM框架。
2.3 前端方案：Vue前后端分离 vs Thymeleaf服务端渲染
前端选型上，往年做这类项目的同学主要分两派。
一派是 Vue + Element UI + Axios 前后端分离，接口走JSON，SpringBoot后端写RESTful API。这个方案观感好、页面漂亮、答辩演示效果好，也能在论文里写“前后端分离架构”，但工作量会明显增加——你需要单独维护Vue工程、处理跨域、做联调。另一派是 Thymeleaf 服务端渲染，后端直接用ModelAndView返回HTML页面。这个方案对前端零基础的同学更友好，因为你不需要懂Node.js和Vite那一套东西，SpringBoot集成Thymeleaf之后，页面就是一个普通HTML模板，用 th:each、th:if 这些标签就能把数据渲染出来。
我的建议是：如果你有一点前端功底，或者愿意花一周时间恶补Vue基础，选Vue分离式开发；如果时间紧、纯后端选手，选Thymeleaf。标题里的“闲一品”项目，我默认给的是Vue版本，因为从多年指导经验来看，会来搜这类题目的人普遍想做一个“拿得出手”的东西，前后端分离在答辩时确实是加分项。但如果你需要Thymeleaf版，思路是相通的——把RESTful接口改成返回视图即可，核心业务逻辑不变。
3. 功能模块拆解：闲一品交易平台到底由哪几块组成
3.1 用户端核心功能：从注册到宝贝上架
整个平台按角色分，最核心的是普通用户（既是买家又是卖家），这是C2C模式的特点。用户端的功能清单大致如下：
- 邮箱或手机号注册，密码经过加密存储；
- 登录后通过JWT令牌维持会话状态；
- 商品发布：填写标题、描述、定价、选择分类、上传图片；
- 商品浏览：首页推荐、按分类筛选、按关键词搜索；
- 商品详情：查看信息、查看卖家信息、查看历史评价；
- 下单购买：确认订单、填写联系方式和交易地点；
- 订单管理：作为买家查看自己买到的订单，作为卖家查看自己卖出的订单；
- 订单状态操作：买家确认收货、取消订单；卖家发货；双方互相评价；
- 个人中心：修改头像、修改昵称、查看我发布的商品（下架/重新上架）、查看我的收藏。
从数量上看，这个功能矩阵已经完全具备一个可演示、可写论文的完整业务闭环。你仔细看会发现，它比普通的CRUD管理系统多了一层“角色在业务流中切换”的逻辑——用户不是单一角色，他既是买家也是卖家，这个设计在论文里可以单独拿出来写一节：C2C模式下同一实体在不同业务流程中的角色建模。
3.2 管理端功能：审核、下架和数据看板
管理端是很多同学容易忽略的部分。有人觉得“只要用户端能跑起来就行”，结果论文里的功能设计章节只有薄薄两页，答辩时被问到“作为平台方，你怎么处理违规商品”，一脸懵。
管理端至少要包含以下内容：
- 管理员登录：独立的账号体系，可以和用户表共用一张表，用一个role字段区分，也可以单独建一张admin表。我建议单独建表，逻辑更清晰，也方便扩展。
- 商品管理：查看全部商品、按状态筛选（待审核/已上架/已下架）、强制下架违规商品。
- 用户管理：查看用户列表、禁用或解禁账号。
- 订单管理：查看所有订单流转，但不参与订单业务操作，只做监控。
- 分类管理：增删改商品分类。
- 数据概览：统计注册用户数、商品总数、订单总数，用简单的卡片展示即可，不需要额外引入图表库。如果想让界面好看点，可以加一个轻量级的ECharts柱状图统计最近一周的商品发布量。
有些同学可能觉得管理员功能花时间，但说实话，管理端就是一堆常规CRUD，用MyBatis-Plus写起来非常快，它的价值在于让你的整个系统看起来“完整”——用户、商品、订单三条线都有人管。
3.3 支付功能怎么办：接入真实支付还是模拟支付
这个问题几乎每个做交易类毕设的人都会问。我的建议非常明确：不要碰真实支付接口。原因有三：一是支付宝/微信支付需要企业资质或营业执照，个人开发者很难申请到正式商户号；二是沙箱环境虽然能测，但流程繁琐、回调机制复杂，容易把自己卡死；三是毕设的核心评分点是业务逻辑和系统设计，不是你真的能不能收一分钱。
正确做法是做一个“模拟支付模块”：用户点击“确认支付”时，弹出一个窗口让用户选择支付方式（随便几个图标就行），然后模拟几秒钟的加载效果，接着把订单状态从“待付款”置为“已付款”。这个逻辑非常简单，但在答辩时你可以换个说法——“考虑到毕设演示环境无法接入真实第三方支付，我实现了支付接口的Mock适配层，后续如果需要对接真实支付渠道，只需要替换适配层实现，业务层代码无需变更。”这一段话，直接把劣势变成了设计亮点。
4. 数据库设计：一个交易平台的核心，就是几张表的关系
4.1 核心表结构拆解
数据库设计是毕设论文里占篇幅最多、也是答辩时最容易提问的部分。闲一品平台的数据库我建议至少包含以下表：
- user（用户表）：id、username、password、nickname、avatar、phone、email、role（user/admin）、status（0禁用/1正常）、create_time。
- category（商品分类表）：id、name、parent_id（支持二级分类）、sort、create_time。
- goods（商品表）：id、user_id、category_id、title、description、price、original_price、images（存逗号分隔的图片路径字符串）、status（0待审核/1上架/2下架/3已售出）、view_count、create_time、update_time。
- orders（订单表）：id、order_no、buyer_id、seller_id、goods_id、goods_title、price、status（0待付款/1已付款/2已发货/3已确认收货/4已取消）、message、create_time、pay_time、finish_time。
- evaluation（评价表）：id、order_id、from_user_id、to_user_id、goods_id、content、rating（1~5）、create_time。
- favorite（收藏表）：id、user_id、goods_id、create_time。
- admin（管理员表，如果独立建表）：id、username、password、role、create_time。
每个表的注释和字段说明，在论文的数据库设计章节里画成表格列清楚，这是论文规范里的硬性要求，不要偷懒。
4.2 为什么订单表要冗余商品信息和价格
这里有一个非常关键的设计决策，我当年踩过坑，必须提醒你：订单表里一定要冗余“商品标题”和“商品价格”这两个字段，不要只存一个goods_id。
原因在于：商品是可以修改的，甚至可以下架删除。如果订单表只存goods_id，等你查询历史订单时，发现商品已经被卖家删掉了，那订单详情页连“买的是什么东西”都显示不出来，直接关联查询会得到空指针或空数据。而冗余了商品标题、价格甚至商品图片后，即使商品后来被删了，订单仍然完整可读。
这在数据库设计中有个术语叫“快照设计”，本质上是牺牲了一些存储空间，换取业务数据的历史可追溯性。这个点写进论文“设计考虑”一节，是非常加分的。
4.3 图片存储：本地目录还是OSS对象存储
毕设阶段的图片存储，绝大多数情况下本地存储就够了，不需要上阿里云OSS或腾讯云COS。本地存储实现很简单：在application.yml里配置一个上传路径和静态资源映射路径，前端上传文件后，后端把文件保存到服务器的指定目录，然后返回一个访问URL给前端。
yaml复制spring:
servlet:
multipart:
max-file-size: 10MB
max-request-size: 100MB
upload:
dir: D:/upload/
url-prefix: /upload/**
对应地，在后端写一个配置类把本地目录映射为静态资源：
java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
@Value("${upload.dir}")
private String uploadDir;
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry.addResourceHandler("/upload/**")
.addResourceLocations("file:" + uploadDir);
}
}
这里有一个需要注意的细节：生产环境下的路径要正反向兼容Windows和Linux，建议不要把路径写死在前端，而是后端返回完整的拼接URL给前端。比如上传成功后将 http://localhost:8080/upload/xxx.jpg 返回给调用方，前端直接拿来用，这样就不会出现路径拼接不一致的问题。
5. 核心模块实现详解：这些逻辑写对了，系统就稳了一大半
5.1 登录注册与JWT无状态鉴权
用户模块表面看是简单CRUD，但有几个细节值得展开。
第一是密码加密。不要用MD5，不要用SHA，更不要明文。Spring Security自带的BCryptPasswordEncoder是目前最主流的选择。BCrypt会自动加盐，而且每次加密结果都不同，但验签时仍能校验成功，安全性远高于普通散列算法。
java复制@Bean
public BCryptPasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
// 注册时
user.setPassword(passwordEncoder.encode(user.getPassword()));
// 登录时
if (passwordEncoder.matches(rawPassword, user.getPassword())) {
// 密码正确，签发Token
}
第二是Token方案。很多同学为了省事，直接用拦截器判断Session，但要支持前后端分离，Session方案天然不合适——跨域携带Cookie麻烦、移动端无法支持。项目里我用的是JWT（JSON Web Token）。
鉴权流程如下：
- 用户登录成功，后端生成JWT返回给前端；
- 前端把Token存到localStorage，每次发请求时放在请求头
Authorization: Bearer <token>里； - 后端写一个拦截器（HandlerInterceptor）或OncePerRequestFilter，对需要登录的接口校验Token；
- 校验通过后把用户ID放进ThreadLocal或请求上下文，业务层直接从上下文取用户。
核心的拦截器逻辑大概是这样的：
java复制@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
if ("OPTIONS".equals(request.getMethod())) {
return true; // 放行跨域预检请求
}
String token = request.getHeader("Authorization");
if (StringUtils.hasText(token) && token.startsWith("Bearer ")) {
token = token.substring(7);
}
try {
Claims claims = JwtUtil.parseToken(token);
UserContext.set(claims);
return true;
} catch (Exception e) {
response.setStatus(401);
return false;
}
}
注意这个小细节：跨域的预检请求（OPTIONS）一定要放行，否则前端Vue调试的时候会遇到一个非常经典的问题——接口报错，浏览器控制台显示CORS跨域错误，但后端明明已经配了跨域过滤器。原因就是预检请求被拦截器挡住了。
5.2 商品发布与图片上传：事务和文件操作要分离
商品发布功能的实现，实际涉及两步：图片上传到服务器，商品数据写入数据库。有同学会想当然地在一个方法里先存文件、再存数据库，然后给整个方法加 @Transactional。如果文件存储失败导致运行时异常抛出，Spring会回滚数据库操作，但文件已经写到磁盘上了，本地目录里就留下了一个孤儿文件。
更稳的做法是把文件上传和数据库写入拆开。前端先把图片传给 POST /api/upload 接口，拿到图片URL数组，再随表单数据一起提交给 POST /api/goods 创建商品。这样数据库的事务里只涉及纯数据写入，出问题回滚起来没有副作用。
商品发布逻辑里值得记录的就是状态设计。我建议新发布的商品默认 status=0 即待审核，管理员审核通过后变为 status=1（上架）。但这里要提醒你：如果毕设演示时，每次新发布商品都要登录后台审核一遍，体验会很差。我的实际做法是——商品表设计上保留状态机字段，但默认商品发布后直接置为 status=1（上架），同时在管理后台保留强制下架的能力。这样既保证了系统设计的完整性，又不影响现场演示。
答辩时如果老师问“你这个系统如何保障平台内容安全”，你就可以说：我预留了商品状态字段，管理员可以在后台对违规商品强制下架，平台具备内容管控能力。话术提前准备好，现场才不会怂。
5.3 下单核心流程：状态机与超时取消
订单是交易系统里最复杂的部分，也是论文里能写到“系统设计”深度的地方。核心是设计一个订单状态机。
订单状态我用整数表示，方便扩展：
- 0：待付款
- 1：已付款
- 2：已发货（虽然是面对面交易/同城交易，但保留这个状态可以让流程更完善）
- 3：已收货（订单完成）
- 4：已取消
状态流转规则如下：
- 下单后：0
- 买家点击支付：0 → 1
- 买家点取消：0 → 4
- 卖家点发货：1 → 2（如果功能设计里没有物流，可以省略，但论文里建议保留）
- 买家点确认收货：2 → 3
- 订单完成后，自动允许买家和卖家互评：3 →（生成评价记录）
在订单超时处理上，有一个比较容易被问到的点：如果用户下单后一直不支付，占着商品库存怎么办？项目里我建议两条方案：
方案一：前端简单方案——在订单列表里显示“距离创建已超过X小时，可关闭订单”的按钮，由买家手动取消，同时卖家也能关闭指定买家的待付款订单。
方案二：后端自动化方案——SpringBoot加定时任务，每5分钟扫描一次超过30分钟未付款的订单，自动将其状态置为已取消，同时把对应商品恢复到上架状态。
java复制@Scheduled(fixedDelay = 300000)
public void cancelExpiredOrders() {
LocalDateTime deadline = LocalDateTime.now().minusMinutes(30);
List<Orders> expiredOrders = orderMapper.selectList(new LambdaQueryWrapper<Orders>()
.eq(Orders::getStatus, 0)
.lt(Orders::getCreateTime, deadline));
for (Orders order : expiredOrders) {
order.setStatus(4);
orderMapper.updateById(order);
// 恢复商品状态
Goods goods = goodsMapper.selectById(order.getGoodsId());
if (goods != null && goods.getStatus() == 3) {
goods.setStatus(1);
goodsMapper.updateById(goods);
}
}
}
在SpringBoot启动类上不要忘了加 @EnableScheduling 注解。这个功能在答辩现场很有话题性——它体现了你对真实业务场景中“并发和用户操作意外中断”的考虑。
5.4 商品搜索与分页：条件构造器就够了
商品搜索功能，不推荐上Elasticsearch，也不必搞复杂的数据库索引优化，直接用MyBatis-Plus的条件构造器完成一个多条件模糊搜索即可。
java复制public PageResult<GoodsVO> searchGoods(String keyword, Integer categoryId, int page, int size) {
Page<Goods> goodsPage = new Page<>(page, size);
LambdaQueryWrapper<Goods> wrapper = new LambdaQueryWrapper<>();
if (StringUtils.hasText(keyword)) {
wrapper.and(w -> w.like(Goods::getTitle, keyword)
.or().like(Goods::getDescription, keyword));
}
if (categoryId != null) {
wrapper.eq(Goods::getCategoryId, categoryId);
}
wrapper.eq(Goods::getStatus, 1).orderByDesc(Goods::getCreateTime);
goodsMapper.selectPage(goodsPage, wrapper);
return new PageResult<>(goodsPage.getRecords(), goodsPage.getTotal());
}
搜索排序上，默认按发布时间降序，再加一个可选的按价格升序/降序排序参数。这些不复杂，但能让你在论文里多一段功能展示。
还有一个细节值得做：给商品表加一个 view_count 字段，每次查看详情时 +1，首页热门推荐按浏览量倒序。这个功能实现成本极低，但演示效果非常好——“我这个平台有热门推荐，是根据浏览量自动计算的”。
6. 常见问题与排查技巧实录：我替你们把这四年的坑都踩了一遍
6.1 SpringBoot启动失败：端口占用和依赖冲突
端口占用问题，很常见。上次项目跑完没关，这次再启动就报 Port 8080 was already in use. 解决办法有三：一是把上次的Java进程关掉；二是换端口：
yaml复制server:
port: 8081
三是用命令行查占用端口的进程把它干掉。第二条最省事，但我建议养成启动前关掉上次服务的习惯，调试时多处并行开服务，端口冲突就是家常便饭。
依赖冲突问题，最常见的是各种 spring-boot-starter 版本不一致，或者引入了 spring-boot-starter-security 导致所有接口默认都需要认证。毕设项目里，如果你只想用BCrypt密码加密而不想引入整套Security的拦截体系，就不要引入 spring-boot-starter-security，可以单独引入 spring-security-crypto 这个轻量级加密模块，然后自己写拦截器做鉴权。这样既用上了BCrypt，又不会被Security的默认登录页折磨。
6.2 Lombok 报错：编译器与注解处理器不兼容
热词里有一条“java: you aren't using a compiler supported by lombok, so lombok will not work”。这个问题本质上就是Lombok版本和JDK版本不匹配。JDK版本太新，而Lombok版本太老，Lombok的注解处理器无法识别新的JDK内部API，就会直接罢工。
解决办法很简单：
- 升级Lombok到较新版本，比如1.18.30+；
- 或者最保守的做法：项目中不用Lombok，实体类的getter/setter/toString让IDEA自动生成。减少一个工具依赖就少一类版本兼容问题。
但是考虑到写实体类时 @Data 确实很香，我通常建议把Lombok版本提升到1.18.30以上，并且保持项目JDK版本不超过Lombok支持范围。
6.3 数据库连接报错：时区问题与驱动版本
Spring Boot 2.7.x 默认的MySQL驱动是 com.mysql.cj.jdbc.Driver，连接URL里必须带时区参数，否则会报 The server time zone value ... 异常。完整的connection URL写成下面这样：
yaml复制spring:
datasource:
url: jdbc:mysql://localhost:3306/xianyipin?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
username: root
password: 123456
driver-class-name: com.mysql.cj.jdbc.Driver
另一个常见问题是MySQL 8.x 和 MySQL 5.x 需要的驱动版本不一样。如果连的是MySQL 8，pom.xml里应该引入：
xml复制<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.33</version>
</dependency>
如果你的MySQL是5.7，用上面的驱动也可以，但要注意密码加密方式 mysql_native_password 和 caching_sha2_password 的兼容问题。实在登录不上去，就在MySQL命令行里重置一下用户密码和加密规则。
6.4 前后端联调：跨域问题三板斧
Vue前端端口通常是8081，后端8080，两者端口不一样就会触发跨域限制。跨域解决三板斧：
第一板斧，后端加全局跨域配置：
java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOriginPatterns("*")
.allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
.allowedHeaders("*")
.allowCredentials(true)
.maxAge(3600);
}
}
第二板斧，前端Vue在请求里配置 withCredentials 或者后端加 @CrossOrigin 注解在Controller上。第三板斧是开始生产环境部署时，用Nginx把前后端统一成同一个域名，从根上消灭跨域问题。
毕设阶段用第一板斧就够了，但注意如果同时开启了JWT拦截器，一定要把OPTIONS请求放行，我在5.1节已经强调过。
6.5 文件上传大小限制：配置文件不要漏
SpringBoot默认的单个文件上传最大是1MB，如果商品图片是手机拍的照片，轻轻松松超过1MB，前端传着传着就报 MaxUploadSizeExceededException。解决方法是前面已经提过的，在 application.yml 里配置：
yaml复制spring:
servlet:
multipart:
max-file-size: 10MB
max-request-size: 100MB
这里要顺带提醒：如果图片过大，页面渲染会变慢。建议在演示前把图片压缩到几百KB以内，可以用在线压缩工具，也可以后端接一个Thumbnailator做压缩。毕设阶段用前者就好——不要给自己增加不必要的复杂度。
7. 答辩和项目包装：源码能跑只是起点，会讲才是王道
7.1 答辩时老师最爱问的5个问题
做了多年毕设指导，我总结答辩老师对这类交易平台的提问高度相似。提前准备好回答，比现场脑子空白要好得多。
问题一：整个项目你用的是SpringBoot，它的核心优势是什么？
成熟回答思路：SpringBoot基于Spring框架，通过自动配置和Starter机制大幅简化了Spring应用的搭建和部署，我只需要在pom里引入依赖、在配置文件中写少量配置，就能快速构建一个独立运行的Web应用。内置Tomcat也让部署变得简单，打包成jar后一条命令就能启动。
问题二：你这个系统的权限控制是怎么实现的？
成熟回答思路：项目采用JWT无状态鉴权方案。用户登录后，后端签发一个包含用户ID和角色信息的Token，前端请求时把它放在请求头里，后端通过拦截器统一解析校验，并把用户信息放入上下文。管理员接口会额外校验角色是admin，防止普通用户越权操作。
问题三：数据库表为什么这么设计？
成熟回答思路：围绕“用户、商品、订单、评价”四条核心链路做垂直拆分，通过外键逻辑关联保证数据一致性。重点是订单表冗余了商品标题、价格等字段，避免关联查询时因商品被删而丢失订单核心信息。另外用状态字段标记业务流转状态，便于追踪。
问题四：如果多个用户同时购买同一个商品，你怎么保证不会超卖？
成熟回答思路：这个场景在毕设里一般不会写到，但老师问出来就是加分题。回答要点：下单前先执行一次“商品状态为已上架”的条件更新，用 UPDATE goods SET status=3 WHERE id=? AND status=1，并判断受影响行数，如果为0说明商品已被抢购，就返回失败。这样通过数据库行锁级的状态变更来保证只有一个用户能成功下单。
问题五：你项目里的亮点是什么？
这个问题的回答思路，就是把前面我们设计的细节搬出来：JWT无状态鉴权、订单状态机与超时自动取消、订单商品快照、图片本地目录映射、管理端强制下架。随便挑两个讲清楚，就已经远远超过60分及格线了。
7.2 源码拿到手之后应该怎么二次开发
如果你拿到的源码已经能跑通，这只是一个开始，你需要在此基础上进行二次开发，做出“自己的东西”。我强烈建议你做以下几件事：
第一，把数据库里的表名、字段名、注释全部过一遍。不需要全部重写，但至少要能照着表结构画出ER图，这个答辩时十有八九会让你现场画。第二，加一个原有系统没有的小功能模块。比如“浏览历史”“卖家信用评分”“商品举报”等，哪怕实现得很粗糙，只要逻辑自洽、功能能跑，答辩的时候你就可以理直气壮地说“这个功能是我自己设计并实现的”。第三，把项目启动流程和数据库初始化脚本写进README，并自己复现一遍“从环境搭建到跑起来”全过程。很多同学代码跑通了就认为自己会了，但现场评委如果让你换台机器部署，你就知道哪里还有依赖了。
7.3 论文写作时的章节安排建议
论文架构上，可以参考这条主线：
- 第一章 绪论：背景与意义、国内外研究现状、主要内容与章节安排。
- 第二章 相关技术介绍：Java、SpringBoot、MyBatis-Plus、MySQL、Vue。这一章不要大段贴官方文档，尽量结合系统实际说明“为什么选它”。
- 第三章 系统分析：可行性分析、需求分析（用户端、管理端）、用例图、系统流程分析。
- 第四章 系统设计：总体架构、功能模块设计、数据库设计（ER图+表结构）。
- 第五章 系统实现：按功能模块贴核心代码、截图、运行效果。
- 第六章 系统测试：编写测试用例表格、功能测试、性能测试（至少要有基本响应时间数据）。
这里要提个醒：论文里代码不要大段大段地贴，只要贴核心逻辑片段，并用文字说明实现思路，否则查重率会高到让人崩溃。我见过不少人论文查重率30%多，一问就是代码贴了太多，被当成重复文本了。
8. 写在最后的几点经验
这个项目我陆陆续续迭代过几个版本，从最原始的纯JSP+Servlet到SSM再到SpringBoot+Vue，最大的感受是：技术栈不是越新越好，适合自己项目阶段和演示场景的，才是最好的。你做的是毕业设计，不是工业级产品，所以一切设计的评价标准都应该围绕“能不能完整跑通、能不能讲清楚、能不能被验证”这三个维度来展开。
如果你选用这个题目，下面的实操顺序可以照抄：先搭SpringBoot项目，跑通数据库连接；然后写用户模块、商品模块、订单模块；再做管理端；最后才去完善前端页面和美化。不要一上来就纠结页面配色，不要花一周时间去打磨一个没人关注的动画效果。把核心业务逻辑提前跑通，你的心态会稳很多，后面做优化也有底气。
另外一个非常实用的建议：所有配置文件的路径、端口、数据库连接信息统一放到 application.yml 中，用 @ConfigurationProperties 或 @Value 注入使用。不要硬编码在代码里。这样不管换机器、换环境，都不需要去改Java代码，只改配置文件即可。我的一个学生就是把数据库密码写死在Mapper里，结果部署到老师电脑上时现场改代码，直接暴露了问题。
如果你拿到的是我这边的源码和文档，先花半小时把项目结构理清楚：controller层、service层、mapper层、entity层、common层（通用返回结果和异常处理）、config层（配置类）。明白了每一层是干什么的，后面无论改bug还是加功能，你都不会慌。
还有一件事，项目跑起来之后，第一件事不是急着看界面，而是用Postman把后端的核心接口挨个测一遍。把注册、登录、发布商品、浏览商品、下单、支付、确认收货、评价这个完整链路用接口跑通，然后再去联调前端页面。这样分离式测试的好处是，出了问题你立刻能判断是后端接口的问题还是前端传参的问题，不至于两边互相猜。
最后再分享一个小技巧：项目里养成写日志的习惯。Controller入口打一条接收参数的日志，Service关键操作打一条业务日志，异常捕获里打印完整堆栈。这不仅是调试的利器，论文的“系统实现”章节里也可以截几段日志作为系统运行的佐证材料。很多人觉得写日志是多余的，直到出问题时追了两小时bug，才会后悔为什么当初没多打一行log。