SpringBoot+Vue图书推荐系统：从行为采集到协同过滤

做图书推荐系统这个需求我在线上项目里前前后后接触过不下十次但说实话绝大多数所谓的“个性化推荐”只是按点击量或者借阅量排个序跟真正的个性化差着十万八千里。这次整理的这套基于SpringBootVue的个性化图书推荐系统是一版从用户行为采集、标签召回、协同过滤排序到前端展示都比较完整的源码技术栈就是SpringBoot Vue MyBatis MySQL都是老熟人但细节做得比较扎实。适合正在做毕业设计的学生、想从前端转全栈的开发以及需要快速搭一套可演示的完整推荐系统Demo的工程师参考。系统的核心价值不在于“能登录能增删改查”而在于推荐链路的完整度用户注册登录后可以给图书打分、收藏、加标签后端基于这些行为数据做内容召回和协同过滤排序最终在“猜你喜欢”和“书友推荐”两个页面输出个性化结果。管理员端则负责图书录入、分类维护、用户管理和推荐参数配置。整条链路从前端交互到后端计算没有断档这在国内不少课程项目和培训机构的成品源码里都算稀罕的。1. 项目整体设计与技术选型思路1.1 技术栈为什么这么搭先说结论SpringBoot Vue这套前后端分离的组合在2025年依然是中小型管理系统和推荐类Demo项目的主流选择没有之一。原因很简单——生态成熟资料多招人好招出问题百度一下基本都有答案。后端用SpringBoot核心优势是省配置。以前SSH时代写一个项目要配一堆XMLSpringBoot用自动配置把绝大部分脏活累活都干了一个application.yml就能把数据源、MyBatis、事务、端口全部搞定。对于图书推荐系统这种业务不算复杂但需要快速迭代的项目SpringBoot的开箱即用体验非常舒服。版本方面如果是全新项目且JDK是17直接用SpringBoot 3.2.x如果环境还在JDK 8老老实实用2.7.x别追求版本号新兼容性才是第一位的。实测SpringBoot 3.x对MyBatis的依赖方式有变化新版需要引入mybatis-spring-boot-starter并手动适配对新手不太友好。持久层选MyBatis而非JPA我的理由很直接推荐系统里有大量复杂SQL比如下面要讲的协同过滤相似度计算用JPA的Entity映射去表达这种多表关联聚合查询写起来能把自己绕晕。MyBatis的XML里写SQL是所见即所得调优路径非常清晰尤其适合数据量上来之后做SQL层面的精确控制。前端用Vue准确的说是Vue3 Vite Element Plus。Vite的冷启动速度和热更新体验比Webpack时代的旧Vue CLI快太多了现在装Vue环境基本就是npm create vitelatest一条命令的事。Element Plus的组件库覆盖了后台管理系统里几乎所有的表单、表格、弹窗场景图书管理页面和推荐结果页面用几个核心组件就能拼出来开发效率很高。1.2 推荐链路从用户行为到推荐结果这个系统里推荐不是写死一个算法而是一条完整的数据链路这也是我最想强调的设计思路。整条链路可以拆成四个环节数据采集用户在页面上的打分1到5分、收藏、浏览行为全部落库到评分表和收藏表这部分相当于推荐系统的原料仓。召回从候选图书池里先粗筛一批“可能感兴趣”的书。系统里实现了两种召回策略一是基于图书标签的匹配召回二是基于相似用户的协同过滤召回两者取并集进入后续精排。排序召回回来的候选集用预测评分做排序选出Top N推荐给用户。兜底新用户没有行为数据时走冷启动策略按图书热度、分类热门榜推荐保证首次打开页面也有内容可看。这个设计最大的好处是每一环都可以独立替换优化。召回不够就加策略排序不准就换模型冷启动效果差就优化热度公式整个推荐引擎是活的而不是死代码。2. MySQL数据库设计与核心表结构2.1 六张核心业务表的设计数据库设计决定推荐算法的实现复杂度这一点怎么强调都不过分。这套系统一共设计了六张核心表用户表、图书表、分类表、评分表、收藏表、标签关联表其中评分表和标签关联表是推荐算法的命脉。用户表没啥特殊常规的id、username、password、nickname、role字段角色字段区分管理员和普通读者。密码存储一定要用BCrypt加密明文密码在演示项目里无所谓的想法赶紧丢掉就算只是毕业设计安全习惯也该从第一天养成。图书表需要注意两个细节一是category_id外键关联分类表但查询时我强烈建议冗余一个category_name字段避免每次列表查询都要JOIN一次分类表二是borrow_count借阅次数字段这个看似不起眼的字段在冷启动热度推荐里就是核心排序信号原理和电商的销量排序一个逻辑。别小看这个字段很多初写推荐系统的人就是漏了这种“隐性信号”导致新用户推荐页面效果很差。评分表是整个推荐系统的核心资产唯一键必须是(user_id, book_id)保证一个用户对同一本书只有一条评分记录这既是业务约束也是算法前提。协同过滤计算相似度时如果存在重复评分相似度结果会被污染这是必须从表结构层面杜绝的。标签关联表我设计的模式是user_tag和book_tag两张用户给书打的标签和图书自身的分类标签分开存。为什么要分开因为用户打标签和系统分类标签是两种不同的语义空间图书分类标签更官方用户标签更个性化混在一张表里对后续推荐权重的设置会产生干扰。2.2 建表SQL与索引优化实录直接上一段核心建表SQL你可以直接拿去建库。CREATE TABLE t_user ( id INT NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL, password VARCHAR(128) NOT NULL, nickname VARCHAR(50), role TINYINT DEFAULT 0 COMMENT 0-读者 1-管理员, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE t_book ( id INT NOT NULL AUTO_INCREMENT, title VARCHAR(120) NOT NULL, author VARCHAR(80), isbn VARCHAR(20), category_id INT, category_name VARCHAR(50), publisher VARCHAR(120), intro TEXT, cover_url VARCHAR(255), publish_time DATE, stock INT DEFAULT 0, borrow_count INT DEFAULT 0 COMMENT 借阅次数冷启动热度信号, PRIMARY KEY (id), KEY idx_category (category_id), KEY idx_author (author) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT图书表; CREATE TABLE t_rating ( id INT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, book_id INT NOT NULL, score TINYINT NOT NULL COMMENT 1-5分, comment VARCHAR(500), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_book (user_id, book_id), KEY idx_book (book_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT评分表;几个索引设计的实操心得第一唯一索引uk_user_book在评分表里是必须的它既是约束也是查询加速器。协同过滤的第一步就是“查某个用户的所有评分”(user_id, book_id)的头字段正好命中user_id的等值查询哪怕后面单独只按book_id查评分也有idx_book兜底这两个索引合起来覆盖了绝大多数推荐算法的查询模式。第二字符集必须用utf8mb4不要用utf8。图书书名和介绍里有大量生僻字和特殊字符utf8只能存3字节遇到冷门汉字直接报错我见过不止一个人在这里踩坑。另外建表时用DATETIME DEFAULT CURRENT_TIMESTAMP省掉每次插入时手动维护时间的麻烦。第三borrow_count这种计数类字段在并发写入量大的时候会有热点问题但图书管理系统的规模远没到需要分表分库的程度加个ON DUPLICATE KEY UPDATE borrow_count borrow_count 1就够了不用为了炫技引入Redis计数徒增复杂度。3. SpringBoot MyBatis 后端落地3.1 工程结构与配置文件后端工程我按标准分层来组织controller、service、mapper、entity、common五个包其中common放统一返回值、异常处理和工具类。这个分层结构不新奇但它是目前维护成本最低的结构别在这个项目里去搞DDD那一套领域驱动的复杂度对小项目是负担。application.yml里有几个配置直接影响开发体验我直接放出关键部分spring: datasource: url: jdbc:mysql://localhost:3306/book_recommend?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.book.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl pagehelper: helper-dialect: mysql reasonable: true这个配置里有两个细节我重点说明。第一个是serverTimezoneAsia/Shanghai这个参数不加MySQL 8的驱动会报时区异常报错信息是The server time zone value йʱ is unrecognized乱码和报错同时出现非常劝退。2019年之后MySQL驱动升级到8.0后这个坑特别常见网上搜MySQL安装教程的人十个有八个在这个问题上卡住。第二个是map-underscore-to-camel-case: true自动开启驼峰映射这样数据库字段category_name能自动映射到Java实体里的categoryName不用在XML里写几百行resultMap。这个配置开了之后写MyBatis的体验会好很多核心就在于能少写80%的映射代码。如果要在项目里引入MyBatis分页插件PageHelper直接加依赖并在配置里指定helper-dialect: mysql即可。分页插件用起来虽然方便但有两点要记住第一PageHelper.startPage()必须紧跟第一条查询中间不能插入其他逻辑第二为了获取总数它会在每次分页时多执行一条COUNT SQL当图书表数据量超过百万级时这条COUNT反而会成为性能瓶颈届时要自己优化计数SQL。3.2 核心接口与XML实现后端接口设计上遵从一个原则前端拿到的数据就是页面需要的数据不要让前端自己去拼装多张表的信息。因此图书列表接口返回的VO里会包含分类名、平均评分、评分人数这些字段而不是只返回book实体然后让前端再发几个请求去组合。图书分页查询的XML写法是MyBatis动态SQL的代表作我放一个骨架select idselectBookPage resultTypecom.book.entity.Book SELECT b.*, IFNULL(AVG(r.score), 0) AS avg_score, COUNT(r.id) AS rating_count FROM t_book b LEFT JOIN t_rating r ON r.book_id b.id where if testkeyword ! null and keyword ! b.title LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null AND b.category_id #{categoryId} /if /where GROUP BY b.id ORDER BY b.borrow_count DESC /select这个写法有个地方值得注意WHERE条件里第一种情况只有关键字条件时AND前缀是多余的第二种情况只有分类条件时AND又是必须的。这就是为什么用where标签而不是写死WHERE 11——where会自动去掉第一个条件前多余的AND或OR代码干净也不会出错。MyBatis参数绑定只用#{}绝不能用${}拼SQL。#{}底层是预编译占位符天然防SQL注入${}是字符串替换用户输入个 or 11就可能把整个表拖出来。新手在这个坑上翻车的概率极高我用一句话总结业务代码里出现${}大概率是问题代码。3.3 事务与异常处理推荐系统中“用户打分”这个动作涉及三个写操作更新评分表、更新图书表的平均分、更新用户的活跃度任何一个失败都可能导致数据不一致必须用事务包起来。在SpringBoot里加Transactional注解即可但我发现很多人只加注解不看传播行为默认的REQUIRED在这种情况下够用但要注意事务只对RuntimeException回滚如果方法里catch了异常然后吞掉事务是不会感知的。统一异常处理建议用RestControllerAdvice全局兜底接口返回统一结构code / message / data前端axios拦截器里判断code不等于200时统一弹出message。这套模式几乎成了行业标准好处是前后端之间的错误处理逻辑从各写各的变成一套约定。4. 个性化推荐算法的实现4.1 基于标签的内容召回内容召回的逻辑很直观用户对某本技术类图书打了高分系统就认为他可能对同标签或相近标签的图书感兴趣按标签匹配度从高到低拉一批候选书出来。这个策略用SQL实现其实不复杂关键是把“标签匹配度”定义清楚。我用的匹配度计算思路是重叠度加权候选书的标签集合与用户的历史偏好标签集合取交集交集越大匹配度越高在此基础上再叠加一个标签稀有度的惩罚项——如果一个图书标签只有少数人关注那么它比热门标签更能反映用户的具体兴趣。这是参考了TF-IDF思想避免“技术”这种大而泛的标签盖过“微服务”“性能优化”这种明确意图的标签。内容召回的代码结构大致是这样public ListBookVO recallByTag(Long userId, int limit) { // 1. 收集用户的历史偏好标签及权重 ListTagWeight userTags tagMapper.selectUserTagWeights(userId); if (userTags.isEmpty()) { return new ArrayList(); } // 2. 按标签权重召回候选图书 ListBookVO candidates recommendMapper.selectBooksByTags(userTags); // 3. 按匹配度打分并取TopN return candidates.stream() .sorted(Comparator.comparing(BookVO::getMatchScore).reversed()) .limit(limit) .collect(Collectors.toList()); }4.2 基于用户的协同过滤排序协同过滤是这个系统的重头戏思路一句话就能讲清楚找到和你口味最像的一群人把他们对某本书的平均评分作为你对这本书的预测评分。这里最核心的步骤是“用户相似度计算”我用的是皮尔逊相关系数公式上比余弦相似度多考虑了用户评分尺度差异的问题。举例来说小A习惯给书打高分小B习惯打低分两个人对同一本书分别给5分和3分绝对值差异看似很大但相对各自的评分均值两个用户的口味可能是一致的高度满意。余弦相似度对这种尺度偏移不敏感皮尔逊相关系数通过先减均值再算余弦完美解决了这个问题。我实现的SQL大体是这样SELECT ur.user_id AS similar_user, SUM((ur.score - ua.avg_score) * (mr.score - ma.avg_score)) / (SQRT(SUM(POW(ur.score - ua.avg_score, 2))) * SQRT(SUM(POW(mr.score - ma.avg_score, 2)))) AS similarity FROM t_rating ur JOIN t_rating mr ON ur.book_id mr.book_id AND mr.user_id #{userId} JOIN (SELECT user_id, AVG(score) AS avg_score FROM t_rating GROUP BY user_id) ua ON ua.user_id ur.user_id JOIN (SELECT user_id, AVG(score) AS avg_score FROM t_rating GROUP BY user_id) ma ON ma.user_id mr.user_id WHERE ur.user_id ! #{userId} GROUP BY ur.user_id HAVING COUNT(*) 3 ORDER BY similarity DESC LIMIT 20;这条SQL有几个关键点值得说。第一HAVING COUNT(*) 3是为了过滤掉只共同评过一两本书的“伪相似用户”共同评分数太少时算出的相似度没有任何统计学意义。第二每次计算都要实时对全表跑GROUP BY平均值数据量在几千条评分时没感觉但如果评分数据涨到十万级以上这条SQL会非常慢届时就该把用户平均分单独存一张统计表或者引入离线计算定时刷了。第三相似度为负数说明两人口味相反这类用户的数据在计算预测评分时应该剔除不然会严重拉低推荐结果质量。拿到相似用户之后预测评分就是加权平均。我还会在最终排序时叠加一个小小的“流行度惩罚”若某本书的热度异常高说明它被推荐的原因可能更多来自大众偏好而非用户个性适当降低它在个性化列表里的分值推荐结果就没那么“大众脸”。4.3 冷启动与混合推荐新用户没有任何评分行为协同过滤完全失效这是推荐系统所有方案里最绕不开的问题。这套系统用混合策略处理冷启动具体的做法在推荐接口里按优先级走三层逻辑第一层用户有个位数评分记录内容召回做主、协同过滤做辅助排序。第二层用户完全没行为热门榜推荐排序信号是borrow_count和近30天新增评分数的加权组合保证新用户看到的都是经过市场验证的书。第三层连用户登录都没登录做Cookie级匿名推荐按当前访客浏览的图书分类给他临时建一份浏览偏好这个功能在很多课程项目里是空缺的但对展示效果提升非常明显。混合推荐的权重设置我建议做成管理员后台可配置项而不是写死在代码里。比如内容召回占比30%、协同过滤占比70%这个比例在不同数据规模下最优解完全不同做成配置项之后调参不用重新编译部署这个细节在演示项目里是加分项。5. Vue 3 前端搭建与联调5.1 环境准备与项目初始化前端这一步我直接说2025年的推荐做法。环境准备其实就三件事装Node.js 18以上的LTS版装npm或者pnpm然后执行下面的初始化命令npm create vitelatest book-web -- --template vue cd book-web npm install npm install element-plus axios pinia vue-router这里有个常见问题npm install慢或者报错多半是npm源的问题。国内环境建议先设置淘宝镜像npm config set registry https://registry.npmmirror.com基本能解决99%的依赖安装问题。Vite创建项目后默认端口是5173启动命令是npm run dev这些细节网上一搜就有但如果能提前把npm源配置好整个环境搭建可以控制在十分钟以内。Element Plus引入方式我推荐全量引入虽然打包体积大一点但对图书管理系统这种中后台项目来说全量引入的开发效率远高于按需引入。按需引入需要额外配置unplugin-auto-import和unplugin-vue-components两个插件配置复杂度增加不少而实际打包多出来的体积几十KB根本不用在意。5.2 核心页面与组件拆解前端页面按角色分两条线读者端和管理员端。读者端有首页、图书列表、图书详情、评分弹窗、猜你喜欢、书友推荐管理员端有图书管理、分类管理、用户管理、推荐参数配置。页面组件化是我比较在意的点。比如图书卡片BookCard这个组件在“图书列表”“猜你喜欢”“书友推荐”三个页面里都会用到如果每个页面各写一遍图书封面标题评分信息收藏按钮的模板后期改样式要改三处这种重复是前端代码里最伤维护性的地方。正确做法是抽成组件通过props接收book对象这样三处引用同一套模板样式统一、改动只动一处。路由和权限控制用vue-router的导航守卫实现。基础写法import { createRouter, createWebHistory } from vue-router const router createRouter({ history: createWebHistory(), routes: [ { path: /, component: () import(../views/HomeView.vue) }, { path: /books, component: () import(../views/BookListView.vue) }, { path: /recommend, component: () import(../views/RecommendView.vue), meta: { requiresAuth: true } }, { path: /login, component: () import(../views/LoginView.vue) } ] }) router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) } else { next() } })刷新页面后token丢失是个容易忽略的问题推荐用Pinia把用户信息和登录态存store里store初始化时从localStorage恢复就能避免刷新后被强制踢回登录页的尴尬。5.3 前后端联调与跨域处理本地联调时前端开发服务器在5173端口后端在8080端口直接请求必然跨域。我在Vite的vite.config.js里配置代理让/api前缀的请求全部转发到后端server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端代码里请求地址写/api/books/page就行浏览器看到的是同源请求自然没有跨域问题。同时后端也要放行Preflight预检请求SpringBoot里用addCorsMappings或者加CrossOrigin注解都行但我更推荐统一配置WebMvcConfigurer避免每个controller都挂注解。axios封装方面拦截器里统一处理两件事请求头加JWT Token响应里统一处理业务错误码和HTTP 401跳登录页。这个封装做完业务代码里调接口只要写一行request.get(/api/recommend/list)不用每个请求都重复写token和错误处理几十个页面的开发体验提升是肉眼可见的。6. 常见问题与排查技巧实录6.1 高频报错速查表这几天陆续有同学照着源码跑遇到的问题翻来覆去就那几样我整理成一张表省得大家在网上东搜西找报错现象根因解决方案The server time zone value is unrecognizedMySQL连接串缺时区参数URL加serverTimezoneAsia/ShanghaiUnknown column xxx in field list下划线字段没映射到驼峰属性开启map-underscore-to-camel-case: trueInvalid bound statement (not found)Mapper接口和XML没绑定上检查mapper-locations路径是否匹配classpath:mapper/*.xml前端请求跨域报错后端没放开CORS或Vite没配代理优先用Vite代理解决PageHelper分页第一页正常后面错乱startPage()和查询之间插了其他SQL把startPage()紧贴目标查询之前端口8080被占用本机有其他进程占用netstat -ano查PID后结束进程或改server.portError 2002 (HY000): Cant connectMySQL服务没启动Mac/Linux检查socketWindows检查服务列表其中Invalid bound statement (not found)是最容易被忽略的。很多人明明XML文件存在路径也对但就是报这个错最后发现是XML文件没被Maven编译进target目录。解决方法是检查pom.xml里resources配置或者直接把mapper目录放进资源目录这个细节网上很多教程都没提。6.2 实际调优心得最后分享几个我在实际跑这个项目时总结的调优经验都是代码以外但特别影响体验的点。第一图书表导入测试数据时一定要保证评分数据有足够的密度。协同过滤的效果高度依赖“用户-图书”评分矩阵的稀疏度如果500个用户只有几十条评分算出来的相似用户全是噪声推荐结果基本等于随机。我建议每个用户至少打5本以上的评分再配合脚本生成一部分模拟行为数据演示效果立刻上一个档次。第二SQL日志要打开但生产环境要关。开发阶段开着log-impl: StdOutImpl每执行一条SQL都能在控制台看到参数和执行时间排查问题极其方便上线前一定要关掉否则全量SQL打到日志文件里能把磁盘写满而且StdOutImpl会打印全部参数有敏感信息泄露风险。第三管理员缓存策略这块可以适度优化。图中的分类列表和热门榜这类变化不频繁的数据可以在Service层加一个简单的Map缓存或者用Spring Cache注解配合CacheEvict在数据变更时清空。这个改动不大但对接口响应速度的提升非常直观。不过要注意缓存切面只对通过Spring代理调用的外部方法生效同类内部调用是不走缓存的这个坑我在别的项目里踩过一次。第四如果用SpringBoot 3.x版本跑这个项目依赖里要特别检查MyBatis Starter的版本是否兼容SpringBoot 3的Jakarta命名空间。很多人把SpringBoot 2.7项目的依赖直接拷过来启动大量报错就是因为javax.*改成jakarta.*没跟上。实在搞不定就用低版本的JDK 8加SpringBoot 2.7稳定压倒一切。我个人在实际操作中的体会是这类图书推荐系统的难点从来不在增删改查而在推荐算法的落地细节和整体链路的完整性。你从这套源码里能学到的不应该只是SpringBoot怎么配、Vue页面怎么写更重要的是体会“数据如何驱动功能”用户行为怎么转化为推荐信号不同数据状态下算法如何降级兜底这些思路换到电商推荐、视频推荐场景里同样成立。按着这个链路把代码捋一遍再把评分数据进行扩充和清洗把它改成一套适合自己场景的推荐服务并不是难事。