我做了好几个毕业设计项目也帮学弟学妹们审过不少代码。说句实话校园二手物品置换系统这个题目算是Spring Boot毕设选题里性价比非常高的一类。业务场景贴近实际生活、角色划分清晰、技术栈覆盖面广而且做出来之后演示效果直观——无论是答辩还是写论文都有东西可讲。但正因为做的人多如果你的系统只是停留在“前台发布商品、后台管理订单”这种层面很容易被评委老师问住。这篇文章我就以“基于Spring Boot的校园二手物品置换系统”为例把从需求分析、技术选型、数据库设计到核心模块实现、部署避坑的完整链路拆开来讲重点说清楚每一步背后的考量以及哪些地方值得做成答辩亮点。先说这个系统是干什么的。简单来讲它解决的是高校里二手物品信息分散、交易缺乏信用保障的问题——学生在宿舍楼下贴纸条、在QQ群里刷屏发广告信息很快被淹没也没法验证对方身份。一个独立的置换平台让用户注册登录后发布闲置物品、浏览搜索、发起置换或购买意向管理员在后台审核信息和处理举报这样就把线下混乱的“跳蚤市场”搬到了线上。适合谁来参考如果你是计算机相关专业、正在做Spring Boot方向毕设的学生或者想快速搭一个带管理后台的Web全栈项目这篇文章应该能帮你省掉不少查资料的弯路。1. 整体设计与技术选型为什么这么组合1.1 题目里“置换”二字的业务本质很多人看到“二手物品置换系统”第一反应就是把“置换”等同于“购买”。这其实是个误区。置换的核心是“以物换物”的意向撮合而不是简单的商品买卖。也就是说用户A发布一件自己不用的物品可能标注“想换一个羽毛球拍”或者“接受议价出售”用户B看到后可以发起置换请求双方协商达成意向再通过线下见面完成交易。这个业务特点决定了系统的关键功能点一是商品发布必须支持“置换意向”字段不能只有价格二是要有“求购信息”这类反向需求发布功能让用户先说明自己想要什么再等待别人来匹配三是交易状态必须比普通电商复杂一些——待协商、已达成意向、已完成、已关闭每种状态之间的流转要有约束。如果只是做成了“二手商城”那和题目里的“置换”就对不上了答辩时容易被质疑需求理解不到位。1.2 后端框架为什么是Spring Boot而不是SSH或纯Servlet这个基本没什么悬念Spring Boot是目前Java Web开发的绝对主流。它的价值在于“约定大于配置”内嵌Tomcat无需单独部署WAR包一个mvn spring-boot:run或者java -jar就能跑起来这对毕设开发效率来说是质的提升。如果非要用SSHStrutsSpringHibernate那种老组合光是配置XML就得折腾好几天而且答辩时要解释一堆早已过时的概念属于给自己挖坑。Spring Boot生态里最值得选的两个配套组件是Spring Boot Starter Web处理HTTP接口和Spring Boot Starter Validation做参数校验。另外要注意的是版本选择——不要无脑上最新版。我从实际经验的角度建议稳定使用Spring Boot 2.7.x就好对应Java 8或者Spring Boot 3.x Java 17也可以但3.x里有些API写法变了比如javax包改成了jakarta网上大量教程都是针对2.x的跟着做容易踩坑。1.3 ORM选型MyBatis-Plus 还是 JPA这是一个毕设里必然会纠结的问题。我个人的建议是用MyBatis-Plus。原因很简单——MyBatis-Plus在MyBatis的基础上提供了内置的通用Mapper、通用Service和条件构造器LambdaQueryWrapper单表CRUD基本不用写SQL多表查询又保留了手写SQL的灵活性。相比之下Spring Data JPA虽然抽象层次更高但多表关联和复杂查询的学习成本不低而且一旦查不好就生成一堆低效SQL被评委问到底层实现时很难讲透。用MyBatis-Plus还有一个额外好处它的Page分页插件用起来很方便配合IPageT接口几行代码就能把分页逻辑做完这在没引入前端分页组件的情况下尤其省事。1.4 前端方案服务端渲染还是前后端分离这一项决定了你的工作量上限。我见过很多同学用Thymeleaf模板引擎直接在后端写HTML页面这种做法对于功能简单的系统确实省事不需要额外开前端服务。但“校园二手物品置换系统”的前端交互是比较多的——商品卡片筛选、图片预览、状态流转按钮、站内消息提醒这些用服务端渲染会写得非常别扭。所以我建议采用前后端分离架构后端只提供JSON接口RESTful风格前端用Vue 2 Element UI或Vue 3 Element Plus构建单页面应用。这样做演示效果明显更好而且技术亮点更足——你可以大大方方地在论文里写“基于前后端分离架构前端通过Axios异步调用RESTful API”。部署时只需要把前端npm run build生成的dist目录交给后端托管放到src/main/resources/static下或者用Nginx做反向代理二选一即可整体并不复杂。1.5 存储与中间件MySQL Redis MinIO RabbitMQ这一步是关键也是拉开项目档次的地方。最基础的存储肯定选MySQL比如5.7或8.0版本这个是常规操作不展开说了。但要做出亮点最好引入三个组件MinIO对象存储用来存商品图片。为什么不直接把图片存到数据库或者本地磁盘因为数据库存二进制大字段极影响查询性能本地磁盘在部署到服务器后又会面临路径迁移、静态资源访问权限等问题。MinIO是开源兼容S3协议的对象存储启动一个Docker容器就能用Java端通过MinioClient几行代码即可上传下载还能生成临时访问链接。我后来也把MinIO使用纳入正文因为在“Spring Boot整合MinIO”这个热词背后正是毕设系统处理文件上传的通用痛点。Redis缓存用来缓存商品列表、热点商品详情以及用户会话。如果不想引入Spring Session至少也要把首页推荐列表、分类列表做缓存减少数据库压力。这是论文里“性能优化”章节的实打实素材。RabbitMQ消息队列这个可以做一个轻量级应用——当用户发起置换意向后向对方发送站内消息通知通过消息队列异步处理避免同步调用阻塞接口。如果觉得引入消息队列太重也可以用Spring Boot自带的Async异步方法替代但RabbitMQ的引入无疑会让项目在“分布式基础”维度上加分而且是面试常问的点。你可能注意到了前面提到的Spring Boot整合ActiveMQ、整合Kettle、整合Flink等关键热词大多是不同方向项目的技术选型。本系统的业务规模用不上Flink和大数据组件我不会强行堆叠这是很多同学犯的错误——为“炫技”引入与业务无关的组件一被追问就露馅。选RabbitMQ的理由必须明确写在论文里系统需要处理站内通知的异步解耦队列能削峰填谷保证核心交易链路不因通知阻塞而超时。2. 功能模块拆解与数据库设计2.1 角色划分与功能矩阵系统至少要包含三类角色普通用户、管理员、访客未登录用户。核心功能矩阵如下角色核心功能说明访客浏览商品、搜索、查看详情不能发起置换或购买需要登录普通用户注册登录、发布商品、编辑/下架、发起置换、接受/拒绝置换、发布求购信息、个人中心商品权限只对自己发布的条目生效管理员用户管理、商品审核/下架、分类管理、举报处理、数据统计用户数/商品数/活跃度拥有后台最高操作权限“举报处理”这个功能容易被忽略但在校园场景里非常必要——二手交易最大的痛点是信任问题给用户一个举报入口管理员才能及时处置虚假信息这在答辩时可以作为一个“平台治理”层面的设计亮点来讲。2.2 数据库表结构设计核心表与关键字段下面梳理核心表以及设计时最容易出错的地方。我不会贴全部建表语句只放关键字段和设计意图。用户表t_user核心字段id, username, password, nickname, avatar_url, phone, email, role, status, create_time。这里有一个重要考量密码不能明文存储。至少要用BCryptSpring Security Crypto自带做哈希这一点在答辩时基本是必问题。如果连密码加密都没有项目质量会被直接打问号。商品表t_goods核心字段id, user_id, title, description, category_id, price, expect_exchange, images, status, view_count, create_time。关键设计点在于expect_exchange期望置换的物品描述和price价格都必须保留——因为“置换可议价出售”的双模式正是系统的业务特色。images字段建议用JSON字符串存多个图片URL格式如[url1,url2]不要单独建一张图片表把逻辑搞复杂。status字段建议使用以下枚举值0-待审核1-已上架2-已下架3-置换中4-已完成。状态机是这个系统的核心逻辑之一后面我会专门讲。求购信息表t_wanted核心字段id, user_id, title, description, category_id, max_price, status, create_time。注意求购信息同样要审核吗可以设计为“无需审核、举报后下架”的轻量治理模式这样能减少管理员工作量也更贴近实际场景。置换意向表t_exchange_order这是整个系统最重要的一张表能不能把“置换”业务讲清楚就看这张表的逻辑。核心字段id, goods_id, from_user_id, to_user_id, offer_goods_id, status, message, create_time, update_time。其中offer_goods_id表示发起方愿意用哪件自己的商品来换这样可以与商品表关联起来展示“以物换物”的具体对象。status建议设计为0-待对方确认1-已同意2-已拒绝3-已完成4-已取消。举报表t_report核心字段id, user_id, target_type, target_id, reason, status, create_time。这里target_type可以区分是举报商品还是举报用户status表示处理状态管理员处理完成后可以标记结果。2.3 状态机设计置换流程的核心约束这部分值得在论文里画一个状态图Word里用Visio画就行用户A发布商品待审核→ 管理员审核通过已上架→ B发起置换意向意向表创建商品状态变为“置换中”→ A同意/拒绝 → 双方线下交付后标记完成 / 协商失败则商品重新变为“已上架”。设计这个状态机时有一个关键点同一件商品同一时刻只能有一个有效的置换意向。也就是说B发起置换后商品要立即进入“置换中”状态其他人再发起时要提示“该商品已被置换意向占用”。如果不加这个互斥逻辑就会出现两个用户同时看中一件商品、先后发起请求而卖家又没及时处理的尴尬情况。这个“互斥”的实现方式也很简单在发起置换的Service方法里加一个前置查询判断goods.status是否等于“已上架”如果不等则直接抛出业务异常。因为这是单机应用不需要做太复杂的分布式锁用synchronized或者数据库行锁SELECT ... FOR UPDATE都可以但你要是想在论文里写亮点可以提一下“未来可扩展为基于Redis的分布式锁”。2.4 数据库索引与性能优化数据量虽然不大但建索引的习惯必须有。核心索引如下商品表的(status, category_id, create_time)联合索引用于按分类筛选和最新排序。商品表的user_id索引用于“我的发布”查询。置换意向表的(goods_id, status)联合索引用于同一商品的意向互斥查询。求购表的(category_id, status)索引。用EXPLAIN查看执行计划确保核心查询走索引而不是全表扫描这是答辩时“数据库优化”环节的常规操作。之前我带过一个同学他发布列表的SQL在goods表数据过万之后明显变慢加了联合索引后从180毫秒降到20毫秒这种优化案例写进论文里很有说服力。3. 核心模块实现从前端请求到后端落库3.1 项目结构与统一响应体设计我推荐的后端包结构长这样com.campus.secondhand ├── common // 通用类统一返回结果、异常处理、常量 ├── config // 配置类拦截器、跨域、Redis、MinIO、RabbitMQ ├── controller // 接口层只做参数接收和结果返回 ├── service // 业务层存放核心逻辑 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库实体 ├── dto // 前端请求参数对象 ├── vo // 前端响应对象 └── utils // 工具类JWT、日期处理等统一响应体是我反复强调的一点。直接用Result类包裹所有接口返回格式为public class ResultT { private Integer code; // 200成功500失败401未登录 private String message; private T data; }前端拿到code判断业务成功与否而不是靠HTTP状态码。这样做的直接好处是业务异常比如“商品已被置换”也能返回正常的HTTP 200方便前端统一处理弹窗提示不会有各种奇奇怪怪的跨域错误和代理错误混在一起。3.2 JWT登录鉴权拦截器实现虽然引入了Spring Security可以做更完整的权限控制但很多毕设场景下用Spring Security反而增加了配置复杂度。一个更轻量且同样有技术含量的方案是JWTJSON Web Token HandlerInterceptor。流程如下用户登录成功后后端生成一个JWT里面包含userId和role设置过期时间比如7天返回给前端。前端把Token存到localStorage每次请求在Header里带上Authorization: Bearer token。后端写一个LoginInterceptor在preHandle里解析并校验Token把userId放到ThreadLocal或RequestContext里供后续Service使用。对于登录后才能访问的接口在WebMvcConfig里注册拦截器并配置excludePathPatterns排除登录、注册、商品浏览等接口。JWT实现起来不难但有一个坑不要把敏感信息放进Payload。JWT的Payload只是Base64编码不是加密别人能直接解码看到内容。所以Payload里放userId、role就够了最多加个nickname不要放手机号、密码之类的东西。登录状态也不是非要引入Spring Security不可但如果你已经比较熟悉Spring Security或者论文需要体现安全框架也可以选。不过综合来看JWT拦截器方案更轻、更好讲推荐优先。3.3 商品发布与图片上传Spring Boot整合MinIO商品发布流程里最先要解决的是图片上传。前端用Element UI的el-upload组件选中图片后先上传到后端接口/api/file/upload拿到图片URL后再连同商品表单一起提交。后端的文件上传Controller核心代码如下配合MinIOPostMapping(/api/file/upload) public ResultString upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { throw new BizException(上传文件不能为空); } // 校验文件类型和大小只允许jpg/png/webp最大5MB String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); if (!ALLOW_TYPES.contains(ext.toLowerCase())) { throw new BizException(不支持的文件类型); } if (file.getSize() 5 * 1024 * 1024) { throw new BizException(文件大小不能超过5MB); } String objectName UUID.randomUUID().toString().replace(-, ) ext; minioClient.putObject( PutObjectArgs.builder() .bucket(bucketName) .object(objectName) .stream(file.getInputStream(), file.getSize(), -1) .contentType(file.getContentType()) .build() ); String url minioClient.getPresignedObjectUrl( GetPresignedObjectUrlArgs.builder() .method(Method.GET) .bucket(bucketName) .object(objectName) .expiry(60 * 60 * 24) // 一天内有效 .build() ); return Result.success(url); }MinIO的配置就写在application.yml里minio: endpoint: http://127.0.0.1:9000 access-key: minioadmin secret-key: minioadmin bucket-name: secondhand部署时在服务器上用Docker一条命令启动docker run -d --name minio -p 9000:9000 -p 9001:9001 \ -e MINIO_ROOT_USERminioadmin \ -e MINIO_ROOT_PASSWORDminioadmin \ -v /data/minio:/data \ minio/minio server /data --console-address :9001注意这个持久化预签名URL是有时效的expiry参数。如果你的商品详情页需要长期展示图片更好的做法是让MinIO存储桶设为公有读直接用http://ip:9000/bucket/object访问或者用Nginx对MinIO做反向代理加一层路径转发。我在实践中更推荐前者——直接生成一个无时效的永久访问URL避免用户过一天再打开商品详情图挂了。MinIO本身也支持在创建桶时设置只读策略这个操作在MinIO的Web控制台9001端口里手动点一下就行。3.4 商品列表查询MyBatis-Plus多条件分页商品列表页是用户使用频率最高的页面筛选条件包括分类、关键字、价格区间、排序方式最新/热度。用MyBatis-Plus的LambdaQueryWrapper可以优雅实现public PageGoodsVO searchGoods(GoodsQueryDTO dto, PageGoods page) { LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); wrapper.eq(Goods::getStatus, 1); // 只查已上架 wrapper.eq(StringUtils.hasText(dto.getCategoryId()), Goods::getCategoryId, dto.getCategoryId()); wrapper.like(StringUtils.hasText(dto.getKeyword()), Goods::getTitle, dto.getKeyword()); wrapper.between(dto.getMinPrice() ! null dto.getMaxPrice() ! null, Goods::getPrice, dto.getMinPrice(), dto.getMaxPrice()); wrapper.orderByDesc(createTime.equals(dto.getSort()) ? Goods::getCreateTime : Goods::getViewCount); PageGoods result goodsMapper.selectPage(page, wrapper); // 将实体转为VO并拼接用户昵称、图片列表等 return convertToVOPage(result); }这里几个容易踩的小坑wrapper.eq(condition, column, value)这种重载方法条件为false时自动忽略该查询条件推荐优先使用不要手动去拼if。查询的关键字用like时要注意SQL注入风险。MyBatis-Plus的like方法会自动处理%的转义比手拼SQL安全。分页时用PageGoods作为查询参数但在返回前要转成PageGoodsVO避免把不必要的字段暴露给前端。3.5 发起置换状态互斥与事务控制这是一段非常核心的交易逻辑我把关键代码列出来你感受一下状态控制的节奏Transactional(rollbackFor Exception.class) public void createExchange(ExchangeCreateDTO dto) { Long goodsId dto.getGoodsId(); Goods goods goodsMapper.selectById(goodsId); if (goods null || goods.getStatus() ! GoodsStatus.ONSHELF.getCode()) { throw new BizException(商品不存在或已被置换); } // 不能置换自己发布的商品 if (goods.getUserId().equals(currentUserId())) { throw new BizException(不能置换自己发布的商品); } // 校验发起方提供的置换物品 Goods offerGoods goodsMapper.selectById(dto.getOfferGoodsId()); if (offerGoods null || !offerGoods.getUserId().equals(currentUserId())) { throw new BizException(置换物品不合法); } // 核心互斥将商品状态改为“置换中”利用行锁避免并发覆盖 int updated goodsMapper.updateStatusByVersion(goodsId, GoodsStatus.ONSHELF.getCode(), GoodsStatus.EXCHANGING.getCode()); if (updated 0) { throw new BizException(手慢了商品已被其他用户发起置换); } // 创建置换意向 ExchangeOrder order new ExchangeOrder(); order.setGoodsId(goodsId); order.setFromUserId(currentUserId()); order.setToUserId(goods.getUserId()); order.setOfferGoodsId(dto.getOfferGoodsId()); order.setStatus(ExchangeStatus.WAITING.getCode()); exchangeOrderMapper.insert(order); // 异步发送通知消息到RabbitMQ rabbitTemplate.convertAndSend(exchange.exchange, exchange.notify, new NotifyMessage(goods.getUserId(), 您的商品[ goods.getTitle() ]收到新的置换请求)); }这里需要特别强调一下updateStatusByVersion这个方法的含义它是乐观锁的一种应用。SQL大致写成UPDATE t_goods SET status #{newStatus} WHERE id #{goodsId} AND status #{oldStatus}通过“更新影响行数是否为0”来判断状态是否被并发修改。在单机部署下这个写法已经足够健壮。要是用select再update两段式两个请求同时读到“已上架”就会产生重复意向这是标准的并发bug。另一个要点就是Transactional。商品状态更新、意向单插入、消息发送这三步要么全部成功要么全部回滚不能让状态改了但意向单没插上。RabbitMQ的发送放到事务里其实有讲究——消息发出后如果事务回滚了消费者就收到了不存在的通知。严谨做法是用事务消息或在事务提交后再发消息但毕设层面能意识到这个问题并说明“为保证最终一致性可引入本地消息表”就已经足够了。3.6 后台管理拦截器 数据统计管理员的身份校验只需要在LoginInterceptor里加一行角色判断如果请求路径以/api/admin开头校验role是否为管理员。这里有个细节值得注意——前端隐藏按钮不算权限控制前端只是用户体验层真正的权限必须在后端校验。就算有人绕过前端直接构造请求后端的拦截器也能挡住。后台的数据统计可以用一个简单的Mapper方法实现SELECT COUNT(*) FROM t_user SELECT COUNT(*) FROM t_goods WHERE status 1 SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS day, COUNT(*) AS cnt FROM t_goods GROUP BY day ORDER BY day DESC LIMIT 7用DATE_FORMAT按天分组就能在ECharts折线图上展示近七天的商品发布趋势。这类统计完全没必要上报表框架或引入大数据的组件MySQL的聚合函数就足够了。4. 部署上线从本地到服务器的完整路径与避坑清单4.1 后端打包含Fat JAR在pom.xml中配置Spring Boot Maven插件build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId /plugin /plugins /build然后执行mvn clean package -DskipTests生成的target/*.jar就是一个可独立运行的Fat JAR。如果打包时报错找不到主类或者依赖冲突优先检查是不是Maven没配置阿里云镜像导致依赖下载不完整换镜像后clean再package一次mirror idaliyunmaven/id mirrorOfcentral/mirrorOf urlhttps://maven.aliyun.com/repository/public/url /mirror4.2 前端Vue项目打包并托管到Spring Boot前端执行npm run build生成dist目录。接下来有两种做法做法一不需要Nginx适合毕设演示把dist目录下的所有文件复制到后端项目的src/main/resources/static/下然后重新打包。访问http://ip:8080/index.html就是前端页面。这个方法的好处是部署简单但要注意前端路由——Vue Router如果用了history模式刷新二级页面会404需要在后端加一个ViewController把非API路径转发到index.html。嫌麻烦的话前端直接改用hash模式URL上带#刷新问题就不存在了。做法二推荐稍专业服务器上装Nginx把dist目录放到/usr/share/nginx/html配置Nginx监听80端口接口请求/api反向代理到本机的8080端口。这样做的好处是前后端彻底分离后端以后换了端口前端不用改。Nginx里核心的配置片段server { listen 80; server_name _; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; # 关键解决history路由刷新404 } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }4.3 常见部署问题排查问题现象排查思路前端请求接口报CORS错误后端WebMvcConfig没配置跨域或者Nginx反向代理漏了add_header。确认后端CrossOrigin或全局CorsFilter生效即可图片上传失败MinIO报Bucket不存在第一次使用MinIO时桶不会自动创建需要在代码里加bucketExists()判断不存在则makeBucket()打包后的页面白屏大概率是Vue里配置了绝对路径/assets建议把publicPath改为./相对路径数据库连接不上确认application.yml里的url写了时区参数serverTimezoneAsia/ShanghaiMySQL 8必须加否则报时区错误最后再说一个容易忽视的细节服务器上跑Spring Boot不要在nohup日志里记录敏感信息。SQL日志打印到控制台没问题但生产上建议关闭mybatis-plus的SQL日志输出避免表结构和参数写进日志文件。5. 实际答辩中容易被追问的问题把系统做出来只是第一步。你要在答辩前把下面几个问题想清楚这才是展示你对项目真正理解到位的地方。第一个问题是为什么要用消息队列如果回答“因为大家都用所以我也用”那基本就凉了。正确逻辑是置换意向创建后需要给卖家发通知如果同步调用短信/站内信接口高峰期会出现响应变慢用RabbitMQ把通知动作异步化后核心交易链路的接口响应时间从“通知耗时业务耗时”降低为“仅业务耗时”。哪怕你的站内信只是写一张通知表这个设计思路也是对的——把非核心链路从主链路里剥离。第二个问题是怎么防止“超卖”或重复置换答案不是用synchronized而是数据库层面的幂等约束和状态机流转控制。实际上可以用一个唯一索引——在t_exchange_order表上建(goods_id, status)的部分索引或者依赖上面的update ... where status 旧状态来保证并发安全。只要你提到“乐观锁”“CAS思想”,老师就会知道你理解的不只是CRUD。第三个问题是为什么选了Spring Boot不要回答“因为简单”。要答出两点一是Spring Boot内嵌容器、自动装配让开发部署变得更高效二是大量Starter的存在让第三方技术MinIO、Redis、RabbitMQ可以快速集成而不需要像传统SSM那样逐步写Bean配置。如果有余力可以提一下自动装配的核心原理——EnableAutoConfiguration配合META-INF/spring.factories这个之前也是热词榜单里的高频问题能讲清楚就是加分项。6. 项目扩展方向让毕设从“能做”到“有亮点”如果时间充裕下面几个方向可以挑一个做进系统里直接提升项目的技术深度。一个是基于HanLP的内容合规检测。校园二手系统最大的治理难题是商品标题/描述里可能存在违规词。HanLP是一个开源中文NLP工具包把商品标题通过它的分词和词性标注接口跑一遍再结合一个自定义敏感词表做匹配审核效率会明显提升。我之前看到一个实现思路管理员审核列表里系统自动给每条商品打一个“内容风险等级”标签低风险直接自动通过高风险才有人工复核。这个功能放在“系统管理”模块里是答辩的杀手锏——它体现了算法与业务的结合。另一个是基于WebSocket的实时聊天。置换双方在确认意向后需要一个站内沟通渠道总不能把微信号写在留言板里。引入Spring Boot的WebSocket模块在置换意向创建后为买卖双方建立一个聊天会话前端用stomp.js连接后端用MessageMapping处理消息收发。这个功能除了实用性强还能在论文里写“基于WebSocket的长连接技术实现低延迟的实时通信”比单纯轮询的体验好一个量级。还有一个相对简单的加分项是数据导出。管理员后台提供商品数据导出Excel功能用EasyExcel或Apache POI生成报表。别看这个功能小它在毕设里的价值是能体现“系统不仅能用还能辅助管理决策”写论文时可以作为一篇独立的“系统管理子模块”来写。我个人在实际操作中的体会是毕设项目最怕的不是功能少而是每个功能都是“照抄照搬”的模板代码。你在关键点上有自己独立的思考——哪怕只是在一个并发控制上用了乐观锁、在一个存储方案上选了MinIO、在一个通知链路上用了消息队列——就足以让项目在答辩时脱颖而出。校园二手置换系统这类题目虽然常见但它覆盖了Java Web开发的主线技术栈而且业务逻辑完整只要做得扎实、讲得清楚它就是一份很好的毕业设计作品。