JavaWeb校园物品置换平台毕设实战：从需求到答辩全流程详解

校园物品置换这个题目，可以说是JavaWeb方向毕设里非常经典的一类了。无论是某高校的课程设计，还是毕业设计选题库里的常客，它都占据着重要位置。原因很简单：它不是一个纯CRUD的增删改查Demo，而是融合了用户体系、商品生命周期、交易流程、站内互动等多个完整业务环节的系统，既能体现开发者的工程能力，又不会难到让人毕不了业。我自己在带学生做这个题目时，也积累了相当多的踩坑经验。这篇文章就把整个项目的设计思路、表结构、核心代码、常见坑点以及答辩准备，完完整整地拆开来聊一遍。不管你是打算自己从头写，还是拿了别人的项目代码想把它吃透，希望这篇内容能帮你省下大量查资料的时间。

1. 项目立项与需求拆解：先想清楚到底要做什么

1.1 校园物品置换的真实业务场景

做毕业设计最容易犯的毛病，就是拿到题目马上开写代码，写着写着发现需求没想清楚、表结构反复改，最后变成一个四不像。校园物品置换场景其实有一个非常清晰的业务主线，我们可以先把它捋一捋。

在校园里，闲置物品的产生是源源不断的：毕业学长学姐带不走的自行车、考研党用过的参考书、换宿舍后多余的收纳箱、冲动消费买回来吃灰的耳机——这些东西扔了可惜，留着占地方。而另一边，新生刚入学需要便宜的代步工具，学弟学妹想淘二手专业书，这就是天然的交易需求。但传统的校园论坛贴吧交易有个问题：信息杂乱、没有分类、没有双方信任机制、交易状态全靠人工沟通。所以这个系统的核心价值，就是给校园内的闲置物品提供一个结构化的置换环境，让发布、浏览、沟通、确认置换这个流程有迹可循。

基于这个业务分析，系统必须具备以下几个核心模块：

• 用户模块：注册、登录、个人信息维护，以及最基本的权限区分（普通用户和管理员）。
• 商品模块：闲置物品的发布、编辑、下架、删除，商品信息的分类展示与检索。
• 置换与交易模块：用户之间对感兴趣的物品发起置换意向，对方接受后达成交易，这里要考虑业务状态流转。
• 互动模块：针对某件商品的留言、站内消息，让买家卖家能沟通具体细节（比如"能不能便宜点""书是第几版的"）。
• 后台管理模块：管理员对用户、商品内容进行审查与治理。

把业务主线想清楚了，后面的表设计和代码编写才能一步到位。

1.2 功能模块拆分与角色权限设计

在这个系统里，角色其实就两类：普通用户和管理员。但权限设计上要理清楚每一类角色能干什么、不能干什么，否则答辩时老师问一句"你的权限控制是怎么做的"，你容易答不上来。

• 游客（未登录）：只能浏览商品列表、查看商品详情、搜索商品。不能发布商品、不能留言、不能发起置换。
• 普通用户（已登录）：在游客权限基础上，可以发布商品、编辑和删除自己发布的商品、对别人的商品发起置换申请、发送和接收站内留言、查看自己的置换记录。
• 管理员：可以管理全站用户，包括禁用违规账号；可以管理商品，包括强制下架违规商品；可以查看全站的置换记录和留言信息。

这里有一个很容易被忽略的点：权限控制不能只在前端隐藏按钮，后端接口也要做校验。也就是说，用户通过接口直接操作不属于自己的商品时，系统必须拒绝。很多学生做的系统前端看着没问题，但后端接口完全不设防，这就是一个明显的安全漏洞，答辩的时候是减分项。

1.3 技术栈选型：JavaWeb生态怎么选才稳妥

这个题目的技术选型，说实话有两条路，我分别说一下适用场景。

路线一：传统JavaWeb三件套（JSP + Servlet + JDBC）

