Java毕设选来选去还是选了这种“业务逻辑清晰、技术栈主流、还带一点算法亮点”的题目——基于SpringBoot与协同过滤算法的流浪动物领养与救助系统。这类平台型项目在毕设里非常吃香一是主题自带正能量救助流浪动物本身就容易引发共鸣二是功能边界清楚从宠物信息发布、领养申请到救助记录上报每一块都能落地三是加上推荐算法之后技术深度一下子就有了答辩的时候也有的聊。如果你正打算做类似的系统或者已经在写这类项目但卡在推荐算法和模块设计上这篇文章会给你一条相对完整的路线。我会把题目拆解、功能设计、数据库建模、协同过滤实现、常见坑和答辩经验一次性讲清楚所有内容都基于我实际写这种TypeScript的经验偏实用不整虚的。1. 毕设选题拆解这个题目到底在做什么1.1 “流浪动物领养与救助”背后的真实业务场景很多同学看到这个题目第一反应是“这不就是一个CRUD系统吗”。从表面看确实是这样管理员发布流浪动物信息、用户浏览、然后提交领养申请。但如果你真把业务场景想清楚了会发现它比普通的“商品管理系统”多了一层临时性的信息撮合逻辑。真实的流浪动物救助流程是这样的有人在外面发现一只流浪猫或流浪狗先拍照、上报位置和基本情况然后由救助站或志愿者把动物接到临时安置点进行健康检查、驱虫、绝育等状态稳定后发布领养信息。有领养意愿的人浏览信息觉得合适就提交申请救助方审核通过后进行线下交接最后还要做回访确认动物在新家里过得好不好。所以这个系统里至少要有三条主线救助上报记录谁在什么时间、什么地点发现流浪动物目前状态是什么。领养流转待领养宠物信息发布、用户浏览收藏、申请审核、领养结果反馈。用户行为追踪用户浏览了哪些宠物、收藏了哪些、申请了哪些这些数据是后面推荐算法的燃料。如果把这三条主线理顺了系统的功能边界自然就出来了。很多毕设做得散就是因为上来就写代码没先把这个业务流想明白。1.2 技术栈选择的合理性分析标题里出现了JavaEE和SpringBoot这两个词放在一起需要留意一下。严格来说JavaEE是一整套企业级规范SpringBoot是实现这些规范的主流框架之一。毕设项目一般不需要去抠概念上的区别你只需要明白用SpringBoot做Web后端是现代Java项目的默认选项因为它内嵌了Tomcat不用单独部署容器起步快生态成熟。再来说SpringBoot的版本选择。我用的是SpringBoot 2.7.x配JDK 8这个组合在毕设里最稳。SpringBoot 3.x确实新但需要JDK 17起步而且不少教程和第三方依赖还没完全跟上你在开发的过程中遇到问题不好搜答案。如果你学校机房的JDK版本比较老更不要强行上3.x。推荐算法部分标题点名了协同过滤。为什么选协同过滤而不是深度学习原因很简单数据集规模小、需要可解释性、答辩时要能说清楚原理。协同过滤是推荐系统里最经典的算法逻辑直观公式也不复杂用纯Java写几百行就能实现不需要引入Python服务或复杂的机器学习框架。毕设阶段选它属于“性价比”最高的方案。## 2. 需求分析与功能架构设计 ### 2.1 用户角色与核心业务流程 系统建议设计三种角色普通用户、救助方/机构、系统管理员。如果不想把角色分得太碎可以把“救助方”和“管理员”合并但主流程会稍微模糊一些。我更推荐拆开理由很实在不同角色的权限边界清晰了后台管理的代码就更好写答辩时讲权限控制也更有说服力。 先看业务流程的全貌。一个普通用户进入系统后在首页能看到推荐宠物列表也可以按品种、年龄、健康状态筛选。点进宠物详情页能看到这个小动物的救助故事、健康状况、性格描述。用户如果有领养意向可以点击收藏或直接提交领养申请。申请提交后救助方在后台看到申请记录审核通过后进入线下接触流程。 救助方的操作链路是另一条线。他们在后台发布待领养宠物填写基本信息、上传照片、标记健康状态和领养要求。同时能管理自己上报的救助记录比如某只流浪动物目前是“待安置”“已安置”“已领养”中的哪个状态。 管理员主要负责基础数据维护和全局审核比如用户管理、公告发布、救助机构审核、领养成功后的回访记录管理。整个系统不是简单的“管理员管一切”而是让业务顺着角色流起来。 ### 2.2 功能模块划分及其边界 基于上面的业务流程我会把系统拆成两类模块面向用户的前台模块和面向管理方的后台模块。 前台模块主要有用户注册登录、首页推荐流、宠物分类浏览与搜索、宠物详情、收藏管理、领养申请、救助上报、个人中心、站内公告。这里有一个容易被忽略的点救助上报不能只做成一个“填表单”的入口上报之后的状态应该能被用户追踪比如“我上报的那只猫现在是否已被救助站接收”。这个追踪闭环做好了系统才真正有“救助”属性而不是只有领养功能。 后台模块主要有宠物信息管理、救助记录管理、领养申请审核、用户管理、公告管理、回访记录管理、数据统计看板。数据统计看板是加分项不用做得很复杂展示待领养数量、领养成功率、本月新增救助量这几个指标就够撑场面了。 边界划分上有一个常见的“度”不要把推荐算法混进业务模块里。推荐逻辑应该独立成一个服务类只依赖于用户行为数据这样即使推荐算法挂了基本的浏览和申请功能依然可用。代码结构上也更清晰控制层管参数校验服务层管业务编排推荐模块单独放在recommend包下面。 ## 3. 数据库设计表结构是系统的地基 ### 3.1 核心表设计与字段说明 这个系统的数据库表不需要设计得很花哨但有一张表是灵魂用户行为日志表。因为协同过滤算法要依赖用户的历史行为来做推荐如果没有这张表算法就是无米之炊。 我列出主要表及其核心字段你可以直接参考 | 表名 | 核心字段 | 说明 | | --- | --- | --- | | user | id, username, password, phone, avatar, role_type, status | 用户表role_type区分普通用户/救助方/管理员 | | pet | id, name, category_id, breed, gender, age_month, health_status, description, cover_image, publisher_id, status, create_time | 宠物信息表status标记待领养/已申请/已领养 | | rescue_record | id, reporter_id, pet_id, location, description, status, process_result | 救助上报记录关联到pet_id以便后续转为待领养宠物 | | apply_record | id, user_id, pet_id, apply_reason, contact_info, audit_status, audit_time | 领养申请记录audit_status为待审核/通过/拒绝 | | behavior_log | id, user_id, pet_id, behavior_type, score, create_time | 行为日志表浏览/收藏/点赞/申请每种行为对应不同分值 | | collection | id, user_id, pet_id, create_time | 收藏关系表也可直接用behavior_log替代但单独建表查询更快 | | adoption_feedback | id, apply_id, user_id, pet_id, content, create_time | 领养回访反馈表体现领养后的闭环 | 你会发现我特意把行为日志表和收藏表分成两张表。原因很简单收藏是用户主动的显式行为需要频繁查询“我收藏了哪些宠物”单独建表更方便而浏览、点赞是隐式行为适合用一张大日志表统一记录供推荐算法离线分析。 字段类型上给几个实用建议年龄不要用int写“几岁”用age_month存月龄这样既能兼容幼宠又能表达成年宠物的准确年龄健康状态不要用字符串用tinyint存枚举值比如1表示健康、2表示待治疗、3表示已康复描述文本字段如果用MySQL建议用text类型不要用varchar(255)否则宠物故事写长了会报错。 ### 3.2 表关系与查询场景梳理 表关系上核心是user和pet的多对多“行为”关系中间通过behavior_log和collection来连接。pet的publisher_id指向user表示这只宠物是谁发布上来的apply_record是user和pet之间的领养关系表一个用户可以对多只宠物发起申请但需要限制同一只宠物重复申请。 有一个细节需要在设计时就想好领养申请的业务规则。一般情况下一只宠物同一时间只能被一个用户正式申请并通过但允许有多人申请、一人通过的场景。所以在apply_record表中要加一个状态流转待审核、已通过、已拒绝、已失效。如果某个申请通过了其他待审核的申请要自动改成“已失效”这里可以在事务里处理也可以用状态字段控制。 推荐算法需要的查询主要集中在这几条SQL上查询一个用户的所有行为记录、查询所有用户对某个宠物的行为记录、查询宠物分类信息。所以behavior_log表尽量给(user_id, pet_id)建联合索引pet表的status字段要建索引因为推荐和筛选都要过滤“待领养”状态。 补充一个用MyBatis-Plus的心得如果你用它的代码生成器可以直接从实体类反向生成建表SQL省去手写一大堆表结构的时间。但生成之后务必检查字段注释、索引设置自动生成的不一定完全符合业务需求。 ## 4. 协同过滤推荐算法怎么让系统“懂”用户 ### 4.1 为什么领养系统需要推荐算法 这部分是整个项目的技术亮点也是答辩时的得分点。你需要先想明白一个问题一个用户打开领养平台看到几十只或几百只流浪动物如果没有推荐机制他就只能靠分类筛选和关键词搜索效率很低而且很容易漏掉真正适合他的宠物。 协同过滤解决的问题就是“从大量候选中找出用户最可能感兴趣的那几只”。比如一个用户收藏过柯基、申请过一只黄色短毛犬系统就可以学习到他对“小型、短毛、活泼”的犬种有偏好然后把相似的待领养动物推荐给他。这个逻辑听起来很自然但靠代码实现出来就是算法的价值。 在毕设答辩时老师大概率会问“为什么用协同过滤”。你至少要知道两种经典协同过滤的区别基于用户的UserCF和基于物品的ItemCF。UserCF是找“和你行为相似的其他用户”把他们喜欢的宠物推荐给你ItemCF是找“和你喜欢的宠物相似的宠物”直接推荐相似的。在宠物领养场景下我推荐用ItemCF因为用户的兴趣会变化但宠物的属性相对稳定而且ItemCF的推荐结果更直观方便你做出“因为你看过A所以推荐B”的解释。 ### 4.2 协同过滤的原理与相似度计算 基于物品的协同过滤核心就三步构建用户行为评分矩阵、计算物品之间的相似度、根据用户的既有行为生成推荐列表。 第一步把用户行为转成分值。用户的行为有浏览、收藏、点赞、申请它们对“用户感兴趣”的权重肯定不一样。我自己用的是这套分值浏览记1分点赞记2分收藏记3分提交领养申请记5分。分值可以自己调关键是让“申请”这种强意向行为的权重显著高于“浏览”这种弱行为。 第二步计算宠物之间的相似度。最常用的方法是余弦相似度把每只宠物视为一个向量向量的维度是所有用户每一维的值是用户是否对该宠物有过行为或行为总分。两只宠物的向量越接近余弦值越接近1说明它们越相似。以宠物A和宠物B为例公式是 cos(A, B) Σ(用户对A的分值 × 用户对B的分值) / (√Σ(对A分值的平方) × √Σ(对B分值的平方)) 这个公式的直观理解是如果同一批用户都同时喜欢A和B那么A和B的相似度就高。在代码里实现这个计算并不复杂难点在于处理稀疏数据——大部分用户的行为很少向量里全是0。毕设阶段可以不用做复杂的稀疏优化直接基于内存计算足够。 第三步预测用户对没有行为过的宠物的“推荐度”。做法是找到用户已经有过行为的宠物列表把每只宠物的相似宠物集合加权汇总。比如用户收藏过宠物X而宠物Y是X的相似宠物那么Y的推荐分就等于用户对X的行为分乘以X和Y的相似度最后把同一只宠物的多个来源分数累加。按推荐分从高到低排序取Top-N就是推荐列表。 ### 4.3 推荐模块的核心代码实现 推荐逻辑在SpringBoot里建议写成独立的Service比如RecommendService。核心思路是先查所有用户的行为记录构建userId到宠物评分Map再遍历宠物对计算相似度最后生成当前用户的推荐列表。下面给一个简化但能跑通的核心代码标注了关键逻辑 java Service public class RecommendService { Resource private BehaviorLogMapper behaviorLogMapper; Resource private PetMapper petMapper; // 用户行为记录列表 private MapInteger, MapInteger, Double buildUserItemScoreMap() { ListBehaviorLog logs behaviorLogMapper.selectAll(); MapInteger, MapInteger, Double userItemMap new HashMap(); for (BehaviorLog log : logs) { userItemMap.computeIfAbsent(log.getUserId(), k - new HashMap()) .merge(log.getPetId(), (double) log.getScore(), Double::sum); } return userItemMap; } // 计算两只宠物之间的余弦相似度 private Double calcSimilarity(MapInteger, Double petAVectors, MapInteger, Double petBVectors) { double dot 0, normA 0, normB 0; for (Map.EntryInteger, Double entry : petAVectors.entrySet()) { normA entry.getValue() * entry.getValue(); Double bScore petBVectors.get(entry.getKey()); if (bScore ! null) { dot entry.getValue() * bScore; } } for (Double score : petBVectors.values()) { normB score * score; } if (normA 0 || normB 0) return 0.0; return dot / (Math.sqrt(normA) * Math.sqrt(normB)); } // 为指定用户生成Top-N推荐 public ListPetVO recommendForUser(Integer userId, int topN) { MapInteger, MapInteger, Double userItemMap buildUserItemScoreMap(); MapInteger, Double userScores userItemMap.getOrDefault(userId, Collections.emptyMap()); MapInteger, Double recommendScores new HashMap(); ListInteger petIds petMapper.selectAllPetIds(); for (Integer userBevPetId : userScores.keySet()) { MapInteger, Double petAVectors getPetVector(userBevPetId, userItemMap); for (Integer candidatePetId : petIds) { if (userScores.containsKey(candidatePetId) || candidatePetId.equals(userBevPetId)) { continue; } MapInteger, Double petBVectors getPetVector(candidatePetId, userItemMap); double sim calcSimilarity(petAVectors, petBVectors); recommendScores.merge(candidatePetId, sim * userScores.get(userBevPetId), Double::sum); } } return recommendScores.entrySet().stream() .sorted(Map.Entry.Integer, DoublecomparingByValue().reversed()) .limit(topN) .map(entry - petMapper.selectPetVOById(entry.getKey())) .collect(Collectors.toList()); } }这段代码刻意做了简化核心是为了展示协同过滤从数据构建到相似度计算再到推荐排序的完整流程。实际项目里要注意几点不要每次请求都全表扫描行为日志而是定期把计算好的相似度矩阵缓存起来要过滤掉status不是“待领养”的宠物推荐结果里要排除用户已经申请过的宠物不然会出现“我已经申请了这只系统还推给我”的硬伤。关于相似度计算我建议在纯协同过滤基础上加一个小的改进把宠物自身的属性因素融入评分。比如两只宠物品种不同但体形和年龄相近可以在计算相似度时叠加一个属性相似度影响因子。改动不大但答辩时能讲出一套“改进思路”效果比照搬教科书要好得多。5. 实操过程中的坑与答辩经验5.1 冷启动与数据稀疏问题毕设系统最大的问题是“没有数据”。你设计了一套推荐算法但数据库里只有你自己注册的测试账号行为日志空荡荡算出来的相似度全是0推荐列表只能靠随机补位。这里分享几个使用的处理思路第一写一个数据初始化组件在系统启动时自动生成模拟数据。比如创建10个测试用户为每个用户随机生成浏览、收藏、申请记录。用SpringBoot的CommandLineRunner或者MyBatis-Plus的初始化脚本都可以实现。数据量不用很大每个用户5到20条行为就足够让目标算法跑出有意义的结果。第二冷启动要分两种情况处理。新注册用户没有行为数据推荐模块直接给他返回“热门宠物列表”——按浏览量和收藏数排序。新发布的宠物没有行为记录在推荐候选集里要保底露出可以随机在推荐列表里穿插一两只。如果你不处理冷启动问题答辩时老师随便创建个新用户点进来看推荐页是空的这就很难解释了。第三数据稀疏时加权策略要调整。真实场景里用户行为极度稀疏直接算余弦相似度可能大部分值都接近0。我的做法是对稀有行为提交申请给予更高权重前面提到的分值设计就是干这个的。你甚至可以设计一个提权因子如果一只宠物被申请的次数很少那么这只宠物相关相似度的置信度会打折这个细节写进论文里是一个加分项。5.2 部署与项目结构的一些心得SpringBoot项目的结构按照标准的controller、service、mapper、entity、config分包即可。网上常见的模板是controller层做参数校验和路由编排service层做业务逻辑mapper层用MyBatis-Plus操作数据库实体类与数据库表对应。推荐算法单独放在recommend包里不要和业务service混在一起这样国内外答辩老师看目录结构的时候能一眼找到技术重点。前端如果用Vue建议开发阶段用Vite启动独立前端服务通过proxy代理把/api请求转发到SpringBoot的8080端口。等开发的差不多要合体了再把Vue打包后的dist目录整个放进SpringBoot的src/main/resources/static下这样SpringBoot一个jar包就包含了前后端整套系统演示和部署都方便很多。这个“打包放进静态目录”的操作网上已经有很多教程但要注意Vue里的接口地址要改成相对路径别写死localhost:8080否则换一台机器演示就挂了。部署方面最省事的方式是在服务器或本地安装MySQL用SpringBoot的application.yml配置好数据源然后执行java -jar启动项目。不强制非要上Docker或Nginx毕设演示时一个能开机启动的jar包比一堆容器配置更靠谱。有条件的话可以加一层Redis缓存相似度矩阵但我个人建议毕设阶段按情况取舍——别为了加分引入一个你没完全掌握的技术答辩时经不起追问反而扣分。5.3 常见问题速查与答辩高频追问把我在实际写这类项目时遇到过的典型问题整理成一个速查表你可以直接对照着排查现象可能原因处理方式启动报端口被占用8080端口被其他程序占用换端口或杀掉占用进程开发期用server.port8081临时解决数据库中文乱码MySQL连接串没指定编码JDBC URL加useUnicodetruecharacterEncodingutf8Vue请求接口404前端代理未配置或打包后路径不对开发期配置vite proxy生产环境检查static目录结构推荐列表为空没有行为数据或冷启动未处理先跑数据初始化脚本再检查推荐候选集是否为空用户重复申请同一宠物缺少业务校验在apply_record加唯一索引并在service层做存在性校验相似度全部为0用户行为矩阵太稀疏调整行为权重增加模拟数据或者加入宠物属性相似度兜底答辩时老师常问的问题其实可以提前准备好。第一个高频问题是“什么是协同过滤它和基于内容推荐有什么区别”。你要能说清楚协同过滤完全依赖用户行为不需要理解物品内容基于内容推荐依赖物品的属性标签比如品种、年龄、性格不需要用户行为。第二个问题是“你的推荐效果怎么评价”。坦白说毕设阶段很难做离线评测你可以说用了留一法测试或者人工对比几个典型用户案例。第三个问题是“为什么不用深度学习”。答案是数据量太小深度学习没有训练价值协同过滤能给出可解释的推荐理由更适合这种中小型平台。提示答辩的时候一定要准备一组可视化演示数据。比如用一个名为“小林”的测试账号精心构造他浏览过两只柯基、申请过一只的行为然后演示首页推荐流给他推了另一只柯基并且讲一句话“因为您看过多只柯基所以为您推荐了这只相似体型的柯基”。一句具体的推荐理由比讲十页公式更容易让老师相信“你真的做出来了”。我个人做完这套系统最大的体会是技术面试和项目答辩其实都在看一件事——你是不是真的理解了自己写的代码。协同过滤的实现不难难的是你把它安放到一个合适的业务场景里并且能解释清楚为什么这样设计。流浪动物领养这个场景给了它一个天然合理的落点救助者想快点找到靠谱的领养人领养人想找到合眼缘的宠物推荐算法就是在这两者之间架一座桥。如果你也在做类似的平台型毕设我建议先把业务流和表结构想清楚再动手写代码数据模型稳了后面加什么功能都不慌。最后再分享一个小技巧接口能早联调就早联调别等后端全部写完再对接前端两个人或者你自己又当后端又当前端拖到后面才发现字段对不上那才是最折磨人的。
SpringBoot+协同过滤：流浪动物领养救助系统毕设设计与实现
Java毕设选来选去还是选了这种“业务逻辑清晰、技术栈主流、还带一点算法亮点”的题目——基于SpringBoot与协同过滤算法的流浪动物领养与救助系统。这类平台型项目在毕设里非常吃香一是主题自带正能量救助流浪动物本身就容易引发共鸣二是功能边界清楚从宠物信息发布、领养申请到救助记录上报每一块都能落地三是加上推荐算法之后技术深度一下子就有了答辩的时候也有的聊。如果你正打算做类似的系统或者已经在写这类项目但卡在推荐算法和模块设计上这篇文章会给你一条相对完整的路线。我会把题目拆解、功能设计、数据库建模、协同过滤实现、常见坑和答辩经验一次性讲清楚所有内容都基于我实际写这种TypeScript的经验偏实用不整虚的。1. 毕设选题拆解这个题目到底在做什么1.1 “流浪动物领养与救助”背后的真实业务场景很多同学看到这个题目第一反应是“这不就是一个CRUD系统吗”。从表面看确实是这样管理员发布流浪动物信息、用户浏览、然后提交领养申请。但如果你真把业务场景想清楚了会发现它比普通的“商品管理系统”多了一层临时性的信息撮合逻辑。真实的流浪动物救助流程是这样的有人在外面发现一只流浪猫或流浪狗先拍照、上报位置和基本情况然后由救助站或志愿者把动物接到临时安置点进行健康检查、驱虫、绝育等状态稳定后发布领养信息。有领养意愿的人浏览信息觉得合适就提交申请救助方审核通过后进行线下交接最后还要做回访确认动物在新家里过得好不好。所以这个系统里至少要有三条主线救助上报记录谁在什么时间、什么地点发现流浪动物目前状态是什么。领养流转待领养宠物信息发布、用户浏览收藏、申请审核、领养结果反馈。用户行为追踪用户浏览了哪些宠物、收藏了哪些、申请了哪些这些数据是后面推荐算法的燃料。如果把这三条主线理顺了系统的功能边界自然就出来了。很多毕设做得散就是因为上来就写代码没先把这个业务流想明白。1.2 技术栈选择的合理性分析标题里出现了JavaEE和SpringBoot这两个词放在一起需要留意一下。严格来说JavaEE是一整套企业级规范SpringBoot是实现这些规范的主流框架之一。毕设项目一般不需要去抠概念上的区别你只需要明白用SpringBoot做Web后端是现代Java项目的默认选项因为它内嵌了Tomcat不用单独部署容器起步快生态成熟。再来说SpringBoot的版本选择。我用的是SpringBoot 2.7.x配JDK 8这个组合在毕设里最稳。SpringBoot 3.x确实新但需要JDK 17起步而且不少教程和第三方依赖还没完全跟上你在开发的过程中遇到问题不好搜答案。如果你学校机房的JDK版本比较老更不要强行上3.x。推荐算法部分标题点名了协同过滤。为什么选协同过滤而不是深度学习原因很简单数据集规模小、需要可解释性、答辩时要能说清楚原理。协同过滤是推荐系统里最经典的算法逻辑直观公式也不复杂用纯Java写几百行就能实现不需要引入Python服务或复杂的机器学习框架。毕设阶段选它属于“性价比”最高的方案。## 2. 需求分析与功能架构设计 ### 2.1 用户角色与核心业务流程 系统建议设计三种角色普通用户、救助方/机构、系统管理员。如果不想把角色分得太碎可以把“救助方”和“管理员”合并但主流程会稍微模糊一些。我更推荐拆开理由很实在不同角色的权限边界清晰了后台管理的代码就更好写答辩时讲权限控制也更有说服力。 先看业务流程的全貌。一个普通用户进入系统后在首页能看到推荐宠物列表也可以按品种、年龄、健康状态筛选。点进宠物详情页能看到这个小动物的救助故事、健康状况、性格描述。用户如果有领养意向可以点击收藏或直接提交领养申请。申请提交后救助方在后台看到申请记录审核通过后进入线下接触流程。 救助方的操作链路是另一条线。他们在后台发布待领养宠物填写基本信息、上传照片、标记健康状态和领养要求。同时能管理自己上报的救助记录比如某只流浪动物目前是“待安置”“已安置”“已领养”中的哪个状态。 管理员主要负责基础数据维护和全局审核比如用户管理、公告发布、救助机构审核、领养成功后的回访记录管理。整个系统不是简单的“管理员管一切”而是让业务顺着角色流起来。 ### 2.2 功能模块划分及其边界 基于上面的业务流程我会把系统拆成两类模块面向用户的前台模块和面向管理方的后台模块。 前台模块主要有用户注册登录、首页推荐流、宠物分类浏览与搜索、宠物详情、收藏管理、领养申请、救助上报、个人中心、站内公告。这里有一个容易被忽略的点救助上报不能只做成一个“填表单”的入口上报之后的状态应该能被用户追踪比如“我上报的那只猫现在是否已被救助站接收”。这个追踪闭环做好了系统才真正有“救助”属性而不是只有领养功能。 后台模块主要有宠物信息管理、救助记录管理、领养申请审核、用户管理、公告管理、回访记录管理、数据统计看板。数据统计看板是加分项不用做得很复杂展示待领养数量、领养成功率、本月新增救助量这几个指标就够撑场面了。 边界划分上有一个常见的“度”不要把推荐算法混进业务模块里。推荐逻辑应该独立成一个服务类只依赖于用户行为数据这样即使推荐算法挂了基本的浏览和申请功能依然可用。代码结构上也更清晰控制层管参数校验服务层管业务编排推荐模块单独放在recommend包下面。 ## 3. 数据库设计表结构是系统的地基 ### 3.1 核心表设计与字段说明 这个系统的数据库表不需要设计得很花哨但有一张表是灵魂用户行为日志表。因为协同过滤算法要依赖用户的历史行为来做推荐如果没有这张表算法就是无米之炊。 我列出主要表及其核心字段你可以直接参考 | 表名 | 核心字段 | 说明 | | --- | --- | --- | | user | id, username, password, phone, avatar, role_type, status | 用户表role_type区分普通用户/救助方/管理员 | | pet | id, name, category_id, breed, gender, age_month, health_status, description, cover_image, publisher_id, status, create_time | 宠物信息表status标记待领养/已申请/已领养 | | rescue_record | id, reporter_id, pet_id, location, description, status, process_result | 救助上报记录关联到pet_id以便后续转为待领养宠物 | | apply_record | id, user_id, pet_id, apply_reason, contact_info, audit_status, audit_time | 领养申请记录audit_status为待审核/通过/拒绝 | | behavior_log | id, user_id, pet_id, behavior_type, score, create_time | 行为日志表浏览/收藏/点赞/申请每种行为对应不同分值 | | collection | id, user_id, pet_id, create_time | 收藏关系表也可直接用behavior_log替代但单独建表查询更快 | | adoption_feedback | id, apply_id, user_id, pet_id, content, create_time | 领养回访反馈表体现领养后的闭环 | 你会发现我特意把行为日志表和收藏表分成两张表。原因很简单收藏是用户主动的显式行为需要频繁查询“我收藏了哪些宠物”单独建表更方便而浏览、点赞是隐式行为适合用一张大日志表统一记录供推荐算法离线分析。 字段类型上给几个实用建议年龄不要用int写“几岁”用age_month存月龄这样既能兼容幼宠又能表达成年宠物的准确年龄健康状态不要用字符串用tinyint存枚举值比如1表示健康、2表示待治疗、3表示已康复描述文本字段如果用MySQL建议用text类型不要用varchar(255)否则宠物故事写长了会报错。 ### 3.2 表关系与查询场景梳理 表关系上核心是user和pet的多对多“行为”关系中间通过behavior_log和collection来连接。pet的publisher_id指向user表示这只宠物是谁发布上来的apply_record是user和pet之间的领养关系表一个用户可以对多只宠物发起申请但需要限制同一只宠物重复申请。 有一个细节需要在设计时就想好领养申请的业务规则。一般情况下一只宠物同一时间只能被一个用户正式申请并通过但允许有多人申请、一人通过的场景。所以在apply_record表中要加一个状态流转待审核、已通过、已拒绝、已失效。如果某个申请通过了其他待审核的申请要自动改成“已失效”这里可以在事务里处理也可以用状态字段控制。 推荐算法需要的查询主要集中在这几条SQL上查询一个用户的所有行为记录、查询所有用户对某个宠物的行为记录、查询宠物分类信息。所以behavior_log表尽量给(user_id, pet_id)建联合索引pet表的status字段要建索引因为推荐和筛选都要过滤“待领养”状态。 补充一个用MyBatis-Plus的心得如果你用它的代码生成器可以直接从实体类反向生成建表SQL省去手写一大堆表结构的时间。但生成之后务必检查字段注释、索引设置自动生成的不一定完全符合业务需求。 ## 4. 协同过滤推荐算法怎么让系统“懂”用户 ### 4.1 为什么领养系统需要推荐算法 这部分是整个项目的技术亮点也是答辩时的得分点。你需要先想明白一个问题一个用户打开领养平台看到几十只或几百只流浪动物如果没有推荐机制他就只能靠分类筛选和关键词搜索效率很低而且很容易漏掉真正适合他的宠物。 协同过滤解决的问题就是“从大量候选中找出用户最可能感兴趣的那几只”。比如一个用户收藏过柯基、申请过一只黄色短毛犬系统就可以学习到他对“小型、短毛、活泼”的犬种有偏好然后把相似的待领养动物推荐给他。这个逻辑听起来很自然但靠代码实现出来就是算法的价值。 在毕设答辩时老师大概率会问“为什么用协同过滤”。你至少要知道两种经典协同过滤的区别基于用户的UserCF和基于物品的ItemCF。UserCF是找“和你行为相似的其他用户”把他们喜欢的宠物推荐给你ItemCF是找“和你喜欢的宠物相似的宠物”直接推荐相似的。在宠物领养场景下我推荐用ItemCF因为用户的兴趣会变化但宠物的属性相对稳定而且ItemCF的推荐结果更直观方便你做出“因为你看过A所以推荐B”的解释。 ### 4.2 协同过滤的原理与相似度计算 基于物品的协同过滤核心就三步构建用户行为评分矩阵、计算物品之间的相似度、根据用户的既有行为生成推荐列表。 第一步把用户行为转成分值。用户的行为有浏览、收藏、点赞、申请它们对“用户感兴趣”的权重肯定不一样。我自己用的是这套分值浏览记1分点赞记2分收藏记3分提交领养申请记5分。分值可以自己调关键是让“申请”这种强意向行为的权重显著高于“浏览”这种弱行为。 第二步计算宠物之间的相似度。最常用的方法是余弦相似度把每只宠物视为一个向量向量的维度是所有用户每一维的值是用户是否对该宠物有过行为或行为总分。两只宠物的向量越接近余弦值越接近1说明它们越相似。以宠物A和宠物B为例公式是 cos(A, B) Σ(用户对A的分值 × 用户对B的分值) / (√Σ(对A分值的平方) × √Σ(对B分值的平方)) 这个公式的直观理解是如果同一批用户都同时喜欢A和B那么A和B的相似度就高。在代码里实现这个计算并不复杂难点在于处理稀疏数据——大部分用户的行为很少向量里全是0。毕设阶段可以不用做复杂的稀疏优化直接基于内存计算足够。 第三步预测用户对没有行为过的宠物的“推荐度”。做法是找到用户已经有过行为的宠物列表把每只宠物的相似宠物集合加权汇总。比如用户收藏过宠物X而宠物Y是X的相似宠物那么Y的推荐分就等于用户对X的行为分乘以X和Y的相似度最后把同一只宠物的多个来源分数累加。按推荐分从高到低排序取Top-N就是推荐列表。 ### 4.3 推荐模块的核心代码实现 推荐逻辑在SpringBoot里建议写成独立的Service比如RecommendService。核心思路是先查所有用户的行为记录构建userId到宠物评分Map再遍历宠物对计算相似度最后生成当前用户的推荐列表。下面给一个简化但能跑通的核心代码标注了关键逻辑 java Service public class RecommendService { Resource private BehaviorLogMapper behaviorLogMapper; Resource private PetMapper petMapper; // 用户行为记录列表 private MapInteger, MapInteger, Double buildUserItemScoreMap() { ListBehaviorLog logs behaviorLogMapper.selectAll(); MapInteger, MapInteger, Double userItemMap new HashMap(); for (BehaviorLog log : logs) { userItemMap.computeIfAbsent(log.getUserId(), k - new HashMap()) .merge(log.getPetId(), (double) log.getScore(), Double::sum); } return userItemMap; } // 计算两只宠物之间的余弦相似度 private Double calcSimilarity(MapInteger, Double petAVectors, MapInteger, Double petBVectors) { double dot 0, normA 0, normB 0; for (Map.EntryInteger, Double entry : petAVectors.entrySet()) { normA entry.getValue() * entry.getValue(); Double bScore petBVectors.get(entry.getKey()); if (bScore ! null) { dot entry.getValue() * bScore; } } for (Double score : petBVectors.values()) { normB score * score; } if (normA 0 || normB 0) return 0.0; return dot / (Math.sqrt(normA) * Math.sqrt(normB)); } // 为指定用户生成Top-N推荐 public ListPetVO recommendForUser(Integer userId, int topN) { MapInteger, MapInteger, Double userItemMap buildUserItemScoreMap(); MapInteger, Double userScores userItemMap.getOrDefault(userId, Collections.emptyMap()); MapInteger, Double recommendScores new HashMap(); ListInteger petIds petMapper.selectAllPetIds(); for (Integer userBevPetId : userScores.keySet()) { MapInteger, Double petAVectors getPetVector(userBevPetId, userItemMap); for (Integer candidatePetId : petIds) { if (userScores.containsKey(candidatePetId) || candidatePetId.equals(userBevPetId)) { continue; } MapInteger, Double petBVectors getPetVector(candidatePetId, userItemMap); double sim calcSimilarity(petAVectors, petBVectors); recommendScores.merge(candidatePetId, sim * userScores.get(userBevPetId), Double::sum); } } return recommendScores.entrySet().stream() .sorted(Map.Entry.Integer, DoublecomparingByValue().reversed()) .limit(topN) .map(entry - petMapper.selectPetVOById(entry.getKey())) .collect(Collectors.toList()); } }这段代码刻意做了简化核心是为了展示协同过滤从数据构建到相似度计算再到推荐排序的完整流程。实际项目里要注意几点不要每次请求都全表扫描行为日志而是定期把计算好的相似度矩阵缓存起来要过滤掉status不是“待领养”的宠物推荐结果里要排除用户已经申请过的宠物不然会出现“我已经申请了这只系统还推给我”的硬伤。关于相似度计算我建议在纯协同过滤基础上加一个小的改进把宠物自身的属性因素融入评分。比如两只宠物品种不同但体形和年龄相近可以在计算相似度时叠加一个属性相似度影响因子。改动不大但答辩时能讲出一套“改进思路”效果比照搬教科书要好得多。5. 实操过程中的坑与答辩经验5.1 冷启动与数据稀疏问题毕设系统最大的问题是“没有数据”。你设计了一套推荐算法但数据库里只有你自己注册的测试账号行为日志空荡荡算出来的相似度全是0推荐列表只能靠随机补位。这里分享几个使用的处理思路第一写一个数据初始化组件在系统启动时自动生成模拟数据。比如创建10个测试用户为每个用户随机生成浏览、收藏、申请记录。用SpringBoot的CommandLineRunner或者MyBatis-Plus的初始化脚本都可以实现。数据量不用很大每个用户5到20条行为就足够让目标算法跑出有意义的结果。第二冷启动要分两种情况处理。新注册用户没有行为数据推荐模块直接给他返回“热门宠物列表”——按浏览量和收藏数排序。新发布的宠物没有行为记录在推荐候选集里要保底露出可以随机在推荐列表里穿插一两只。如果你不处理冷启动问题答辩时老师随便创建个新用户点进来看推荐页是空的这就很难解释了。第三数据稀疏时加权策略要调整。真实场景里用户行为极度稀疏直接算余弦相似度可能大部分值都接近0。我的做法是对稀有行为提交申请给予更高权重前面提到的分值设计就是干这个的。你甚至可以设计一个提权因子如果一只宠物被申请的次数很少那么这只宠物相关相似度的置信度会打折这个细节写进论文里是一个加分项。5.2 部署与项目结构的一些心得SpringBoot项目的结构按照标准的controller、service、mapper、entity、config分包即可。网上常见的模板是controller层做参数校验和路由编排service层做业务逻辑mapper层用MyBatis-Plus操作数据库实体类与数据库表对应。推荐算法单独放在recommend包里不要和业务service混在一起这样国内外答辩老师看目录结构的时候能一眼找到技术重点。前端如果用Vue建议开发阶段用Vite启动独立前端服务通过proxy代理把/api请求转发到SpringBoot的8080端口。等开发的差不多要合体了再把Vue打包后的dist目录整个放进SpringBoot的src/main/resources/static下这样SpringBoot一个jar包就包含了前后端整套系统演示和部署都方便很多。这个“打包放进静态目录”的操作网上已经有很多教程但要注意Vue里的接口地址要改成相对路径别写死localhost:8080否则换一台机器演示就挂了。部署方面最省事的方式是在服务器或本地安装MySQL用SpringBoot的application.yml配置好数据源然后执行java -jar启动项目。不强制非要上Docker或Nginx毕设演示时一个能开机启动的jar包比一堆容器配置更靠谱。有条件的话可以加一层Redis缓存相似度矩阵但我个人建议毕设阶段按情况取舍——别为了加分引入一个你没完全掌握的技术答辩时经不起追问反而扣分。5.3 常见问题速查与答辩高频追问把我在实际写这类项目时遇到过的典型问题整理成一个速查表你可以直接对照着排查现象可能原因处理方式启动报端口被占用8080端口被其他程序占用换端口或杀掉占用进程开发期用server.port8081临时解决数据库中文乱码MySQL连接串没指定编码JDBC URL加useUnicodetruecharacterEncodingutf8Vue请求接口404前端代理未配置或打包后路径不对开发期配置vite proxy生产环境检查static目录结构推荐列表为空没有行为数据或冷启动未处理先跑数据初始化脚本再检查推荐候选集是否为空用户重复申请同一宠物缺少业务校验在apply_record加唯一索引并在service层做存在性校验相似度全部为0用户行为矩阵太稀疏调整行为权重增加模拟数据或者加入宠物属性相似度兜底答辩时老师常问的问题其实可以提前准备好。第一个高频问题是“什么是协同过滤它和基于内容推荐有什么区别”。你要能说清楚协同过滤完全依赖用户行为不需要理解物品内容基于内容推荐依赖物品的属性标签比如品种、年龄、性格不需要用户行为。第二个问题是“你的推荐效果怎么评价”。坦白说毕设阶段很难做离线评测你可以说用了留一法测试或者人工对比几个典型用户案例。第三个问题是“为什么不用深度学习”。答案是数据量太小深度学习没有训练价值协同过滤能给出可解释的推荐理由更适合这种中小型平台。提示答辩的时候一定要准备一组可视化演示数据。比如用一个名为“小林”的测试账号精心构造他浏览过两只柯基、申请过一只的行为然后演示首页推荐流给他推了另一只柯基并且讲一句话“因为您看过多只柯基所以为您推荐了这只相似体型的柯基”。一句具体的推荐理由比讲十页公式更容易让老师相信“你真的做出来了”。我个人做完这套系统最大的体会是技术面试和项目答辩其实都在看一件事——你是不是真的理解了自己写的代码。协同过滤的实现不难难的是你把它安放到一个合适的业务场景里并且能解释清楚为什么这样设计。流浪动物领养这个场景给了它一个天然合理的落点救助者想快点找到靠谱的领养人领养人想找到合眼缘的宠物推荐算法就是在这两者之间架一座桥。如果你也在做类似的平台型毕设我建议先把业务流和表结构想清楚再动手写代码数据模型稳了后面加什么功能都不慌。最后再分享一个小技巧接口能早联调就早联调别等后端全部写完再对接前端两个人或者你自己又当后端又当前端拖到后面才发现字段对不上那才是最折磨人的。