基于Java与Spring Boot的图书个性化推荐系统开发实战

简介：这是一套基于Java Spring Boot的图书个性化推荐系统毕业设计包，面向计算机与软件工程专业学生，覆盖用户注册登录、图书检索、评分收藏、个性化推荐等模块，推荐算法融合协同过滤与基于内容的方法，帮助用户获取精准书目。包体含代码、数据库、论文、PPT、演示录像、运行教学及配套软件，共156.34MB。源码展示Spring Boot分层架构与RESTful接口设计；数据库含用户信息表、图书信息表、行为记录表等；论文与PPT覆盖需求分析至测试全过程；演示录像呈现注册到获取推荐的交互流程；配套软件与运行教学可快速搭建本地环境。目前已有82人学习浏览。使用该资源可理解推荐系统工程化实现路径，复用编码规范与模块划分，显著缩短毕设文档撰写与调试周期，兼具学习与实用价值。 图书个性化推荐系统，听起来像是课设或者毕设里最常见的“老熟人”。但把Java和Spring Boot组合起来，再做一套能跑的推荐逻辑，里面能挖的细节其实非常多。这篇内容我打算按自己实际做项目时的思路来拆，从选题、数据库设计、算法落地，到论文和答辩素材怎么整理，一条线讲清楚。不管是正在纠结题目的，还是已经开工想完善系统的，应该都能找到点参考。

1. 选题思路与系统整体架构

1.1 为什么选“图书个性化推荐”当毕业设计

毕设选题有个很现实的原则：既要有技术含量，又要能在一学期内完成，还得让答辩老师一眼看出工作量。图书个性化推荐系统恰好满足这三点。它不是一个简单的CRUD项目，背后有推荐算法这个“灵魂”在；同时业务模型清晰，用户、图书、评分、借阅记录这些实体关系很好画，数据库设计不会绕晕；更重要的是，市面上成熟的推荐算法有大量公开资料，遇到问题能查到解决方案，不会卡死在某个数学公式上。

我当时选这个题目还有一个私心：图书推荐可以做成基于用户行为（收藏、评分、借阅时长）的协同过滤，也可以混入基于内容的标签匹配，算法选型灵活。这意味着我可以在论文里做对比实验，写“改进”部分时也有话可说。如果选电商推荐，数据量和业务复杂度会倍增；如果选新闻推荐，时效性处理又很麻烦。图书推荐的数据相对稳定，冷启动问题也比较容易通过热门榜、分类榜来缓解，是一个“刚刚好”的难度区间。

1.2 Java + Spring Boot 技术选型的真实考量

用Java做毕设的好处不用多提，生态成熟、资料多、面试还能顺手复习一轮基础。Spring Boot在这里面的角色是大幅降低整合成本。传统SSH项目要写一堆XML配置，Spring Boot用自动配置和起步依赖把这些琐事收掉了，让我能把精力放在推荐算法和业务逻辑上。尤其是做毕业设计这种周期紧、需要反复调试的场景，启动快、报错清晰就是最大的效率保障。

架构上我选择了前后端分离但不过度设计的方案：前端用Thymeleaf模板引擎渲染后台管理页面，配合Bootstrap做基础样式；用户浏览和推荐展示的页面用简单的HTML + AJAX调用后端接口。为什么不用Vue或React？因为毕设的重点是后端和算法，前端做到整洁能用即可，引入Node.js构建链反而增加环境复杂度。如果导师明确要求前后端分离，那换成Vue也不是不行，代码里接口返回JSON，适配成本很低。技术栈最后是：

• JDK 1.8 + Maven 3.6 + MySQL 5.7
• Spring Boot 2.x（我用的是2.5.x，稳定且资料多）
• MyBatis-Plus + Druid连接池
• Thymeleaf + Bootstrap + jQuery

这里有个实际心得：Spring Boot版本不要盲目追新，有时最新的版本改动很大，网上很多资料对不上，折腾一圈反而浪费时间。2.5.x这个版本我用下来比较省心，大部分框架兼容性问题网上都有现成答案。

1.3 基础功能模块划分