这种方案的特点是纯手工打造，JSP写页面、Servlet接请求、JDBC连数据库，所有东西都暴露在明面上。适合学校明确要求使用JSP、或者你想在毕业设计中展现扎实底层能力的场景。缺点是开发效率低，写一个简单的列表页要牵扯一堆文件，代码冗余比较多。

路线二：Spring Boot + MyBatis + Thymeleaf/前后端分离

这种方案是企业主流，开发效率高，内置Tomcat，配置简化，对于有实习经验的学生来说写起来很顺手。缺点是有部分学校会要求必须用SSH或SSM框架，需要在开题阶段确认清楚。

我个人给大多数学生的建议是：如果学校不强制，优先选Spring Boot + MyBatis + Thymeleaf这套。原因很简单，这套技术栈既保证了技术含量（框架思想、ORM映射、依赖注入都是可以拿来答辩的亮点），又不会让开发周期拖得太长。而且Spring Boot项目的简历适配性也远好过传统Servlet项目。

不过考虑到这个题目是"基于JavaWeb的校园物品置换平台"，很多课程设计确实要求传统Servlet/JSP模式。为了兼顾大家，本文后续的代码示例我会以 Spring Boot + MyBatis 为主线来写，同时对传统Servlet模式的关键差异做标注说明。这样不论你走哪条路线，都能找到参照。

2. 数据库设计：表怎么建才能扛住业务流转

2.1 核心表结构与字段设计详解

数据库设计是这类项目真正的分水岭。一个置换平台的核心，不是商品表有多花哨，而是业务流转要闭环。我先给出五张核心表的具体设计思路，然后解释每一个关键字段为什么这么设计。

用户表（user）

这里需要重点强调的是password字段。很多学生的设计里密码字段长度给的是VARCHAR(20)，这就是给自己埋坑——如果你用MD5加密，32位十六进制字符串肯定就存不下了。我建议密码字段给VARCHAR(64)，原因后面讲登录的时候会细说。

商品表（goods）

商品状态这个字段是整个系统的核心逻辑所在。它是0上架中、1置换完成还是2下架，直接决定了商品能不能被搜到、能不能被申请置换。这块建议单独做一个状态常量类，避免代码里到处用魔法数字。

置换订单表（exchange_order）

留言表（message）

分类表（category）

有人可能会问：就这些表够了吗？如果项目做成"置换而不是直接购买"，那订单表和商品表之间其实还有一种更复杂的双向置换关系——我用我的A换你的B。如果做的是这种模式，还需要加一个置换匹配表。但在毕设阶段，做成"我看中你的商品，你接受我的置换申请"这种单链模式就足够完整了，双向置换会在答辩中带来很多边界问题，不建议给自己加戏。当然，如果你愿意深入研究，也可以把它作为亮点说出来，但实现层面要有心理准备，状态机复杂度会翻倍。

2.2 商品状态机与数据库索引优化

商品状态的变化，就是整个系统的业务主线。我建议画一个清晰的状态流转路径：

• 上架中（0）：商品正常展示，可以被搜索、被申请置换。
• 置换中：已经有用户发起置换申请，但还没最终确认。注意，这里可以有两种设计思路：一种是商品状态不变，只通过订单状态体现；另一种是加一个"置换中"状态，防止多个用户同时申请引发混乱。我的建议是后一种，加一个状态位会更严谨。
• 已置换（1）：商品拥有者接受了某个申请，商品自动下架，其他申请全部失效。
• 已下架（2）：发布者主动下架，或者管理员强制下架。

这个状态流转的细节，决定了代码写起来到底顺不顺畅。如果做"接受申请后，商品状态改为已置换"，那么必须同时做两件事：把商品状态给改了，把该商品下所有其他待处理订单全部改成已拒绝或已取消。这两步要么在一个事务里做，要么靠状态判断把并发问题挡在外面。不然老师稍微问个"如果有人同时申请你的东西怎么办"，你就会比较被动。

