SpringBoot+Vue 协同过滤体育商品推荐系统，是我在带毕设过程中反复接触的一类项目。它不像纯粹的管理系统那样只管增删改查，也不像复杂的电商平台那样堆砌微服务，而是恰好卡在“有算法亮点、有完整业务闭环、技术栈主流”这个黄金位置。如果你正在为 Java Web 方向的毕设选题发愁，或者已经选了推荐系统相关方向但不知从何下手，这篇内容会帮你把整个项目从思路到落地彻底理清。
我会按照实际做项目的顺序来拆解：先讲清楚系统整体怎么设计、模块怎么划分，再逐一带你过核心功能和数据库脚本，然后深入到协同过滤算法的落地细节，最后把整个项目从本地跑起来并分享排查问题的一线经验。全程用我做项目时的真实思路来讲，不绕弯子。
1. 系统整体设计与技术选型
1.1 为什么选 SpringBoot + Vue 这个组合
现在 Java Web 毕设的技术栈选择，基本绕不开 SpringBoot 和 Vue 这两座大山。SpringBoot 解决了传统 SSM 项目里大量 XML 配置的繁琐问题，内嵌 Tomcat 后一个 java -jar 就能跑起来，这对快速搭建后端服务来说优势太明显了。Vue 则把前端从繁琐的 DOM 操作里解放出来，组件化开发让页面复用和维护都变得轻松。
这个组合对毕设来说还有一个关键优势：生态资料极其丰富。不管是 JWT 登录鉴权、MyBatis-Plus 操作数据库，还是 Element UI 的表格表单组件，遇到问题基本一搜就有答案。相比于用 SSM 写老式 JSP 项目，或者用 React 这类上手曲线更陡的前端框架，SpringBoot + Vue 能让你把有限的精力集中在业务逻辑和算法实现上，而不是浪费在环境配置和框架学习上。这也是我为什么给多数做毕设的同学推荐这个组合的原因。
1.2 推荐系统在体育商品场景下的业务闭环
体育商品推荐系统听起来是个很“大”的方向，但落地到毕设项目里，核心业务闭环其实很清晰：用户注册登录后可以浏览商品、查看商品详情、加入购物车、下单购买，同时系统根据用户的历史行为（浏览、收藏、购买、评分）通过协同过滤算法计算出推荐列表，把用户可能感兴趣的商品推送到首页推荐位和个人推荐页面。
这里有一个容易被忽视的点：推荐系统不能是空中楼阁，它必须建立在完整的电商基础流程之上。如果用户连收藏、加购、订单这些行为数据都没有，协同过滤算法就失去了一部分数据来源，推荐效果会大打折扣。所以我在设计这个项目时，把基础电商功能放在第一优先级，推荐模块作为业务的延伸和亮点，这样整个系统既有完整度又有技术高度。
整个系统可以拆分成前台用户端和后台管理端两大块。前台面向普通用户，包含首页商品展示、推荐商品列表、商品详情、购物车、订单中心、个人信息中心；后台面向管理员，包含商品管理、分类管理、用户管理、订单管理、数据统计。推荐算法的结果是前后台联动的核心指标，前台展示给用户，后台可以配置算法参数和查看推荐效果。
1.3 前后台功能模块全景拆解
前台用户端模块设计上，我倾向于做得既完整又不臃肿。用户模块包含注册、登录（JWT 鉴权）、个人信息修改和头像上传（这里用到了 MinIO 做文件存储），订单模块包含购物车管理、订单创建与状态流转（待支付/已支付/已发货/已完成/已取消），商品模块包含分类浏览、关键词搜索和商品详情展示，推荐模块则包含首页猜你喜欢（基于物品协同过滤）、相似商品推荐（基于内容相似度加权）。
后台管理端就务实很多，主要目标是让管理员能清晰管理整个系统的数据。商品管理支持批量上架下架、库存修改和商品图片上传，分类管理负责维护三级分类结构，用户管理可以查看用户列表并启用/禁用账号，订单管理按状态筛选订单并推进发货流程，数据统计则用图表展示商品销量排行和用户增长趋势。
模块划分完成后，前后端的接口设计也就有了明确边界。我在接口设计上统一采用 RESTful 风格，比如 GET /api/product/page 表示分页查询商品，POST /api/order/create 表示创建订单，这样前端调用时语义清晰，写接口文档时也更轻松。
2. 数据库设计与核心功能落地
2.1 SQL 脚本中那些容易被忽略的设计细节
数据库表设计是毕设评审老师很看重的一部分。这个项目的 SQL 脚本里我设计了 8 张核心表：用户表 sys_user、商品表 product_info、商品分类表 product_category、购物车表 cart_item、订单表 order_info、订单明细表 order_item、用户评分表 user_rating、用户行为日志表 user_behavior_log。
用户评分表 user_rating 是协同过滤算法最重要的数据来源，字段设计上有 user_id、product_id、rating_score、create_time。这里要注意，评分必须是用户对商品的主观打分，和订单表、行为日志表分开存放。行为日志表 user_behavior_log 记录的是浏览、收藏、加购等隐式反馈行为，type 字段用整数区分行为类型，为推荐算法提供额外的数据补充。
商品表 product_info 的字段设计也有一些讲究。除了基础的商品名称、价格、库存、主图之外，我还加了 brand 品牌字段和 tags 标签字段，这两个字段在后面做物品相似度计算的补充时会用到。商品描述用 TEXT 类型存储，有时前端展示需要富文本内容，所以预留了富文本字段。
订单表 order_info 把收货信息直接冗余存储了收货人、电话、地址三个字段，而不是通过用户 ID 去关联查询。这么设计虽然不符合严格的第三范式，但能避免用户修改收货地址后历史订单信息跟着变的问题，这在电商系统里是常见且合理的处理方式。
2.2 用户登录鉴权：JWT 为什么会话管理更省心
登录模块我采用了 JWT（JSON Web Token）方案。传统 Session 方案需要在服务端保存会话状态，对分布式部署不友好，而 JWT 把用户信息加密后放在客户端，服务端只需要验证令牌合法性即可，天然适合前后端分离架构。
JWT 的生成逻辑是在用户登录成功后，把用户 ID 和用户名写入 token 的 payload 部分，用密钥签名后返回给前端。前端把 token 存在 localStorage 里，每次请求时在请求头带上 Authorization: Bearer 。后端通过拦截器统一解析 token，验证通过后把用户信息放入 ThreadLocal 供后续业务使用。
这个小设计的踩坑点在于：token 过期时间不要设置太长也不要太短。我实践下来 24 小时比较合理，既不会让用户一天要登好几次，也不会因为 token 永久有效而出现安全问题。退出登录时直接清除前端 localStorage 中的 token 即可，简单有效。
2.3 商品模块与购物车订单流转的关键逻辑
商品分页查询是最常用的接口。我用 MyBatis-Plus 的 Page 对象配合 LambdaQueryWrapper 来实现条件查询，支持按分类 ID、商品名称关键词、价格区间、上架状态进行筛选，并且按销量和上架时间排序。在日常开发中，这个接口会面临一个性能隐患：如果商品表和分类表的数据量变大，分页会逐渐变慢。我在设计这个项目时预先做了分类索引优化，把 category_id 字段建立了联合索引，并用覆盖索引优化了列表查询的字段选择，确保前端页面在数据增长后依然能保持较快的响应。
购物车模块的逻辑相对直接，核心是幂等处理。用户点击“加入购物车”时，后端先查询购物车表中是否已存在相同用户 ID 和商品 ID 的记录，如果存在则增加数量，不存在则新建记录。这个判断必须做成原子操作，否则高并发下会产生重复记录。订单创建则是一个典型的事务操作，先创建主订单，再批量插入订单明细，同时扣减商品库存，任何一步失败都要回滚，我在代码里用 @Transactional 注解来保证这个过程的原子性。
订单状态流转用状态机来控制，order_status 字段用整数表示：0 待支付、1 已支付、2 已发货、3 已完成、4 已取消。状态变更必须按顺序流转，不允许跳状态，这样可以避免用户多次操作导致订单状态混乱的异常情况。
3. 协同过滤算法：核心亮点的完整手写实现
3.1 基于用户的协同过滤（UserCF）原理解读
这个项目采用的协同过滤算法分为基于用户（UserCF）和基于物品（ItemCF）两种思路。我最终选择以基于物品的协同过滤为主、基于用户的协同过滤为辅的混合策略，这里重点说明两者的适配逻辑。
基于用户的协同过滤核心逻辑是“找相似的人，推荐他们喜欢的东西”。实现上分三步：第一步构建用户-商品评分矩阵，第二步计算用户之间的相似度，第三步根据相似用户的评分预测目标用户对未购买商品的兴趣度。
用户相似度计算采用余弦相似度公式：similarity = (A·B) / (|A| × |B|)，其中 A 和 B 分别代表两个用户的评分向量。我在代码里先把评分数据转换成 Map<Long, Map<Long, Double>> 结构，外层 key 是用户 ID，内层是商品 ID 到评分的映射，然后通过双重循环计算每个用户对之间的相似度。
基于用户的协同过滤适合用户数量相对较少、但每个用户行为数据较丰富的场景。在毕设数据量级下，用户数量可能只有几十个到几百个，此时计算用户相似度的开销完全可以接受，而且推荐结果往往能带来意料之外的发现——用户 A 和用户 B 相似，A 买了羽毛球拍但 B 没买，系统就会把羽毛球拍推荐给 B，这种跨品类的推荐正是协同过滤的魅力所在。
3.2 基于物品的协同过滤（ItemCF）实现细节
基于物品的协同过滤核心思想是“喜欢某物品的人也喜欢与之相似的物品”。它的优势在于推荐结果更具可解释性，而且物品数量相对稳定，相似度矩阵可以离线计算，在线推荐时只需要做一次矩阵查询，性能远优于实时计算用户相似度。
物品相似度计算同样使用余弦相似度，公式为：similarity(i, j) = 同时评分过物品 i 和 j 的用户数 / sqrt(评过 i 的用户数 × 评过 j 的用户数)。代码实现时，我先构建物品-用户倒排表，遍历用户评分记录，统计物品两两之间的共现次数，再根据共现次数计算相似度矩阵。由于这个计算过程相对耗时，我把计算结果持久化到 Redis 中，设置 12 小时过期时间，避免每次请求都重新计算。
做推荐时，遍历用户评分过的商品，找出相似度排名 Top-N 的商品，排除用户已经购买过的商品，再按相似度加权得分聚合，最终输出推荐列表。我实测下来，这个方案的准确率感知比 UserCF 更稳定，也更容易给用户解释为什么要推荐某款商品（因为你买过这款，而这两款很相似）。
3.3 冷启动问题与混合推荐策略的取舍
冷启动是协同过滤算法绕不开的痛点。新用户没有评分记录，新商品没有被评分过，算法直接失效。我在项目里采用了三个补救措施：给新用户推荐热门商品兜底，给新商品打上系统预置的基础标签，用基于内容的相似度计算作为补充，当用户评分数据不足时按商品标签、品牌等属性计算相似度，保证首页推荐位不会空白。
混合推荐策略我采用的是加权融合法：当用户评分记录少于 3 条时，以热门推荐为主，内容推荐为辅；评分记录大于等于 3 条时，以 ItemCF 为主，UserCF 为辅，按 7:3 的比例加权。这个比例是我多次测试后比较理想的经验值，你可以在实际项目中调整并对比推荐效果。
混合策略里还要踩一个新的坑：推荐结果不能长期固定不变。很多同学做的推荐系统，用户今天看到的推荐列表和明天看到的完全一样，这会让用户感知不到“推荐”的存在。我在项目中加入了时间衰减因子，对 7 天前的行为数据乘以 0.7 的衰减系数，让近期行为在推荐计算中占更大权重，推荐列表会随用户行为的积累而动态变化，用户每次刷新页面都能看到差异化的推荐内容。
3.4 推荐接口的性能优化实战
推荐计算虽然做了离线缓存，但在线推送时依然要避免查库过多的问题。我优化后的流程是这样的：接口接收到用户 ID 后，先查 Redis 中的相似度矩阵；再批量查询用户近 30 天的行为数据；通过一次 IN 查询把候选商品的信息全部取出；最后在内存中完成加权排序和 Top-N 截断。整个流程只发生两次数据库查询，响应时间实测在 100ms 以内。
如果在 Redis 中没命中相似度缓存，接口会回退到实时计算方案，但我会在代码里用本地锁保证只有一个线程触发重新计算，其他线程直接等待结果，防止缓存击穿把数据库打爆。这个细节在面试和答辩时是很好的加分项，它体现的不是会调 API，而是真正考虑过高并发场景下的系统稳定性。
4. 前端 Vue 实现与后端交互全记录
4.1 前端页面结构与路由设计要点
前端项目基于 Vue 2 + Element UI 构建，使用 Vue Router 管理页面路由。前台路由做了动态加载，根据用户登录状态判断是否允许访问购物车和订单中心；后台路由则通过路由守卫校验管理员角色，非管理员访问后台页面直接重定向到登录页，避免出现越权访问的尴尬。
页面结构上，首页是核心页面，包含轮播图、分类导航、热门商品列表和“猜你喜欢”推荐列表四个区域。推荐列表单独封装了一个 ProductCard 组件，商品卡片展示商品主图、名称、价格和销量信息，点击跳转到详情页，这个组件在首页、猜你喜欢页和相似推荐模块中被复用了三次，组件化开发的好处在这里体现得最明显。
4.2 Axios 拦截器与跨域问题的处理思路
前后端分离架构下，跨域问题是必踩的坑。我在 Vue 项目中通过 vue.config.js 配置 devServer 的 proxy 属性，把 /api 前缀的请求转发到后端服务地址，开发环境下由 Node 服务完成代理转发，避免浏览器直接跨域。生产环境则通过 Nginx 反向代理把同一域名的 /api 路径转发到后端端口，这就把跨域问题彻底消化在了架构层。
Axios 拦截器统一处理请求和响应逻辑：请求拦截器从 localStorage 中取出 token 并放入请求头；响应拦截器统一处理后端返回的 code、message、data 结构，当 code 为 401 时自动跳转登录页，并把后端返回的 error message 封装成统一的 Message 提示。这么做最大的好处是页面代码里不需要重复处理错误提示和鉴权跳转逻辑，代码量精简不少。
4.3 推荐模块的展示逻辑与交互体验优化
推荐模块在前端展示上我做了几个细节优化。首页“猜你喜欢”区域每次进入页面时调用 /api/recommend/home 接口获取推荐列表，并显示推荐理由，例如“因为您浏览过 威尔胜篮球”，这种可解释性展示让推荐系统显得更智能、更容易获得用户信任。
详情页的“相似商品推荐”区域实现方式比较轻量，复用后端返回的相似商品列表，展示在用了一组横向滑动的卡片布局里。用户在详情页停留时间越长，这个推荐位的曝光价值就越高，这是电商系统里非常经典的一个交互设计模式。
后端接口返回的推荐列表会带上一个来源标识（0 表示热门兜底、1 表示物品协同过滤、2 表示用户协同过滤、3 表示内容推荐），前端可以据此展示不同样式的推荐理由标签。这个做法让推荐系统内部的算法分工清晰可见，也算是一个额外的展示亮点。
5. 从源码到部署：完整跑通项目的实操指南
5.1 本地环境准备与调试注意事项
本地跑通这个项目需要准备 JDK 1.8 或 11、Maven 3.6+、Node.js 14+、MySQL 5.7 或 8.0、Redis 5.0+（用于缓存相似度矩阵）和 MinIO（用于图片文件存储）。环境版本必须对准，尤其是 Redis 和 MySQL 的版本差异会对部署行为产生直接影响，尽量循序渐进地按顺序安装。
后端启动步骤：用 IDEA 打开项目后，等待 Maven 下载依赖；执行项目根目录下的 SQL 脚本文件创建数据库并初始化数据；修改 application.yml 中的数据库连接、Redis 连接和 MinIO 配置信息；最后启动 Application 主类。看到“Started Application in X seconds”的日志就说明后端启动成功了。
前端启动步骤：用 VSCode 或 WebStorm 打开前端目录，执行 npm install 安装依赖（这一步网络不好时需要多试几次，也可以用淘宝镜像源加速），然后执行 npm run serve 启动开发服务器，浏览器访问 localhost:8080 就能看到项目首页了。
5.2 接口文档设计：给前后端协作按上加速器
接口文档是毕设验收时容易被忽略但极其重要的交付物。很多同学项目做完了才补文档，这是本末倒置的做法。接口文档应该与开发同步编写、同步维护，文档中每个接口都要包含请求 URL、请求方式、请求参数（名称、类型、是否必填、说明）、响应结构（code、message、data）和示例。
响应结构的统一设计比接口文档本身更重要。我在项目里统一约定后端返回 JSON 结构为 Result 对象，包含 code、message、data 三个字段：code 为 200 时表示成功，400 表示参数错误，401 表示未登录，500 表示服务异常。前端不用为每个接口单独处理异常情况，拦截器统一处理即可。这个约定在接口文档中明确了之后，前后端协作效率提升明显。
5.3 实战踩坑：我从这个项目中学到的 5 个教训
第一，数据库时间字段的存储方式尽量用 datetime 类型，不要用 varchar 存时间字符串，会导致排序和范围查询时无法使用索引，排查问题时也会非常吃力。第二，用户评分表一定要加唯一约束（user_id + product_id），否则用户重复提交评分会产生脏数据，影响协同过滤的计算结果。第三，删除商品采用逻辑删除（deleted 字段）而不是物理删除，既能保留数据完整性，又方便后续做推荐算法测试或数据回滚。
第四，对象存储 MinIO 的桶名不要包含大写字母和下划线，MinIO 对桶名有严格的命名规范，不合规会导致创建桶时直接报错。第五，前后端联调时遇到跨域不要急着在后端加 @CrossOrigin 注解，更推荐用网关或代理层统一解决，否则后端开启了跨域后，从 Nginx 部署的生产环境访问会出现二次跨域问题。
5.4 答辩时如何把这个项目讲出亮点
毕设答辩环节，评审老师最常问的问题集中在三个方面：为什么要做这个课题、算法是怎么实现的、系统有什么创新点。在介绍项目时，不要平铺直叙罗列功能，而是用一个主线故事串联：用户进入系统后产生数据，数据进入算法引擎计算，计算形成推荐分发到页面，页面反馈转化为新的数据，形成业务闭环。
算法的问题一定要能讲清楚原理。评审老师如果问你 UserCF 和 ItemCF 的区别，你可以从适用范围切入：UserCF 适合用户少、个性化程度高的场景；ItemCF 适合物品少、用户多且兴趣稳定的场景。结合你这个项目，体育商品种类相对固定，所以主推 ItemCF 是更合理的方案，这种结合业务场景的回答会让老师眼前一亮。
写在最后的一些碎碎念
这个项目我前前后后完整做过几遍，也帮不少同学远程调试过。我比较大的感受是，推荐系统的魅力不在于算法本身有多高深——实际代码量可能也就几百行——而在于它让整个项目有了“生命力”。用户数据不断积累，推荐结果不断变化，系统像在慢慢学会理解用户的偏好，这种动态成长的感觉是纯增删改查系统完全无法带来的。
最后分享一个环境踩坑的小技巧：如果你启动项目时发现前端能访问但接口 404，先别急着改代码，用浏览器直接访问后端接口地址，看能不能通；再检查前端代理配置里的 target 是否指向了正确的后端端口。大部分前后端联调问题都出在代理配置或端口不一致上。建议先把后端接口调通，再层层排查前端，这样能省下大把排查时间。整个项目跑通之后，强烈建议你往数据库里多导入一些用户和真实的评分数据，推荐效果会直观很多——数据量越大，协同过滤的威力越明显，答辩时演示效果也更有说服力。
