“基于JavaSpringBootSSM基于协同过滤算法的跳蚤市场商品推荐系统”——这名字一看就是典型的毕设/课设标题但说实话很多同学拿到这类题目最担心的问题往往是推荐算法怎么落地SpringBoot和SSM怎么同时出现跳蚤市场这个场景到底有什么特殊之处这篇文章我会把整个系统的设计思路、技术选型、协同过滤算法的工程化实现、数据库建模、部署调试的坑全部按我实际做项目的方式给你拆开讲。无论你是拿这套东西做毕设还是想独立从零搭一个二手交易平台这篇文章都能帮你少走很多弯路。这里先给你一个结论这类系统的核心难点不在增删改查而在两个方面——推荐算法的质量能不能在产品上说得通以及整条数据链路用户行为采集→相似度计算→推荐结果输出能不能闭环。只要这两个问题解决代码层面的SpringBootSSM不过是一层壳。1. 项目定位与整体设计思路1.1 为什么跳蚤市场天然适合推荐系统跳蚤市场和淘宝、京东这类标准电商最大的区别在于商品是高度非标准化的。二手商品没有统一SKU同一款手机成色不同、配件不同、价格甚至能差出一倍买家搜索时很难用关键词精准表达自己的真实需求比如我不知道怎么搜“适合宿舍用的成色还行的蓝牙音箱”但我知道“我看了三个音箱类商品”。这种场景下基于行为的推荐比搜素引擎更靠谱。另一个原因是数据特征跳蚤市场用户行为稀疏度极高普通用户一天最多浏览几十个商品收藏个位数。这就让协同过滤算法中“相似用户”和“相似物品”的构建变得比较困难。所以单纯套用MovieLens那种评分矩阵的思路在二手场景下往往效果很差。必须引入浏览、收藏、点击、搜索记录多类行为加权而不是只用评分。这一点是整篇项目的核心也是答辩时最容易出彩的地方。1.2 这套系统解决什么问题从功能上看系统需要完成两条主线用户端是逛集市管理员端是管集市。用户能注册登录、浏览商品、搜索、收藏、加入购物车、下单购买、发布自己的闲置管理员能审核商品、管理用户、查看订单、配置推荐参数。这些功能用SpringBootSSM做CRUD完全没难度真正需要设计的是推荐模块。推荐模块解决的是“千人千面”的落地问题每个用户进入首页看到的推荐商品列表是不一样的。系统基于当前用户的历史行为找到和他兴趣相似的一群用户UserCF或者找到和他之前喜欢的商品相似的一批商品ItemCF把结果推到他面前。在整体架构上我采用了SpringBoot做容器整合SSMSpringSpringMVCMyBatis作为底层开发框架的组合。很多同学会问SpringBoot和SSM不是冲突吗其实不冲突。SpringBoot本身只是把Spring家族做了自动配置和约定化封装SSM中的SpringMVC和MyBatis完全可以在SpringBoot里继续使用。所以这个项目准确的表述是以SpringBoot为基础的SSM工程。1.3 开发者和毕设学生可以从这里拿走什么如果你是在校学生这套系统最核心的参考价值有三块推荐算法的完整工程化代码不是只调一个库而是手写相似度计算、推荐生成、以及数据预处理的全过程SpringBoot整合SSM的真实项目结构包括yml配置、多环境profile、MyBatisMapper分层一个“非标准电商”的数据库设计范本涵盖了商品维度、行为维度、推荐结果缓存维度。如果你是工作一到三年的Java开发者想转推荐方向这篇文章里的协同过滤实现也是一个不错的迷你样品让你理解推荐系统从离线计算到在线查询的基本链路。2. 技术选型与架构分层2.1 SpringBootSSM的工程落地方式既然提到SpringBootSSM第一步就是理清角色SpringBoot负责整体容器管理、自动配置、内嵌Tomcat、统一配置入口SpringMVC负责Web层路由Controller与视图交互MyBatis负责持久层Mapper接口XML映射SQLSpring负责事务管理、依赖注入把Service层的推荐逻辑和DAO层粘在一起。在实际工程里我推荐的工程结构是标准分层的单模块Maven工程而不是多模块因为毕设项目单模块打包部署更简单老师也更好查重和阅读。com.example.fleamarket ├── config // 配置类跨域、拦截器、公共字段填充 ├── controller // 用户端、管理员端Controller ├── service // 业务接口及实现 ├── dao // MyBatis Mapper接口 ├── entity // 数据库实体类 ├── dto // 前端交互数据传输对象 ├── utils // 推荐算法工具类、相似度计算类 ├── recommend // 推荐核心引擎用户类、物品类CF └── resources ├── mapper // MyBatis XML └── application.yml要注意的是controller中只做参数校验和响应封装所有业务逻辑下推到service层尤其是推荐模块的计算绝不能放在controller。原因不只是解耦更重要的是推荐计算耗时较长放在controller会导致请求被阻塞且不方便做缓存。实际项目中我专门加了一个RecommendContext工具类用来缓存当前批次推荐结果避免每次请求都重算。2.2 用户端和管理员端的功能划分用户端必须的功能注册用户名/手机号/密码、登录Shiro或JWT二选一、首页推荐列表、商品搜索按标题检索、商品详情轮播图基本信息发布者信息、收藏/取消收藏、加入购物车、提交订单、我的发布、我的买卖记录。管理员端必须的功能管理员登录、用户管理启用/禁用、商品审核上架/下架/删除、商品分类管理、订单管理、推荐算法参数配置相似度阈值、推荐商品数、行为权重。这套系统的管理员端我用的是独立的Controller前缀/admin配合拦截器做角色校验。前端没有用Vue而是直接用Thymeleaf模板引擎渲染因为毕设项目用前后端分离会额外引入Vue脚手架的篇幅而模板引擎能在一个SpringBoot工程内把页面和逻辑串完写代码和写文档都省事。2.3 推荐链路在技术架构中的位置推荐链路是整个系统中最容易“纸上谈兵”的部分实际开发中我这样设计的用户点击浏览、收藏、购买时同步写入行为日志表user_behavior_log定时任务Spring Schedule每天凌晨把行为日志加工成“商品-用户”行为矩阵保存在推荐基础数据表中推荐引擎读取行为矩阵利用协同过滤算法计算用户间的相似度或物品间的相似度计算出的推荐商品ID集合写入recommend_result表给每个用户维护一份离线结果在线接口查询推荐结果如果离线表没有数据则降级为热门商品列表。这套离线计算/在线查询的架构是生产环境推荐系统的常见简化版。写论文或者答辩时只要你能把这个链路讲清楚就已经超出大多数同类毕设的水平。因为多数同学的推荐模块是写完相似度算法就完事根本没有考虑“计算一次和查询一次”之分。3. 协同过滤推荐算法从原理到Java实现3.1 协同过滤的基本原理用大白话讲协同过滤的核心假设是过去行为相似的人未来的行为也相似。反过来过去被相似商品吸引的用户也会被同一个商品吸引。所以算法只需要回答一个问题谁和谁像。基于用户的协同过滤UserCF有三个步骤找到与目标用户兴趣最相似的一批用户找到这批用户喜欢过但目标用户没碰过的商品按相似度加权汇总生成推荐列表。这个适合用户少、商品多的场景但跳蚤市场用户量通常比商品少理论上UserCF是可行的。可它的缺点是当用户数量增多时计算用户两两相似度的开销是O(n^2)级别性能堪忧。基于物品的协同过滤ItemCF也有三个步骤计算商品之间的相似度找到用户历史上喜欢的商品集合把与这些商品最相似的、且用户没接触过的商品推荐给用户。ItemCF的优势是商品数量相对稳定计算好的相似度矩阵可以复用在线响应快。所以在我的系统里默认推荐引擎是ItemCF而UserCF作为备用切换通过管理端的配置项进行动态选择。3.2 相似度计算的工程实现在真实代码中我没有使用评分评矩阵而是构造了“行为权重矩阵”。因为跳蚤市场用户很少打分更多是隐式反馈。我设定了以下权重行为类型权重浏览商品1.0收藏商品3.0加入购物车5.0下单购买10.0这样对同一个用户-商品对把多类行为累加权值得到一个非零矩阵值。计算相似度时我用余弦相似度公式similarity(A, B) (A·B) / (||A|| × ||B||)通俗地解释把每个用户的商品权重向量看成一个高维空间中的箭头两个箭头的夹角余弦值越接近1代表两个人兴趣越一致。余弦相似度忽略了向量长度只看方向正好符合“有人只浏览了3个商品、有人浏览了200个商品但方向一致”应被视为相似的需求。编码实现时我不会直接对全量用户矩阵做双重循环那样时间复杂度高且内存爆炸。我维护一个“商品到用户”的倒排表只对共同行为过的用户对计算相似度。比如用户A浏览过商品x、y用户B浏览过y、z他们只在y上有共同交集就只计算A、B这一对在公共商品上的贡献。这是工程性能优化的关键。下面是我在UserCFCore类里计算用户相似度矩阵的关键代码片段用了一个Map嵌套结构来累加共现次数public MapInteger, MapInteger, Double calcUserSimMap(ListUserItemBehavior behaviorList) { // 构建 商品 - [用户列表] 的倒排表 MapInteger, ListInteger item2Users new HashMap(); for (UserItemBehavior behavior : behaviorList) { item2Users.computeIfAbsent(behavior.getItemId(), k - new ArrayList()) .add(behavior.getUserId()); } // 统计用户间共同行为商品数 MapInteger, MapInteger, Double simMap new HashMap(); for (Map.EntryInteger, ListInteger entry : item2Users.entrySet()) { ListInteger users entry.getValue(); for (int i 0; i users.size(); i) { int u1 users.get(i); for (int j i 1; j users.size(); j) { int u2 users.get(j); simMap.computeIfAbsent(u1, k - new HashMap()) .merge(u2, 1.0, Double::sum); simMap.computeIfAbsent(u2, k - new HashMap()) .merge(u1, 1.0, Double::sum); } } } // 归一化处理除以模长得到余弦相似度 MapInteger, Double userNorm new HashMap(); for (UserItemBehavior b : behaviorList) { userNorm.merge(b.getUserId(), b.getWeight() * b.getWeight(), Double::sum); } for (Map.EntryInteger, MapInteger, Double uEntry : simMap.entrySet()) { int u uEntry.getKey(); double uLen Math.sqrt(userNorm.getOrDefault(u, 0.0)); for (Map.EntryInteger, Double vEntry : uEntry.getValue().entrySet()) { int v vEntry.getKey(); double vLen Math.sqrt(userNorm.getOrDefault(v, 0.0)); double cos vEntry.getValue() / (uLen * vLen); simMap.get(u).put(v, cos); } } return simMap; }这里的weight来自行为表加工后的累加值也就是前面表格中的权重体系。之所以先统计共现再整体归一化是因为如果每遍历一个用户对就做一次余弦计算会产生大量重复的开根号操作。先算共现次数再算分母复杂度可控。3.3 推荐列表生成给用户推荐什么相似度矩阵算完并不意味着推荐完成了。用户相似度只是中间产物。真正生成推荐时要遍历与目标用户相似度最高的K个用户通常取K10把这些用户行为过的商品集合拿出来剔除目标用户已经交互过的商品然后按相似度加权汇总商品得分。这里有一个关键点同类商品不能全推要分类分组。比如用户看了二手手机系统不能推荐十个手机最好手机、平板、耳机各几个。我实现了predictScore方法后会再用一个分类抽样的逻辑将商品按categoryId分组每个分类最多取2个推荐项。这会在真实商品展示时让推荐列表看起来更像是“一个懂二手的人”在推东西而不是算法单纯约等于排序。推荐结果得分公式score(u, i) Σ(sim(u, n) × r(n, i))其中sim(u, n)是目标用户u和相似用户n的相似度r(n, i)是用户n对商品i的加权行为值。ItemCF的实现思路是对称的只是计算物品相似度矩阵再通过用户历史喜欢的物品扩散出推荐物品。3.4 冷启动与稀疏矩阵问题的实战处理跳蚤市场推荐系统里冷启动几乎是必修课。新用户没有行为数据协同过滤直接失效新商品没有用户行为永远无法进推荐池。我在系统里做了三层降级策略第一层离线协同过滤结果。用户有足够行为数据时走完整算法第二层热门商品兜底。如果用户行为数据少于3条直接按浏览量收藏量加权返回热门商品。第三层分类偏好修正。如果系统检测到用户只浏览过手机分类那么在热门商品基础上保证手机品类占推荐位40%同时补充其他分类。商品冷启动则更简单新发布的商品直接进入“待推荐商品池”给予一个初始的浏览加权值这样新上架的商品有机会获得曝光。我不能说这套方案有多完美但在数据量只有几千条样本的毕设场景下这套降级策略保证了你不管怎么演示页面上永远有推荐内容不会出现“没有推荐数据”的尴尬情况。4. 数据库设计一张好的行为表比算法更重要4.1 核心表结构设计我把整个系统拆成8张大表用户表、商品表、分类表、收藏表、购物车表、订单表、行为日志表、推荐结果表。其中后端开发时最容易忽视但是整个推荐算法的基石是行为日志表。行为日志表这样设计CREATE TABLE user_behavior_log ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 用户ID, item_id bigint(20) NOT NULL COMMENT 商品ID, behavior_type tinyint(4) NOT NULL COMMENT 1-浏览 2-收藏 3-加购 4-购买, weight double(8,2) DEFAULT 1.00 COMMENT 行为权重, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_item (user_id,item_id), KEY idx_item_user (item_id,user_id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4;这张表有四个核心设计点一是行为类型用tinyint而不是字符串方便扩展也省空间二是单独存weight字段而不是让算法代码里去查表映射行为类型和权重的对应关系这样管理员在后台调整“收藏权重”时只需改新写入的日志数据的weight不需要改算法代码。三是建立双联合索引user_id,item_id联合索引服务于按用户行为生成矩阵item_id,user_id联合索引服务于商品反查和ItemCF倒排表构建四是所有时间字段用DATETIME且默认值直接来自数据库不让应用层在并发时出现时间漂移。对于商品表我额外增加了item_status、view_count、collect_count三个字段。view_count和collect_count不只是展示用它们是推荐结果降级热门榜时最直接的数据来源。我见过不少项目把浏览量做成单独统计表但在这种数据量级直接冗余在商品表里换来的是查询快和代码简单。4.2 推荐结果表离线算好在线读很多写推荐系统的毕设算法都是在请求接口时现场算。这种写法对演示来说没问题但一问“如果用户量到十万会怎么样”就露怯了。我的设计是每天凌晨定时任务批量算好推荐结果存放在推荐结果表中CREATE TABLE recommend_result ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL, item_id bigint(20) NOT NULL, score double(10,4) DEFAULT 0.0000, reason varchar(20) DEFAULT COMMENT 推荐来源user_cf/item_cf/hot, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_recommend_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;在线接口只查询这张表。每次用户访问首页拿userId去查最多取20条如果为空就去兜底热门接口里查。这样做的好处是两个接口稳定性好推荐响应时间从可能秒级降到毫秒级答辩时可以说清楚这是“离线计算在线服务”的架构和工业界主流思路一致。4.3 用户与商品的实体字段对算法的影响在跳蚤市场上商品的地域属性很关键。两个人距离一千公里哪怕兴趣相似推荐同一个需要自提的桌子也没有意义。所以我给商品表加了region字段并在推荐结果生成时增加一个过滤条件与当前用户同省份的商品加权1.2倍外省商品加权0.8倍。这是在纯算法基础上叠加业务规则的做法实际效果非常明显。类似的业务规则还有“新发布商品加权”、“低于当前用户历史浏览价格区间的商品加权”等等。这些都验证了一句话推荐系统的价值不在于算法本身有多炫而在于你能否把领域知识写进规则链路里。5. 核心功能模块与推荐引擎的整合实操5.1 登录鉴权设计JWT无状态方案考虑到前后端交互的简单性和扩展性我选了JWT做登录鉴权没有引入Shiro。核心逻辑是用户登录成功后后端生成携带用户ID和角色信息的JWT字符串前端在后续请求的Authorization头中携带。拦截器里解析JWT把用户信息放入ThreadLocal上下文Controller通过注解获取。配置上最值得提醒的是JWT的密钥、过期时间这些不要写死在代码里要放到yml配置文件中并且用ConfigurationProperties读取ConfigurationProperties(prefix jwt) public class JwtProperties { private String secret; private long expire; }这里还有一个毕设答辩常见的坑JWT中不建议放大量用户信息只放user_id和role就行否则很容易出现token过长、请求头超限的情况。每次鉴权后如果需要用户名再去数据库查询或者用Redis做缓存。5.2 商品发布与图片上传实现商品发布这块最关键的流程是前端表单提交商品title、description、categoryId、price、region、图片文件后端Controller接收MultipartFile图片存储到服务器磁盘并生成访问URL商品表插入记录状态置为“待审核”;图片存储我采用本地磁盘存储加配置映射的方式。在yml中配置upload.path/data/flea-market/images再通过自定义WebMvcConfigurer把URL/images/**映射到该目录。这种方式比把图片存数据库的BLOB字段靠谱得多也比引入OSS更简单适合本地演示。上传中有一个坑图片尺寸和文件名必须处理。我在上传工具类中强制将图片压缩到宽度不超过1280px文件名重命名为UUID 原始扩展名避免用户上传中文文件名导致的乱码问题。5.3 购物车、订单与商品库存的联动订单模块最容易出现的数据问题就是并发下单导致的超卖。二手商品多数是一对一交易数量就是1所以我在下单时使用了最经典的“乐观锁更新”Update(UPDATE item SET status 2, buyer_id #{buyerId} WHERE id #{itemId} AND status 1 AND deleted 0) int lockItem(Param(itemId) Long itemId, Param(buyerId) Long buyerId);这条路保证了同一件商品只有一个买家能下单成功。配合事务注解Transactional确保更新和订单插入要么同时成功要么同时回滚。这种写法在答辩时同样是亮点——很多同学做订单就是简单插一条记录完全不考虑并发。5.4 推荐引擎与Controller的整合方式推荐引擎调用链是这样的用户访问首页推荐接口GET /api/recommend/list?userId1page1Controller - RecommendService.queryRecommendList(userId)先查Redis缓存如果配置了或直接查recommend_result表数据不足时调用HotItemService.getHotList()封装为统一响应体ResultListItemVO返回前端为了让推荐结果可解释我额外实现了“推荐理由”字段。比如ItemCF的推荐理由可以拼接为“因为你浏览过xx商品所以为你推荐相似商品”。前端虽然可以展示也可以不展示但这个字段是论文中可以写的一大亮点体现你考虑到推荐结果的解释性。6. 测试部署与避坑记录6.1 数据稀疏导致推荐结果为空我第一次运行整个项目时数据库里只有20个测试用户、50个商品行为日志几乎为零协同过滤计算的相似度矩阵全零推荐接口输出空列表。排查后定位原因用户行为太稀疏倒排表里没有足够的“公共商品”构建连接。解决方案不是调算法而是填充演示数据。我写了一个DataInitializer组件在系统启动时检查行为日志表行数如果为零则生成一批模拟用户和模拟行为。用户行为分布要符合幂律少数商品被大量浏览多数商品只有几次浏览。这样推荐结果才符合常识。在真实生产环境数据稀疏问题的解决思路是召回阶段多路召回协同过滤只是其中一路另一路可以是“同类目热门”另一路可以是“相同地区新上架”。6.2 物品相似度矩阵的内存优化问题我用商品数量是2000用户数量是3000做测试时ItemCF的物品间相似度如果用二维数组全量存储要找[2000][2000]的double数组空间大约32MB勉强能接受。但到1万商品时[10000][10000]的double数组直接就是800MB应用直接OOM。这个问题的解决办法是只保留Top-N相似商品。在计算每个商品的相似商品时用一个大小为N20的小顶堆维护前20个相似度最高的商品其余相似度较低的丢弃。这样矩阵从O(n^2)降到O(n*k)空间和时间都优化了。我在代码中实现了RetainTopKHeap工具类这也是面试时可以讲的优化点。6.3 后端一大坑Thymeleaf模板渲染与推荐接口缓存冲突用户端首页有两种访问方式一是后端渲染Thymeleaf页面时直接查询推荐数据模型二是前端通过/api/recommend/list走后端接口拿JSON。开发中发现推荐数据对象被缓存后用户退出登录再切换账号首页仍显示上一个用户的推荐结果。原因是我用了static MapLong, ListItemVO做本地缓存没有考虑退出登录时清理。修复方案有两种要么在退出登录接口明确清理该用户的缓存要么将缓存失效策略改为30秒过期。我最终选择了双保险主动清理 超时淘汰。6.4 部署环境的经典问题项目最终打包成spring-boot-maven-plugin的jar包部署到服务器时碰到两个问题第一个是图片上传目录权限不足导致上传图片时报FileNotFoundException解决为启动前手动创建目录并chmod 755第二个是MySQL的max_allowed_packet默认值过小商品描述里插入大量图片Base64时报错调大到64MB后解决。如果你用IDEA直接启动项目则几乎碰不到这些问题但答辩时你要部署到服务器上给老师演示务必检查环境变量里有没有漏配DB_HOST、DB_PASSWORD等。我的惯例是直接在application.yml中写死本地开发配置在服务器部署时通过--spring.profiles.activeprod覆盖配置这样既方便本地调试也不会把数据库密码暴露在一份文件里。注意一定不要尝试把大文件Base64编码后存入MySQL来做“简单存储”。短期能跑后面查询性能会越来越差图片文件的存储和访问至少要文件系统或对象存储。6.5 推荐效果不好时的排查速查表现象可能原因解决方向推荐列表永远一样行为日志无新增检查日志写入逻辑确认浏览行为是否异步插入相似度全部为0行为矩阵太稀疏填充演示数据或改用热门兜底某个用户推荐空相似用户未找到检查是否过滤掉已购买商品时误删全部推荐结果与浏览历史无关冷启动降级生效属于预期行为检查降级条件后台配置权重不生效权重只在写入时固定将权重设计成算法读取配置而非写入时固化我实际做项目时最耗时间的往往不是算法代码本身而是“正确性验证”。我曾经花了两天排查推荐结果中某个商品不该出现最终发现是商品下架后没有从推荐结果表中删除。所以在商品审核下架的逻辑里一定要同步清理recommend_result中该商品的数据或者在在线查询阶段加状态过滤。7. 项目后续可以怎么扩展如果你不满足于现在的功能想进一步提升项目的完整度和答辩含金量可以在现有架构上做三个方向的扩展。第一个方向是引入Redis缓存。把推荐结果表中最热门的几组用户推荐放入Redis设定过期时间为1小时可以有效降低数据库的压力。同时购物车模块用Redis的Hash结构存储用户的临时商品选择订单提交时再同步到MySQL也能让流程更贴近生产实践。第二个方向是把影视/电商领域常见的“基于内容的推荐”做一个简单版本出来。协同过滤解决的是“用户行为关联”问题基于内容的推荐则依靠商品文本特征比如标题分词后的关键词向量计算相似度。两者做一个加权融合推荐质量会提升不少而这在论文中可以作为“算法融合优化”章节。第三个方向是增加用户画像标签。根据用户浏览商品分类分布给用户打上“数码爱好者”“图书收藏家”“极简生活”等标签把标签展示在个人中心再从标签池反向匹配商品。这个方向跟推荐算法无关但能让你系统看起来完成度特别高适合时间充裕的毕业设计。最后说回跳蚤市场这个主题。很多人认为二手交易系统的技术门槛就是普通电商这个理解其实不全面。二手商品的非标特性让商品建模变得复杂用户行为的稀疏性让推荐算法的本地化、兜底策略变得非常重要。我做这个项目最深的一点体会是真正难的设计往往不在怎么把表建出来而在怎么让一个不太精准的推荐算法在一个不规范的场景里表现得像是“懂你”的。希望这篇拆解能帮你把整个项目脉络理顺写代码、写文档、答辩都能少踩几个坑。如果你的时间比较紧张我的建议是优先把“行为日志→离线计算→在线读取”这条数据链路打通先把推荐跑通再回过头优化页面细节。推荐链路是一个系统区别于普通增删改查项目的灵魂把这个做好了整个项目的水平自然就上去了。