再说索引。毕设项目的数据量虽然不大，但索引设计是个很好的加分点，在数据库设计文档里写出来很亮眼。建议在以下字段上建索引：

• user.id（主键天然索引）
• goods.user_id（查"我发布的商品"）
• goods.category_id（按分类筛选）
• goods.status（按状态筛选）
• goods.create_time（按时间排序列表）
• exchange_order.goods_id（查某商品的所有申请）
• exchange_order.from_user_id / to_user_id（查买卖双方的置换记录）

这里面的核心原则是：索引不是越多越好，而是要为查询服务。你去反编译一下自己写的查询SQL，看看where之后跟了哪些字段，就往这些字段上建索引，准没错。

3. 核心功能实现：登录、商品发布到置换流程的完整闭环

3.1 用户登录与密码安全处理

用户登录看起来是最简单的功能，但它恰恰是体现专业性的一块。纯粹的明文密码存储是绝对不行的，哪怕这是毕设也不行。我用的是 MD5 加盐的方式，代码拿来就能用。

首先，密码存储的流程是：注册时，用户提交的明文密码 + 一个随机生成的盐值，用 MD5 做哈希，把哈希值和盐值一起存到数据库。登录时，用输入的密码 + 数据库里的盐值做同样的哈希，比对结果。这样做的好处是，即使数据库泄露了，逆向破解的难度也高得多。

示例代码如下：

