戈玄白今天要做题我最近看了一个非常典型的毕设选题：Java SpringBoot基于微信小程序的高校二手商品交易平台系统校园论坛。很多人第一反应是“这不就是闲鱼套壳嘛”，但只要认真拆一遍需求和实现，就会发现校园场景的二手交易和多模块论坛组合，远比想象中复杂。账号信任怎么建、商品状态怎么切、论坛发帖怎么防垃圾内容、小程序的登录态怎么和Spring Boot后端打通，这些都是能直接写进答辩PPT里的技术点。
这篇内容不是标题党式的“源码展示”，而是把我对这类系统的理解、数据表设计逻辑、后端分层方式、小程序端联调心得，以及线上部署容易翻车的细节，全部梳理出来。无论是正在做毕业设计、课程设计，还是想拿一个完整项目去面试讲项目，都可以照着这个思路去复现和扩展。
1. 高校场景里的二手交易，不是“闲鱼套壳”那么简单
1.1 用户边界和角色权限要先收敛
很多同学做校园类系统，第一件事就是打开Navicat开始建表，这是最容易被带偏的。校园二手交易和普通二手交易最大的区别在于“信任半径”。闲鱼有芝麻信用、支付宝担保、平台客服，而这些能力平台方不会给到一个校园小项目。那么校园平台靠什么建立信任？靠的是“本校学生”这四个字。
所以整个系统的角色必须非常清晰：游客、注册用户、已认证学生、管理员。游客或者刚用微信登录但还没认证的用户，只能浏览首页、搜索商品、看帖子；想要发布商品或者下单，就必须提交学生认证信息；管理员则负责审核认证、管理商品、管理帖子。
这个权限设计不只是在页面按钮上做控制，后端接口更需要强校验。真实开发里最容易出现的问题就是前端把“立即购买”按钮隐藏了，但别人直接调接口也能下单，导致认证体系形同虚设。角色权限一定要在后端过滤链或者AOP切面里做统一校验。
1.2 先画出完整业务闭环，再决定功能模块
不要一上来就整天琢磨“小程序页面应该有几个tab”。交易类系统的核心是闭环，我建议立刻用文字把流程走一遍：
认证学生发布闲置商品 → 管理员审核上架 → 其他学生浏览/搜索/收藏 → 买家发起订单 → 卖家确认成交 → 双方线下约定地点 → 买家确认完成 → 订单完成。
这个闭环看起来普通，但里面藏着非常多的边界问题。比如商品上架后又被别人下单了怎么办？订单还在进行中，商品要不要下架？买家一直不确认线下交付，订单卡在中间怎么办？如果平台没有真实支付渠道，又该如何保障双方权益？
我见过很多失败项目，代码写了一大堆，数据库表也有二十几张，但核心的“订单状态机”完全没设计，逻辑全都写在了一个updateGoodsStatus()方法里。状态靠if判断硬堆，最后自己都理不清。提前把闭环走一遍，能让后面的设计省很多事。
1.3 论坛模块不是“加分项”，是二手交易的重要入口
单看“高校二手交易平台”，很多人会把论坛当成一个附属模块，好像只是为了让页面更丰富才加的。但实际上在校园场景里，二手交易的需求大量藏在“求购”“拼车”“考研资料转让”“失物招领”这类帖子中。
论坛的意义在于把交易从“人找货”变成“人找人”。一个同学发帖求购某本绝版教材，评论区里可能就有学长回复“我有一本，私聊我”，这时候交易就自然发生了。所以我在设计时会把“帖子”和“商品”做成两套独立内容模型，但帖子内容里可以“@”商品或者直接跳转商品详情。
另外，论坛本身也会有独立的生命周期：发帖、审核、置顶、加精、评论、点赞、举报。如果做得好，论坛才是这个系统日活最高的模块。所以不要把它当做一个简单评论板，需要按内容社区的方式进行治理。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Spring Boot后端如何分层，才能扛得住毕设答辩和二次开发
2.1 Spring Boot并不是“因为题目要求”才选的
这个项目标题里已经锁定了Java和Spring Boot。很多人会问，为什么不用更轻量级的Flask或者Node.js？最直接的原因是Java生态的稳定性和资料完备度，尤其在校园范围内，你遇到的大多数问题都能搜索到现成方案。
具体版本选择上，我建议使用Spring Boot 2.7.x + JDK 1.8 + MyBatis-Plus + MySQL 5.7/8.0 + Redis。Spring Boot 3.x虽然已经出来很久，但如果你不是特别有把握，不要轻易碰。Spring Boot 3.X默认使用Jakarta EE命名空间，很多老教程和老依赖都不兼容，一旦遇到“包找不到”或者“javax.servlet报错”的问题，排查起来会非常消耗时间。
ORM层用MyBatis-Plus最大的好处是单表CRUD不用手写SQL，分页查询直接用IPage就能解决。但要注意，MP的QueryWrapper不要滥用，复杂多表统计还是老老实实写XML里的SQL，不然索引用不上，数据量稍微大一点整页接口就慢了。
2.2 工程目录这样拆，中期改需求不头大
我见过不少同学的Spring Boot里只有四个包：controller、service、mapper、model，所有代码都堆在这几个包里。订单逻辑和日志逻辑混在一起，微信登录和论坛功能挤在同一个Controller里，这导致后期加一个功能要改动好几个文件，很容易出Bug。
如果是我来做，工程结构会分成这样几块：
text复制com.campus.trade
├── common
│ ├── exception
│ ├── result
│ └── constant
├── config
├── controller
│ ├── app // 小程序端接口
│ └── admin // 后台管理端接口
├── service
│ └── impl
├── mapper
├── entity
├── dto
├── vo
└── util
common/result里放统一返回对象Result<T>和全局异常处理器，dto存放前端传入的请求参数对象，vo专门用于返回给前端的视图对象，和数据库entity分开。这样做的最大好处是，别人看你的代码时，可以单从目录结构就理解整个项目的脉络，而不是顺着方法名之间跳来跳去。
2.3 接口要统一返回、统一鉴权，别在Controller里写任何判断逻辑
小程序端和后端交互，一般都会走一个请求封装。如果后端接口一会儿返回{code:0, data:{}}，一会儿直接返回裸数组，前端封装层就会非常痛苦。
我推荐定义一个极简的Result<T>结构：
java复制public class Result<T> {
private Integer code;
private String message;
private T data;
}
业务失败直接抛出业务异常，由全局异常处理器统一捕获转换。例如用户未登录、学生未认证、商品已下架等，都不需要在Controller里通过return Result.error("...")去写一堆分支，直接抛异常会让代码干净得多。
鉴权方面，由于微信小程序不支持传统的Cookie同源会话，后端最好基于token做认证。用户通过wx.login获取临时code，请求后端登录接口获取先入openid，再生成一个token返回给前端。前端把它放在请求头Authorization里，后端在拦截器中解析并保存当前用户上下文。token可以放在Redis里，设置合理的过期时间。别用纯JWT不带服务端失效机制，否则用户被拉黑后token仍然有效，会非常尴尬。
3. 核心表设计：把账号可信、商品流转和论坛发言串起来
3.1 用户表和校园认证表要分开设计
很多学生会把用户信息、微信openid、学号认证信息全部塞到user表里。这样做也不是不行，但后续如果想要扩展“一个微信账号可以绑多个角色”或者“学生毕业之后账号变成校友”这类场景，就非常挤。
我会拆成两张表：
t_user：存放微信侧的账号身份，例如id、openid、nickname、avatar、phone、role、status、create_time。t_student_certification：存放校园身份认证记录，user_id、real_name、student_no、college、grade、card_image、status、audit_remark。
这样设计的好处是：一个用户可能提交多次认证申请，管理员能看到每一次提交的记录，而不是直接把用户表里的real_name覆盖掉。认证状态有0待审核、1通过、2驳回三种，发布商品和下单前都要去查最新一条认证状态，而不是只看用户表某个字段。
3.2 商品表要支持完整状态流转
商品表是整个交易系统的核心，字段设计上一定要把“状态”和“冗余字段”想清楚。我的建议字段如下：
text复制t_goods
- id
- user_id // 卖家ID
- title
- description
- category
- price // 商品当前价格
- original_price // 原购价，可选
- cover_image
- quality // 成色
- status // 0草稿 1待审核 2上架中 3交易中 4已售出 5下架
- view_count
- create_time
- update_time
这里要注意的是“交易中”和“已售出”是两个状态。买家下单但还没有线下确认之前，商品状态应该是“交易中”，而不是直接“已售出”，否则中途订单取消，商品又得从“已售出”改回“上架中”，状态非常容易乱。商品表还要加一个version或者利用status做乐观锁，避免两个人同时对同一件商品发起下单，后一个请求把商品状态覆盖掉。
商品图片使用单独的t_goods_image表（id, goods_id, url, sort_no），而不是把所有图片URL拼成一个字符串存到goods表里，这样图片数量不一致、排序调整都很方便。
3.3 订单表里要保留交易快照和线下交割信息
订单表最好叫t_goods_order，因为order在MySQL里可能不是唯一保留字但最好不要直接使用。订单设计上不是简单记录“谁买了什么”，还要把线下交易需要的信息放进去。
text复制t_goods_order
- id
- order_no
- goods_id
- buyer_id
- seller_id
- price // 成交价格快照
- meet_place // 约定线下交易地点
- contact_info // 联系方式
- trade_code // 买家用于确认的核销码
- status // 0待卖家确认 1待线下交易 2待买家确认 3已完成 4已取消
- finish_time
- create_time
为什么订单里要有price字段？因为商品价格后续可能被卖家修改，如果不做快照，订单记录里的金额也会跟着商品表变化，那订单才算真正的“记录”。trade_code的设计可以非常简单：卖家确认订单后，系统生成一个随机6位码给买家，双方线下碰面交易时，买家把这个码告诉卖家或者在小程序里点“确认到货”，订单就自动完成。整个流程不需要真实支付，避开了平台无支付牌照的风险，也符合校园场景的日常习惯。
3.4 论坛帖子、评论、点赞和消息表
论坛模块的核心表至少有：
text复制t_post
- id
- user_id
- category // 求购 / 闲置 / 二手 / 拼车 / 失物招领
- title
- content
- images
- view_count
- like_count
- comment_count
- status // 0审核中 1正常 2违规下架 3删除
- is_top
- is_essence
- create_time
评论表t_comment至少要包含post_id、user_id、content、parent_id，parent_id用于支持楼中楼，否则做成平铺评论虽然简单，但体验上很粗糙。点赞表t_post_like用user_id + post_id建唯一索引，防止一个人给同一个帖子反复点赞。
消息表稍微讲究一点，我一般会把消息内容统一成一种结构：type（评论、点赞、订单状态通知、认证结果通知）、from_user、to_user、biz_type、biz_id、content、is_read。这样小程序端只需要一个消息列表接口，就能把所有通知都拉出来，不需要每一种通知单独建表。
4. 小程序端从登录到收货：一条主流程的完整实现路线
4.1 登录设计：别再去拿微信头像昵称当登录态
小程序端最容易被坑的就是登录。微信官方很早之前就调整了用户信息授权策略，直接调wx.getUserInfo弹窗授权的方式基本不可用了。如果你在做一个学习项目，应该走最稳妥的静默登录方案：前端调wx.login拿到临时code，把code传给后台，后台调用微信接口换取openid和session_key。
之后小程序通过uni.setStorageSync('token', token)保存登录态，并在每次请求时带上Authorization: token。头像昵称可以后续通过个人资料编辑页手动选择或填写，而不是一进来就强制弹窗。很多同学运行项目时报“获取登录后的微信用户失败”，基本都是老的授权代码造成的。
4.2 商品列表与搜索分页
首页商品列表不能一次性从数据库查出所有数据返回给小程序。正确的做法是后端接口接收page和pageSize，例如每页10条，返回total和当前页列表。小程序滚动到页面底部时（onReachBottom），把page加一后继续请求，追加到本地数组；下拉刷新时把page重置为1再重新请求。
搜索功能至少要支持按商品标题模糊匹配、按分类筛选、按价格升降序排序。用MyBatis-Plus时可以直接在LambdaQueryWrapper里动态拼条件。需要注意，价格排序不要让前端拿到全部数据再排序，那是错误示范；分页和排序要放到SQL里面执行，否则数据量一大页面马上就卡。
4.3 发布商品的路径要带上认证门槛
小程序端发布商品，“认证未通过”的状态不应该隐藏入口，而是应该清楚提示用户去“学生认证”。认证入口放在“个人中心”，表单一般包括姓名、学号、院系、年级，然后还需要上传一张校园卡或学生证的清晰照片。后端把照片存起来，等待管理员在管理端审核。
这里有一个体验细节：当用户提交认证后，小程序端要能实时显示“审核中”“已通过”“已驳回”状态，驳回原因也要展示出来。不要只给用户一个“认证结果已更新”的模糊提示。
商品发布表单通常包含标题、描述、分类、价格、原价、成色、图片。图片上传前可以在小程序端做压缩，比如使用wx.compressImage，避免直接传原图，原图体积大且增加服务器存储压力。后端接收上传图片时要限制文件大小和类型，同时重命名文件，防止用户上传带中文名或恶意后缀的文件。
4.4 订单状态推进的并发防护
订单流程的关键逻辑不在前端，而在后端接口的原子性。当买家点击“我想要”时，后端应该先校验当前商品状态是否为2（上架中），然后开事务：把商品状态从2改成3（交易中），再插入一条订单记录。
这种操作要用“条件更新”避免并发问题：
sql复制UPDATE t_goods SET status = 3 WHERE id = #{goodsId} AND status = 2
如果这条更新的影响行数为0，说明商品已经被别人抢先下单了，直接抛出“商品已被拍下或已下架”异常。这个方法比先查询再更新更可靠，因为数据库层面已经帮我们做了并发控制。
订单后续的状态推进只需要按顺序：卖家确认 → 生成交易码 → 线下见面 → 买家确认完成。每一步后端都要校验当前用户是不是订单中的卖家/买家，不能只看前端传过来的orderId就盲目更新。很多毕设系统就是因为缺少这个权限校验，导致随便登录一个账号都能改别人订单状态。
5. 论坛模块的“隐形工作”：文本安全、热度计算与消息通知
5.1 帖子内容安全不能只靠“等等再改”
校园论坛是开放发言的模块，如果不做内容过滤，很容易被垃圾内容和广告刷屏。最基础的做法是在后端发布帖子和评论时做一次敏感词过滤，把明显违规的词汇替换成**或者直接拒绝发布。演示项目里可以内置一个敏感词列表，并把过滤逻辑抽成一个工具类。
如果项目想往生产级靠，可以继续接微信官方的内容安全检测接口，对用户发布的文本内容进行异步检测，检测结果再异步回调修改帖子状态。图片方面也要避免只做上传不做审核，至少后台管理端要在帖子和商品图片旁边提供“下架”“删除”按钮，否则出了纠纷无法及时处理。
帖子状态应该区分“待审核/正常/违规下架/删除”，而不是简单加一个delete_flag。这样管理员处理举报时，可以看到是用户自删还是管理员下架。不要小看这个字段，真到答辩演示“管理员审核功能”时，你会发现没有这个字段很难自圆其说。
5.2 热帖排序：用统一公式而不是人肉置顶
论坛页面常见的排序方式是“最新”“最热”。最新排序很容易实现，按create_time倒序即可。但“最热”如果只按照comment_count排序，老帖子会永远霸占顶部，新发的优质内容很难被看到。
比较简单的热度分公式可以是：
text复制score = view_count * 1 + like_count * 3 + comment_count * 5
在SQL排序时直接按score DESC排。如果想更精细一些，可以加时间衰减。比如用score / POWER(1.5, 距离发布的时间/24小时)，让发布时间越短的帖子权重越高，这个计算放在SQL里也很快，但演示项目不一定需要这么复杂。我个人的处理是三种Tab：最新、最热、精华。“精华”由管理员从后台打标，活动或版规类内容用is_top置顶。
5.3 站内消息通知的触发点要全部梳理
论坛评论了帖子、有人点赞、有人回复了自己的评论，这些都是消息触发点。消息通知不需要真的推送到微信，否则没有备案消息模板很难搞定。比较实用的做法是站内消息表，用户进入小程序时从消息接口拉取未读数，首页和个人中心显示一个小红点。
触发消息的时机要整理清楚。比如评论成功时要往t_message里插入一条“xxx评论了你的帖子”；订单状态变化时也要给买家或卖家推一条状态变更消息。别小看这部分的关联关系，我在做的时候遗漏了好几个触发点，比如卖家确认了订单但没有给买家发消息，买家反复刷新页面根本不知道订单已经被确认。
整合这些触发点的最好方式，是在Service层抽一个MessageService.notify(type, fromUserId, toUserId, bizType, bizId, content)方法，在订单、评论等核心操作成功后统一调用。不要在Controller层里调消息逻辑，否则以后接入消息队列时会很痛苦。
6. 从本地调试到上线演示：容易翻车的细节和交付清单
6.1 选一套稳妥的环境版本，别被“版本太高”坑死
最近经常能在技术社区看到各种“SpringBoot版本太高”的求助帖。针对这类毕设项目，我建议直接用以下组合，这套组合相对保守且资料最多：
| 组件 | 推荐版本 | 说明 |
|---|---|---|
| JDK | 1.8 | 绝大多数老教学代码兼容 |
| Spring Boot | 2.7.x | 稳定且支持JDK8 |
| MyBatis-Plus | 3.5.x | 内置分页和通用CRUD |
| MySQL | 5.7或8.0 | 5.7更省内存，8.0也没问题 |
| Redis | 5.x/6.x | 主要用户token和缓存 |
| Maven | 3.6.3或3.8.x | 镜像源建议修改阿里云 |
| 微信开发者工具 | 最新稳定版 | 本地联调用稳定版即可 |
很多项目跑不起来的直接原因是Maven下载依赖超时或者下载到一半失败了。遇到这种情况可以检查一下settings.xml里的镜像源，改成国内镜像会让后续步骤顺畅很多。运行项目第一件事不是启动Application，而是先把application.yml里的数据库地址、密码、Redis配置都改成自己的本地配置。
6.2 小程序联调时，合法域名校验可以暂时关掉
后端还在本地运行的时候，小程序默认是没法直接请求http://localhost:8080的。微信开发者工具里可以临时打开“详情 → 本地设置 → 不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”，这样开发阶段就能直接访问本地接口。
但这里要提醒一句：这个开关只对开发者工具有效，手机真机预览时必须使用HTTPS域名。所以正式演示前，要么把后端部署到一台带HTTPS证书的服务器，要么给后端配好HTTPS证书再用手机预览。如果只是录一个“运行视频”，可以在开发者工具页面录，画面观感也很不错。
6.3 线上部署最容易踩的三个坑
第一是Redis没启动或者配置错误。很多项目的登录、验证码、缓存都依赖Redis，本地启动后端时如果Redis服务没有启动，很容易出现“接口报错但数据库本身没问题”的奇怪现象。排查顺序是：先看Redis，再看MySQL，再看依赖服务。
第二是文件上传目录没有权限。图片上传到服务器之后，前台经常能通过路径访问到文件，但过一会或者换到其他环境就打不开。多数情况是上传目录没有设置成静态资源目录，或者nginx没有把图片路径映射到本地磁盘目录。建议项目里将图片存储路径抽取成配置项，不要硬编码成本地绝对路径。
第三是数据库保留字和字符集。建表时如果盲目使用description、order、rank等字段名，某些SQL版本下执行会报错，推荐统一使用反引号？其实更好的做法是起名时避开保留字。另外，MySQL数据库的表默认字符集要设成utf8mb4，否则用户写入emoji表情会直接保存失败。
6.4 源码、文档、运行视频、讲解视频该怎么组织
这个项目标题里带着“源码+文档+运行视频+讲解视频”，很多人会觉得这是商品描述，但我更愿意把它理解为一份优秀的交付标准。就算你不是花钱买项目，而是自己从零做项目，也建议用同样的交付逻辑来管理你的产出。
文档建议至少包括四份：需求分析报告、数据库设计说明、接口文档、部署说明。其中数据库设计说明尤其重要，要把每张表的用途、核心字段、表之间的关系描述清楚。运行视频不要只拍“程序起来了”，而是从导入数据库、启动Redis、启动后端、打开小程序开发者工具开始演示，直到完成一次完整的交易流程。讲解视频则可以针对代码里的核心类做逐段解释，比如登录流程、订单状态机、论坛热度分计算。
这部分内容对答辩和面试特别有价值。你可以很自然地在面试里说：“这个项目我做了源码之外的四份文档，并且录了完整的演示视频，每一个核心模块我都能讲清楚为什么要这么设计。”这比干巴巴地说“我做了二手交易系统”要有说服力得多。
最后几个建议
如果你正打算照着这个方向做一个类似项目，我特别建议先把“学生认证”和“订单状态机”彻底想透。这两个模块是校园交易系统的灵魂，而不是简单把用户表加两个字段。
另一个小技巧是：开发和测试阶段多准备几个测试账号。一个号当管理员，一个号当卖家，一个号当买家。每测试一次完整闭环，就把订单状态、商品状态的变化记录下来，形成自己的“状态流转测试表”。这样项目最后验收时，你能非常自信地回答任何一笔订单当前处于什么状态、为什么会卡住、异常情况怎么恢复。
我在实践过程中踩过最痛的坑，就是以为把功能做完就万事大吉，结果自己都不知道订单在哪种情况下会变成死数据。后来把状态机列成表格、用测试脚本把所有分支都跑一遍，整个系统才算真正“立得住”。如果你正在写代码的初期，希望你跳过这个坑。