尧图网页设计 
1. 项目整体设计与技术选型思路1.1 为什么是SpringBootVue这套组合如果你准备做电商类项目市面上可选的技术方案其实很多传统的有SSH、SSM新一点的有微服务全家桶。但这套系统最终选择SpringBootVue的前后端分离架构不是因为它热门而是因为它确实是目前最适合中小型电商系统、也最适合毕业设计和简历项目的搭配。先看后端。SpringBoot的核心价值在于“约定大于配置”它把Spring生态里那些繁琐的XML配置全部干掉通过自动装配机制就能把Web层、持久层、安全框架全部串联起来。比如你想引入MyBatis-Plus操作数据库只需要在pom.xml中加一个依赖然后在application.yml里写好数据源就能直接使用了。这种开发体验在一个需要快速出成果的项目里非常舒服。对比2018年之前用SSM搭框架的日子光是spring-mvc.xml、mybatis-config.xml这些配置文件就够折腾一整天而现在SpringBoot把这一切都封装掉了你可以把精力集中在业务逻辑上。实际上这是SpringBoot自动装配的功劳你可以去翻一下spring-boot-autoconfigure这个jar包里的源码会发现每个配置类上都有EnableAutoConfiguration相关的注解和大量的ConditionalOnProperty、ConditionalOnClass条件判断理解这套机制对你面试也有帮助。再看前端。Vue的渐进式框架特点决定了它特别适合做电商这种交互密集型的应用。组件化开发让商品卡片、购物车列表、订单状态这些UI单元可以被复用Vue Router让页面路由切换丝滑流畅Vuex或Pinia做状态管理可以把用户登录信息、购物车数据这类全局共享状态统一管理起来。相比JSP时代那种后端渲染页面、前端只负责写jQuery的做法这种前后端彻底分离的模式让两个人的分工可以完全并行后端专心写接口前端专心写页面交互最后通过HTTP协议联调对接。这套组合还有一个实际的好处就是部署架构干净清晰。后端的SpringBoot打成jar包前端的Vue执行npm run build生成一套纯静态文件交给Nginx托管。两者之间通过接口域名或者反向代理关联起来无论是部署在一台服务器还是各自独立部署都非常灵活。你甚至可以只把dist目录里的文件扔到GitHub Pages上都能跑起来前端页面这对演示项目来说非常友好。1.2 协同过滤算法在电商场景中的定位这个项目标题里包含“协同过滤算法”这决定了它不是一个普普通通的管理系统而是一个带智能推荐能力的电商平台。用户打开首页不再是看到一成不变的商品列表而是能看到系统根据他自己的历史行为生成的个性化推荐——“猜你喜欢”。那么为什么要用协同过滤电商场景里解决推荐问题的主流手段分为三类基于内容的推荐、协同过滤推荐、以及混合推荐。基于内容的推荐简单理解就是“给用户推荐和他买过的商品相似的商品”比如他买了一个iPhone你就推荐同品牌的手机壳这种方案没有用户行为数据的积累也能跑。协同过滤则不同它的核心逻辑是“找和你相似的人看看他们喜欢什么”也就是利用群体的智慧来做个性化推荐这需要一定量的用户行为数据支撑。在一个毕业设计或者中小型项目里协同过滤是最合适的选择原因有三个。第一它的算法原理清晰易懂基于用户的协同过滤UserCF也好基于物品的协同过滤ItemCF也好核心公式就是余弦相似度或者皮尔逊相关系数完全可以在Java中用几十行代码手写实现。第二它不需要大量的商品特征工程不需要去维护每个商品的属性标签只需要收集“用户-物品-评分”三元组数据。第三它的可解释性强你可以告诉用户“因为与你兴趣相似的用户也喜欢这款商品所以为你推荐”这种推荐理由在电商实战中很有说服力。然而协同比过滤也有它的脾气冷启动问题首当其冲。新用户没有行为数据系统就不知道他喜欢什么新商品没有人评分系统就更难把它推出去。这我在后面算法实现的部分会给出具体的兜底方案。1.3 系统功能模块划分一个完整的网上购物商城系统按照角色可以拆成四个端游客端、用户端、商家端、管理员端。这种多角色的划分是电商系统的标准做法也直接决定了数据库表结构和权限控制的设计。游客端其实是用户端的子集游客可以浏览商品、搜索商品、查看商品详情但一旦需要加入购物车、提交订单、查看个人中心就必须登录。这个登录门槛设计成用户点击结算时再弹出登录框而不是一开始就强制注册这样能最大限度减少用户流失。用户端是核心包含注册登录、商品浏览与搜索、商品详情、购物车管理、订单管理、收货地址管理、个人中心、商品收藏与评价。这里需要注意购物车和订单是电商系统里逻辑最复杂的两个模块购物车涉及库存校验、价格快照、勾选状态的实时计算订单则涉及多个状态节点。商家端负责商品的上架、下架、库存管理、订单发货、查看销售统计。在毕设场景里不需要做到淘宝的千牛那么复杂但最基本的商品CRUD和订单状态流转一定要完整。管理员端则负责用户管理、商品分类管理、全局订单监管、以及系统数据统计。核心提示在功能设计上推荐系统不是孤立的一块它需要用户行为数据作为输入源。因此数据库设计里要有一张用户行为记录表记录用户的浏览、收藏、加购、购买、评价行为再配合商品评分数据共同作为协同过滤算法的输入。2. 数据库设计与协同过滤数据体系构建2.1 核心表结构设计数据库是整个电商系统的地基表结构设计得好不好直接决定后期开发效率和推荐算法的数据质量。我以下提供一套经过验证的核心表设计基本能覆盖一个小型电商的全部业务。用户表user需要包含id、username、passwordBCrypt加密后的密文、nickname、avatar、phone、email、status、create_time。密码加密这一点非常重要千万不要明文存储SpringSecurity自带的BCryptPasswordEncoder就可以用。商品表product需要包含id、category_id关联分类表、name、subtitle副标题、main_image、detail富文本详情、price、stock库存、sales销量、status上下架状态、create_time。注意price字段建议使用decimal(10,2)不要用float或者double否则在金额计算时会出现精度丢失的问题。订单表和订单明细表是电商系统的重头戏。订单表orders存储id、order_no订单编号、user_id、total_amount、pay_amount、freight_amount、status待付款、待发货、待收货、已完成、已取消、address_info收货信息快照、create_time、pay_time、deliver_time、finish_time。订单明细表order_item存储id、order_id、product_id、product_name、product_image、current_price下单时的价格快照、quantity、total_price。这里做价格快照是为了防止用户下单后商品改价导致订单金额对不上。购物车表cart相对简单包含id、user_id、product_id、quantity、checked是否勾选。评价表comment包含id、user_id、product_id、order_id、content、rating1-5分、create_time。这里还有一个很容易被忽略但推荐算法急需要的表——用户行为表user_behavior。字段包括id、user_id、product_id、behavior_type浏览1/收藏2/加购3/购买4/评价5、create_time。这张表是协同过滤算法最重要的数据来源在你没有显式评分数据时可以通过行为类型映射成评分权重来构建用户-物品评分矩阵。2.2 从零开始的用户画像与评分矩阵构建协同过滤算法的输入是一个“用户-物品评分矩阵”。但这个矩阵怎么来是项目落地的第一个坎。真实电商平台比如淘宝、京东让你给商品打1到5星的场景其实并不多大量用户的偏好藏在他们的行为里。你在淘宝上搜了一个商品、点进去看了详情、把它加入购物车、最终下单这一系列动作已经暗示了你的偏好强度。所以在实现算法之前第一步要做的就是把原始行为数据转化成评分。我采用的行为到评分映射规则如下浏览、收藏、加购、购买、评价这五类行为分别映射为1分、2分、3分、4分、5分如果一个用户对同一商品有多种行为则取最大值加权。举个例子用户A浏览过商品X1分后来又将其加入购物车3分最终下单并评价5分那么在这个“用户-商品”交叉点上评分值就是5表示强偏好。有了评分矩阵接下来就面临两个经典问题。一个是数据稀疏性问题假设有100个用户、200个商品那么矩阵中评过分的格子可能只占不到5%因为绝大多数用户只会跟少数商品发生交互。另一个是冷启动问题新用户新商品在矩阵里没有任何数值。针对数据稀疏性问题可以在构建矩阵时设置一个阈值比如用户行为记录数少于5条的用户在计算相似度时暂时不考虑他等他的行为数据积累够了再纳入推荐。针对冷启动问题推荐模块需要加一道兜底逻辑如果协同过滤算法找不到足够相似的用户就退回热门商品推荐按销量和浏览量排序如果是新商品就推荐同分类下销量靠前的商品。这种混合策略才能保证新用户打开页面时不会看到“推荐为空”的尴尬场景。2.3 数据库性能与索引优化的细节电商系统的数据库规模虽然不会像大厂那样动辄上亿条记录但是表之间的关联查询、订单状态的实时更新、商品搜索的模糊匹配依然对数据库设计提出了明确的要求。首先是索引的建立。在订单表上一定要给user_id和status建立联合索引因为用户端最频繁的查询就是“查我自己的订单按照状态筛选”订单号order_no要建立唯一索引保证不重复订单明细表上的order_id加索引用于订单详情页的关联查询。在行为表user_behavior上给user_id和product_id分别建索引因为协同过滤算法在Stage1要查某用户的全部行为Stage2要查某商品被哪些用户行为过。其次是分页查询。商品列表页如果数据量大了千万不要用select * from product这种一次性把所有商品全部查出来再在内存里分页的写法而是使用MyBatis-Plus的Page分页插件配合limit offset实现物理分页。我见过太多新手在商品列表页一次性查出几千条数据导致首页加载延迟到五六秒的惨案。最后是事务控制。下单操作涉及多个表的写入——生成订单记录、插入订单明细、扣减商品库存、清空购物车对应项任何一个环节失败都会导致数据不一致。所以在Service层实现下单方法时必须使用Transactional注解让这四步操作在同一事务里执行。3. 协同过滤算法的Java实现与业务接入3.1 基于用户的协同过滤算法原理基于用户的协同过滤User-based Collaborative Filtering简称UserCF是整个推荐系统的灵魂。它的核心思想可以用一句话概括找到和目标用户兴趣相似的其他用户把这些相似用户喜欢过的、而目标用户没有接触过的商品推荐给目标用户。这句话里面包含了两个核心步骤。第一步计算用户之间的相似度。第二步基于相似用户的评分来预测目标用户对某个商品的评分然后按预测分数排序取Top-N作为推荐结果。在相似度计算上最常用的方法是余弦相似度。把每个用户的评分行为看作一个n维空间中的向量n即商品总数两个用户之间的相似度就是这两个向量夹角的余弦值。余弦相似度的公式为sim(u,v) (u向量点乘v向量) / (|u向量模长| × |v向量模长|)。取值区间在-1到1之间越接近1表示两个用户越相似。在预测评分上最简单有效的方法是利用相似用户群对目标商品的加权评分。假如用户A对商品X还没有行为那么预测A对X的评分为找到前K个与A最相似的用户K通常取10到20这些用户中对X有过评分的那些用户用他们的评分值乘以各自的相似度权重再除以权重之和得到加权平均值。这个预测值越高说明X越可能被A喜欢也就是推荐优先级越高。这里要特别强调一下不相似用户的负向行为要不要考虑。对于一个商品如果一个相似度很高的用户给了低分那么它对预测值的影响应该是正向降低还是负向拉低在简化的场景里我们可以只用正评分的数据来计算也就是只考虑评分大于等于4的用户行为如果你想做精细一点的版本可以把评分映射到-1到1之间比如评分1到3映射为负值评分4到5映射为正值这样低评分也能起到负向抑制的作用。我建议毕设场景里用简单版就足够了。3.2 Java手写协同过滤的核心代码实现用Java实现协同过滤算法不需要引入复杂的机器学习框架纯JDK代码加一点Apache Commons Math的数学工具类就足够了。下面我给出核心算法的关键代码逻辑你可以直接参考并集成到SpringBoot项目中。首先准备一个用户-商品评分矩阵的数据结构。最容易理解的方式是使用MapString, MapString, Double外层Key是用户ID内层Key是商品IDValue就是评分。// 将用户行为记录转换成评分矩阵的方法 public MapString, MapString, Double buildRatingMatrix() { // 从数据库中查询用户行为数据 ListUserBehavior behaviors behaviorMapper.selectList(null); MapString, MapString, Double ratingMatrix new HashMap(); for (UserBehavior behavior : behaviors) { double score convertBehaviorToScore(behavior.getBehaviorType()); String userId behavior.getUserId(); String productId behavior.getProductId(); // 如果同一用户对同一商品有多个行为取分值最高的行为作为最终评分 ratingMatrix.computeIfAbsent(userId, k - new HashMap()) .merge(productId, score, Math::max); } return ratingMatrix; } // 将行为类型映射为评分 public double convertBehaviorToScore(int behaviorType) { switch (behaviorType) { case 1: return 1.0; // 浏览 case 2: return 2.0; // 收藏 case 3: return 3.0; // 加购 case 4: return 4.0; // 购买 case 5: return 5.0; // 评价 default: return 0.0; } }其次计算用户之间的余弦相似度。这里需要对两个用户评分向量中共同包含的商品ID集合做计算都评过分的商品越多、评分值越接近相似度越高。如果两个人没有任何共同评过分的商品直接返回0。// 计算两个用户之间的余弦相似度 public double cosineSimilarity(MapString, Double userRatings1, MapString, Double userRatings2) { SetString commonProducts new HashSet(userRatings1.keySet()); commonProducts.retainAll(userRatings2.keySet()); if (commonProducts.isEmpty()) { return 0.0; } double dotProduct 0.0; double norm1 0.0; double norm2 0.0; for (String productId : commonProducts) { dotProduct userRatings1.get(productId) * userRatings2.get(productId); } for (double value : userRatings1.values()) { norm1 Math.pow(value, 2); } norm1 Math.sqrt(norm1); for (double value : userRatings2.values()) { norm2 Math.pow(value, 2); } norm2 Math.sqrt(norm2); if (norm1 0.0 || norm2 0.0) { return 0.0; } return dotProduct / (norm1 * norm2); }最后为用户生成Top-N推荐商品列表。这部分的流程是先遍历所有其他用户逐一计算与目标用户的相似度把相似度排前K的用户作为最近邻集合再分析这些最近邻用户评分过的所有商品找出目标用户还没有行为过的商品用相似度加权平均的方式预测评分最后按预测评分降序排列取前N个商品作为推荐结果。public ListProduct recommendProducts(String targetUserId, int topN) { MapString, MapString, Double ratingMatrix buildRatingMatrix(); // 目标用户已经购买或行为过的商品推荐时排除 SetString targetUserProducts ratingMatrix.getOrDefault(targetUserId, Collections.emptyMap()).keySet(); // 1. 找到和目标用户最相似的K个用户 MapString, Double userSimilarities new HashMap(); for (String otherUserId : ratingMatrix.keySet()) { if (otherUserId.equals(targetUserId)) { continue; } double similarity cosineSimilarity( ratingMatrix.get(targetUserId), ratingMatrix.get(otherUserId)); if (similarity 0.3) { // 低于阈值视为不相关直接跳过 userSimilarities.put(otherUserId, similarity); } } // 2. 按相似度排序取前K个K取20 int k 20; ListMap.EntryString, Double topKUsers userSimilarities.entrySet().stream() .sorted((e1, e2) - Double.compare(e2.getValue(), e1.getValue())) .limit(k) .collect(Collectors.toList()); // 3. 基于最近邻用户预测目标用户对未接触商品评分 MapString, Double predictScores new HashMap(); MapString, Double similaritySum new HashMap(); for (Map.EntryString, Double entry : topKUsers) { String otherUserId entry.getKey(); double similarity entry.getValue(); MapString, Double otherUserRatings ratingMatrix.get(otherUserId); for (Map.EntryString, Double ratingEntry : otherUserRatings.entrySet()) { String productId ratingEntry.getKey(); // 只推荐目标用户没有行为过的商品 if (targetUserProducts.contains(productId)) { continue; } double weightedScore predictScores.getOrDefault(productId, 0.0) similarity * ratingEntry.getValue(); predictScores.put(productId, weightedScore); similaritySum.put(productId, similaritySum.getOrDefault(productId, 0.0) similarity); } } // 4. 计算加权平均预测分并推荐Top-N ListMap.EntryString, Double sortedRecommendations new ArrayList(); for (Map.EntryString, Double entry : predictScores.entrySet()) { String productId entry.getKey(); double predictedScore entry.getValue() / similaritySum.getOrDefault(productId, 1.0); sortedRecommendations.add(new AbstractMap.SimpleEntry(productId, predictedScore)); } sortedRecommendations.sort((e1, e2) - Double.compare(e2.getValue(), e1.getValue())); // 5. 取TopN商品ID并查询商品详情 ListString recommendProductIds sortedRecommendations.stream() .limit(topN) .map(Map.Entry::getKey) .collect(Collectors.toList()); // 转换成项目中的商品列表返回 ListProduct result new ArrayList(); for (String productId : recommendProductIds) { Product product productMapper.selectById(productId); if (product ! null) { result.add(product); } } return result; }这段代码里有几个细节值得注意。相似度阈值0.3是我在实际调试中常用的一个经验值如果设置太高可能找不到足够的相似用户推荐结果为空设置太低又会把不相关的用户纳入计算拉低推荐精度。另外内层循环中的similaritySum是为了做归一化防止某个相似度特别高的用户独占推荐结果。底层的思路就是一次完整的UserCF流程你在博客或者简历里介绍推荐模块时可以清楚地说出这三个阶段相似度计算、最近邻选取、评分预测。3.3 推荐的兜底策略与接口设计协同过滤算法跑完之后不能直接把结果扔给前端要考虑各种边界情况。比如算法输出的推荐列表为空怎么办目标用户行为数太少导致相似度结果不准怎么办我在项目中引入了三层推荐策略。第一层优先走协同过滤推荐如果算法返回的商品数大于等于6个直接返回结果。第二层如果协同过滤返回不足6个就补充同类目下的热门商品按销量倒序把列表填满。第三层如果用户压根没有行为数据新用户就直接返回全站热销榜的前12条。这种兜底逻辑不需要写得很复杂一个简单的if-else就把推荐接口的健壮性兜住了。在实际接口设计上推荐模块对外暴露的是GET /api/recommend/products?userIdxxxlimit10和GET /api/recommend/user/{userId}/guess-like猜你喜欢这样两个接口。前端首页的“猜你喜欢”区域通过Axios调用该接口拿到商品数据后渲染成推荐卡片列表。为了让用户感知推荐的个性化特点接口返回的数据结构中还可以加一个recommendReason字段后端根据推荐来源填上“因为与你兴趣相似的用户也喜欢”或“全网热销”这样的文本。这里补充一个关于算法性能的说明。协同过滤算法中计算用户相似度的复杂度是O(n²)级别n为用户数当用户量达到一万以上时每次请求都实时计算会明显卡顿。在毕设和小型项目场景中用户量通常不会太大实时计算是可以接受的。但如果你的数据量上来了建议引入离线计算机制比如用定时任务每天凌晨计算一次用户相似度矩阵存入Redis或者数据库表白天推荐时直接查预计算结果响应时间可以从几百毫秒降到几十毫秒。4. 前端Vue开发与SpringBoot接口联调4.1 Vue项目整体结构与页面路由规划前端部分采用Vue 2 Element UI这套组合如果你是新起项目也可以直接上Vue 3 Element Plus原理类似。项目的目录结构按电商业务划分能让你在开发过程中快速定位每个模块的代码位置。src/ |-- api/ # 封装的接口请求模块 | |-- product.js # 商品相关接口 | |-- user.js # 用户相关接口 | |-- order.js # 订单相关接口 | |-- cart.js # 购物车相关接口 |-- assets/ # 静态资源图片、全局样式 |-- components/ # 通用组件 |-- router/index.js # 路由配置 |-- store/ # Vuex状态管理 |-- views/ | |-- home/ # 首页含推荐位 | |-- product/ # 商品列表与商品详情 | |-- cart/ # 购物车 | |-- order/ # 订单确认与订单列表 | |-- user/ # 用户中心 | |-- admin/ # 后台管理 |-- App.vue |-- main.js路由配置划分成三层结构一层是游客可访问的公共路由一层是需要登录的用户路由通过路由守卫判断本地token是否存在还有一层是管理员路由登录用户角色为admin才能进入。路由守卫是确保页面访问权限的唯一关卡没有它用户直接修改URL路径就能跳进后台管理页这在面试中是会被追问的明显安全漏洞。关于Vue Router的配置我推荐使用路由懒加载的方式也就是在路由定义时通过() import()动态加载对应组件。这样做的效果是首屏加载时只加载首页需要的代码其他页面的JS在访问时按需加载减少首屏白屏时间。我在实际项目中实测过使用懒加载后首页的初始JS包体积能从800KB以上降到300KB以内这对用户体验是实打实的提升。4.2 前后端接口交互的最佳实践前后端分离架构中接口的对接规范直接决定联调效率。我的做法是前后端共同约定一套RESTful API风格的数据返回格式后端所有接口统一返回JSON数据结构如下{ code: 200, message: success, data: { } }其中code为200表示成功401表示未登录403表示无权限500表示服务器异常。前端Axios封装统一的请求实例并根据返回code统一处理。这样做的好处是前端不需要在每个请求里单独写错误处理逻辑全局拦截器统一处理一遍就够用了。下面是前端Axios拦截器的核心代码// 创建axios实例 const service axios.create({ baseURL: /api, // 通过代理转发到后端 timeout: 10000 }); // 请求拦截器给所有请求携带token service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] Bearer token; } return config; }, error { return Promise.reject(error); }); // 响应拦截器统一处理错误状态码 service.interceptors.response.use(response { const res response.data; if (res.code 401) { // token失效跳转登录页 router.push(/login); return Promise.reject(new Error(未登录)); } if (res.code ! 200) { Message.error(res.message); return Promise.reject(new Error(res.message)); } return res.data; }, error { Message.error(网络异常请稍后重试); return Promise.reject(error); });关于跨域问题这是前后端分离联调时的第一个拦路虎。本地开发时前端运行在localhost:8080后端运行在localhost:8081端口不同就构成了跨域。解决方案有两种一是在后端配置CORS跨域过滤器允许指定来源访问接口二是在前端Vue的vue.config.js中配置devServer代理把请求转发到后端地址。我推荐使用第二种方案因为它在本地开发时能完美模拟生产环境的前后端同源状态生产部署时也不需要后端额外放开跨域更安全。Vue.config.js代理配置如下module.exports { devServer: { proxy: { /api: { target: http://localhost:8081, changeOrigin: true, pathRewrite: { ^/api: } } } } };这样前端请求/api/product/list时开发服务器会把请求转发到http://localhost:8081/product/list后端不需要任何跨域配置就能正常接收。4.3 购物车和商品列表的性能优化细节购物车是电商前端中交互最频繁的模块。每次勾选、修改数量、删除商品都要实时计算总金额。如果每次交互都向后端发起请求不仅网络开销大而且体验卡顿。我在开发时采用了前端本地计算的方式购物车数据在进入页面时从后端一次性获取之后用户在页面上的所有操作只更新本地数据只有到结算这一步才把最终的购物车数据提交给后端。这种方案把网络请求次数减少了80%以上体验非常顺畅。商品列表页的优化也有一个关键点滚动加载。当商品数量较多时一次性渲染几百个商品卡片会导致页面卡顿。我的做法是引入无限滚动组件一开始只加载前12条商品数据用户滚动到底部时再自动加载下一页数据。配合后端的分页接口和loading状态提示整个浏览体验会维持在流畅的水平。首页推荐区域的渲染则是另一套逻辑。推荐接口返回的数据结构和普通商品列表接口一样都包含商品图片、名称、价格、销量等基础信息所以完全可以复用商品卡片组件。只需要在卡片组件中多接收一个recommendReason属性当该属性存在时就展示在卡片右上角。这样“猜你喜欢”区域和普通商品列表在视觉上就会呈现不同的信息层次让用户直观地感受到推荐模块的存在。5. 系统部署与上线运行实战5.1 基于Docker的快速部署方案项目开发完成后部署上线是最后一个环节。这里推荐使用Docker Compose来编排整个服务栈把你的SpringBoot后端、Vue前端用Nginx托管静态文件、MySQL数据库、Redis缓存服务放到同一个Docker网络里一条命令就能启动全部服务。首先为SpringBoot后端编写DockerfileFROM openjdk:8-jdk-alpine VOLUME /tmp COPY target/mall-0.0.1-SNAPSHOT.jar app.jar ENV TZAsia/Shanghai ENTRYPOINT [java, -jar, /app.jar]然后为Vue前端编写Dockerfile利用多阶段构建先在node镜像中构建前端产物再把产物拷贝到Nginx镜像中# 第一阶段构建前端 FROM node:16-alpine as build-stage WORKDIR /app COPY package.json ./ RUN npm install --registryhttps://registry.npmjs.org COPY . . RUN npm run build # 第二阶段打包Nginx镜像 FROM nginx:alpine COPY --frombuild-stage /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/nginx.conf EXPOSE 80最后用docker-compose.yml把三个服务串联起来。后端服务需要配置MySQL数据源地址和Redis地址因为容器之间通过服务名互访所以在application.yml里数据库地址要写成mysql:3306而不是localhost:3306。version: 3.8 services: mysql: image: mysql:5.7 container_name: mall-mysql environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: mall ports: - 3306:3306 volumes: - ./mysql-data:/var/lib/mysql command: --character-set-serverutf8mb4 redis: image: redis:6-alpine container_name: mall-redis ports: - 6379:6379 backend: build: ./backend container_name: mall-backend depends_on: - mysql - redis ports: - 8081:8081 frontend: build: ./frontend container_name: mall-frontend depends_on: - backend ports: - 80:80部署时只需要在服务器上执行docker-compose up -d系统就会自动完成所有服务的启动。后续更新代码时重新构建对应的镜像再restart即可。5.2 Nginx反向代理配置与前后端连接Nginx在部署架构中承担两个职责托管前端静态文件、反向代理后端接口。如果你没有使用Docker直接在Linux服务器上部署Nginx配置文件大概长这样server { listen 80; server_name your-domain.com; # 托管前端静态文件 location / { root /var/www/mall/dist; index index.html; try_files $uri $uri/ /index.html; # 解决Vue Router的history模式刷新404问题 } # 反向代理后端接口 location /api/ { proxy_pass http://127.0.0.1:8081/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 静态资源缓存配置 location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ { expires 30d; add_header Cache-Control public, no-transform; } }这里有个非常关键的细节try_files $uri $uri/ /index.html这行配置。Vue Router默认使用history模式即URL中没有#号当用户直接访问一个子路由地址例如www.example.com/product/123时如果Nginx找不到对应的静态文件路径就会返回404。这行配置的作用是把所有找不到的路由都重定向到index.html然后Vue Router再根据URL自行匹配对应的组件页面刷新问题就解决了。后端接口的proxy_pass记得要加上尾部的斜杠/。proxy_pass http://127.0.0.1:8081/会把前端请求的/api前缀去掉然后转发给后端如果少了这个斜杠后端接收到的URL就会多带一个/api前缀导致接口404。这个坑我踩过不止一次非常隐蔽。5.3 生产环境的安全优化清单上线后不是就万事大吉了一套能对外展示的商城系统有几个安全问题是必须处理的。第一后台管理接口要做权限校验。SpringBoot后端可以引入Spring Security或者简单的拦截器对所有/admin开头的接口做管理员角色校验。前端路由守卫只是隐藏了页面入口真正的权限控制必须在后端接口层面完成。第二数据库密码不要硬编码在配置文件里。虽然毕设演示场景要求没那么高但我还是建议至少把数据库密码放到环境变量里引用比如使用SpringBoot的${DB_PASSWORD}占位符方式这样即使配置文件和代码被泄露数据库也不会直接暴露。第三接口层要加请求参数校验。商品价格、库存数量、订单金额这些关键字段在后端接收参数时就必须校验范围不能仅依赖前端校验。否则用户可以直接构造一个价格为0的订单请求接口这是非常严重的逻辑漏洞。我见过有毕设项目在订单接口里直接信任前端传过来的金额字段结果被评委演示环节当场发现了漏洞。6. 开发中常见问题与排查技巧实录6.1 前端跨域与接口联调问题速查表在实际开发过程中前后端联调阶段是问题最多的时候。我把最常遇到的几个问题汇总成一张速查表方便你按图索骥地排查。问题现象可能原因排查方式与解决方案前端请求后端返回404代理路径配置错误或后端接口路径不匹配打开浏览器F12查看Network中的请求URL和后端Controller的RequestMapping路径逐一核对前端请求后端返回CORS错误后端未配置跨域且前端未使用代理开发阶段优先使用Vue的devServer代理生产环境用Nginx同源部署请求发送成功但响应体结构异常Axios拦截器里返回的data层级不对检查拦截器代码确认返回的是res.data还是res.data.data登录接口正常但页面跳转失败路由守卫逻辑中token写入时机不对确认登录成功后、跳转路由前token已写入localStorage商品图片不显示图片路径是相对路径前后端域名不同图片上传时返回完整URL或者在前端配置统一的上传文件访问前缀6.2 协同过滤算法效果不好的调试方向推荐算法不是写完就能直接看到好效果的很多人在第一次运行时得到的结果不理想。这时候不要急着改算法先按下面几个方向排查。首先是数据集规模太小。如果你的数据库里只有少量测试数据比如只有几十个用户、每个用户只有几条行为记录那么协同过滤的效果会非常不稳定。解决方案是先造一批符合真实分布的模拟数据设计20个用户让这些用户有不同的偏好主题比如有一部分用户偏好数码产品、一部分偏好服装然后生成几百条行为记录。这样算法的效果就能直观地体现出来。造数据的过程也是对算法逻辑的一次很好的验证。其次是行为评分映射是否合理。如果几乎所有用户对几乎所有商品都只有浏览行为那评分矩阵就变成了稀疏的0-1矩阵区分度很低。解决方法是把评分映射调整得更有梯度浏览给1分加购给3分购买给5分评价在购买的基础上加2分即7分封顶这样高价值行为对推荐结果的贡献更明显。最后是阈值参数调整。相似度阈值0.3要不要改最近邻K值20是否合适这两个参数直接影响推荐结果的质量。实际调试时可以打印出每个用户的推荐列表看看推荐的商品是否合理。如果推荐出来的都是用户从未看过且完全不搭边的商品可以适当调高相似度阈值或者调整TopN数量。6.3 数据库并发与性能问题的经典场景电商系统有一个典型的高并发测试场景秒杀抢购时多个用户同时购买同一个商品数据库库存字段出现超卖库存扣成负数。这个问题在毕设答辩时被评委问到概率极高。出现超卖的本质原因是“先查库存再扣减”这两个操作之间存在时间窗口。解决思路是在数据库层面保证操作的原子性。最简单的方案是把库存扣减SQL改成原子操作UPDATE product SET stock stock - 1 WHERE id ? AND stock 0让数据库自己判断库存是否足够。如果影响行数为0说明库存不足下单失败。另一个容易出现性能瓶颈的地方是商品搜索。如果直接在MySQL中采用LIKE %关键字%的方式做模糊搜索数据量大时查询效率会很低。在毕设场景里可以给商品名称加上全文索引或者直接使用Elasticsearch。但引入ES对毕设来说太过复杂所以我在项目里采用的是轻量级方案先按分类筛选再在分类内做LIKE查询同时配合分页控制返回量。实测在几千条商品数据规模下响应时间在100毫秒以内完全满足需求。7. 项目亮点总结与后续扩展方向7.1 这个项目在面试和答辩中如何展示这个项目的核心卖点是“前后端分离的SpringBootVue组合”加上“协同过滤推荐算法”。在面试中你可以这样组织介绍逻辑先说明系统的整体架构和功能模块再重点突出推荐模块的算法实现细节和落地效果。面试官感兴趣的通常是三个层面的问题你为什么选这个算法、你是怎么实现和优化它的、你遇到了什么具体问题又是怎么解决的。在回答算法相关问题之前我建议你先把UserCF和ItemCF的区别想清楚因为面试官很可能会追问“既然基于用户的协同过滤需要计算用户间相似度当用户量变大时性能急剧下降你有什么改进思路”这个问题不需要你给出完美答案但至少能说出“可以引入离线计算、用户聚类、交替使用ItemCF”这些方向就能证明你有真正的工程思考能力。答辩演示的时候提前准备一份包含模拟数据的演示脚本非常重要。你要能现场演示一个完整链路登录一个用户账号能立刻在首页看到和它历史购买行为相关的推荐商品切换另一个不同偏好的账号推荐结果有明显差异。这样直观的对比效果比任何文字说明都更有说服力。7.2 从协同过滤到混合推荐系统的演进路径如果你后续还想把推荐系统做深完全可以往混合推荐方向走。现在的推荐逻辑本质是UserCF也就是“人以群分”但电商场景还有一个重要的推荐策略是ItemCF即“物以类聚”——买了A商品的用户也常买B商品。ItemCF适合用在商品详情页的“相关推荐”区域而UserCF适合用在首页的“猜你喜欢”区域。将两种算法加权融合可以有不错的推荐效果。比如用户详情页的“看了又看”区域可以整合ItemCF的“与该商品相似的商品”和同分类的热门商品。上面的扩展路径每个都不复杂但都能让项目的推荐系统更像一个真实商业系统。还可以加入基于标签的推荐。给每个商品预设多个标签如“数码”“便携”“性价比高”基于用户历史行为算出用户的标签偏好向量然后推荐标签匹配度高的商品。这种基于内容的推荐手段可以在协同过滤数据不足时发挥很好的补充作用也是解决冷启动问题的有效途径。7.3 前端体验层还可以打磨的几个小细节推荐系统做完了前端展示层也有几个值得打磨的细节。比如在“猜你喜欢”列表中加入“不感兴趣”按钮用户点击后自动刷新推荐列表数据会反馈到后端行为表。这种主动反馈机制既是产品细节也是推荐系统优化迭代的数据输入。再比如一个加载骨架屏的设计。推荐接口因为涉及算法计算响应时间通常比普通接口要长一些如果页面在数据返回前是一片空白用户体验会很差。用Vue的v-if控制推荐区域的组件状态在数据加载中显示灰色骨架占位数据到达后再渲染真实内容这比一个简单的loading转圈要有质感得多。还有推荐理由标签的展示优化。推荐接口返回的recommendReason字段可以进一步细分比如基于相似用户推荐显示“和你兴趣相投的人都在看”基于热门兜底推荐显示“大家都在抢购”基于同分类推荐显示“你喜欢的分类又上新了”。这些文案上的小差异能让用户更清晰地感知到推荐系统的存在价值也让整个首页的个性化氛围更浓。回到项目本身这套系统的架构能力、推荐算法的工程落地能力、前后端联调的熟练度都是真实可复用的项目经验。如果你正在准备毕业设计按这条路线做下来从数据库设计到算法实现再到部署上线走通一遍之后你对一套业务系统的完整生命周期会有很扎实的体感。 基于SpringBoot+Vue的电商系统协同过滤推荐算法实战
1. 项目整体设计与技术选型思路1.1 为什么是SpringBootVue这套组合如果你准备做电商类项目市面上可选的技术方案其实很多传统的有SSH、SSM新一点的有微服务全家桶。但这套系统最终选择SpringBootVue的前后端分离架构不是因为它热门而是因为它确实是目前最适合中小型电商系统、也最适合毕业设计和简历项目的搭配。先看后端。SpringBoot的核心价值在于“约定大于配置”它把Spring生态里那些繁琐的XML配置全部干掉通过自动装配机制就能把Web层、持久层、安全框架全部串联起来。比如你想引入MyBatis-Plus操作数据库只需要在pom.xml中加一个依赖然后在application.yml里写好数据源就能直接使用了。这种开发体验在一个需要快速出成果的项目里非常舒服。对比2018年之前用SSM搭框架的日子光是spring-mvc.xml、mybatis-config.xml这些配置文件就够折腾一整天而现在SpringBoot把这一切都封装掉了你可以把精力集中在业务逻辑上。实际上这是SpringBoot自动装配的功劳你可以去翻一下spring-boot-autoconfigure这个jar包里的源码会发现每个配置类上都有EnableAutoConfiguration相关的注解和大量的ConditionalOnProperty、ConditionalOnClass条件判断理解这套机制对你面试也有帮助。再看前端。Vue的渐进式框架特点决定了它特别适合做电商这种交互密集型的应用。组件化开发让商品卡片、购物车列表、订单状态这些UI单元可以被复用Vue Router让页面路由切换丝滑流畅Vuex或Pinia做状态管理可以把用户登录信息、购物车数据这类全局共享状态统一管理起来。相比JSP时代那种后端渲染页面、前端只负责写jQuery的做法这种前后端彻底分离的模式让两个人的分工可以完全并行后端专心写接口前端专心写页面交互最后通过HTTP协议联调对接。这套组合还有一个实际的好处就是部署架构干净清晰。后端的SpringBoot打成jar包前端的Vue执行npm run build生成一套纯静态文件交给Nginx托管。两者之间通过接口域名或者反向代理关联起来无论是部署在一台服务器还是各自独立部署都非常灵活。你甚至可以只把dist目录里的文件扔到GitHub Pages上都能跑起来前端页面这对演示项目来说非常友好。1.2 协同过滤算法在电商场景中的定位这个项目标题里包含“协同过滤算法”这决定了它不是一个普普通通的管理系统而是一个带智能推荐能力的电商平台。用户打开首页不再是看到一成不变的商品列表而是能看到系统根据他自己的历史行为生成的个性化推荐——“猜你喜欢”。那么为什么要用协同过滤电商场景里解决推荐问题的主流手段分为三类基于内容的推荐、协同过滤推荐、以及混合推荐。基于内容的推荐简单理解就是“给用户推荐和他买过的商品相似的商品”比如他买了一个iPhone你就推荐同品牌的手机壳这种方案没有用户行为数据的积累也能跑。协同过滤则不同它的核心逻辑是“找和你相似的人看看他们喜欢什么”也就是利用群体的智慧来做个性化推荐这需要一定量的用户行为数据支撑。在一个毕业设计或者中小型项目里协同过滤是最合适的选择原因有三个。第一它的算法原理清晰易懂基于用户的协同过滤UserCF也好基于物品的协同过滤ItemCF也好核心公式就是余弦相似度或者皮尔逊相关系数完全可以在Java中用几十行代码手写实现。第二它不需要大量的商品特征工程不需要去维护每个商品的属性标签只需要收集“用户-物品-评分”三元组数据。第三它的可解释性强你可以告诉用户“因为与你兴趣相似的用户也喜欢这款商品所以为你推荐”这种推荐理由在电商实战中很有说服力。然而协同比过滤也有它的脾气冷启动问题首当其冲。新用户没有行为数据系统就不知道他喜欢什么新商品没有人评分系统就更难把它推出去。这我在后面算法实现的部分会给出具体的兜底方案。1.3 系统功能模块划分一个完整的网上购物商城系统按照角色可以拆成四个端游客端、用户端、商家端、管理员端。这种多角色的划分是电商系统的标准做法也直接决定了数据库表结构和权限控制的设计。游客端其实是用户端的子集游客可以浏览商品、搜索商品、查看商品详情但一旦需要加入购物车、提交订单、查看个人中心就必须登录。这个登录门槛设计成用户点击结算时再弹出登录框而不是一开始就强制注册这样能最大限度减少用户流失。用户端是核心包含注册登录、商品浏览与搜索、商品详情、购物车管理、订单管理、收货地址管理、个人中心、商品收藏与评价。这里需要注意购物车和订单是电商系统里逻辑最复杂的两个模块购物车涉及库存校验、价格快照、勾选状态的实时计算订单则涉及多个状态节点。商家端负责商品的上架、下架、库存管理、订单发货、查看销售统计。在毕设场景里不需要做到淘宝的千牛那么复杂但最基本的商品CRUD和订单状态流转一定要完整。管理员端则负责用户管理、商品分类管理、全局订单监管、以及系统数据统计。核心提示在功能设计上推荐系统不是孤立的一块它需要用户行为数据作为输入源。因此数据库设计里要有一张用户行为记录表记录用户的浏览、收藏、加购、购买、评价行为再配合商品评分数据共同作为协同过滤算法的输入。2. 数据库设计与协同过滤数据体系构建2.1 核心表结构设计数据库是整个电商系统的地基表结构设计得好不好直接决定后期开发效率和推荐算法的数据质量。我以下提供一套经过验证的核心表设计基本能覆盖一个小型电商的全部业务。用户表user需要包含id、username、passwordBCrypt加密后的密文、nickname、avatar、phone、email、status、create_time。密码加密这一点非常重要千万不要明文存储SpringSecurity自带的BCryptPasswordEncoder就可以用。商品表product需要包含id、category_id关联分类表、name、subtitle副标题、main_image、detail富文本详情、price、stock库存、sales销量、status上下架状态、create_time。注意price字段建议使用decimal(10,2)不要用float或者double否则在金额计算时会出现精度丢失的问题。订单表和订单明细表是电商系统的重头戏。订单表orders存储id、order_no订单编号、user_id、total_amount、pay_amount、freight_amount、status待付款、待发货、待收货、已完成、已取消、address_info收货信息快照、create_time、pay_time、deliver_time、finish_time。订单明细表order_item存储id、order_id、product_id、product_name、product_image、current_price下单时的价格快照、quantity、total_price。这里做价格快照是为了防止用户下单后商品改价导致订单金额对不上。购物车表cart相对简单包含id、user_id、product_id、quantity、checked是否勾选。评价表comment包含id、user_id、product_id、order_id、content、rating1-5分、create_time。这里还有一个很容易被忽略但推荐算法急需要的表——用户行为表user_behavior。字段包括id、user_id、product_id、behavior_type浏览1/收藏2/加购3/购买4/评价5、create_time。这张表是协同过滤算法最重要的数据来源在你没有显式评分数据时可以通过行为类型映射成评分权重来构建用户-物品评分矩阵。2.2 从零开始的用户画像与评分矩阵构建协同过滤算法的输入是一个“用户-物品评分矩阵”。但这个矩阵怎么来是项目落地的第一个坎。真实电商平台比如淘宝、京东让你给商品打1到5星的场景其实并不多大量用户的偏好藏在他们的行为里。你在淘宝上搜了一个商品、点进去看了详情、把它加入购物车、最终下单这一系列动作已经暗示了你的偏好强度。所以在实现算法之前第一步要做的就是把原始行为数据转化成评分。我采用的行为到评分映射规则如下浏览、收藏、加购、购买、评价这五类行为分别映射为1分、2分、3分、4分、5分如果一个用户对同一商品有多种行为则取最大值加权。举个例子用户A浏览过商品X1分后来又将其加入购物车3分最终下单并评价5分那么在这个“用户-商品”交叉点上评分值就是5表示强偏好。有了评分矩阵接下来就面临两个经典问题。一个是数据稀疏性问题假设有100个用户、200个商品那么矩阵中评过分的格子可能只占不到5%因为绝大多数用户只会跟少数商品发生交互。另一个是冷启动问题新用户新商品在矩阵里没有任何数值。针对数据稀疏性问题可以在构建矩阵时设置一个阈值比如用户行为记录数少于5条的用户在计算相似度时暂时不考虑他等他的行为数据积累够了再纳入推荐。针对冷启动问题推荐模块需要加一道兜底逻辑如果协同过滤算法找不到足够相似的用户就退回热门商品推荐按销量和浏览量排序如果是新商品就推荐同分类下销量靠前的商品。这种混合策略才能保证新用户打开页面时不会看到“推荐为空”的尴尬场景。2.3 数据库性能与索引优化的细节电商系统的数据库规模虽然不会像大厂那样动辄上亿条记录但是表之间的关联查询、订单状态的实时更新、商品搜索的模糊匹配依然对数据库设计提出了明确的要求。首先是索引的建立。在订单表上一定要给user_id和status建立联合索引因为用户端最频繁的查询就是“查我自己的订单按照状态筛选”订单号order_no要建立唯一索引保证不重复订单明细表上的order_id加索引用于订单详情页的关联查询。在行为表user_behavior上给user_id和product_id分别建索引因为协同过滤算法在Stage1要查某用户的全部行为Stage2要查某商品被哪些用户行为过。其次是分页查询。商品列表页如果数据量大了千万不要用select * from product这种一次性把所有商品全部查出来再在内存里分页的写法而是使用MyBatis-Plus的Page分页插件配合limit offset实现物理分页。我见过太多新手在商品列表页一次性查出几千条数据导致首页加载延迟到五六秒的惨案。最后是事务控制。下单操作涉及多个表的写入——生成订单记录、插入订单明细、扣减商品库存、清空购物车对应项任何一个环节失败都会导致数据不一致。所以在Service层实现下单方法时必须使用Transactional注解让这四步操作在同一事务里执行。3. 协同过滤算法的Java实现与业务接入3.1 基于用户的协同过滤算法原理基于用户的协同过滤User-based Collaborative Filtering简称UserCF是整个推荐系统的灵魂。它的核心思想可以用一句话概括找到和目标用户兴趣相似的其他用户把这些相似用户喜欢过的、而目标用户没有接触过的商品推荐给目标用户。这句话里面包含了两个核心步骤。第一步计算用户之间的相似度。第二步基于相似用户的评分来预测目标用户对某个商品的评分然后按预测分数排序取Top-N作为推荐结果。在相似度计算上最常用的方法是余弦相似度。把每个用户的评分行为看作一个n维空间中的向量n即商品总数两个用户之间的相似度就是这两个向量夹角的余弦值。余弦相似度的公式为sim(u,v) (u向量点乘v向量) / (|u向量模长| × |v向量模长|)。取值区间在-1到1之间越接近1表示两个用户越相似。在预测评分上最简单有效的方法是利用相似用户群对目标商品的加权评分。假如用户A对商品X还没有行为那么预测A对X的评分为找到前K个与A最相似的用户K通常取10到20这些用户中对X有过评分的那些用户用他们的评分值乘以各自的相似度权重再除以权重之和得到加权平均值。这个预测值越高说明X越可能被A喜欢也就是推荐优先级越高。这里要特别强调一下不相似用户的负向行为要不要考虑。对于一个商品如果一个相似度很高的用户给了低分那么它对预测值的影响应该是正向降低还是负向拉低在简化的场景里我们可以只用正评分的数据来计算也就是只考虑评分大于等于4的用户行为如果你想做精细一点的版本可以把评分映射到-1到1之间比如评分1到3映射为负值评分4到5映射为正值这样低评分也能起到负向抑制的作用。我建议毕设场景里用简单版就足够了。3.2 Java手写协同过滤的核心代码实现用Java实现协同过滤算法不需要引入复杂的机器学习框架纯JDK代码加一点Apache Commons Math的数学工具类就足够了。下面我给出核心算法的关键代码逻辑你可以直接参考并集成到SpringBoot项目中。首先准备一个用户-商品评分矩阵的数据结构。最容易理解的方式是使用MapString, MapString, Double外层Key是用户ID内层Key是商品IDValue就是评分。// 将用户行为记录转换成评分矩阵的方法 public MapString, MapString, Double buildRatingMatrix() { // 从数据库中查询用户行为数据 ListUserBehavior behaviors behaviorMapper.selectList(null); MapString, MapString, Double ratingMatrix new HashMap(); for (UserBehavior behavior : behaviors) { double score convertBehaviorToScore(behavior.getBehaviorType()); String userId behavior.getUserId(); String productId behavior.getProductId(); // 如果同一用户对同一商品有多个行为取分值最高的行为作为最终评分 ratingMatrix.computeIfAbsent(userId, k - new HashMap()) .merge(productId, score, Math::max); } return ratingMatrix; } // 将行为类型映射为评分 public double convertBehaviorToScore(int behaviorType) { switch (behaviorType) { case 1: return 1.0; // 浏览 case 2: return 2.0; // 收藏 case 3: return 3.0; // 加购 case 4: return 4.0; // 购买 case 5: return 5.0; // 评价 default: return 0.0; } }其次计算用户之间的余弦相似度。这里需要对两个用户评分向量中共同包含的商品ID集合做计算都评过分的商品越多、评分值越接近相似度越高。如果两个人没有任何共同评过分的商品直接返回0。// 计算两个用户之间的余弦相似度 public double cosineSimilarity(MapString, Double userRatings1, MapString, Double userRatings2) { SetString commonProducts new HashSet(userRatings1.keySet()); commonProducts.retainAll(userRatings2.keySet()); if (commonProducts.isEmpty()) { return 0.0; } double dotProduct 0.0; double norm1 0.0; double norm2 0.0; for (String productId : commonProducts) { dotProduct userRatings1.get(productId) * userRatings2.get(productId); } for (double value : userRatings1.values()) { norm1 Math.pow(value, 2); } norm1 Math.sqrt(norm1); for (double value : userRatings2.values()) { norm2 Math.pow(value, 2); } norm2 Math.sqrt(norm2); if (norm1 0.0 || norm2 0.0) { return 0.0; } return dotProduct / (norm1 * norm2); }最后为用户生成Top-N推荐商品列表。这部分的流程是先遍历所有其他用户逐一计算与目标用户的相似度把相似度排前K的用户作为最近邻集合再分析这些最近邻用户评分过的所有商品找出目标用户还没有行为过的商品用相似度加权平均的方式预测评分最后按预测评分降序排列取前N个商品作为推荐结果。public ListProduct recommendProducts(String targetUserId, int topN) { MapString, MapString, Double ratingMatrix buildRatingMatrix(); // 目标用户已经购买或行为过的商品推荐时排除 SetString targetUserProducts ratingMatrix.getOrDefault(targetUserId, Collections.emptyMap()).keySet(); // 1. 找到和目标用户最相似的K个用户 MapString, Double userSimilarities new HashMap(); for (String otherUserId : ratingMatrix.keySet()) { if (otherUserId.equals(targetUserId)) { continue; } double similarity cosineSimilarity( ratingMatrix.get(targetUserId), ratingMatrix.get(otherUserId)); if (similarity 0.3) { // 低于阈值视为不相关直接跳过 userSimilarities.put(otherUserId, similarity); } } // 2. 按相似度排序取前K个K取20 int k 20; ListMap.EntryString, Double topKUsers userSimilarities.entrySet().stream() .sorted((e1, e2) - Double.compare(e2.getValue(), e1.getValue())) .limit(k) .collect(Collectors.toList()); // 3. 基于最近邻用户预测目标用户对未接触商品评分 MapString, Double predictScores new HashMap(); MapString, Double similaritySum new HashMap(); for (Map.EntryString, Double entry : topKUsers) { String otherUserId entry.getKey(); double similarity entry.getValue(); MapString, Double otherUserRatings ratingMatrix.get(otherUserId); for (Map.EntryString, Double ratingEntry : otherUserRatings.entrySet()) { String productId ratingEntry.getKey(); // 只推荐目标用户没有行为过的商品 if (targetUserProducts.contains(productId)) { continue; } double weightedScore predictScores.getOrDefault(productId, 0.0) similarity * ratingEntry.getValue(); predictScores.put(productId, weightedScore); similaritySum.put(productId, similaritySum.getOrDefault(productId, 0.0) similarity); } } // 4. 计算加权平均预测分并推荐Top-N ListMap.EntryString, Double sortedRecommendations new ArrayList(); for (Map.EntryString, Double entry : predictScores.entrySet()) { String productId entry.getKey(); double predictedScore entry.getValue() / similaritySum.getOrDefault(productId, 1.0); sortedRecommendations.add(new AbstractMap.SimpleEntry(productId, predictedScore)); } sortedRecommendations.sort((e1, e2) - Double.compare(e2.getValue(), e1.getValue())); // 5. 取TopN商品ID并查询商品详情 ListString recommendProductIds sortedRecommendations.stream() .limit(topN) .map(Map.Entry::getKey) .collect(Collectors.toList()); // 转换成项目中的商品列表返回 ListProduct result new ArrayList(); for (String productId : recommendProductIds) { Product product productMapper.selectById(productId); if (product ! null) { result.add(product); } } return result; }这段代码里有几个细节值得注意。相似度阈值0.3是我在实际调试中常用的一个经验值如果设置太高可能找不到足够的相似用户推荐结果为空设置太低又会把不相关的用户纳入计算拉低推荐精度。另外内层循环中的similaritySum是为了做归一化防止某个相似度特别高的用户独占推荐结果。底层的思路就是一次完整的UserCF流程你在博客或者简历里介绍推荐模块时可以清楚地说出这三个阶段相似度计算、最近邻选取、评分预测。3.3 推荐的兜底策略与接口设计协同过滤算法跑完之后不能直接把结果扔给前端要考虑各种边界情况。比如算法输出的推荐列表为空怎么办目标用户行为数太少导致相似度结果不准怎么办我在项目中引入了三层推荐策略。第一层优先走协同过滤推荐如果算法返回的商品数大于等于6个直接返回结果。第二层如果协同过滤返回不足6个就补充同类目下的热门商品按销量倒序把列表填满。第三层如果用户压根没有行为数据新用户就直接返回全站热销榜的前12条。这种兜底逻辑不需要写得很复杂一个简单的if-else就把推荐接口的健壮性兜住了。在实际接口设计上推荐模块对外暴露的是GET /api/recommend/products?userIdxxxlimit10和GET /api/recommend/user/{userId}/guess-like猜你喜欢这样两个接口。前端首页的“猜你喜欢”区域通过Axios调用该接口拿到商品数据后渲染成推荐卡片列表。为了让用户感知推荐的个性化特点接口返回的数据结构中还可以加一个recommendReason字段后端根据推荐来源填上“因为与你兴趣相似的用户也喜欢”或“全网热销”这样的文本。这里补充一个关于算法性能的说明。协同过滤算法中计算用户相似度的复杂度是O(n²)级别n为用户数当用户量达到一万以上时每次请求都实时计算会明显卡顿。在毕设和小型项目场景中用户量通常不会太大实时计算是可以接受的。但如果你的数据量上来了建议引入离线计算机制比如用定时任务每天凌晨计算一次用户相似度矩阵存入Redis或者数据库表白天推荐时直接查预计算结果响应时间可以从几百毫秒降到几十毫秒。4. 前端Vue开发与SpringBoot接口联调4.1 Vue项目整体结构与页面路由规划前端部分采用Vue 2 Element UI这套组合如果你是新起项目也可以直接上Vue 3 Element Plus原理类似。项目的目录结构按电商业务划分能让你在开发过程中快速定位每个模块的代码位置。src/ |-- api/ # 封装的接口请求模块 | |-- product.js # 商品相关接口 | |-- user.js # 用户相关接口 | |-- order.js # 订单相关接口 | |-- cart.js # 购物车相关接口 |-- assets/ # 静态资源图片、全局样式 |-- components/ # 通用组件 |-- router/index.js # 路由配置 |-- store/ # Vuex状态管理 |-- views/ | |-- home/ # 首页含推荐位 | |-- product/ # 商品列表与商品详情 | |-- cart/ # 购物车 | |-- order/ # 订单确认与订单列表 | |-- user/ # 用户中心 | |-- admin/ # 后台管理 |-- App.vue |-- main.js路由配置划分成三层结构一层是游客可访问的公共路由一层是需要登录的用户路由通过路由守卫判断本地token是否存在还有一层是管理员路由登录用户角色为admin才能进入。路由守卫是确保页面访问权限的唯一关卡没有它用户直接修改URL路径就能跳进后台管理页这在面试中是会被追问的明显安全漏洞。关于Vue Router的配置我推荐使用路由懒加载的方式也就是在路由定义时通过() import()动态加载对应组件。这样做的效果是首屏加载时只加载首页需要的代码其他页面的JS在访问时按需加载减少首屏白屏时间。我在实际项目中实测过使用懒加载后首页的初始JS包体积能从800KB以上降到300KB以内这对用户体验是实打实的提升。4.2 前后端接口交互的最佳实践前后端分离架构中接口的对接规范直接决定联调效率。我的做法是前后端共同约定一套RESTful API风格的数据返回格式后端所有接口统一返回JSON数据结构如下{ code: 200, message: success, data: { } }其中code为200表示成功401表示未登录403表示无权限500表示服务器异常。前端Axios封装统一的请求实例并根据返回code统一处理。这样做的好处是前端不需要在每个请求里单独写错误处理逻辑全局拦截器统一处理一遍就够用了。下面是前端Axios拦截器的核心代码// 创建axios实例 const service axios.create({ baseURL: /api, // 通过代理转发到后端 timeout: 10000 }); // 请求拦截器给所有请求携带token service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] Bearer token; } return config; }, error { return Promise.reject(error); }); // 响应拦截器统一处理错误状态码 service.interceptors.response.use(response { const res response.data; if (res.code 401) { // token失效跳转登录页 router.push(/login); return Promise.reject(new Error(未登录)); } if (res.code ! 200) { Message.error(res.message); return Promise.reject(new Error(res.message)); } return res.data; }, error { Message.error(网络异常请稍后重试); return Promise.reject(error); });关于跨域问题这是前后端分离联调时的第一个拦路虎。本地开发时前端运行在localhost:8080后端运行在localhost:8081端口不同就构成了跨域。解决方案有两种一是在后端配置CORS跨域过滤器允许指定来源访问接口二是在前端Vue的vue.config.js中配置devServer代理把请求转发到后端地址。我推荐使用第二种方案因为它在本地开发时能完美模拟生产环境的前后端同源状态生产部署时也不需要后端额外放开跨域更安全。Vue.config.js代理配置如下module.exports { devServer: { proxy: { /api: { target: http://localhost:8081, changeOrigin: true, pathRewrite: { ^/api: } } } } };这样前端请求/api/product/list时开发服务器会把请求转发到http://localhost:8081/product/list后端不需要任何跨域配置就能正常接收。4.3 购物车和商品列表的性能优化细节购物车是电商前端中交互最频繁的模块。每次勾选、修改数量、删除商品都要实时计算总金额。如果每次交互都向后端发起请求不仅网络开销大而且体验卡顿。我在开发时采用了前端本地计算的方式购物车数据在进入页面时从后端一次性获取之后用户在页面上的所有操作只更新本地数据只有到结算这一步才把最终的购物车数据提交给后端。这种方案把网络请求次数减少了80%以上体验非常顺畅。商品列表页的优化也有一个关键点滚动加载。当商品数量较多时一次性渲染几百个商品卡片会导致页面卡顿。我的做法是引入无限滚动组件一开始只加载前12条商品数据用户滚动到底部时再自动加载下一页数据。配合后端的分页接口和loading状态提示整个浏览体验会维持在流畅的水平。首页推荐区域的渲染则是另一套逻辑。推荐接口返回的数据结构和普通商品列表接口一样都包含商品图片、名称、价格、销量等基础信息所以完全可以复用商品卡片组件。只需要在卡片组件中多接收一个recommendReason属性当该属性存在时就展示在卡片右上角。这样“猜你喜欢”区域和普通商品列表在视觉上就会呈现不同的信息层次让用户直观地感受到推荐模块的存在。5. 系统部署与上线运行实战5.1 基于Docker的快速部署方案项目开发完成后部署上线是最后一个环节。这里推荐使用Docker Compose来编排整个服务栈把你的SpringBoot后端、Vue前端用Nginx托管静态文件、MySQL数据库、Redis缓存服务放到同一个Docker网络里一条命令就能启动全部服务。首先为SpringBoot后端编写DockerfileFROM openjdk:8-jdk-alpine VOLUME /tmp COPY target/mall-0.0.1-SNAPSHOT.jar app.jar ENV TZAsia/Shanghai ENTRYPOINT [java, -jar, /app.jar]然后为Vue前端编写Dockerfile利用多阶段构建先在node镜像中构建前端产物再把产物拷贝到Nginx镜像中# 第一阶段构建前端 FROM node:16-alpine as build-stage WORKDIR /app COPY package.json ./ RUN npm install --registryhttps://registry.npmjs.org COPY . . RUN npm run build # 第二阶段打包Nginx镜像 FROM nginx:alpine COPY --frombuild-stage /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/nginx.conf EXPOSE 80最后用docker-compose.yml把三个服务串联起来。后端服务需要配置MySQL数据源地址和Redis地址因为容器之间通过服务名互访所以在application.yml里数据库地址要写成mysql:3306而不是localhost:3306。version: 3.8 services: mysql: image: mysql:5.7 container_name: mall-mysql environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: mall ports: - 3306:3306 volumes: - ./mysql-data:/var/lib/mysql command: --character-set-serverutf8mb4 redis: image: redis:6-alpine container_name: mall-redis ports: - 6379:6379 backend: build: ./backend container_name: mall-backend depends_on: - mysql - redis ports: - 8081:8081 frontend: build: ./frontend container_name: mall-frontend depends_on: - backend ports: - 80:80部署时只需要在服务器上执行docker-compose up -d系统就会自动完成所有服务的启动。后续更新代码时重新构建对应的镜像再restart即可。5.2 Nginx反向代理配置与前后端连接Nginx在部署架构中承担两个职责托管前端静态文件、反向代理后端接口。如果你没有使用Docker直接在Linux服务器上部署Nginx配置文件大概长这样server { listen 80; server_name your-domain.com; # 托管前端静态文件 location / { root /var/www/mall/dist; index index.html; try_files $uri $uri/ /index.html; # 解决Vue Router的history模式刷新404问题 } # 反向代理后端接口 location /api/ { proxy_pass http://127.0.0.1:8081/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 静态资源缓存配置 location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ { expires 30d; add_header Cache-Control public, no-transform; } }这里有个非常关键的细节try_files $uri $uri/ /index.html这行配置。Vue Router默认使用history模式即URL中没有#号当用户直接访问一个子路由地址例如www.example.com/product/123时如果Nginx找不到对应的静态文件路径就会返回404。这行配置的作用是把所有找不到的路由都重定向到index.html然后Vue Router再根据URL自行匹配对应的组件页面刷新问题就解决了。后端接口的proxy_pass记得要加上尾部的斜杠/。proxy_pass http://127.0.0.1:8081/会把前端请求的/api前缀去掉然后转发给后端如果少了这个斜杠后端接收到的URL就会多带一个/api前缀导致接口404。这个坑我踩过不止一次非常隐蔽。5.3 生产环境的安全优化清单上线后不是就万事大吉了一套能对外展示的商城系统有几个安全问题是必须处理的。第一后台管理接口要做权限校验。SpringBoot后端可以引入Spring Security或者简单的拦截器对所有/admin开头的接口做管理员角色校验。前端路由守卫只是隐藏了页面入口真正的权限控制必须在后端接口层面完成。第二数据库密码不要硬编码在配置文件里。虽然毕设演示场景要求没那么高但我还是建议至少把数据库密码放到环境变量里引用比如使用SpringBoot的${DB_PASSWORD}占位符方式这样即使配置文件和代码被泄露数据库也不会直接暴露。第三接口层要加请求参数校验。商品价格、库存数量、订单金额这些关键字段在后端接收参数时就必须校验范围不能仅依赖前端校验。否则用户可以直接构造一个价格为0的订单请求接口这是非常严重的逻辑漏洞。我见过有毕设项目在订单接口里直接信任前端传过来的金额字段结果被评委演示环节当场发现了漏洞。6. 开发中常见问题与排查技巧实录6.1 前端跨域与接口联调问题速查表在实际开发过程中前后端联调阶段是问题最多的时候。我把最常遇到的几个问题汇总成一张速查表方便你按图索骥地排查。问题现象可能原因排查方式与解决方案前端请求后端返回404代理路径配置错误或后端接口路径不匹配打开浏览器F12查看Network中的请求URL和后端Controller的RequestMapping路径逐一核对前端请求后端返回CORS错误后端未配置跨域且前端未使用代理开发阶段优先使用Vue的devServer代理生产环境用Nginx同源部署请求发送成功但响应体结构异常Axios拦截器里返回的data层级不对检查拦截器代码确认返回的是res.data还是res.data.data登录接口正常但页面跳转失败路由守卫逻辑中token写入时机不对确认登录成功后、跳转路由前token已写入localStorage商品图片不显示图片路径是相对路径前后端域名不同图片上传时返回完整URL或者在前端配置统一的上传文件访问前缀6.2 协同过滤算法效果不好的调试方向推荐算法不是写完就能直接看到好效果的很多人在第一次运行时得到的结果不理想。这时候不要急着改算法先按下面几个方向排查。首先是数据集规模太小。如果你的数据库里只有少量测试数据比如只有几十个用户、每个用户只有几条行为记录那么协同过滤的效果会非常不稳定。解决方案是先造一批符合真实分布的模拟数据设计20个用户让这些用户有不同的偏好主题比如有一部分用户偏好数码产品、一部分偏好服装然后生成几百条行为记录。这样算法的效果就能直观地体现出来。造数据的过程也是对算法逻辑的一次很好的验证。其次是行为评分映射是否合理。如果几乎所有用户对几乎所有商品都只有浏览行为那评分矩阵就变成了稀疏的0-1矩阵区分度很低。解决方法是把评分映射调整得更有梯度浏览给1分加购给3分购买给5分评价在购买的基础上加2分即7分封顶这样高价值行为对推荐结果的贡献更明显。最后是阈值参数调整。相似度阈值0.3要不要改最近邻K值20是否合适这两个参数直接影响推荐结果的质量。实际调试时可以打印出每个用户的推荐列表看看推荐的商品是否合理。如果推荐出来的都是用户从未看过且完全不搭边的商品可以适当调高相似度阈值或者调整TopN数量。6.3 数据库并发与性能问题的经典场景电商系统有一个典型的高并发测试场景秒杀抢购时多个用户同时购买同一个商品数据库库存字段出现超卖库存扣成负数。这个问题在毕设答辩时被评委问到概率极高。出现超卖的本质原因是“先查库存再扣减”这两个操作之间存在时间窗口。解决思路是在数据库层面保证操作的原子性。最简单的方案是把库存扣减SQL改成原子操作UPDATE product SET stock stock - 1 WHERE id ? AND stock 0让数据库自己判断库存是否足够。如果影响行数为0说明库存不足下单失败。另一个容易出现性能瓶颈的地方是商品搜索。如果直接在MySQL中采用LIKE %关键字%的方式做模糊搜索数据量大时查询效率会很低。在毕设场景里可以给商品名称加上全文索引或者直接使用Elasticsearch。但引入ES对毕设来说太过复杂所以我在项目里采用的是轻量级方案先按分类筛选再在分类内做LIKE查询同时配合分页控制返回量。实测在几千条商品数据规模下响应时间在100毫秒以内完全满足需求。7. 项目亮点总结与后续扩展方向7.1 这个项目在面试和答辩中如何展示这个项目的核心卖点是“前后端分离的SpringBootVue组合”加上“协同过滤推荐算法”。在面试中你可以这样组织介绍逻辑先说明系统的整体架构和功能模块再重点突出推荐模块的算法实现细节和落地效果。面试官感兴趣的通常是三个层面的问题你为什么选这个算法、你是怎么实现和优化它的、你遇到了什么具体问题又是怎么解决的。在回答算法相关问题之前我建议你先把UserCF和ItemCF的区别想清楚因为面试官很可能会追问“既然基于用户的协同过滤需要计算用户间相似度当用户量变大时性能急剧下降你有什么改进思路”这个问题不需要你给出完美答案但至少能说出“可以引入离线计算、用户聚类、交替使用ItemCF”这些方向就能证明你有真正的工程思考能力。答辩演示的时候提前准备一份包含模拟数据的演示脚本非常重要。你要能现场演示一个完整链路登录一个用户账号能立刻在首页看到和它历史购买行为相关的推荐商品切换另一个不同偏好的账号推荐结果有明显差异。这样直观的对比效果比任何文字说明都更有说服力。7.2 从协同过滤到混合推荐系统的演进路径如果你后续还想把推荐系统做深完全可以往混合推荐方向走。现在的推荐逻辑本质是UserCF也就是“人以群分”但电商场景还有一个重要的推荐策略是ItemCF即“物以类聚”——买了A商品的用户也常买B商品。ItemCF适合用在商品详情页的“相关推荐”区域而UserCF适合用在首页的“猜你喜欢”区域。将两种算法加权融合可以有不错的推荐效果。比如用户详情页的“看了又看”区域可以整合ItemCF的“与该商品相似的商品”和同分类的热门商品。上面的扩展路径每个都不复杂但都能让项目的推荐系统更像一个真实商业系统。还可以加入基于标签的推荐。给每个商品预设多个标签如“数码”“便携”“性价比高”基于用户历史行为算出用户的标签偏好向量然后推荐标签匹配度高的商品。这种基于内容的推荐手段可以在协同过滤数据不足时发挥很好的补充作用也是解决冷启动问题的有效途径。7.3 前端体验层还可以打磨的几个小细节推荐系统做完了前端展示层也有几个值得打磨的细节。比如在“猜你喜欢”列表中加入“不感兴趣”按钮用户点击后自动刷新推荐列表数据会反馈到后端行为表。这种主动反馈机制既是产品细节也是推荐系统优化迭代的数据输入。再比如一个加载骨架屏的设计。推荐接口因为涉及算法计算响应时间通常比普通接口要长一些如果页面在数据返回前是一片空白用户体验会很差。用Vue的v-if控制推荐区域的组件状态在数据加载中显示灰色骨架占位数据到达后再渲染真实内容这比一个简单的loading转圈要有质感得多。还有推荐理由标签的展示优化。推荐接口返回的recommendReason字段可以进一步细分比如基于相似用户推荐显示“和你兴趣相投的人都在看”基于热门兜底推荐显示“大家都在抢购”基于同分类推荐显示“你喜欢的分类又上新了”。这些文案上的小差异能让用户更清晰地感知到推荐系统的存在价值也让整个首页的个性化氛围更浓。回到项目本身这套系统的架构能力、推荐算法的工程落地能力、前后端联调的熟练度都是真实可复用的项目经验。如果你正在准备毕业设计按这条路线做下来从数据库设计到算法实现再到部署上线走通一遍之后你对一套业务系统的完整生命周期会有很扎实的体感。