public class PasswordUtil { // 生成随机盐值 public static String generateSalt() { return UUID.randomUUID().toString().replace("-", "").substring(0, 16); } // 密码哈希：MD5(明文密码 + 盐) public static String digest(String rawPassword, String salt) { String base = rawPassword + salt; return DigestUtils.md5DigestAsHex(base.getBytes(StandardCharsets.UTF_8)); } }

写到这里我必须多说一句，MD5本身在企业实践中已经被视为不够安全了，真正生产环境至少要用 BCrypt 这类自适应哈希算法。但毕设项目里用MD5加盐属于"够用且易懂"的方案。如果答辩时老师问到安全性，你可以主动说"我知道MD5不是最安全的，如果将来改进，我会引入BCrypt"。这种主动承认改进空间的回答，比硬撑反而得分高。

登录态的管理有传统Session和Token两种方案。传统Servlet模式用Session没有任何问题，Spring Boot项目如果做了前后端分离，我建议用Token（JWT）。Session方案要注意的一个小细节是：用户登录后把用户信息放进Session，每次请求通过过滤器拦截未登录的访问。下面是一个典型的拦截策略：

• /user/**路径下的所有接口，必须登录才能访问。
• /goods/publish、/goods/edit这类操作型接口，必须登录。
• /admin/**路径下的所有接口，必须管理员才能访问。
• /goods/list、/goods/detail、首页等展示型接口，游客可访问。

用拦截器实现权限控制，是后端安全设计的基本功，也是答辩的高频提问点。

3.2 商品发布与图片上传：最常见的技术卡点

商品发布涉及表单提交和文件上传两个动作，是新手踩坑重灾区。

先说表单设计。商品发布的提交字段至少有：标题、描述、分类、期望价格、图片。这里有个小陷阱：图片是多张的，前端上传后要把图片路径拼成字符串（用逗号分隔）再存到数据库。获取图片展示时，再用split方法切回数组。这个方案虽然简单粗暴，但在毕设里完全够用。

再说图片上传的存储位置。这是整个项目里最经典的一个坑：很多人把图片上传到Tomcat部署目录下的某个临时文件夹，导致部署环境一变（比如重启IDE、或者改了磁盘目录），图片就不见了。正确做法是：

1. 在项目的resources目录下，配置一个自定义的上传路径，比如D:/workspace/upload/（本地开发时用）。
2. 在Spring Boot中配置静态资源映射，把/upload/**的请求映射到该物理路径。
3. 数据库里存的是逻辑路径，比如/upload/goods/20250107123456.jpg，页面直接通过/upload/xxx访问。

对应Spring Boot的配置类大概是这样：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath + "/"); } }

传统Servlet模式则是在server.xml里配置<Context docBase="..." path="/upload"/>，原理一致。理解了这个映射关系，图片上传问题就解决了一大半。

3.3 置换流程实现：事务与状态变更的联动

置换是核心业务，代码逻辑要非常清晰。这里我给出整个流程的伪代码级描述：

第一步：发起置换申请

// 校验：商品必须存在、状态必须是上架中、发起者不能是商品拥有者 Goods goods = goodsMapper.findById(goodsId); if (goods == null || goods.getStatus() != GoodsStatus.ON_SALE) { throw new RuntimeException("商品不可置换"); } if (goods.getUserId().equals(currentUserId)) { throw new RuntimeException("不能置换自己发布的商品"); } // 创建订单，状态设为待处理(0) ExchangeOrder order = new ExchangeOrder(); order.setGoodsId(goodsId); order.setFromUserId(currentUserId); order.setToUserId(goods.getUserId()); order.setMessage(applyMessage); order.setStatus(OrderStatus.WAITING); exchangeOrderMapper.insert(order);

第二步：买家"我的置换记录"列表

查询时区分两个角色视角：我发起的置换（from_user_id = 我）；我收到的置换（to_user_id = 我）。在页面上分别用两个Tab展示，这是很多项目容易漏掉的需求。

第三步：卖家处理申请

这里就是状态联动最关键的地方。卖家点击"接受置换"后，需要做的事情是：

// 开启事务 // 1. 校验订单状态仍然是待处理，否则拒绝 // 2. 更新订单状态为已接受(1)，记录处理时间 // 3. 更新商品状态为已置换(1) // 4. 把同商品其他待处理订单全部标记为已取消(3) // 5. 事务提交

这个操作必须放在一个事务里，任何一个步骤失败都要整体回滚。我在实际做项目时，经常看到学生只改订单状态不改商品状态，结果商品下架了还在首页展示，这就是典型的业务闭环没做好。

3.4 搜索、分页与站内留言的细节处理

搜索功能看似简单，但要做好也不容易。最简单的方案是SQL的LIKE模糊查询：

SELECT * FROM goods WHERE status = 0 AND (title LIKE CONCAT('%', #{keyword}, '%') OR description LIKE CONCAT('%', #{keyword}, '%'))

需要警惕的是，如果搜索关键词含有SQL的特殊字符（比如单引号），使用MyBatis的#{}预编译是完全安全的，但如果你图省事用了${}直接拼接，那SQL注入就来了。这里必须用#{}，没有商量的余地。

分页我直接用了MyBatis的PageHelper插件，一行代码搞定：

PageHelper.startPage(pageNum, pageSize); List<Goods> goodsList = goodsMapper.selectGoodsByCondition(keyword, categoryId); PageInfo<Goods> pageInfo = new PageInfo<>(goodsList);

不需要自己写LIMIT语法，也不需要手动管理count查询。如果项目要求不能用插件，自己写LIMIT #{offset}, #{pageSize}也很简单，但PageHelper省心得多。

站内留言这块，我建议做成"商品详情页底部的评论回复区"，而不是独立的站内信界面。前者交互更直观，实现也更简单。用户A在商品B下面留言，商品持有者C可以回复，其他用户也能看到。这是典型的一对多评论场景，一张message表配合一个自关联的parent_id字段就能支持楼中楼。不过毕设阶段做一层评论就够了，不用过度设计。

4. 实操过程记录：从零搭建到跑通全流程

4.1 开发环境搭建与项目结构规划

我先说说我建议的环境搭配，这是我在实际带项目过程中调试过无数次的最稳组合：

• JDK 1.8 或 8 以上（老项目用8的最多，新的也可以用11或17）
• Maven 3.6+（统一的依赖管理）
• Tomcat（Spring Boot内置，传统模式用8或9）
• MySQL 5.7 或 8.0
• IDE：IntelliJ IDEA（用习惯Eclipse也行，但IDEA对Spring Boot的支持好出一个量级）
• 数据库可视化工具：Navicat 或者 DataGrip

项目结构方面，如果是Spring Boot模式，我推荐的包结构如下：

com.campus.exchange ├── controller // 接口层 ├── service // 业务层 ├── mapper // MyBatis的Mapper接口 ├── entity // 实体类 ├── common // 通用类：状态常量、统一返回结果、异常处理 ├── config // 配置类 └── utils // 工具类

统一返回结果类（Result）是很容易被忽视但非常有用的东西。它让所有接口都返回一个结构一致的JSON，前后端对接会舒服很多。这个类我建议至少包含：code（状态码）、message（消息）、data（数据）。成功返回200，失败返回500，未登录返回401，权限不足返回403。不然每个接口返回格式不一样，前端调起来就是灾难。

启动流程上，Spring Boot项目无非就是三步：配置好数据源，建好数据库表，启动Application类。但传统Servlet项目需要多注意一步：本地开发时用IDEA直接运行的Tomcat要用本地目录，部署时用WAR包扔到独立Tomcat的webapps下，这两种模式下的线上图片路径配置容易出岔子，建议提前测试。

4.2 核心代码实现：商品列表页到详情页的链路

商品列表页是主页面，它展示的其实就是一个分页列表。为了不让商品图片在列表页一次性加载太多造成卡顿（其实毕设数据量根本不卡，但设计思路要说清楚），列表页字段做了裁剪：只查id、标题、主图（images的第一个）、价格、分类、发布时间。详情页才查全字段。

列表查询SQL用一个联合查询就可以关联出分类名称和发布者昵称：

SELECT g.id, g.title, g.price, g.image, g.create_time, c.name AS category_name, u.nickname AS owner_nickname FROM goods g LEFT JOIN category c ON g.category_id = c.id LEFT JOIN user u ON g.user_id = u.id WHERE g.status = 0 ORDER BY g.create_time DESC LIMIT #{offset}, #{pageSize}

这里有个小技巧：如果列表页只要显示一张图，就不用把images整串字段拿出来，可以在SQL里用SUBSTRING_INDEX(g.images, ',', 1)直接取第一张，省一层Java处理逻辑。这种细节在答辩时随口提一句，老师会知道你SQL基本功是在线的。

前端页面我用的是一套轻量级模板加少量原生JS。Spring Boot + Thymeleaf模式下，JSP是不能直接在jar包里运行的，如果你习惯了JSP，要在application.properties里配prefix和suffix也不太一样。所以这里再次建议，用Spring Boot就走Thymeleaf，用传统Servlet就走JSP，哪条路走到底都行，最忌讳两条路混着用。

4.3 商品发布页与图片上传的完整实现

商品发布页涉及表单和文件同时提交。前端form的enctype要设置为multipart/form-data，这个如果忘记写，文件上传会变成字符串路径提交，后台接到的MultipartFile就是空值。

Spring Boot的Controller写法：

@PostMapping("/goods/publish") public Result publish(@RequestParam("title") String title, @RequestParam("description") String description, @RequestParam("categoryId") Integer categoryId, @RequestParam("price") BigDecimal price, @RequestParam(value = "files", required = false) MultipartFile[] files) { // 获取当前登录用户 User user = (User) session.getAttribute("loginUser"); // 保存图片文件到磁盘 List<String> imagePaths = new ArrayList<>(); if (files != null) { for (MultipartFile file : files) { if (file.isEmpty()) continue; String fileName = UUID.randomUUID().toString() + getExt(file.getOriginalFilename()); file.transferTo(new File(uploadPath + fileName)); imagePaths.add("/upload/" + fileName); } } Goods goods = new Goods(); goods.setUserId(user.getId()); goods.setTitle(title); // ... goods.setImages(String.join(",", imagePaths)); goods.setStatus(GoodsStatus.ON_SALE); goodsMapper.insert(goods); return Result.success(); }

这里要注意文件名的处理。真实文件名包含中文和空格，直接存可能产生乱码和路径问题，所以统一用UUID生成新文件名，但后缀要保留原来文件的扩展名，因为.jpg和.png的后缀信息对浏览器展示有影响。

图片上传的大小限制也要提前配置好。Spring Boot默认单文件上传限制1MB，如果在application.properties里不调大，传一张手机拍的高清图就直接报错了。建议配置：

spring.servlet.multipart.max-file-size=10MB spring.servlet.multipart.max-request-size=20MB

这两行配置救了很多人的命，我亲眼见过有人传图片一直报错，怎么查都查不到，最后发现就是默认大小限制的问题。同时前端也要校验图片格式和大小，避免用户传一个几十MB的GIF直接把服务器内存拖爆。

4.4 管理员后台的报表与治理功能

管理员后台至少要包含三个列表页面：用户管理、商品管理、置换订单管理。每个页面都可以搜索和分页，管理员可以对违规用户执行禁用，对违规商品执行强制下架。

这个模块有两点需要注意。第一，后台的接口必须做管理员权限校验，不能只是菜单隐藏了就算完。我在拦截器里做的是：如果当前用户不存在，返回未登录；如果当前用户存在但role不是管理员，返回403。第二，后台操作商品下架时，要联动处理。一个商品强制下架了，它下面所有待处理的置换申请都应该自动失效，避免买家还在傻等一个不会再被接受的结果。

如果想让后台更有亮点，还可以加一个简单的统计面板：今天新注册用户数、上架商品数、成交量、待处理订单数。这些统计用一个简单的COUNT查询就能实现，但对答辩展示的视觉冲击力非常强。

5. 常见问题与排查技巧实录

5.1 高频报错场景速查表

我在这个项目上被人问过的问题，汇总成一张速查表：

5.2 几个必须收藏的避坑细节

第一个坑是时间字段。MySQL的datetime类型在Java里对应的是java.util.Date或LocalDateTime。很多新手会在这里踩到java.sql.SQLException: Cannot convert value 'xxx' to java.sql.Date，一查就是因为MyBatis的typeHandler类型不匹配。我的建议是实体类统一用LocalDateTime，数据库时间字段用datetime，然后在MyBatis里注意配置jdbcType。写成create_time DATETIME和Java的LocalDateTime是完全匹配的，但如果你是手动在代码里用new Date()去set，那很可能是java.util.Date和LocalDateTime混用了。这个类型问题不如干脆利落：全部统一，别混。

第二个坑是循环依赖和Service层逻辑过厚。有些同学喜欢在一个Service里写全部逻辑，拆不出来，最后代码膨胀到几百行。我建议的做法是：每个Service负责一个业务域，比如GoodsService、UserService、ExchangeOrderService，这样在答辩讲项目结构的时候特别清晰。

第三个坑是前端AJAX请求后端接口的路径问题。传统Servlet模式下，请求路径是/goods/publish.html。如果前端写JS时路径写错，会404报错。最简单的排查方法：打开浏览器F12看Network，看看发出的请求路径到底是什么，跟后端注解的@RequestMapping("/goods/publish")做逐字对比。80%的前后端接口不通问题都是这个原因。

5.3 并发与数据一致性：毕设也能讲出深度

虽然毕设项目并发不大，但如果你能在答辩时主动提一句并发控制，加分效果会很明显。比如，当两个用户同时申请同一件商品，最后只有一个能成功。这个场景在代码层面怎么防？

答案是用数据库层面的乐观锁或状态校验。最简单可靠的做法是：在处理申请时，先执行一个更新语句，带上商品状态条件，如果影响行数为0，说明商品已被别人抢先：

int rows = goodsMapper.updateStatus(goodsId, GoodsStatus.ON_SALE, GoodsStatus.RESERVED); if (rows == 0) { throw new RuntimeException("商品已被置换或下架"); }

这个技巧在实战中极其好用，比起先查询再判断再更新，它把整个业务判断压缩在一个原子操作里，从根上避免了并发问题。答辩时讲到这个点，老师会对你刮目相看。

6. 答辩准备与实用经验分享

6.1 演示流程设计：别把重点讲歪了

答辩演示的时间通常只有5到10分钟，这个时间很宝贵。很多人上来就演示注册、登录、发布商品，等演示到核心的置换流程时时间到了，反而没有把项目的亮点展示出来。我建议的演示顺序是：

第一，先花一分钟讲清楚系统定位：校园闲置物品置换，解决了什么问题，分几个角色。

第二，直接演示核心流程：用户登录，发布一件商品，然后切换另一个账号，浏览商品并发起置换申请，再切回发布者账号，处理申请，确认置换。这个流程从头到尾完整走一遍，直接证明系统具有完整的业务闭环。

第三，演示管理后台：管理员能看到用户和商品列表，并能禁用、下架。把治理能力展示出来。

最后，如果时间允许，把代码结构打开，指给老师看分层架构和事务处理的位置。这里点到为止即可。

6.2 答辩高频问题提前备好底稿

根据我多年的经验，老师问得最多的几个问题，我给你整理一个标准答法：

• "你的系统有哪些角色，权限怎么控制的？"答：两个角色，普通用户和管理员。登录后用户信息存在Session里，拦截器拦截请求判断Session是否存在、角色是否匹配，后端接口做了二次校验。
• "商品状态是怎么流转的？"答：商品有上架中、置换中、已置换、已下架四个状态。买家申请后商品变为置换中，卖家接受后状态被更新为已置换，同时其他待处理申请被标记取消。状态变更用事务保证一致性。
• "多个用户同时申请同一件商品怎么办？"答：通过带状态条件的UPDATE语句，影响行数为0说明被抢先，直接拒绝。这就是乐观锁的思想。
• "图片存储为什么放在磁盘而不是数据库？"答：数据库存储二进制大对象会让数据库膨胀、性能下降，文件存磁盘，数据库存路径URL，并通过静态资源映射对外访问，这也是企业的常规做法。
• "为什么选择这套技术栈？"答：结合项目规模，Spring Boot能快速搭建并聚焦业务逻辑，MyBatis对SQL控制更灵活，Thymeleaf适合服务端渲染，这套组合兼顾开发效率与可维护性。

这些问题反复练几遍，语速放慢，思路清晰，答辩基本没有压力了。

6.3 从毕设到简历项目：这套系统的真实延伸价值

最后再说一点题外话。这个项目做完，别让它真的只成为一个"毕设就扔"的项目。它其实有很好的延伸空间，我建议你把它往简历项目方向再打磨一版：

• 引入Redis做热门商品缓存，说明你了解缓存穿透和缓存雪崩。
• 引入Elasticsearch做商品搜索，说明你具备全文检索能力。
• 把商品图片上传到对象存储（比如阿里云OSS或MinIO），说明你了解分布式文件存储的基本方案。

哪怕只是在原有代码上做一版"优化版"，都能让这个项目从课程设计级别提升到实习求职可用的实战项目级别。很多学生在面试时拿项目讲来讲去都是图书管理系统、学生管理系统，而校园物品置换平台天然带有交易属性、状态机属性、多角色权限属性，只要你能把业务讲透、把技术选型动机说清楚，它就是一个比绝大多数仓库项目都更能吸引面试官注意的完整作品。

我在实际开发和带项目的过程中最大的体会是：这个系统不难，但它非常考验实现者能不能把一条完整业务链路做扎实。很多人不是不会写代码，而是不清楚业务从哪开始、在哪结束，导致开发过程中反复改表、改接口，越做越乱。希望你按照这篇文章的思路，先把需求想透，把表和状态理清，再动手写代码。等你把置换流程完整跑通的那一刻，那种顺畅感和成就感，就是你在这个项目里最值得记住的时刻。