简介这是一套面向高校计算机相关专业学生的Java毕业设计图书推荐系统完整项目源码适合用于毕业设计、期末大作业与课程设计等场景难度适中评审得分达到98分内容经助教老师审定可直接放心使用。压缩包共包含2000个文件整体约102.56MB涵盖Java源码、JSP页面、CSS与JavaScript前端资源、XML配置、JAR依赖包、SQL脚本及db数据库文件并配有大量jpg、png、gif图片素材构成一套结构完整、可直接编译运行的Web工程。项目围绕图书推荐业务展开包含图书管理、订单处理、推荐逻辑等核心模块源码分层清晰便于理解MVC架构与数据库交互流程。目前已有141人学习下载读者可据此快速搭建运行环境、梳理系统设计思路并在此基础上进行功能扩展与二次开发为毕业设计答辩与项目实战提供可靠参考。1. 从一份 98 分毕设说起这套 Java 图书推荐系统源码到底能跑出什么去年帮学弟看毕设他花两周拼了个图书管理答辩时被问「推荐逻辑在哪」当场卡壳。后来我翻到这套 Java 毕业设计图书推荐系统源码加数据库的压缩包解压后第一眼看到的是BookNewExample$GeneratedCriteria.class、OrderExample$GeneratedCriteria.class这类文件心里就有数了——这是 MyBatis Generator 逆向工程生成的标准产物说明项目不是手写 SQL 硬凑的而是走了正经的持久层框架路线。对正在找 Java 毕业设计源码、又不想拿一个纯 CRUD 糊弄答辩的人来说这套东西的价值在于它把「图书管理」和「推荐」两条线都落到了代码里评审分能到 98 分不是靠界面花哨而是功能闭环完整。它适合三类人赶毕业设计进度的、想拿一个能讲清楚架构的课程设计案例的、以及准备 Java 面试想找个真实项目练手的。下面我按自己拆包的顺序把这份资源从结构到跑通再到改推荐算法完整过一遍。2. 拆开压缩包先看什么目录结构、技术栈与数据库表关系2.1 从 class 文件反推技术栈很多人拿到源码包第一反应是找pom.xml或application.yml但这套资源里混着编译后的 class 文件正好可以拿来验证技术栈。BookNewExample$GeneratedCriteria.class这种命名是 MyBatis Generator 的典型输出$GeneratedCriteria是内部类用来动态拼where条件。看到它基本能确定三件事持久层用 MyBatis、实体和 Example 分离、SQL 是逆向生成的而不是手写。再配合CoreController.class这种命名控制层走的是 Spring MVC 的注解风格。常见做法是 Spring Boot MyBatis MySQL Thymeleaf 或 JSP这套资源大概率也是这个组合因为图书推荐系统不需要太重的前端工程化服务端渲染足够撑起答辩演示。判断技术栈不要只看文件名要交叉验证。我的习惯是先看有没有mapper目录和对应的 XML再看实体类字段和数据库表字段是否一一对应最后看 Controller 里注入的是 Service 还是直接注入 Mapper。如果 Controller 直接调 Mapper说明分层做得浅答辩时容易被追问「Service 层干嘛的」如果中间有 Service那这套代码的讲解空间就大很多。这套资源从 class 命名看Controller、Example、实体是齐的分层大概率是完整的。2.2 数据库表关系与推荐逻辑的落点图书推荐系统的核心表通常绕不开这几张用户表、图书表、订单表、借阅或收藏表、推荐记录表。从OrderExample和BookExample同时出现能推断订单和图书是强关联的推荐逻辑很可能基于「用户买过/借过什么书 → 找相似书 → 推给该用户」这条链路。这是协同过滤里最基础的 item-based 思路也是毕设里最容易讲清楚的一种。表名作用推荐逻辑中的角色user存用户账号、角色推荐的目标对象book图书基础信息被推荐物品order订单/借阅记录行为数据来源category图书分类冷启动时的兜底推荐recommend推荐结果或日志展示层直接读取建表时要注意外键和索引。order表的user_id和book_id一定要建联合索引否则数据量一上来推荐查询会慢得肉眼可见。我一般会在order(user_id, book_id)上建复合索引再在book(category_id)上建单列索引这样基于分类的兜底推荐和基于行为的个性化推荐都能走索引。2.3 导入数据库与改连接配置拿到源码后第一步不是急着跑而是先把数据库还原。资源里一般会带.sql文件用命令行导入最稳# 登录 MySQL 后创建库字符集用 utf8mb4 避免中文乱码 mysql -u root -p -e CREATE DATABASE book_recommend DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 导入表结构和初始数据注意路径换成你解压后的实际位置 mysql -u root -p book_recommend /path/to/book_recommend.sql # 验证表是否建好重点看 order 和 book 两张表 mysql -u root -p book_recommend -e SHOW TABLES; SELECT COUNT(*) FROM book;导入完成后去改配置文件里的数据库连接。如果是 Spring Boot 项目找application.properties或application.yml如果是传统 SSM找jdbc.properties。要改的就四项URL、用户名、密码、驱动类名。URL 里记得加useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai少一个serverTimezone就可能报时区错误这是血泪经验。提示导入 SQL 前先确认 MySQL 版本。5.7 和 8.0 在驱动类名上有区别8.0 用com.mysql.cj.jdbc.Driver5.7 用com.mysql.jdbc.Driver写错直接启动失败。3. 让项目跑起来环境配置、启动流程与推荐模块调用链3.1 JDK、Maven 与 Tomcat 的版本对齐这套源码是 Java 毕业设计项目JDK 版本大概率是 1.8因为 MyBatis Generator 和很多老牌 SSM 模板在 JDK 8 上最稳。装 JDK 后要配JAVA_HOME和Path验证命令是java -version和javac -version两个版本号必须一致不一致说明 Path 里混了别的 JDK。Maven 用来拉依赖配好MAVEN_HOME后跑mvn -v看是否指向你装的版本。如果项目是 Spring Boot 打成的 jar 包直接java -jar就能起如果是传统 war 包需要外置 Tomcat。判断方法很简单看pom.xml里packaging标签是jar还是war。war 包部署到 Tomcat 的webapps目录下启动startup.bat或startup.sh。我一般会先跑mvn clean package -DskipTests跳过测试打包因为毕设项目的测试用例经常因为环境差异挂掉跳过能省时间。# 清理并打包跳过测试适合第一次跑通 mvn clean package -DskipTests # 如果是 Spring Boot 的 jar 包直接启动 java -jar target/book-recommend-0.0.1-SNAPSHOT.jar # 如果是 war 包复制到 Tomcat 后启动 cp target/book-recommend.war $TOMCAT_HOME/webapps/ $TOMCAT_HOME/bin/startup.sh启动后看日志里有没有Started Application in x seconds或Server startup in x ms有就说明容器起来了。接着访问http://localhost:8080能看到登录页或首页就算成功一半。3.2 推荐模块的调用链怎么读推荐功能不是孤立的一个方法而是一条链Controller 接收请求 → Service 组装推荐逻辑 → Mapper 查行为数据 → 返回推荐列表 → 前端渲染。读代码时我习惯从CoreController入手找带recommend字样的方法然后顺着它注入的 Service 往下追。// 典型的推荐入口方法名可能是 recommend 或 getRecommendBooks GetMapping(/recommend) public String recommendBooks(RequestParam Long userId, Model model) { // Service 层负责推荐算法Controller 只做参数接收和视图返回 ListBook books recommendService.getRecommendBooks(userId); model.addAttribute(books, books); return recommend/list; }这段代码的逻辑说明Controller 不写算法只把userId传给 ServiceService 返回ListBook再塞进 Model 给页面。参数说明userId是推荐的目标用户Model是 Spring MVC 的视图数据载体。如果你要改推荐逻辑改的是 Service 里的getRecommendBooks不是 Controller。常见误用是把算法写在 Controller 里导致没法复用也没法单元测试答辩时被问「怎么保证推荐结果可测试」就答不上来。3.3 基于订单行为的推荐实现推荐的核心数据来自订单表。最朴素的实现是查该用户买过的所有书的分类再查这些分类下他没买过的书按销量或上架时间排序取前 N 本。这个逻辑不复杂但能讲清楚「行为数据 → 候选集 → 排序 → 返回」的完整链路。public ListBook getRecommendBooks(Long userId) { // 第一步查用户历史订单拿到他买过的书 ListOrder orders orderMapper.selectByUserId(userId); if (orders.isEmpty()) { // 冷启动没有行为数据时按分类热度推荐 return bookMapper.selectHotBooks(10); } // 第二步提取这些书的分类 ID去重 SetLong categoryIds orders.stream() .map(o - bookMapper.selectById(o.getBookId()).getCategoryId()) .collect(Collectors.toSet()); // 第三步查这些分类下用户没买过的书排除已购 SetLong boughtBookIds orders.stream() .map(Order::getBookId).collect(Collectors.toSet()); return bookMapper.selectByCategoriesExcludeBought(categoryIds, boughtBookIds, 10); }逻辑说明先判断有没有历史订单没有就走冷启动兜底这是推荐系统必须处理的边界。参数说明userId是目标用户10是返回条数可以改成配置项。selectByCategoriesExcludeBought需要在 Mapper XML 里写动态 SQL用foreach拼category_id in (...)和book_id not in (...)。这里有个坑如果boughtBookIds为空not in ()会报语法错误所以要在 Java 层先判空或者 XML 里用if包一层。注意selectByUserId和selectById如果每次循环都查库订单多的时候会有 N1 问题。常见做法是一次性把订单关联的书查出来或者在 Mapper 里写 join别在 for 循环里调 Mapper。4. 改推荐算法与二次开发从分类推荐到协同过滤的落地边界4.1 为什么毕设推荐系统大多停在分类推荐答辩老师不会要求你实现工业级推荐但会看你是否理解推荐的基本范式。分类推荐属于基于内容的推荐优点是解释性强、冷启动友好、代码量可控缺点是推荐结果同质化用户买了两本 Java 书后面推的全是 Java 书。协同过滤分 user-based 和 item-baseditem-based 更适合图书场景因为图书之间的相似度比用户之间的相似度稳定。但协同过滤需要用户-物品评分矩阵毕设数据量小矩阵稀疏算出来的相似度经常是 0反而效果不如分类推荐。所以我的建议是主逻辑用分类推荐保底在论文或答辩里加一节讲协同过滤的改进思路代码里留一个开关这样既有落地又有深度。4.2 用 SQL 实现 item-based 相似度计算如果要在数据库层面算图书相似度可以用「共同购买次数」作为相似度代理指标。这个 SQL 不依赖外部库直接在 MySQL 里跑适合毕设场景。-- 计算图书两两之间的共同购买次数作为相似度 SELECT o1.book_id AS book_a, o2.book_id AS book_b, COUNT(*) AS co_buy_count FROM order o1 JOIN order o2 ON o1.user_id o2.user_id AND o1.book_id o2.book_id GROUP BY o1.book_id, o2.book_id HAVING co_buy_count 2 ORDER BY co_buy_count DESC;逻辑说明自连接订单表找同一用户买过的图书对o1.book_id o2.book_id避免重复对和自配对。参数说明co_buy_count 2是阈值低于 2 的相似度不可信可以按数据量调整。这个查询在数据量大时会很慢所以要在order(user_id, book_id)上建索引。查出来的结果可以落一张book_similarity表推荐时直接查这张表避免每次实时计算。4.3 把推荐结果缓存起来每次请求都跑一遍推荐查询页面会卡。常见做法是用 Redis 或本地缓存把推荐结果存起来设置过期时间。如果项目里没引入 Redis用 Java 的ConcurrentHashMap做个简易缓存也能顶一阵。// 简易本地缓存key 是 userIdvalue 是推荐列表 private final MapLong, ListBook recommendCache new ConcurrentHashMap(); public ListBook getRecommendBooks(Long userId) { // 先查缓存命中直接返回 if (recommendCache.containsKey(userId)) { return recommendCache.get(userId); } ListBook books doRecommend(userId); // 写入缓存实际项目里应该加过期时间 recommendCache.put(userId, books); return books; }逻辑说明缓存命中就跳过数据库查询降低响应时间。参数说明ConcurrentHashMap保证并发安全但没有过期机制用户行为更新后推荐结果不会自动刷新。改进方向是加时间戳或换成 Guava Cache、Caffeine。这个改动在答辩时是个加分项因为能讲「性能优化」和「缓存一致性」。5. 避坑与排查这套源码跑不起来时先查这五处5.1 启动报数据库连接失败现象控制台抛Communications link failure或Access denied for user。原因通常是数据库没启动、URL 里的库名写错、用户名密码不对或者 MySQL 8 没配时区。解决先mysql -u root -p手动登录确认库存在再核对配置文件里的 URL、用户名、密码最后检查 URL 是否带serverTimezoneAsia/Shanghai。如果是 8.0 版本驱动类名必须是com.mysql.cj.jdbc.Driver。5.2 页面 404 或静态资源加载不出来现象后端启动成功但访问首页 404或者页面样式全丢。原因一般是 war 包的 context path 不对或者静态资源被拦截器拦了。解决war 包部署时访问路径要带项目名比如http://localhost:8080/book-recommend/。静态资源 404 就检查 Spring MVC 的mvc:resources配置或 Spring Boot 的WebMvcConfigurer里有没有放行/static/**、/css/**、/js/**。5.3 中文乱码现象图书标题、用户昵称显示成问号或方块。原因有三层数据库字符集不是 utf8mb4、连接 URL 没指定编码、页面 meta 没声明 charset。解决建库时用utf8mb4URL 加characterEncodingutf8JSP 页面顶部加% page contentTypetext/html;charsetUTF-8 %HTML 页面加meta charsetUTF-8。三层都对齐才不会乱。5.4 推荐结果为空现象登录后推荐列表是空白但数据库里明明有订单。原因可能是userId传错、订单表里该用户没数据、或者not in子查询把结果全排除了。解决先在数据库里手动跑一遍推荐 SQL确认能查出数据再在 Service 里打日志看userId和中间结果最后检查boughtBookIds为空时 SQL 是否报错。冷启动分支也要测用一个没有订单的新用户登录看兜底推荐是否生效。5.5 Maven 依赖下载失败现象mvn package卡在下载依赖或者报Could not resolve dependencies。原因通常是中央仓库网络不通或镜像没配。解决在settings.xml里配国内镜像比如阿里云 Maven 镜像。如果某个依赖死活下不下来去本地仓库目录删掉对应文件夹再重新拉。还有一种情况是 JDK 版本和依赖要求的版本不匹配比如某些库要求 JDK 11 而你用的是 8这时要么换 JDK要么降依赖版本。6. 答辩前必做的一次完整验证从登录到推荐结果落库跑通不等于能答辩。我一般会在答辩前做一次端到端验证确保每个环节都有数据可展示。第一步用管理员账号登录确认图书管理、用户管理、订单管理三个模块都能增删改查。第二步注册一个新用户手动下两单模拟真实行为数据。第三步用这个新用户访问推荐页看推荐结果是否排除了已购图书、是否命中了订单里的分类。第四步去数据库查recommend表或日志确认推荐结果有落库记录这样答辩时能拿出「推荐链路可追溯」的证据。-- 验证推荐结果是否落库假设推荐日志表叫 recommend_log SELECT user_id, book_id, recommend_time FROM recommend_log WHERE user_id 你的测试用户ID ORDER BY recommend_time DESC LIMIT 10;如果这张表是空的说明推荐结果只在前端展示没落库答辩时被问「怎么评估推荐效果」就会很被动。补救办法是在 Service 返回前插一条日志或者在 Controller 里加一个切面统一记录。这个改动不大但能让你的项目从「能跑」变成「可观测」。还有一个容易被忽略的点把项目里的硬编码路径、测试账号、本地 IP 全部清理一遍。我见过有人答辩演示时页面报错原因是代码里写死了D:/workspace/...的图片路径换台机器就挂。从那以后我每次交付前都强制走一遍「换机验证」把项目拷到另一台电脑只改数据库配置看能不能独立跑起来。能跑才算真正可交付。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/9/24 20:01:51 · 阅读 1.2k Java毕业设计图书推荐系统源码解析：从MyBatis逆向工程到推荐算法落地
简介这是一套面向高校计算机相关专业学生的Java毕业设计图书推荐系统完整项目源码适合用于毕业设计、期末大作业与课程设计等场景难度适中评审得分达到98分内容经助教老师审定可直接放心使用。压缩包共包含2000个文件整体约102.56MB涵盖Java源码、JSP页面、CSS与JavaScript前端资源、XML配置、JAR依赖包、SQL脚本及db数据库文件并配有大量jpg、png、gif图片素材构成一套结构完整、可直接编译运行的Web工程。项目围绕图书推荐业务展开包含图书管理、订单处理、推荐逻辑等核心模块源码分层清晰便于理解MVC架构与数据库交互流程。目前已有141人学习下载读者可据此快速搭建运行环境、梳理系统设计思路并在此基础上进行功能扩展与二次开发为毕业设计答辩与项目实战提供可靠参考。1. 从一份 98 分毕设说起这套 Java 图书推荐系统源码到底能跑出什么去年帮学弟看毕设他花两周拼了个图书管理答辩时被问「推荐逻辑在哪」当场卡壳。后来我翻到这套 Java 毕业设计图书推荐系统源码加数据库的压缩包解压后第一眼看到的是BookNewExample$GeneratedCriteria.class、OrderExample$GeneratedCriteria.class这类文件心里就有数了——这是 MyBatis Generator 逆向工程生成的标准产物说明项目不是手写 SQL 硬凑的而是走了正经的持久层框架路线。对正在找 Java 毕业设计源码、又不想拿一个纯 CRUD 糊弄答辩的人来说这套东西的价值在于它把「图书管理」和「推荐」两条线都落到了代码里评审分能到 98 分不是靠界面花哨而是功能闭环完整。它适合三类人赶毕业设计进度的、想拿一个能讲清楚架构的课程设计案例的、以及准备 Java 面试想找个真实项目练手的。下面我按自己拆包的顺序把这份资源从结构到跑通再到改推荐算法完整过一遍。2. 拆开压缩包先看什么目录结构、技术栈与数据库表关系2.1 从 class 文件反推技术栈很多人拿到源码包第一反应是找pom.xml或application.yml但这套资源里混着编译后的 class 文件正好可以拿来验证技术栈。BookNewExample$GeneratedCriteria.class这种命名是 MyBatis Generator 的典型输出$GeneratedCriteria是内部类用来动态拼where条件。看到它基本能确定三件事持久层用 MyBatis、实体和 Example 分离、SQL 是逆向生成的而不是手写。再配合CoreController.class这种命名控制层走的是 Spring MVC 的注解风格。常见做法是 Spring Boot MyBatis MySQL Thymeleaf 或 JSP这套资源大概率也是这个组合因为图书推荐系统不需要太重的前端工程化服务端渲染足够撑起答辩演示。判断技术栈不要只看文件名要交叉验证。我的习惯是先看有没有mapper目录和对应的 XML再看实体类字段和数据库表字段是否一一对应最后看 Controller 里注入的是 Service 还是直接注入 Mapper。如果 Controller 直接调 Mapper说明分层做得浅答辩时容易被追问「Service 层干嘛的」如果中间有 Service那这套代码的讲解空间就大很多。这套资源从 class 命名看Controller、Example、实体是齐的分层大概率是完整的。2.2 数据库表关系与推荐逻辑的落点图书推荐系统的核心表通常绕不开这几张用户表、图书表、订单表、借阅或收藏表、推荐记录表。从OrderExample和BookExample同时出现能推断订单和图书是强关联的推荐逻辑很可能基于「用户买过/借过什么书 → 找相似书 → 推给该用户」这条链路。这是协同过滤里最基础的 item-based 思路也是毕设里最容易讲清楚的一种。表名作用推荐逻辑中的角色user存用户账号、角色推荐的目标对象book图书基础信息被推荐物品order订单/借阅记录行为数据来源category图书分类冷启动时的兜底推荐recommend推荐结果或日志展示层直接读取建表时要注意外键和索引。order表的user_id和book_id一定要建联合索引否则数据量一上来推荐查询会慢得肉眼可见。我一般会在order(user_id, book_id)上建复合索引再在book(category_id)上建单列索引这样基于分类的兜底推荐和基于行为的个性化推荐都能走索引。2.3 导入数据库与改连接配置拿到源码后第一步不是急着跑而是先把数据库还原。资源里一般会带.sql文件用命令行导入最稳# 登录 MySQL 后创建库字符集用 utf8mb4 避免中文乱码 mysql -u root -p -e CREATE DATABASE book_recommend DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 导入表结构和初始数据注意路径换成你解压后的实际位置 mysql -u root -p book_recommend /path/to/book_recommend.sql # 验证表是否建好重点看 order 和 book 两张表 mysql -u root -p book_recommend -e SHOW TABLES; SELECT COUNT(*) FROM book;导入完成后去改配置文件里的数据库连接。如果是 Spring Boot 项目找application.properties或application.yml如果是传统 SSM找jdbc.properties。要改的就四项URL、用户名、密码、驱动类名。URL 里记得加useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai少一个serverTimezone就可能报时区错误这是血泪经验。提示导入 SQL 前先确认 MySQL 版本。5.7 和 8.0 在驱动类名上有区别8.0 用com.mysql.cj.jdbc.Driver5.7 用com.mysql.jdbc.Driver写错直接启动失败。3. 让项目跑起来环境配置、启动流程与推荐模块调用链3.1 JDK、Maven 与 Tomcat 的版本对齐这套源码是 Java 毕业设计项目JDK 版本大概率是 1.8因为 MyBatis Generator 和很多老牌 SSM 模板在 JDK 8 上最稳。装 JDK 后要配JAVA_HOME和Path验证命令是java -version和javac -version两个版本号必须一致不一致说明 Path 里混了别的 JDK。Maven 用来拉依赖配好MAVEN_HOME后跑mvn -v看是否指向你装的版本。如果项目是 Spring Boot 打成的 jar 包直接java -jar就能起如果是传统 war 包需要外置 Tomcat。判断方法很简单看pom.xml里packaging标签是jar还是war。war 包部署到 Tomcat 的webapps目录下启动startup.bat或startup.sh。我一般会先跑mvn clean package -DskipTests跳过测试打包因为毕设项目的测试用例经常因为环境差异挂掉跳过能省时间。# 清理并打包跳过测试适合第一次跑通 mvn clean package -DskipTests # 如果是 Spring Boot 的 jar 包直接启动 java -jar target/book-recommend-0.0.1-SNAPSHOT.jar # 如果是 war 包复制到 Tomcat 后启动 cp target/book-recommend.war $TOMCAT_HOME/webapps/ $TOMCAT_HOME/bin/startup.sh启动后看日志里有没有Started Application in x seconds或Server startup in x ms有就说明容器起来了。接着访问http://localhost:8080能看到登录页或首页就算成功一半。3.2 推荐模块的调用链怎么读推荐功能不是孤立的一个方法而是一条链Controller 接收请求 → Service 组装推荐逻辑 → Mapper 查行为数据 → 返回推荐列表 → 前端渲染。读代码时我习惯从CoreController入手找带recommend字样的方法然后顺着它注入的 Service 往下追。// 典型的推荐入口方法名可能是 recommend 或 getRecommendBooks GetMapping(/recommend) public String recommendBooks(RequestParam Long userId, Model model) { // Service 层负责推荐算法Controller 只做参数接收和视图返回 ListBook books recommendService.getRecommendBooks(userId); model.addAttribute(books, books); return recommend/list; }这段代码的逻辑说明Controller 不写算法只把userId传给 ServiceService 返回ListBook再塞进 Model 给页面。参数说明userId是推荐的目标用户Model是 Spring MVC 的视图数据载体。如果你要改推荐逻辑改的是 Service 里的getRecommendBooks不是 Controller。常见误用是把算法写在 Controller 里导致没法复用也没法单元测试答辩时被问「怎么保证推荐结果可测试」就答不上来。3.3 基于订单行为的推荐实现推荐的核心数据来自订单表。最朴素的实现是查该用户买过的所有书的分类再查这些分类下他没买过的书按销量或上架时间排序取前 N 本。这个逻辑不复杂但能讲清楚「行为数据 → 候选集 → 排序 → 返回」的完整链路。public ListBook getRecommendBooks(Long userId) { // 第一步查用户历史订单拿到他买过的书 ListOrder orders orderMapper.selectByUserId(userId); if (orders.isEmpty()) { // 冷启动没有行为数据时按分类热度推荐 return bookMapper.selectHotBooks(10); } // 第二步提取这些书的分类 ID去重 SetLong categoryIds orders.stream() .map(o - bookMapper.selectById(o.getBookId()).getCategoryId()) .collect(Collectors.toSet()); // 第三步查这些分类下用户没买过的书排除已购 SetLong boughtBookIds orders.stream() .map(Order::getBookId).collect(Collectors.toSet()); return bookMapper.selectByCategoriesExcludeBought(categoryIds, boughtBookIds, 10); }逻辑说明先判断有没有历史订单没有就走冷启动兜底这是推荐系统必须处理的边界。参数说明userId是目标用户10是返回条数可以改成配置项。selectByCategoriesExcludeBought需要在 Mapper XML 里写动态 SQL用foreach拼category_id in (...)和book_id not in (...)。这里有个坑如果boughtBookIds为空not in ()会报语法错误所以要在 Java 层先判空或者 XML 里用if包一层。注意selectByUserId和selectById如果每次循环都查库订单多的时候会有 N1 问题。常见做法是一次性把订单关联的书查出来或者在 Mapper 里写 join别在 for 循环里调 Mapper。4. 改推荐算法与二次开发从分类推荐到协同过滤的落地边界4.1 为什么毕设推荐系统大多停在分类推荐答辩老师不会要求你实现工业级推荐但会看你是否理解推荐的基本范式。分类推荐属于基于内容的推荐优点是解释性强、冷启动友好、代码量可控缺点是推荐结果同质化用户买了两本 Java 书后面推的全是 Java 书。协同过滤分 user-based 和 item-baseditem-based 更适合图书场景因为图书之间的相似度比用户之间的相似度稳定。但协同过滤需要用户-物品评分矩阵毕设数据量小矩阵稀疏算出来的相似度经常是 0反而效果不如分类推荐。所以我的建议是主逻辑用分类推荐保底在论文或答辩里加一节讲协同过滤的改进思路代码里留一个开关这样既有落地又有深度。4.2 用 SQL 实现 item-based 相似度计算如果要在数据库层面算图书相似度可以用「共同购买次数」作为相似度代理指标。这个 SQL 不依赖外部库直接在 MySQL 里跑适合毕设场景。-- 计算图书两两之间的共同购买次数作为相似度 SELECT o1.book_id AS book_a, o2.book_id AS book_b, COUNT(*) AS co_buy_count FROM order o1 JOIN order o2 ON o1.user_id o2.user_id AND o1.book_id o2.book_id GROUP BY o1.book_id, o2.book_id HAVING co_buy_count 2 ORDER BY co_buy_count DESC;逻辑说明自连接订单表找同一用户买过的图书对o1.book_id o2.book_id避免重复对和自配对。参数说明co_buy_count 2是阈值低于 2 的相似度不可信可以按数据量调整。这个查询在数据量大时会很慢所以要在order(user_id, book_id)上建索引。查出来的结果可以落一张book_similarity表推荐时直接查这张表避免每次实时计算。4.3 把推荐结果缓存起来每次请求都跑一遍推荐查询页面会卡。常见做法是用 Redis 或本地缓存把推荐结果存起来设置过期时间。如果项目里没引入 Redis用 Java 的ConcurrentHashMap做个简易缓存也能顶一阵。// 简易本地缓存key 是 userIdvalue 是推荐列表 private final MapLong, ListBook recommendCache new ConcurrentHashMap(); public ListBook getRecommendBooks(Long userId) { // 先查缓存命中直接返回 if (recommendCache.containsKey(userId)) { return recommendCache.get(userId); } ListBook books doRecommend(userId); // 写入缓存实际项目里应该加过期时间 recommendCache.put(userId, books); return books; }逻辑说明缓存命中就跳过数据库查询降低响应时间。参数说明ConcurrentHashMap保证并发安全但没有过期机制用户行为更新后推荐结果不会自动刷新。改进方向是加时间戳或换成 Guava Cache、Caffeine。这个改动在答辩时是个加分项因为能讲「性能优化」和「缓存一致性」。5. 避坑与排查这套源码跑不起来时先查这五处5.1 启动报数据库连接失败现象控制台抛Communications link failure或Access denied for user。原因通常是数据库没启动、URL 里的库名写错、用户名密码不对或者 MySQL 8 没配时区。解决先mysql -u root -p手动登录确认库存在再核对配置文件里的 URL、用户名、密码最后检查 URL 是否带serverTimezoneAsia/Shanghai。如果是 8.0 版本驱动类名必须是com.mysql.cj.jdbc.Driver。5.2 页面 404 或静态资源加载不出来现象后端启动成功但访问首页 404或者页面样式全丢。原因一般是 war 包的 context path 不对或者静态资源被拦截器拦了。解决war 包部署时访问路径要带项目名比如http://localhost:8080/book-recommend/。静态资源 404 就检查 Spring MVC 的mvc:resources配置或 Spring Boot 的WebMvcConfigurer里有没有放行/static/**、/css/**、/js/**。5.3 中文乱码现象图书标题、用户昵称显示成问号或方块。原因有三层数据库字符集不是 utf8mb4、连接 URL 没指定编码、页面 meta 没声明 charset。解决建库时用utf8mb4URL 加characterEncodingutf8JSP 页面顶部加% page contentTypetext/html;charsetUTF-8 %HTML 页面加meta charsetUTF-8。三层都对齐才不会乱。5.4 推荐结果为空现象登录后推荐列表是空白但数据库里明明有订单。原因可能是userId传错、订单表里该用户没数据、或者not in子查询把结果全排除了。解决先在数据库里手动跑一遍推荐 SQL确认能查出数据再在 Service 里打日志看userId和中间结果最后检查boughtBookIds为空时 SQL 是否报错。冷启动分支也要测用一个没有订单的新用户登录看兜底推荐是否生效。5.5 Maven 依赖下载失败现象mvn package卡在下载依赖或者报Could not resolve dependencies。原因通常是中央仓库网络不通或镜像没配。解决在settings.xml里配国内镜像比如阿里云 Maven 镜像。如果某个依赖死活下不下来去本地仓库目录删掉对应文件夹再重新拉。还有一种情况是 JDK 版本和依赖要求的版本不匹配比如某些库要求 JDK 11 而你用的是 8这时要么换 JDK要么降依赖版本。6. 答辩前必做的一次完整验证从登录到推荐结果落库跑通不等于能答辩。我一般会在答辩前做一次端到端验证确保每个环节都有数据可展示。第一步用管理员账号登录确认图书管理、用户管理、订单管理三个模块都能增删改查。第二步注册一个新用户手动下两单模拟真实行为数据。第三步用这个新用户访问推荐页看推荐结果是否排除了已购图书、是否命中了订单里的分类。第四步去数据库查recommend表或日志确认推荐结果有落库记录这样答辩时能拿出「推荐链路可追溯」的证据。-- 验证推荐结果是否落库假设推荐日志表叫 recommend_log SELECT user_id, book_id, recommend_time FROM recommend_log WHERE user_id 你的测试用户ID ORDER BY recommend_time DESC LIMIT 10;如果这张表是空的说明推荐结果只在前端展示没落库答辩时被问「怎么评估推荐效果」就会很被动。补救办法是在 Service 返回前插一条日志或者在 Controller 里加一个切面统一记录。这个改动不大但能让你的项目从「能跑」变成「可观测」。还有一个容易被忽略的点把项目里的硬编码路径、测试账号、本地 IP 全部清理一遍。我见过有人答辩演示时页面报错原因是代码里写死了D:/workspace/...的图片路径换台机器就挂。从那以后我每次交付前都强制走一遍「换机验证」把项目拷到另一台电脑只改数据库配置看能不能独立跑起来。能跑才算真正可交付。希望帮到你。本文还有配套的精品资源点击获取