系统的功能模块按照“前台用户”和“后台管理”两个视角来切。前台包括：用户注册登录、图书列表与详情、分类浏览、搜索、评分、收藏、借阅模拟、个性化推荐（猜你喜欢）、热门排行榜。后台包括：图书管理（增删改查）、用户管理、评论管理、评分数据管理、推荐算法参数配置、数据统计报表。

模块划分的原则是：每个模块尽量独立，接口清晰。比如评分和收藏归到“用户行为”模块，推荐算法单独一个service包，与具体业务解耦。这样写论文的时候可以按模块展开需求分析，画功能结构图也方便。另一个好处是，如果时间不够，某些模块可以只实现核心功能，但整体框架依然是完整的，答辩时能自圆其说。

2. 数据库设计与核心表结构

2.1 从ER图到建表：哪些表必不可少

数据库设计是答辩时老师很容易提问的环节，也是很多同学偷懒的地方。我画ER图时整理了7张核心表：用户表（t_user）、图书表（t_book）、图书分类表（t_category）、评分表（t_rating）、收藏表（t_favorite）、借阅记录表（t_borrow）、推荐结果表（t_recommend）。每一张表都有明确的业务含义，关联关系也干净。

用户表字段包括用户ID、用户名、密码（加盐MD5存储）、昵称、头像、角色等。图书表要涵盖书名、作者、ISBN、出版社、出版日期、封面URL、简介、分类ID、点击量、库存量。这里特别建议把ISBN设为普通索引而不是唯一索引，因为有些旧版本书没有ISBN，写入会报错。评分表要带用户ID、图书ID、评分值（1到5分）、评分时间，并且对（用户ID，图书ID）做联合唯一约束，防止同一用户重复评分。

建表时注意InnoDB引擎和utf8mb4字符集，这是一个很容易被忽略的点。如果不指定字符集，插入中文书名和简介时会出现乱码，在答辩演示现场非常尴尬。我之前在实验室就遇到过这个问题，后来统一在Navicat的默认字符集里设置成utf8mb4，再没有出现过“问号乱码”的问题。

2.2 设计推荐结果表的两种思路

关于推荐结果要不要存表，有两种做法。一种是动态计算，用户每次请求推荐就会实时跑一遍协同过滤算法，返回结果。另一种是离线计算后存到推荐结果表，用户请求时直接查询。我的建议是：推荐结果表一定要有，但推荐结果的更新要靠定时任务。

原因很实际：协同过滤算法在数据量上来之后，实时计算的响应时间会从毫秒级变成秒级，用户体验很差。而且毕业设计答辩时要演示，老师说“你点一下推荐看看”，如果转半天圈圈，体验分就掉了。我的方案是：用户登录时触发一次计算，把该用户的Top-N推荐结果写进t_recommend表；每晚凌晨2点通过Spring Boot自带的@Scheduled定时任务再全量计算一次，刷新所有用户的推荐列表。这样既能保证推荐结果在一天内相对新鲜，又不会拖慢接口响应。t_recommend表的字段为推荐ID、用户ID、图书ID、推荐分数、推荐类型（基于用户还是基于物品）、生成时间，加一个（用户ID，推荐类型）的联合索引。

2.3 MyBatis-Plus的巧妙使用

MyBatis-Plus在这里的价值被我低估了一段时间。一开始我还在手写XML的ResultMap和动态SQL，后来发现用MyBatis-Plus的BaseMapper，单表CRUD基本不用写SQL语句。比如图书分页查询，直接用LambdaQueryWrapper构造条件，代码量能减少一半以上。对于联表查询，比如“查询某一用户收藏的所有图书及其分类名称”，我的经验是尽量简化：先查收藏表拿到图书ID列表，再用ID列表到图书表查出完整信息。两次单表查询在数据量不大时性能很好，而且逻辑清晰，不容易出bug。

不过要注意，MyBatis-Plus的自动填充和逻辑删除功能要用对。比如create_time字段设置自动填充后，插入数据时如果没给该字段赋值，框架会自动填当前时间。但如果表里字段名和Java属性名不一致，或者字段类型错了，自动填充会静默失败。我出现过一次登录日志时间全是空值，排查半天才发现是Java属性里用了sql.Date而表里是datetime类型。所以用框架自动功能之前，先确认类型匹配。

