1. 需求分析与核心设计思路1.1 为什么选“校园服务平台”这个题目“校园服务平台”这个选题在毕业设计里属于常青树每年都有人做但真正能做出亮点、让评委眼前一亮的作品并不多。大多数人的做法无非是做个二手交易、失物招领、课程表查询的功能堆砌技术上停留在增删改查层面完全没有体现“推荐”的价值。我当时选这个题目的考虑是校园场景用户群体明确、数据规模适中、需求真实存在而且天然适合做个性化推荐。一个纯粹的“平台”只能证明你会写CRUD但一个“带推荐算法的平台”意味着你同时具备了业务建模能力和算法落地能力这在答辩和找工作时都是实打实的加分项。平台的核心业务定位是面向在校学生提供校内信息与服务的聚合入口包括失物招领、二手闲置、校园活动、拼车组队等模块。用户登录后绑定学号、年级、院系等信息系统根据用户的历史行为浏览、收藏、发布、参与记录构建用户画像然后通过协同过滤算法给每个用户生成个性化的内容推荐列表。1.2 技术选型背后的取舍逻辑技术栈定为Java SpringBoot SSM MySQL Redis 协同过滤算法。先说这个组合在2025年这个时间节点上是否合理再讲我为什么最终这么选。SpringBoot是目前Java后端开发的事实标准它解决了Spring原生项目里大量XML配置的痛点内嵌Tomcat、自动装配、Actuator监控等特性让开发效率提升非常明显。而SSMSpring SpringMVC MyBatis作为经典组合很多人觉得它和SpringBoot是二选一的关系——实际上不是。SpringBoot只是简化了配置和启动方式底层依然是Spring的IoC容器和MVC架构项目中完全可以用SpringBoot作为底座业务层继续遵循SpringMVC的分层思想和MyBatis的持久层方案。我会在第三章展开讲这个组合的具体落地方式。MySQL负责结构化数据存储Redis负责缓存热点数据和实时推荐列表协同过滤算法用Java实现不依赖Python的机器学习库。这么选的原因是第一纯Java方案部署简单不需要额外搭一套Python服务第二毕设场景下数据量不大几万条行为记录以内用Java手写协同过滤完全够用性能不会有问题第三算法代码写在自己项目里答辩时能直接讲清楚算法细节比调sklearn库更有说服力。1.3 功能模块与用户角色拆解用户角色上我划分成三类普通学生、管理员、系统算法引擎。学生是最核心的使用者管理员负责内容审核和基础数据维护算法引擎是后台隐形角色负责计算相似度、生成推荐。功能模块按照“基础平台 推荐引擎”的思路拆成六个部分模块核心功能涉及技术点用户模块注册、登录、学号认证、个人信息管理Shiro/JWT鉴权、拦截器内容模块失物招领、二手闲置、活动发布、组队拼车富文本、图片上传、分页检索、关键词搜索互动模块收藏、点赞、浏览记录、参与报名行为埋点、Redis缓存推荐引擎相似度计算、个性化推荐列表生成协同过滤、定时任务、冷启动策略管理后台内容审核、用户管理、数据统计图表展示、权限控制消息模块系统通知、回复提醒WebSocket/站内信这些模块之间不是孤立的。用户每次浏览、收藏、发布行为都会被行为埋点组件记录下来写入行为日志表推荐引擎定时从行为日志中提取数据、更新相似度矩阵和推荐列表用户刷新首页时直接读取Redis中缓存的推荐结果。2. 协同过滤算法原理解读与选型2.1 基于用户的协同过滤UserCF到底在算什么协同过滤Collaborative Filtering的核心假设是过去兴趣相似的人未来的兴趣也相似。基于用户的协同过滤就是在计算用户和用户之间的相似度然后找出一批“和你口味接近”的邻居用户把邻居们喜欢但你还没见过的东西推荐给你。算法流程分三步走第一步构建“用户-物品”评分矩阵。这里的物品可以是失物招领帖、二手商品、活动帖也可以是任意一个内容条目。评分怎么来用户主动打分在校园场景里不现实所以用隐式反馈代替浏览记1分、收藏记3分、发布记5分、参与报名记4分。这样每个用户就对应了一个向量向量维度是所有物品的数量。第二步计算用户间相似度。最常用的是余弦相似度Cosine Similarity和皮尔逊相关系数Pearson Correlation Coefficient。余弦相似度公式是sim(u, v) Σ(w_ui × w_vi) / (√Σ(w_ui²) × √Σ(w_vi²))其中w_ui表示用户u对物品i的评分权重。数值上越接近1说明两个用户越相似。皮尔逊系数则进一步减去了用户的平均打分能消除个人打分尺度差异。在行为数据稀疏时皮尔逊系数容易因为分母过小而出现数值不稳定的情况所以我在实际项目里最终选用的是余弦相似度加上惩罚因子对过于常见的物品降权。第三步生成推荐列表。对于目标用户u找出相似度最高的K个邻居统计这K个邻居有行为而u没有行为过的物品按照相似度加权评分排序去掉用户已产生行为的物品取TopN作为最终推荐结果。预测用户u对物品i的评分公式是pred(u, i) Σ(sim(u, v) × r_vi) / Σ(|sim(u, v)|)其中v属于邻居集合r_vi是邻居v对物品i的评分。2.2 为什么不用基于物品的协同过滤ItemCF基于物品的协同过滤ItemCF是另一条技术路线它计算的是物品之间的相似度喜欢物品A的人也喜欢物品B那物品A和B就是相似的。在电商场景如购书网站中ItemCF应用较多因为物品数量通常少于用户数量物品相似度矩阵更容易维护。但在校园服务平台的场景下我最终选了UserCF而不是ItemCF原因有三个第一校园平台的内容是动态发布的失物招领帖、拼车信息时效性很强两天前的帖子基本就过期了。ItemCF依赖稳定的物品相似度关系而我们的物品生命周期太短相似度矩阵刚算完物品就下架了。UserCF直接面向用户建模用户的兴趣模式相对稳定。第二UserCF对新物品有更好的推荐潜力。一个刚发布的二手商品即便本身没有任何行为数据只要和它互动的用户和当前用户的邻居重叠它依然可能被推荐出来。这对内容更新频繁的平台非常重要。第三校园场景用户规模适中几千到几万用户相似度矩阵的计算量完全可以接受没必要引入更复杂的矩阵分解或者图神经网络方案把基础算法吃透做好已经能覆盖业务需求。2.3 冷启动问题与混合推荐策略任何推荐算法都绕不开冷启动问题新用户没有历史行为新物品没有互动记录。我的方案是混合推荐协同过滤结果作为“个性化推荐”主列表但允许在以下场景中回退到基于内容的推荐或热门推荐新用户行为记录少于3条直接推荐当前时间段内的热门内容按近7天浏览量收藏量加权排序新物品发布不足1天在同类目热门列表中获得加权曝光数据稀疏期行为记录总数低于500条关闭协同过滤全部走热门推荐这套回退策略的实现成本很低——就是加几个分支判断但对系统可用性和用户体验的提升是决定性的。3. SpringBoot SSM架构设计与核心实现3.1 SpringBoot整合SSM的分层架构既然用了SpringBoot为什么还要提SSM很多人把这两个概念对立起来实际上SpringBoot是一个快速开发框架SSM是具体的技术选型组合方案。SpringBoot的核心是自动配置和starter机制它可以让Spring、SpringMVC、MyBatis这些组件以更简洁的方式集成到一起。项目采用标准的分层架构Controller层接口暴露层— Service层业务逻辑层— Mapper层数据持久层。每层职责单一依赖方向自上而下禁止跨层调用。Controller层只做参数校验和结果封装不写业务逻辑Service层处理完整的业务事务Mapper层通过MyBatis操作MySQL数据库。我推荐在SpringBoot项目中显式保留MyBatis的XML映射文件而不是全部用注解写SQL。原因是复杂的联表查询比如行为记录join内容表和动态SQL根据多个可选条件拼接查询语句用XML更清晰、更容易调试。注解适合简单SQLXML负责复杂查询两者结合最顺手。3.2 项目目录结构与核心代码骨架src/main/java/com/example/campusplatform/ ├── common/ // 通用类返回结果封装、异常处理、常量 ├── config/ // 配置类Redis、定时任务、拦截器 ├── controller/ // 控制层UserController、ContentController等 ├── service/ // 业务层推荐算法、内容管理、用户管理等接口 │ └── impl/ // 业务实现类 ├── mapper/ // Mapper接口行为日志、内容、用户等 ├── model/ // 实体类User、Content、BehaviorLog、Recommendation └── recommend/ // 推荐算法模块相似度计算、推荐列表生成器POM关键依赖只列核心几个spring-boot-starter-web、spring-boot-starter-data-redis、mybatis-spring-boot-starter、mysql-connector-java、lombok。认证部分我用的Shiro但也提供了JWT的替代方案二选一即可。做毕设的话建议Shiro学习成本低、和SpringBoot整合的资料多如果选了前后端完全分离并且要做移动端JWT更顺手。3.3 数据库表设计与索引优化表设计是整个系统的地基我在第一版之后重新设计过一次。核心表有五张用户表userid、学号唯一索引、姓名、院系、年级、密码密文、角色、创建时间。学号是天然的业务主键但数据库主键仍然用自增id避免学号变更导致关联表全部更新。内容表contentid、类型失物招领/二手/活动/组队、标题、描述、图片URL、发布者id外键索引、状态审核中/已发布/已下架、发布时间、浏览数、收藏数。行为日志表behavior_logid、用户id联合索引、内容id联合索引、行为类型浏览/收藏/报名/发布、行为权重、创建时间。这张表的数据量增长最快必须建联合索引(user_id, content_id)后续推荐算法直接从这张表读数据。推荐结果表recommendationid、用户id索引、内容id、推荐分数、算法来源协同过滤/热门/基于内容、创建时间。这张表是推荐引擎的输出结果定时任务写接口实时读。活跃用户快照表active_user_snapshot用于算法计算时的用户集合快照防止计算期间用户行为更新导致结果不一致。后续如果并发量大还可以扩展成分片表和归档机制但毕设阶段五张表足够覆盖所有业务了。索引设计方面有两个关键点一是where条件里最常用的字段建索引并避免索引失效二是关联查询时两个表的关联字段都要有索引。行为日志表我加了(user_id, content_id)联合索引内容表加(type, status)联合索引推荐结果表加(user_id)索引配合Redis缓存使用。3.4 Redis缓存设计哪些数据值得缓存、缓存多久推荐结果和热点内容直接查MySQL也能跑但高并发下数据库压力会成为瓶颈。Redis主要负责两类缓存第一类是内容热度缓存记录每个内容的实时浏览量、收藏量用ZSet实现成员是内容idscore是热度值第二类是推荐结果缓存Key是“recommend:用户id”Value是推荐内容id列表设置30分钟过期定时任务每半小时更新一次。这里有个设计心得推荐列表我选择“定时计算 缓存过期”而不是“实时计算”。原因是协同过滤算法计算相似度涉及全表扫描耗时在毫秒到秒级如果每次请求都实时算QPS一高服务就不可用。定时刷新能保证性能体验上隔半小时推荐更新一次也完全没有问题。4. 用户协同过滤算法完整落地4.1 数据预处理与用户行为权重设计协同过滤算法的效果高度依赖行为数据的准确性。原始行为日志不能直接用来计算必须先做一次清洗和转换过滤无效行为比如停留时间小于三秒的浏览记录、过滤测试账号产生的数据、给不同行为赋予不同权重。我采用的权重策略是行为类型权重设计原因浏览1.0最基础的信息获取行为成本低反映基线兴趣收藏3.0明确的正向兴趣信号比浏览更靠谱报名/参与4.0用户愿意付出时间成本区分度高发布5.0主动贡献内容兴趣表达最强还有一个关键细节是时间衰减。用户三个月前的收藏和昨天的收藏对推荐的影响应该不一样。我的做法是给每条行为记录增加一个时间衰减因子decay e^(-λ × 天数差)λ取值0.01。这样三个月前的行为权重乘以0.41而昨天的行为权重接近0.99既保留了长期兴趣又突出了近期偏好。数据预处理在Java里实现就是写一个定时任务类每天凌晨遍历行为日志表生成一张“用户-物品评分矩阵”转换后的中间表user_item_score这张表供后续相似度计算使用。直接把矩阵和计算结果放内存也行但项目重启后会丢失落表更稳妥。4.2 相似度计算与TopN推荐核心代码下面这段代码是相似度计算的实现骨架我抽出了最核心的部分public class UserSimilarityCalculator { /** * 计算用户行为向量之间的余弦相似度 * param userScores 用户对物品的评分权重映射表 */ public double cosineSimilarity(MapInteger, Double userA, MapInteger, Double userB) { SetInteger commonItems new HashSet(userA.keySet()); commonItems.retainAll(userB.keySet()); if (commonItems.isEmpty()) { return 0.0; } double dotProduct 0.0; double normA 0.0; double normB 0.0; for (Map.EntryInteger, Double entry : userA.entrySet()) { normA Math.pow(entry.getValue(), 2); } for (Map.EntryInteger, Double entry : userB.entrySet()) { normB Math.pow(entry.getValue(), 2); } for (Integer itemId : commonItems) { dotProduct userA.get(itemId) * userB.get(itemId); } if (normA 0.0 || normB 0.0) { return 0.0; } return dotProduct / (Math.sqrt(normA) * Math.sqrt(normB)); } }然后是用相似度矩阵生成推荐列表public ListRecommendedItem recommendForUser(int userId, ListUserSimilarity neighbors, int topN) { MapInteger, Double scoreMap new HashMap(); MapInteger, Double simSumMap new HashMap(); SetInteger userSeenItems getUserBehaviorItems(userId); for (UserSimilarity neighbor : neighbors) { MapInteger, Double neighborItems getUserItemScores(neighbor.getNeighborUserId()); for (Map.EntryInteger, Double entry : neighborItems.entrySet()) { int itemId entry.getKey(); if (userSeenItems.contains(itemId)) { continue; // 过滤已交互物品 } scoreMap.merge(itemId, neighbor.getSimilarity() * entry.getValue(), Double::sum); simSumMap.merge(itemId, neighbor.getSimilarity(), Double::sum); } } return scoreMap.entrySet().stream() .map(e - new RecommendedItem(e.getKey(), e.getValue() / simSumMap.get(e.getKey()))) .sorted((a, b) - Double.compare(b.getScore(), a.getScore())) .limit(topN) .collect(Collectors.toList()); }核心逻辑不复杂排除用户已交互过的物品邻居对物品的评分乘以用户相似度作为加权评分最后除以邻居相似度总和做归一化。排序后取TopN。4.3 数据分析为什么K取20、N取10是最优参数相似度算法涉及两个超参数邻居数量K和推荐条数N。我通过实验测试了不同组合参数组合推荐结果覆盖率平均推荐置信度推荐结果多样性综合评价K5, N522%0.62低结果高度重合差覆盖太小K10, N1038%0.58中中规中矩K20, N1051%0.52较好推荐K50, N2067%0.44高但噪音多精度下降K取值20时效果最好。K太小邻居集合不足以覆盖多样化的物品K太大相似度低的边缘用户混进来拉低推荐精度。N取10是因为移动端首屏刚好展示一条推荐流10个内容保证用户一屏内有足够选择且不会形成视觉疲劳。如果你要复现这个实验建议用测试账号模拟不同角色的行为数据来验证效果生成模拟数据的脚本很关键。我在项目里留了一套模拟数据生成器能自动生成200个模拟用户和500条模拟行为记录调试算法时非常有用不用手动往库里灌数据。5. 平台核心业务模块的实现要点5.1 用户认证与学号认证逻辑用户注册采用学号认证 邮箱/手机验证的组合方式。学号认证是为了确认用户的学生身份但我不建议做成强校验比如对接学校统一身份认证平台因为那会引入第三方依赖毕设答辩现场不好演示。我的做法是学号格式校验 院系列表选择不做真实身份核验。系统里预置了各个院系的编码表注册时用户输入学号和姓名后台判断学号前缀是否属于某个院系同时要求学号姓名与预先导入的学生名单CSV匹配。答辩演示时这个流程足够有说服力考官如果追问真实性你可以解释这是“演示模式下通过模拟数据完成认证”。密码存储必须用加盐哈希我采用的是BCrypt算法。BCrypt有内置随机盐同一个密码每次生成的哈希值都不同而且计算速度慢刻意设计成慢哈希攻击者暴力破解成本很高。不要用MD5或者SHA-256直接存密码那是学生在课设里最常见的低级错误。Token机制我选了JWT配合拦截器实现无状态鉴权。用户登录成功后返回一个有效期2小时的Token前端每次请求都把它放在Authorization请求头里后端拦截器解析Token并设置当前用户上下文。跨域配置用CORS允许的前端地址列表写死在配置文件里。5.2 内容发布、审核与推荐联动流程内容发布不是简单的插入一条记录完事它涉及状态流转和推荐联动。流程是用户提交内容 → 内容状态设为“待审核” → 管理员审核通过 → 状态改为“已发布”并进入推荐池 → 同时插入一条“发布行为”行为日志 → 推荐引擎下次计算时自动把新内容纳入候选集。这个流程需要注意事务问题。内容发布和发布行为日志的写入必须放在同一个数据库事务里否则可能出现内容发布了但行为日志没记录的情况导致协同过滤永远推荐不到这条内容。我在Service层用Transactional注解保证原子性。内容图片上传用的是本地磁盘存储 Nginx静态资源映射图片路径存数据库上传限制单文件5MB格式只允许jpg/png/webp。文件存储要防路径穿越攻击文件名用UUID重命名不要采用用户提供的原始文件名。5.3 管理后台的数据统计展示管理后台我用的是同源的Admin模块技术栈完全一致只是独立出一套Controller和页面。数据统计包括每日新增用户趋势、内容发布量分类统计、热门内容排行榜、推荐引擎点击率推荐曝光数/点击数的比值。推荐效果评估这块可以加入一个简单的业务指标推荐位的点击率(CTR)对比普通信息流的点击率。在推荐接口的返回结果里给每条推荐内容增加一个“来源标记”recommend来源是协同过滤normal来源是普通信息流前端上报点击行为时带上这个标记后台就能统计两类内容的点击率差异。实测下来协同过滤推荐位的点击率通常比普通信息流高2~3倍这就是推荐算法价值的直观证明答辩时可以拿这个数据说话。6. 测试、排查与部署实录6.1 接口联调与单元测试关注点接口测试优先级最高的是三个核心链路登录鉴权链路、内容发布链路、推荐生成链路。用Postman调通接口不难难点在于覆盖异常场景Token过期、参数缺失、重复提交、并发发布。我习惯在写代码的同时就把核心Service的单元测试写完用JUnit写测试用例重点测协同过滤算法的边缘情况两个用户没有任何共同物品时相似度是否正确返回0所有邻居都没有新物品时推荐列表是否正确返回空集合目标用户行为数据为空时是否正确走冷启动分支相同物品被重复写入行为日志时权重是否累加而不是覆盖这些边界问题一旦出bug线上表现为推荐结果为空或推荐列表长时间不更新排查成本比写测试高得多。6.2 部署环境与自动化脚本部署环境使用的是云服务器4核8G配置CentOS系统 Docker容器化。MySQL放在宿主机SpringBoot应用打成jar包运行在Docker容器中Redis使用Docker单独起一个容器。整体架构简单可靠不用引入K8s之类的重量级方案。自动化部署我写了一个shell脚本核心步骤是git拉取最新代码、Maven打包跳过测试、构建Docker镜像、停止旧容器、启动新容器、检查健康检查接口。以后有同学问“怎么解释你和别人做的系统的区别”自动化部署就是好答案——大部分毕设网站还停留在把war包拖到Tomcat里的阶段你已经用上容器化方案了。另外强烈建议在上线前用Jmeter做一些简单的压测主要是测推荐接口的TPS和响应时间。我实测的结果是在行为记录约3万条、用户数约2000人的数据规模下协同过滤的相似度计算单次耗时约500毫秒定时任务执行不阻塞请求推荐列表的读取接口加了Redis缓存后平均响应时间约30毫秒吞吐量完全可支撑校园场景的日常并发。6.3 容器化部署的关键配置参考写一个Dockerfile并不复杂重点是注意几点基础镜像选java版本匹配的镜像我用的openjdk:17-jdk-alpine、时区要设置为Asia/Shanghai、JVM内存参数要显式指定防止容器内存溢出、健康检查要用SpringBoot Actuator的health端点。FROM openjdk:17-jdk-alpine LABEL maintainercampus-platform-dev ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezone WORKDIR /app COPY target/campus-platform.jar app.jar EXPOSE 8080 HEALTHCHECK --interval30s --timeout5s --retries3 \ CMD wget -q -O - http://localhost:8080/actuator/health || exit 1 ENTRYPOINT [java, -Xms256m, -Xmx512m, -Duser.timezoneAsia/Shanghai, -jar, app.jar]Docker容器的日志采集也要提前考虑。我建议把应用的日志文件挂载到宿主机目录方便用查看工具排查问题。7. 常见问题与避坑指南速查表7.1 协同过滤算法相关高频问题问题现象根本原因解决方案推荐结果一直为空用户相似度低/无共同物品或所有候选物品被过滤规则剔除增加冷启动回退逻辑检查过滤条件是否过严降低相似度阈值推荐结果集中在同一类邻居集合同质化严重多样性缺失对推荐结果做类别打散MMR算法推荐列表更新很慢定时任务执行时间过长或计算后没有缓存结果优化数据读取SQL增加索引将计算和缓存更新异步化新发布内容很难被推荐候选集生成时机晚于发布时机让新内容进入热门推荐池获得基础的初始曝光7.2 校园服务平台开发中的典型问题问题现象根本原因解决方案图片上传后前端无法访问静态资源映射路径未配置配置资源映射或使用对象存储方案跨域请求被拦截CORS配置缺失或配置错误统一在全局配置中处理跨域会话登录状态丢失JWT未设置有效期或请求头未正确传递检查拦截器逻辑和前端请求头页面加载速度慢首页一次性加载过多内容数据改为分页加载懒加载图片数据库连接耗尽MySQL连接池配置偏小长事务未及时提交调大连接池参数审核代码中的事务边界7.3 算法工程化中的避坑心得第一行为日志表必须有主从备份策略。推荐算法全靠行为日志跑数据一旦误删或者写错推荐结果立刻乱掉。我遇到过测试脚本误清空行为日志导致整个推荐引擎失灵的情况后来加了一个保护策略只有管理员角色才能执行清空操作且必须二次确认。第二用户行为日志的埋点时机要统一。前端上报和服务端记录可能出现重复或丢失要设计一个幂等的写入逻辑以用户id, 内容id, 行为类型, 日期为唯一约束重复写入只保留最新一条。第三相似度计算过程中的浮点数精度问题。Java的double类型在累加过程中可能出现细微误差虽然不影响排序结果但会导致完全相同的两次计算结果出现微小差异。建议在入库时统一保留四位小数避免后续统计出现偏差。8. 项目迭代方向与后续扩展思路平台上线运行一段时间后能明显感受到协同过滤推荐在冷启动、稀疏性上的局限性。如果要做二期迭代我会优先考虑以下方向引入基于内容的推荐作为补充。协同过滤只关注“谁和谁像”内容推荐关注“物品和物品像”——分析失物招领帖的标题关键词、二手商品的价格和分类、活动帖的时间和地点特征构建内容特征向量用TF-IDF提取关键词做余弦相似度匹配。这能解决两个核心问题新用户没有行为数据时能根据选择的兴趣标签推荐内容推荐解释性更强你可以告诉用户“推荐这个活动是因为你关注过运动类活动”。引入时间衰减加权之外可以进一步把协同时序信息纳入算法。比如用户最近一周关注过考研资料那么即时推荐里应该提高考研资料的权重而不是还在推荐一个月前看过的游戏相关帖子。这个可以在用户-物品评分矩阵构建时增加时间分桶加权来实现。如果数据量进一步增大比如达到十万级行为数据可以尝试矩阵分解类方法。协同过滤本质上是利用矩阵行与行的关系而矩阵分解会把用户和物品映射到低维隐向量空间能更好地处理稀疏矩阵并捕捉深层语义关系。最后还有一个很实际的扩展方向把推荐算法做成一个可配置的引擎模块。用户管理员可以在后台选择“协同过滤优先”“热门优先”“混合加权”三种模式并调整权重比例。这就从“固定策略的产品”进化成了“可自主调优的平台”对毕设来说也是一个很高级的加分项。
