微信小程序跳蚤市场毕设全解析：SSM框架与交易闭环设计

最近整理了一个有意思的毕业设计项目，基于微信小程序的跳蚤市场设计与实现，后端走的是SSM框架，也就是Spring + SpringMVC + MyBatis这套经典组合的校园二手交易平台。这个项目如果只是做出来一个“能发布商品、能浏览列表”的Demo，其实并不难，难的是把交易闭环里那些容易被忽略的环节，比如登录态、商品状态流转、图片处理、搜索排序这些东西串起来，才能真正达到毕业设计答辩时能讲清楚、能演示完整流程的水平。

这篇文章想把我在做这个项目过程中的完整思路写出来，包括需求层面的推演、技术选型为什么锁定了SSM而非其他框架、数据库和接口怎么设计、小程序端和后端是怎么一步步联调的，以及我在实际编码里踩过的一些比较典型的坑。如果你正在做类似的校园二手交易小程序，或者本身就在纠结这类毕设该从哪里下手，这篇文章应该能省你不少摸索的时间。

1. 这类需求背后的真实痛点：二手交易不是只做一个列表页

很多人拿到“基于微信小程序的跳蚤市场设计与实现”这个题目，第一反应就是：这不就是一个商品列表加一个发布页吗？等真正动手做完你会发现，拼凑出一个能看的主界面并不难，真正的麻烦全在那些看不见、却在用户实际使用中随时会暴露问题的地方。

从用户角度讲清楚这个平台到底要解决什么问题。跳蚤市场面向的是校园场景，用户有毕业生卖书、买书，有同学互相转让闲置电器、衣物，也有一部分人是想找便宜好用的二手物品。核心诉求是三个：

第一，用户要能快速发布一件闲置物品，上传图片、写价格和描述，最好从拍照到上架不超过两分钟。这个是整个平台的使用动机，如果发布流程繁琐，用户试一次就不想再打开。

第二，买家要能按分类浏览、关键词搜索、看商品详情，并且能联系到卖家。这里要分清楚“联系”这个动作怎么做。很多毕设项目做成了站内IM聊天，功能是好看，但轮子造得太大，从技术实现和项目管理角度都未必合适。我在这类项目里通常建议做“显示微信号或手机号”的方案，或者做“我要留言”的简单表单。原因后面会详细说。

第三，卖家要能管理自己发布的商品，进行下架、编辑、标记为已售出等操作。商品不能一直挂在平台上，必须有一个状态流转的生命周期。

从管理员的视角出发，隐藏的需求则是审核和统计数据。虽然大多数毕设项目对后台管理模块的演示深度要求不高，但设计里得有，至少要展现“平台内容可控”的思路。管理员可以查看用户列表、商品列表，对违规内容做下架处理，查看基本的发布数量、分类占比统计。

所以我在真正敲代码之前，先进行了一次需求拆解，把项目目标分成了几个层面：

• 用户端核心功能：登录授权、发布闲置、浏览分类、关键词搜索、商品详情、留言联系、个人中心（我发布的、我卖出的、我买到的）
• 管理端核心功能：登录、用户管理、商品管理、分类管理、上架/下架操作、基础数据统计
• 业务规则：商品状态包含在售、已售出、已下架三种；同一件商品只能被买家“我想要”联系，不会出现多个人下重复订单的问题；商品数量达到预警状态时要提示
• 场景延伸：这个是跳蚤市场的特点，商品信息粒度比较粗，不需要像电商系统那样处理SKU、库存、优惠券这类复杂逻辑，所以他的业务建模可以被控制在一个合理的复杂度区间。

明白了这些，才能解释为什么后端架构要用SSM而不是随便写一个Servlet，也才能合理地去设计数据库和接口。没有这一步，后面的开发就只是在“照着教程敲CRUD”。

2. 技术选型为什么盯着SSM不放——毕设项目的取舍逻辑

选技术栈，首先是想清楚这个项目给谁看、用来干什么。基于微信小程序的毕设项目，代码一般要过两关：第一关是导师和评审老师看整体设计是否合理，第二关是答辩时老师可能会直接翻开代码或跑起来看效果。

SSM，全称是Spring + SpringMVC + MyBatis，在当前的毕业设计环境里是一个非常稳的选择。从教学评价角度来说，SSM一定程度上已经代表了Java Web课程体系里足够经典、足够讲究“分层”的框架组合。Controller—Service—Mapper三层结构清晰，MyBatis的SQL写在XML里，反而更好向老师解释每一步在做什么。相比之下，Spring Boot虽然开发效率更高、配置更少，但很多东西是被“约定”掉的，答辨的时候一旦被问到“Spring Boot的自动配置原理”，不少同学反而不容易讲得清楚。SSM的优势在于结构透明：所有配置都在web.xml和Spring配置里显式地写着，每个Bean怎么创建、事务怎么切，都能看得见摸得着。当然这个体验只是针对毕设项目，不是否定Spring Boot在生产环境里的碾压级效率。

小程序的端上技术选用原生微信小程序。为什么不选uni-app？uni-app确实有一个代码编译到多端的优势，但对于这种只跑微信端的项目，引入第三方编译层反而增加了不确定性。原生小程序组件生命周期直接、API调用清楚、调试的时候报错能找到非常直接的原因。而且很多在微信网页开发里的概念，比如rpx动态尺寸、Page和Component的区分，在原生开发者工具里都能获得最原汁原味的支持。如果你是第一次做小程序，直接用原生，不要绕路。

整体的技术栈与运行环境如下表：

|