做Java方向的毕设选校园服务平台这个题的非常多但十个里面至少七个是普通CRUD登录注册、发布信息、后台管理页面倒是不少却没有一个功能真正用上“协同过滤算法”这个概念。今天聊的这套基于Java、SpringBoot、SSM体系搭建的校园服务平台和那些“换皮管理系统”最大的区别是推荐是真实能跑的——用户收藏过一本二手教材系统就能在首页推荐相似课程资料用户经常浏览互助板块首页信息流就会往那边倾斜。这个项目适合两类人看一类是Java方向、正在为毕设选型纠结的同学另一类是学过SpringBoot但没接触过推荐算法落地的开发者想看看工程代码里怎么把用户行为变成一套有解释的推荐结果。1. 项目缘起为什么校园平台需要推荐算法1.1 校园信息过载是真实存在的校园服务平台听着大落到具体场景无非就是几个刚需二手交易教材、自行车、路由器、失物招领、拼课拼团、考试资料分享、校园互助跑腿。这些需求单独拎出来任何一个都能做一个网站但放在同一平台里很快就会遇到信息过载的问题——用户打开首页看到一个列表二手的和求助的混在一起新发布的压在老帖子上。信息少时无所谓信息一旦超过几十条用户就得靠人肉刷新才能找到想要的东西。这个场景和电商平台不一样电商用户带着明确目的去搜索而校园服务平台的用户更多是“随便看看今天有没有什么值得入手”。一个人没有明确目标时推荐就是最重要的导航器。所以平台不能只是信息发布板它需要一个能根据每个人的行为习惯动态调整内容的模块。这也就是协同过滤算法在这个系统里存在的真正理由让每个学生打开首页时看到的顺序不一样。1.2 为什么是协同过滤而不是标签匹配做推荐有两种主流路径一种是基于内容一种是协同过滤。基于内容的思路是给每一条校园服务打标签比如“二手书”“考研”“东区自提”然后按用户历史偏好去匹配标签。这种方案看起来直观但工程上有两个麻烦每条信息都要人工或者写规则打标签冷启动从第一天就存在而且预览和收藏过的“信息流”很难概括成结构化标签比如用户收藏一个“帮忙搬行李”的帖子他到底是想找人搬行李还是想提供搬行李服务内容过滤分不清这个方向。协同过滤绕开了这个问题。它的核心逻辑不是分析物品而是分析人——用户A和用户B都收藏过同一类物品那就认为他们的兴趣相近以后A喜欢的B大概率也喜欢或者换一条路线用户上次收藏了某本教材那么和他收藏过同一批教材的人的书单里再挑一本没看过的推荐给他。这个逻辑不需要知道物品是什么不需要打标签很适合校园服务这种文本短、类型杂、标签难统一的场景。校园用户群体又高度同质化都是学生行为模式接近协同过滤的效果往往比内容过滤更自然。2. 技术选型解析SpringBoot和SSM到底怎么回事2.1 项目里的“JavaSpringBootSSM”是一套组合很多同学看到标题第一反应是SpringBoot和SSM不是两个互相替代的东西吗为什么能一起出现这里的准确说法是项目基于SpringBoot工程底层仍然使用Spring SpringMVC MyBatis这套经典Web开发组件也就是“用SpringBoot的自动配置去驱动SSM”。SpringBoot负责自动装配、内嵌容器、Starter依赖管理而SpringMVC负责请求路由和参数绑定MyBatis负责数据库读写。用一句好理解的话说SpringBoot是骨架SSM是器官Java是全身的血肉。选这套组合的理由很实际。毕设答辩时评委几乎一定会问“你用了什么框架”如果只答“我用了SpringBoot”在三分钟里很难讲出深度而能说出“SpringBoot如何整合MyBatis、如何配置事务、如何暴露REST接口”的人回答问题的颗粒度就完全不一样。而且从就业角度看SpringMVC MyBatis的底层思路在很多公司的老项目中还在用理解SSM的请求渲染和SQL映射方式对Debug能力是直接的锻炼。2.2 工程目录结构与核心依赖我采用的是标准的分层架构代码放在几个固定包下面controller包含REST接口、service业务逻辑、mapperMyBatis的数据访问接口、entity数据库实体类、common通用返回对象和工具类、recommend专门放协同过滤算法相关的服务。recommend包和普通业务包分离是我强烈建议的做法。因为推荐算法代码和CRUD代码风格差异很大混在一起会让维护的同学抓狂答辩时也很难说清楚“算法模块在哪里”。pom.xml里核心依赖无非是这些dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.2.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency不多但都关键。SpringBoot版本我选的是2.6.x而不是3.x原因和兼容性有关3.x要求JDK17及以上、Jakarta命名空间变化、很多教程里用的“魔法值”配置会报错。如果你的机器装的是JDK8或者你手里有大量网上参考的SSM代码老老实实用Spring Boot 2.x JDK8是最稳的能省掉一大半环境报错时间。2.3 数据表这么设计推荐算法才好算数据库是整个项目的地基协同过滤能不能跑起来关键不在算法代码而在数据表设计能不能喂出“行为数据”。我的核心表有六张user用户表、category分类表、service服务/物品表、behavior行为表、collection收藏表、order交易/预约记录表。另外comments表用来存评论但核心的是behavior表。behavior表长这样CREATE TABLE behavior ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, service_id BIGINT NOT NULL, action_type TINYINT NOT NULL COMMENT 1浏览 2收藏 3预约 4评分, rating TINYINT DEFAULT 0 COMMENT 用户打的1-5分非评分行为则为0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user_service (user_id, service_id) ) COMMENT用户行为表协同过滤的原料;当时设计这个表的思路是把浏览、收藏、预约、评分统一放进一张行为表用action_type区分。好处是推荐算法只需要一次性从这张表里读取数据而不需要join三四张表。坏处是行为量大了以后这张表膨胀快所以正式演示前记得给user_id建索引。这张表是我整个推荐系统里最值钱的一张表——没有它协同过滤就是空谈。3. 协同过滤算法从评分矩阵到推荐结果的完整落地3.1 行为数据怎么变成评分协同过滤的输入是“用户-物品”评分矩阵但这个平台里用户不会真的去给每本书、每个互助请求打分。这时候需要用隐式反馈折算成虚拟评分。我用的权重方案是浏览1分收藏3分预约/发起交易5分显式评分则直接采用1-5的原分。举个例子一个用户浏览了一套考研真题收藏了一个搬行李的服务评分矩阵中那条服务记录就是3分如果他又打了个5分就以5分为准。为什么权重要这么设计因为隐式行为里主动程度完全不同。浏览可能是误点收藏是明确的兴趣信号预约基本等于“我要买”主动意愿依次递增。不用权重的话一个只是路过看了一眼的热门帖和一个真正收藏的用户在算法里会被同等对待推荐结果就会偏向“大家都点过”而不是“你个人的偏好”。3.2 相似度计算余弦相似度的工程实现实现协同过滤前必须选一个相似度计算方式。常用的是余弦相似度把两个用户对所有物品的行为评分看成两个高维向量计算夹角的余弦值。公式写出来是similarity(A, B) Σ(A_i * B_i) / ( sqrt(ΣA_i^2) * sqrt(ΣB_i^2) )生活化类比你和一个同学在同一门课里都选了同样的三本参考书但你们侧重的章节不完全一样。余弦相似度衡量的是“方向”而不是“距离”也就是你们在兴趣偏好上的方向是否一致而不是你们看了多少本书的数量是否相当。一个用户只看过3条记录另一个看过300条只要方向一致余弦相似度依然能给出较高分数这是它适合稀疏评分矩阵的重要原因。在Java里我先从behavior表里拉出全部用户-服务评分映射然后做两层遍历生成用户相似度矩阵。核心代码如下public MapLong, Double calcUserSimilarity(long targetUserId, MapLong, MapLong, Double userRatings) { MapLong, Double simMap new HashMap(); MapLong, Double targetVector userRatings.get(targetUserId); if (targetVector null || targetVector.isEmpty()) { return simMap; } for (Map.EntryLong, MapLong, Double entry : userRatings.entrySet()) { long otherUserId entry.getKey(); if (otherUserId targetUserId) continue; double numerator 0.0, normA 0.0, normB 0.0; for (Map.EntryLong, Double item : targetVector.entrySet()) { Double otherScore entry.getValue().get(item.getKey()); if (otherScore ! null) { numerator item.getValue() * otherScore; } normA item.getValue() * item.getValue(); } for (Double score : entry.getValue().values()) { normB score * score; } if (normA 0 || normB 0) continue; simMap.put(otherUserId, numerator / (Math.sqrt(normA) * Math.sqrt(normB))); } return simMap; }这段代码看着不复杂但容易出错的地方是稀疏数据的除零问题。现实中如果两个用户没有任何共同行为记录numerator会是0余弦结果是0可以安全忽略但一旦某个向量的模是0除数为0就会出现NaN推荐结果里就会出现“不存在的用户”。所以if (normA 0 || normB 0) continue这句不能省。3.3 UserCF还是ItemCF这个项目我怎么做选择协同过滤分成User-basedUserCF和Item-basedItemCF两大流派。UserCF的思路是先找相似用户再推荐那些相似用户喜欢但我还没看过的物品ItemCF则是先找相似物品再根据历史行为推荐相似物品。下表是我的工程决策对比对比维度UserCF基于用户ItemCF基于物品计算复杂度用户数量大时矩阵计算重物品数量大时计算重推荐解释解释成本高因为“和你相似的人看了”解释直观因为“你看过类似的服务”冷门物品推荐较强能发现新兴趣弱容易被热门压制适用场景新闻流、社区内容电商、图书、视频校园服务平台本质是社区轻电商用户身份都是校园里的学生兴趣人群高度集中UserCF容易找出“同类人”另一方面二手物品和服务类别差异大ItemCF需要足够的用户评分才能建立物品关联。综合下来我最终选择UserCF作为主推荐算法再配合一个“最新发布”的兜底策略这样既能把算法讲清楚又能保证首页在真实使用时至少有内容。3.4 生成TopN推荐列表的完整流程推荐输出的流程可以拆成四步第一步从行为表计算虚拟评分矩阵第二步基于评分矩阵计算目标用户与其余用户的相似度第三步选择TopK个相似用户作为“邻居集合”第四步把邻居们行为过的物品里目标用户没见过的物品按加权评分排序去掉用户已经“交易/收藏”过的取前N个返回。我设置了默认K10、N8这两个参数在校园小数据量下效果最平衡。预测物品对用户的兴趣度公式我用了简化加权平均score(p) Σ_{neighbor u} (sim(target, u) * rating(u, p)) / Σ |sim(target, u)|这个公式的含义是一个物品对我有多值得推荐取决于所有相似用户对它的评分而且越相似的人权重越高。代码实现并不长但要注意过滤掉userRatings里缺少的条目以及目标用户已经“预约/收藏”过的服务。这个过滤动作不在算法层做而在数据库查询层做我直接用一个NOT IN子查询过滤behavior表里已有的service_id效率更高。4. 核心业务功能模块与推荐系统的整合实战4.1 登录注册与统一权限拦截校园服务平台面向学生普通用户需要注册登录管理员要有后台权限。我没有引入Spring Security而是采用自定义拦截器 Session的方案理由是项目角色只有两个权限规则简单用Spring Security反而引入一堆配置和风险。自定义拦截器实现HandlerInterceptor在preHandle里判断请求路径和当前Session中的用户如果是/ admin/开头且用户角色不是管理员就返回403。密码存储不能明文我用的是MD5加盐。虽然MD5并不是高安全级别的哈希方案但作为毕设项目复杂度正好答辩时能讲清楚为什么不能直接存明文。代码就三步注册时取一个随机盐值把盐和密码拼接后MD5存储盐和哈希值登录时按用户名查记录重新用盐拼接输入的密码做MD5再对比哈希相等才放行。至于前端用的是普通的Session-Cookie协作登录成功后程序把用户对象放进Session并回传一个用户信息JSON。4.2 校园服务发布、审核与状态流转服务平台核心业务是“发一条服务”。学生发布服务时填写标题、分类、描述、价格和图片后端存rows插入service表状态字段status用数字区分1待审核2已上架3已下架4已交易完成。管理员在后台审核审核通过后状态变为2才会出现在首页和推荐池里。这个审核步骤很关键否则用户会随意发布垃圾信息推荐算法会把低质量内容也学进去。图片上传是另一个容易翻车的点。我采用本地磁盘存储配置文件里指定upload-dir路径前端把二进制传到后端后端以UUID重新命名文件并保存到该目录数据库只存图片的访问相对路径。千万别把文件路径硬编码成“D:/xxx”上线或者挪到别的电脑跑的时候路径会失效推荐使用相对路径再通过一个/resources/**映射把物理目录暴露出来。当时我连续踩了两次这个坑一次是Win系统与Linux系统分隔符不同一次是idea内嵌Tomcat的静态资源映射配置忘记加。4.3 首页推荐如何与页面衔接推荐算法计算出来的是一个service_id列表要展示到页面上还需要把这些id转成完整服务信息。我写了一个RecommendService对外暴露两个方法一个getUserRecommend(userId, k, n)负责跑算法返回推荐ID列表另一个convertToCards(List )负责批量查询数据库并组装成前端要的卡片数据。前端首页预留了“为你推荐”板块加载时调用/recommend/list接口拿到的就是组装好的JSON。如果用户是刚注册的新用户没有任何行为记录直接套协同过滤会返回空列表。我的做法是降级成“热门推荐”按behavior表里action_type为2、3的行为总数取TopN再混入最新上架的几条。这个策略成为冷启动兜底在答辩时也是一个重要卖点——你没有假装算法全能而是明确知道协同过滤依赖行为数据。4.4 定时任务让推荐结果定期刷新协同过滤本身的计算成本是O(用户数 x 物品数)在几千人的校园平台规模下撑得住但每次用户看首页都去临时算一遍就不合理了。我用Spring的Scheduled注解配置一个任务在每天凌晨2点离线计算所有用户的相似度矩阵和TopN推荐列表把结果存到一张recommend_result表。用户当天访问首页时接口优先从这张表读缓存只有缓存过期或为空时才实时计算。Component public class RecommendTask { Scheduled(cron 0 0 2 * * ?) public void refreshRecommend() { UserCFCalculator calculator new UserCFCalculator(); // 1.从behavior表拉全量数据 // 2.计算每个用户的相似用户和推荐列表 // 3.清理旧数据写入recommend_result } }定时任务的好处是让“算法计算”和“用户请求”互不阻塞缺点是数据时效性差一点——用户今天刚收藏几个东西要明天凌晨才能体现在推荐里。我加了一个手动触发接口/admin/recommend/refresh管理员在后台点一下就能立刻重算兼顾了演示场景。5. 实际调试中的踩坑记录与问题排查速查5.1 推荐列表永远是空的根因在评分矩阵为空第一次联调时首页推荐一直不出结果。一开始以为是查数据库有问题单测看了SQL也没错后来发现是行为表的用户ID和service的ID对不上演示数据是手工插入的行为表里user_id是1但真实注册用户是5算法查的却是user_id5的行为数据自然查不到。这个坑提醒我造数据时要把外键对齐最好用应用本身的注册和收藏功能去生成行为而不是INSERT脚本硬造。另一个容易忽略的原因是UserId类型不一致。Java里我用Long类型接收主键但某些前端传来的参数是String类型如果不做转换MyBatis的Long和MySQL的BIGINT比较时可能会有隐式转换问题。后来我在Controller入口统一转成Long排查这个问题花了整整一个下午。5.2 MyBatis的字段映射和缓存坑MyBatis里最容易翻车的是接口方法返回类型和SQL结果不匹配。比如我统计用户行为数量时SQL写成SELECT COUNT(*) FROM behavior WHERE user_id...但Mapper接口方法返回的是自定义对象RecommendCount导致映射失败。经验是统计类查询直接用Map或者定义明确的POJO一个字段对应一个列不要偷懒返回List还有一次是增删改之后列表查询还是老数据。这是MyBatis的二级缓存做的好事——某个Mapper配了cache标签后新插入的数据没触发缓存失效。在毕设级别的项目里这个缓存收益很小反而很容易带来排查麻烦。我把所有cache标签全部移除换来的是一致性。5.3 前端联调跨域和Session失效前端项目如果单独跑在8080端口后端在8081那跨域问题必现。我在后端写了一个全局CORS配置类允许指定来源和请求方式并在拦截器里让预检请求OPTIONS直接放行。但更隐蔽的问题是跨域加拦截器组合后Session失效跨域请求默认不带Cookie登录状态根本同步不过来。解决方案是在后端CORS配置中显式允许credentials同时前端用withCredentials: true发请求。如果你用的是axios记得这个属性默认是false不打开就永远处于登录失效状态。5.4 常见问题排查速查表症状可能原因解决建议推荐列表为空用户无行为数据、评分矩阵为空造数据时先产生收藏/评分行为或用热门降级推荐结果全是NaN相似度计算除零计算前过滤模为0的向量图片上传后访问404静态资源配置或路径分隔符问题检查映射路径用相对路径跨域请求接口返回403预检请求被拦截CORS放行OPTIONS并允许credentials修改数据后列表不变MyBatis二级缓存先把cache配置移除再排查定时任务没执行未开启EnableScheduling启动类必须加EnableScheduling注解6. 部署演示、写论文和答辩准备的一些实话6.1 打包部署别在最后一天突然做整套项目在idea里跑通很简单但要打出可运行的jar包还是有些细节要注意。首先在pom里加spring-boot-maven-plugin并配置mainClass其次打包前把test阶段的测试全部跳过因为有些单元测试在无环境时会导致打包失败。执行mvn clean package -DskipTests后target目录下会生成可执行jar。用java -jar运行之前确保MySQL服务已启动、建库脚本已执行、配置文件中的数据库地址是本机127.0.0.1。如果服务器上没有图形界面配置文件里数据库地址写localhost可能没问题但写127.0.0.1更明确。访问端口默认8080如果冲突就用mvn spring-boot:run -Dspring-boot.run.arguments--server.port8081调整。6.2 演示数据要自己造并且要造得像真实用户协同过滤最怕的就是演示现场没有数据。我开发阶段的经验是不要直接手工INSERT几百条行为记录而是老老实实注册6-8个测试账号每个账号收藏、浏览、预约不同类别的服务。这样做出来的行为数据是有相关性的——比如几个账号都收藏了二手书另一个账号收藏了互助服务算法跑起来后推荐效果肉眼可见地更合理。如果你手工插数据常常会出现同一个服务被所有人收藏、行为完全随机的情况推荐结果根本没法看。答辩前我还准备了一个“数据故事”一个新账号测试注册、浏览了计算机类教材收藏了2本二手书预约了1次帮忙搬物品然后打开首页截一张推荐图。这张图里应该出现与教材相关的二手资料而且没出现曾经预约过的那个服务。能解释清楚这个推荐结果为什么长这样答辩的核心问题就过了一大半。6.3 写说明文档时算法部分不要只贴代码很多同学的英文摘要写得很好到了算法章节就把Java代码整段复制上去这不是写论文是贴代码。算法章节应该包含三块第一讲清楚为什么要选择协同过滤第二给出评分公式和相似度公式并说明每个变量的含义第三给出推荐结果的生成流程而不是代码清单。文字描述比代码更能展示你对算法的理解。比如你可以写“对于新用户平台没有足够历史行为因此系统在凌晨定时任务中计算离线推荐结果同时对新用户采用热门降级策略”这句话在答辩时说出来就是得分点。6.4 答辩问答我列几个高频题评委大概率会问几个固定问题协同过滤和内容推荐的区别你和别的管理系统区别在哪如果用户量变大你的算法性能怎么办建议准备好这几个答案的核心点协同过滤靠群体行为预测个体兴趣内容过滤需要物品属性标签平台区别在于用户有个性化推荐且推荐结果随行为动态更新用户量大了以后可以引入离线计算加缓存甚至切换Spark MLlib但毕设阶段用定时任务已经能证明你懂这个工程问题。最后分享一个我实际用过的小技巧答辩演示时提前把推荐缓存清掉然后让评委现场的账号去收藏一条服务再手动点击后台的“刷新推荐”按钮首页推荐立刻变化。把这个变化过程现场展示出来比你准备任何PPT里的架构图都有说服力。我试过评委确实会对这种“能看见算法在工作”的项目留下更深的印象。做这个项目最大的体会是校园服务平台本身没有新奇感但把协同过滤从公式变成一串能跑通的Java代码再把它放进SpringBoot工程里和业务数据打通那种感觉和写普通CRUD完全不一样。以上内容供正在选题或开始动手的同学参考按这个思路写代码、写论文、准备答辩基本能把“基于协同过滤算法”这个标题做成一个真正站得住的作品。