3. 个性化推荐算法的落地实现

3.1 协同过滤的核心原理

图书个性化推荐系统的核心在于推荐算法。我采用的是经典的协同过滤（Collaborative Filtering）思路。协同过滤的基本假设是：对某本书感兴趣的人，他们的喜好路径是可以互相引用的。基于用户的协同过滤（UserCF）先找到和目标用户兴趣相似的一批用户（找相似用户），再把这些用户喜欢的、目标用户没看过的书推荐出来。基于物品的协同过滤（ItemCF）则反过来，先找和目标图书相似的图书，再根据用户的历史行为向他推荐相似图书。

相似度的计算是协同过滤的关键。我使用余弦相似度计算用户之间的兴趣相似度，公式是：两个用户评分的交集商品分数向量点积，除以两个向量模长的乘积。代码实现时，可以用一个Map存储每个用户对图书的评分，然后遍历计算。虽然用双重循环，但数据量小的时候性能完全足够。为了让量级可控，我在SQL里做了一个过滤：只计算那些与目标用户“共同评分超过2本”的用户。举个例子，用户A和用户B都评过《Java核心技术》和《Spring实战》，这时他们的向量点积才有意义。如果只共同评了1本书，相似度的置信度不高，往往是噪声。

3.2 相似度计算与推荐分数生成的完整代码

先看UserCF的Java实现。我用了HashMap来存储用户评分数据，然后在service层完成相似度计算和Top-N推荐。

