金宇澄1. 项目概述与价值分析
1.1 项目定位与核心需求解析
先说结论：这个"闲一品"闲置品交易平台，本质上就是一个典型的SpringBoot商城类练手项目，只不过业务方向切在了二手闲置交易这个场景上。要我说，在毕设选题里，这种场景选择其实挺聪明的。一方面它避开了传统电商那套复杂的供应链体系，比如多级库存、物流轨迹对接、支付网关分账这些"大厂专属"的痛点，另一方面又能把用户管理、商品发布、订单交易、后台审核这些核心业务完整地串起来，用来检验一个Java学生对Web开发全流程的掌握程度，再合适不过。
从毕设答辩的角度看，这类项目的逻辑链条非常清晰：用户注册登录后可以发布闲置商品，其他用户浏览、搜索、收藏、下单购买，卖家处理订单，管理员负责审核商品和用户管理。整个闭环是完整且自洽的，评审老师一眼就能看懂，问起问题来也容易答。比起一些花里胡哨的"智能推荐系统"或者"大数据分析平台"，这种务实型的业务系统反而更容易拿高分。
我再补一句基于多年实操经验的判断。很多同学做毕设容易陷入一个误区，就是总想往项目里堆技术，今天加个Elasticsearch做搜索，明天加个RabbitMQ做消息队列，后天再上Redis做缓存。表面上看技术栈很丰富，但到了实际答辩和代码走查环节，一问为什么用、原理是什么、落地怎么配，就一问三不知。这个闲置品交易系统最大的好处就是，技术选型全部踩在SpringBoot的核心舒适区内，每一处技术使用都能讲出明确的业务理由，既不会显得敷衍，又不会失控。
1.2 技术选型与架构设计思路
技术栈这一块，SpringBoot + MyBatis-Plus + MySQL + Vue（或Thymeleaf）的组合，可以算是目前Java毕设圈的"标准答案"了。为什么这么说？我给你拆开来看：
后端选型：SpringBoot 2.x + MyBatis-Plus
SpringBoot不用多说，现在的Java后端事实标准。它的自动配置机制、起步依赖、内嵌Tomcat这些特性，能让学生把精力集中在业务代码上，而不是折腾XML配置文件。更关键的是，SpringBoot在面试中的出现频率极高，做完这个项目之后，你对自动配置、starter机制、Bean生命周期这些知识的理解会深一个层次，面试时聊起来也有底气。
MyBatis-Plus这个选择更是务实。相比较原生MyBatis要手写大量XML映射，MyBatis-Plus提供了BaseMapper，单表CRUD完全不用写SQL，分页插件一行配置就能用，代码量直接砍掉一半。我自己见过太多同学在毕设里写了一大堆重复的Mapper方法，实际上是浪费时间。当然，如果你项目里涉及多表联查，还是要自己写@Select注解或XML里的SQL，这也能体现出数据库基本功。
前端选型：Vue + Element UI（前后端分离）
现在的主流毕设标配。前后端分离模式的好处有三点：第一，前端静态资源可以独立开发调试，不用每次改个按钮都要重启后端；第二，接口联调方式接近企业真实开发模式；第三，Vue的响应式数据绑定比JQuery操作DOM要高效太多，页面交互做起来轻松。
如果不想折腾Node环境和Vue CLI，也可以用Thymeleaf服务端渲染，一个SpringBoot包搞定所有页面，部署特别省心。但我的建议是，只要前端基础还行，尽量上Vue前后端分离。答辩时展示的架构层次感完全不同，而且现在市面上的毕设视频和源码也基本都沿着这个路线走。
数据库选型：MySQL 5.7 / 8.0
没有悬念的选择。MySQL在个人项目和中小型系统里就是最稳的答案，免费、社区活跃、资料多、Navicat可视化工具好用。5.7和8.0都可以，8.0在性能和JSON支持上更强一些，但5.7更稳妥、和老的JDBC驱动兼容性更好。建议装8.0，同时把MySQL驱动版本调到对应的8.x。
为什么不建议上微服务？
这个必须重点说。我见过好几届学生，学了点Spring Cloud的皮毛，非要在一个毕设项目里拆出什么用户服务、商品服务、订单服务三个模块，结果服务间调用用Feign，分布式事务解决不了，最后熬几个通宵回到单体架构。毕设项目的时间精力是有限的，单体应用 + 模块化代码分包，完全能撑起这个业务规模。微服务是给团队协作和流量弹性的场景准备的，一个毕设硬上微服务，只会暴露你在分布式理论和工程实践上的薄弱。
1.3 核心业务流程梳理
这个项目的核心业务链路其实并不复杂，整个系统中你只需要理清三个角色：
普通用户（买家/卖家双角色合一）：注册后既可以发布自己的闲置商品，也可以浏览购买其他人的商品。这就意味着用户表不需要区分买家表、卖家表，一个user表加个角色字段就搞定，商品表里用user_id关联发布者即可。
管理员：负责审核商品是否合规（比如有没有违禁品、广告、垃圾信息），管理用户状态（封号、解封），维护商品分类，查看平台运营数据。
游客（未登录用户）：可以浏览商品列表、查看商品详情，但下单、收藏、发布商品都需要登录后才能操作。这种权限控制通过拦截器 + 用户登录状态校验来实现。
业务链路从用户角度可以概括为：注册登录 -> 发布闲置 -> 管理员审核 -> 商品上架展示 -> 买家浏览搜索 -> 加入购物车/直接下单 -> 订单状态流转 -> 买家确认收货 -> 交易完成。
有一点值得注意：二手交易平台和普通电商在订单流程上有区别。普通电商有库存概念，二手平台一般来说一件商品只有一件，卖出去就下架。所以商品表里需要一个status字段控制状态：0待审核、1出售中、2已售出/下架。这个状态流转逻辑写清楚，数据库设计就成功了大半。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心功能模块与数据库设计解析
2.1 功能模块划分
按毕设论文的标准格式，功能模块一般分为用户端和管理端两个角色维度，再加上公共模块，画功能结构图的时候分层展示即可。
用户端功能：
- 注册登录：手机号+密码注册、登录、退出
- 商品浏览：首页商品列表、按分类筛选、关键字搜索、商品详情
- 商品收藏：收藏商品、取消收藏、我的收藏列表
- 发布闲置：填写商品信息、上传商品图片、设置价格和成色
- 订单管理：作为买家查看我买到的、作为卖家查看我卖出的
- 个人中心：修改个人信息、修改密码、查看我的发布记录
管理端功能：
- 管理员登录（独立账号体系或复用用户表加角色字段）
- 商品审核：审核通过/拒绝、下架违规商品
- 用户管理：查看用户列表、启用/禁用账号
- 分类管理：增删改查商品分类
- 数据统计：平台商品总量、用户量、订单量统计（简单的SQL count + 图表展示）
这里我提醒一句：功能不是越多越好，做到位比铺得开更重要。很多同学喜欢加一堆聊天室、评论、点赞功能，到Deadline前又做不完，最后每个功能都是半成品。二手交易平台的核心就是"发布—浏览—交易"这三个环节，把这几个功能打磨顺了，论文工作量已经完全足够。
2.2 数据库表结构设计
数据库设计是毕设论文里的重头戏，也是答辩时老师必问的环节。我按这个项目的业务需求，给你列一份经过实战验证的标准表结构：
user 用户表
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键自增 |
| username | varchar(50) | 用户名（唯一） |
| password | varchar(100) | 密码（BCrypt加密存储） |
| nickname | varchar(50) | 昵称 |
| phone | varchar(20) | 手机号 |
| avatar | varchar(255) | 头像URL |
| role | tinyint | 角色：0普通用户，1管理员 |
| status | tinyint | 状态：0正常，1禁用 |
| create_time | datetime | 注册时间 |
密码加密这一点我要特别强调一下。我见过太多学生毕设代码里明文存密码，甚至写死在SQL脚本里。这要是让答辩老师看到，轻则扣分，重则被质疑工程素养。Spring Security里自带的BCryptPasswordEncoder，或者用Spring的DigestUtils工具类做MD5加盐处理，二选一就行。从企业实际开发的角度来讲，BCrypt更安全，因为它是自适应哈希，自带盐值，防彩虹表攻击。
category 商品分类表
字段：id、name（分类名称）、sort（排序号）、create_time
分类表就这三个核心字段够了。建议预置几类常见二手商品分类：数码产品、图书教材、生活家电、服饰美妆、运动户外、其他。
goods 商品表
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| user_id | bigint | 发布者ID（关联user表） |
| category_id | bigint | 分类ID（关联category表） |
| title | varchar(100) | 商品标题 |
| description | text | 商品描述 |
| price | decimal(10,2) | 价格 |
| original_price | decima |