public List<Integer> recommendByUserCF(Integer userId, int topN) { // 1. 获取目标用户评分图书map Map<Integer, Double> currentUserRatings = ratingMapper.selectMapByUserId(userId); // 2. 得到候选相似用户列表 List<Integer> candidateUserIds = ratingMapper.selectDistinctUserIds(); // 3. 计算与所有候选用户的余弦相似度 Map<Integer, Double> userSimilarity = new HashMap<>(); for (Integer candidateId : candidateUserIds) { if (candidateId.equals(userId)) { continue; } Map<Integer, Double> candidateRatings = ratingMapper.selectMapByUserId(candidateId); Double sim = cosineSimilarity(currentUserRatings, candidateRatings); if (sim > 0) { userSimilarity.put(candidateId, sim); } } // 4. 取TopK相似用户 List<Map.Entry<Integer, Double>> sortedUsers = userSimilarity.entrySet().stream() .sorted((e1, e2) -> Double.compare(e2.getValue(), e1.getValue())) .limit(10) .collect(Collectors.toList()); // 5. 聚合推荐分数，过滤已看过的 Map<Integer, Double> scoreMap = new HashMap<>(); for (Map.Entry<Integer, Double> entry : sortedUsers) { Map<Integer, Double> candidateRatings = ratingMapper.selectMapByUserId(entry.getKey()); for (Map.Entry<Integer, Double> bookEntry : candidateRatings.entrySet()) { if (!currentUserRatings.containsKey(bookEntry.getKey())) { scoreMap.merge(bookEntry.getKey(), entry.getValue() * bookEntry.getValue(), Double::sum); } } } // 6. 按分数排序返回TopN return scoreMap.entrySet().stream() .sorted((e1, e2) -> Double.compare(e2.getValue(), e1.getValue())) .limit(topN) .map(Map.Entry::getKey) .collect(Collectors.toList()); }

余弦相似度工具方法：

private double cosineSimilarity(Map<Integer, Double> userA, Map<Integer, Double> userB) { Map<Integer, Double> unionKeys = new HashMap<>(); unionKeys.putAll(userA); unionKeys.putAll(userB); if (unionKeys.isEmpty()) { return 0D; } double dotProduct = 0D; double normA = 0D; double normB = 0D; for (Integer bookId : unionKeys.keySet()) { double scoreA = userA.getOrDefault(bookId, 0D); double scoreB = userB.getOrDefault(bookId, 0D); dotProduct += scoreA * scoreB; normA += Math.pow(scoreA, 2); normB += Math.pow(scoreB, 2); } if (normA == 0D || normB == 0D) { return 0D; } return dotProduct / (Math.sqrt(normA) * Math.sqrt(normB)); }

这段代码看起来不复杂，实际运行效果也不错。但有一个细节要注意：当用户数量增多时，双重遍历的时间复杂度是O(N²)，性能会下降。我的优化方法是：在SQL层先过滤掉那些和当前用户完全没有共同评分项的用户。可以通过inner join评分表，只统计co_rating_count大于等于2的用户，再取前200个候选，再跑内存计算。这样既能保留准确性，又不会把CPU打满。

3.3 ItemCF与混合推荐的参数调节

在实现完UserCF后，我又加了ItemCF，目的是做一个简单的混合推荐，论文里可以有对比数据。ItemCF的核心是计算物品之间的相似度矩阵。在实际代码里，可以用一个Map<Integer, Map<Integer, Double>>来存储图书相似度矩阵。每次推荐时，遍历用户历史评分图书，找到这些图书最相似的TopN图书，再按相似度加权评分。

混合推荐的方式我用的是加权融合：推荐分数 = 0.6 * UserCF分数 + 0.4 * ItemCF分数。加权系数不是拍脑袋定的，我跑了一次简单的评估：以测试集评分预测的MAE（平均绝对误差）为指标，尝试了0.5/0.5、0.6/0.4、0.7/0.3三组参数，最后0.6/0.4效果最好。这一段内容写到论文里会非常加分，因为展示了你做实验、调参数的过程，而不是把算法随便套上就算完。

3.4 冷启动问题的处理策略

冷启动是每个推荐系统都躲不开的问题，但在毕设里可以采取一个直接有效的解法：对没有行为数据的新用户，推荐热门榜加分类榜。热门榜用点击量降序排列，分类榜按用户选择的分类显示。当新用户产生一个评分、收藏或点击行为后，系统立即触发一次推荐结果更新，这时协同过滤算法开始生效。我在前台推荐模块给了一个“换一批”按钮，实际上就是换个时间戳重新计算，保证新用户不至于每次都看到完全相同的推荐列表。

这里有一个坑：如果推荐定时任务在深夜执行，但用户刚刚注册并产生了行为，t_recommend表里可能还没有他的推荐结果。所以我在控制器层面做了一个兜底：查询推荐结果表时，如果发现该用户没有推荐记录，自动调用一次实时计算，把结果写入后再返回。这个兜底逻辑保证了任何情况下刷新页面都能看到推荐内容，演示时绝不白屏。

4. 核心功能模块实现细节

4.1 图书管理、搜索与分页实现

图书管理是后台模块的基础。图书列表一定要分页，否则几千本图书渲染到一个页面上会导致浏览器卡死。我使用MyBatis-Plus的Page对象配合LambdaQueryWrapper实现分页查询，支持按书名模糊搜索、按分类精确筛选、按出版日期排序。每次前端请求传pageNum和pageSize参数，后端返回包含总记录数的JSON数据。图书封面我采用本地静态资源映射方式，把图片放在upload目录，Spring Boot配置静态资源路径后，通过链接直接访问。没配置资源映射时，封面图片死活加载不出来，这是新手最容易卡住的点。

搜索功能我用了MySQL的LIKE模糊匹配，书名和作者都加上了索引前匹配优化。数据量大了以后，全文搜索其实需要Elasticsearch来做，但毕设场景下MySQL足够。为了提升体验，搜素框做了一个防抖处理，输入停止300毫秒后再发请求，载入状态下显示“加载中”。

4.2 用户行为采集：评分、收藏与借阅记录

推荐系统的数据来源是用户行为。评分功能在图书详情页上实现，用户点1到5星后，通过AJAX接口提交评分数据。服务端校验用户是否已对该书评分，如果已评分则更新原来的分数，防止重复记录。收藏功能则通过t_favorite表存储，用户可以随时取消收藏。收藏还有一个辅助作用，我在推荐算法里把收藏行为等同于4分评分，因为收藏的用户往往对书有较强的正向兴趣。

借阅记录表是个模拟借阅流程，因为毕设一般不会对接真实图书管理系统。我设计了BorrowState字段：0表示借阅中，1表示已归还，2表示已预约。用户点击“借阅”后，系统先判断库存是否大于0，库存充足则生成借阅记录并扣减库存，还书后恢复库存。这个流程不复杂，但业务逻辑必须严谨，否则会出现“库存变成负数”这种答辩事故。

4.3 后台数据统计与推荐效果对比

后台统计模块我用了Apache ECharts做折线图和柱状图。统计维度包括：日注册用户数、每日借阅量、图书分类占比、Top10热门图书。这些数据可以通过SQL的GROUP BY日期函数和分类字段聚合获得。统计页面的作用有两个：一是展示系统运行状态，显得真实；二是为论文中的系统测试提供数据支撑。

推荐效果对比页是我比较满意的一个模块。我设计了一个简易的离线测试接口：在测试用户集合上，分别调用UserCF、ItemCF和混合推荐算法，返回各自推荐列表，然后计算推荐的准确率和召回率。虽然这个方法比较粗糙，但折线图和表格一展示，答辩老师就能直观感受到“混合推荐优于单一算法”，比长篇文字解释更有说服力。

5. Spring Boot项目搭建与常见问题排查

5.1 从零搭建项目的关键步骤

新建项目时，我用的是Spring Initializr生成一个基础Spring Boot项目，再手动引入MyBatis-Plus、MySQL驱动、Thymeleaf等依赖。核心的POM依赖片段如下：

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.4.3.4</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency>

配置文件application.yml里，我把数据源、MyBatis-Plus的日志、端口、静态资源路径都做了明确的声明。这里有一个非常容易踩的坑：MySQL 8.0以上版本的驱动类名是com.mysql.cj.jdbc.Driver，MySQL 5.7则是com.mysql.jdbc.Driver。如果用错驱动，启动时会报“Loading class is forbidden”之类的错误。更稳妥的做法是尽量用MySQL 5.7或8.0，并在配置里加上时区参数serverTimezone=Asia/Shanghai，否则连接数据库时会提示时区错误。

环境变量配置方面，JDK和Maven的环境变量如果没配好，项目连启动按钮都看不到。Windows系统里需要在系统变量里新增JAVA_HOME和MAVEN_HOME，PATH里加入对应bin目录。终端运行java -version验证一下是否成功。很多同学在cmd输入java时提示“不是内部或外部命令”，基本都是环境变量没配对或者没重新打开终端导致的。

5.2 启动过程中遇到的高频报错

我整理了启动时最常遇到的几类问题，全部踩过或者帮同学排查过：

端口占用这个问题有个快速排查技巧：Windows下用netstat -ano | findstr 8080命令，找到占用端口的PID后，在任务管理器结束对应进程。但有时8080被多个服务占用，直接换一个端口更快。我在application.yml里配置了server.port，默认8080，如果遇到冲突会临时改成8081。

5.3 中文乱码、依赖冲突与版本兼容问题

中文乱码分为前端乱码和后端乱码两种。前端乱码通常是因为HTML页面没有设置< meta charset="utf-8">，或者模板引擎前缀配置错误。后端乱码则要考虑数据库连接串、MySQL表字符集、HTTP响应头三个层面。我的处理方案是：在application.yml里设置server.tomcat.uri-encoding=UTF-8，在Spring Boot的WebMvcConfigurer中配置消息转换器字符集为UTF-8，同时把MySQL表结构字符集统一为utf8mb4。三层都做对，乱码基本绝迹。

依赖冲突是另一个常见坑。Spring Boot自带了一个spring-boot-starter-logging，如果重新引入logback或log4j2，日志系统可能互相干扰，启动时一直报SLF4J绑定失败。解决方法是排除其中一个依赖，认准一套日志实现。另外，Lombok版本过低可能导致编译期注解处理器报错，直接用Spring Boot父POM管理的Lombok版本即可，不需要手动指定。

香格里拉式的经验是：遇到莫名其妙的报错，先用clean和package命令重新构建，一般能解决一半的问题；再不行就把target目录删除后重新编译。Spring Boot项目启动失败很多时候是缓存或增量编译的问题，并不是代码本身有毛病。

6. 论文结构、答辩准备与资料整理

6.1 论文从绪论到总结的完整结构

毕设论文我按“背景与意义、关键技术、需求分析、系统设计、系统实现、系统测试、总结展望”这个经典结构来写。这里分享一个实操技巧：先不要从绪论开始写，而是先画系统架构图、功能模块图、ER图和数据库表结构，再写需求分析和系统设计。因为图表是论文的骨架，写完图表后，正文的文字只是“图表解释”的扩展，思路会很顺畅，不会卡文。

绪论部分可以从“信息过载”和“如何高效获取图书资源”切入，引出个性化推荐的价值。关键技术与算法原理章节要写清UserCF与ItemCF的区别、余弦相似度公式、推荐流程时序图。系统实现章节要放关键代码和截图。截图的排版用3×2的网格能有效压缩页数，同时还能保持图表清晰。测试章节要包含功能测试用例表、性能测试结果和推荐算法准确率对比表，有数据支撑的论文往往能拿更高的评阅分。

6.2 ER图、流程图和文档规范

老师评阅论文时首先看格式，ER图是数据库设计部分的重要加分项。不要用截图代替ER图，最好用Visio或draw.io画出来。ER图中实体和关系的命名要与数据表一致，属性不要全部铺开，选关键字段即可。流程图方面，推荐算法的运行流程用PowerDesigner或者ProcessOn画一个简单的活动图，图号、图题、字体大小都要统一。

需要注意的是，论文里所有图都要有编号和图题，表格要有表题和编号。参考文献格式用GB/T 7714，这个在Word的引用管理功能里可以自动生成。我当时把所有参考的文章标题、重点内容都放在一个表格里，写论文时直接关联，省下了大把回翻浏览器书签的时间。

6.3 PPT制作与演示录像的细节经验

答辩PPT不用花哨，控制在12页左右，内容覆盖：题目背景、系统开发技术栈、功能模块介绍、数据库设计、系统截图展示、核心算法代码、测试结果、总结与展望。演示是关键，一个稳定的系统演示胜过大段文字。PPT中的代码块和截图一定要大，老师坐在教室后排也能看得清，字体小于16号会显得不专业。

演示录像则是我建议提前准备的工作。答辩现场网络可能不稳定，数据库可能连接不上，提前录一段5分钟的功能演示视频能作为稳妥预案。录像时用OBS或EV录屏，分辨率1920×1080，确保鼠标移动不要过于频繁。录制内容顺序为：用户注册登录、浏览图书、搜索图书、评分收藏、查看个性化推荐列表、后台管理界面操作。录完后用剪映简单裁剪一下，配上字幕就完成了。这一套资料放在“运行教学”文档里，对学弟学妹复现项目特别有用。

论文查重也是很多同学头疼的事。建议不要抄袭直接搬代码，但可以多看几篇优秀论文，学习它们的问题描述方式和图表表达能力，用自己的话重新整理逻辑。代码部分可以用学术不端检测工具先自查一遍，再针对重复度高的段落重新组织措辞。

7. 运行教学与资料交付的整理心得

做完整个项目之后，我整理了一套完整的学习型资料包，包括源代码、数据库初始化SQL、论文Word版、答辩PPT、演示录像和运行教学文档。很多同学拿到一个开源项目不知道从哪下手，所以我把运行教学文档写成了一份从零开始的“保姆级”指南：如何安装JDK、如何配置Maven环境变量、如何导入项目到IDEA、如何导入数据库SQL、如何修改配置、如何启动，每个步骤都附带截图。这套文档在我复制给组员和后续几届学弟学妹时，有效降低了大家的上手门槛。

写这一节是希望大家在完成毕设时，不只是写完代码就扔在一边，而是把“交付物”这个思维贯穿始终。老师通常关注的不只是代码能不能跑，还有项目是否可复现、逻辑是否完整。一份良好的README、清晰的数据表说明、规范注释的代码、可复现的运行环境，都是评估一个毕设是否优秀的重要维度。

最后还有一个很实用的小经验：整个项目代码在写的时候，控制台打印一下接口耗时，把推荐算法的耗时数据记录下来。论文测试章节里写“平均推荐响应时间小于200毫秒”时，不能只靠感觉，有了真实日志输出，任何答辩提问都稳得住。

本文还有配套的精品资源，点击获取