每年到毕业设计季总有一批人卡在选题上纯做商城没亮点纯做算法没工作量。我最近带着学生复现了一套东北特产销售系统正好把两边都补上了——SpringBoot Vue MySQL 做完整的电商闭环协同过滤算法单独成一个推荐模块另外源码、数据库、论文、部署文档都是整理好的。这篇就围绕这套系统把从选题思路、算法落地到跑起来部署的每个关键点拿出来唠一遍。先说结论这套项目拿去应付毕业设计绰绰有余而且不是那种“只能演示”的花架子推荐模块的核心矩阵计算代码是可以现场给老师讲清楚的。后面我按五个部分展开分别是选题逻辑、算法实现、数据库与业务编码、部署联调、答辩避坑。1. 项目选题与整体技术架构1.1 这个题目的核心价值在哪里很多同学选毕设题容易走两个极端要么选个“网上商城”这种太普通的题目功能做完老师觉得没技术含量要么选个“基于深度学习的某某推荐系统”听起来高大上结果自己连环境都搭不起来最后论文全靠编。这套东北特产销售系统比较好的地方在于它踩在了一个平衡点上。商城部分覆盖了用户注册登录、商品浏览、购物车、下单、订单管理、后台商品维护这些常规闭环工作量很扎实。推荐模块又引入了协同过滤算法不是只做一个“猜你喜欢”的空壳页面而是真正有相似度计算、有推荐打分、有TopN排序。东北特产这个垂直品类也选得聪明商品数量不用多几十条就能把推荐效果展示出来比那种动辄上千条SKU的通用商城更容易把算法跑出声。对想拿这套项目做参考的人来说它的覆盖面足够全前端有Vue页面后端有SpringBoot接口数据层有MySQL设计算法层有协同过滤落地交付物里还有论文框架和部署文档。换句话说无论你是要照着改一个相似题目还是想理解一套完整项目的组织方式都能从里面找到可以直接用的东西。1.2 技术栈选型背后的真实逻辑这套项目的技术栈是典型的“毕业设计黄金组合”选型理由很实际技术版本用在哪个环节为什么选它SpringBoot2.7.x后端基础框架配置少、内嵌Tomcat、开箱即用Vue 22.6.x前端页面组件化开发、上手曲线低、案例多Element UI2.15.x前端UI组件表格、表单、弹窗直接拿来用MySQL5.7 / 8.0数据存储稳定、免费、教程满天飞MyBatis-Plus3.5.x持久层内置通用Mapper避免手写大量SQLMaven3.8.x后端构建标准Java项目构建工具这里有个细节值得说为什么不用SpringCloud因为毕设的体量根本不需要分布式硬上注册中心、网关、配置中心只会给自己挖坑。老师问起来“你这个项目用分布式干嘛”反而不好回答。为什么前端不用Vue3不是Vue3不好而是目前大量毕业设计参考代码、Element UI适配版本都集中在Vue2上遇到问题随手能搜到答案对赶时间的同学来说稳定压倒一切。架构上就是标准的前后端分离后端跑在8080端口提供RESTful接口前端跑在8081端口通过代理转发请求。没有复杂的服务调用链路没有消息队列也没有微服务拆分但这个组合刚好能把一个完整的业务系统讲清楚。2. 协同过滤推荐算法怎么落到商城业务里2.1 基于物品还是基于用户这是个选择题协同过滤分两类基于用户的协同过滤UserCF和基于物品的协同过滤ItemCF。很多教程把它们讲得云里雾里我用大白话说UserCF的思路是“物以类聚人以群分”。找到和你兴趣相似的一批用户看他们买了什么推荐给你。适合用户数量不多、用户兴趣变化快的场景比如资讯类App。ItemCF的思路是“买了A的人还会买B”。先算商品之间的相似度再根据你历史买过的商品推荐和它们最相似的商品。适合商品数量相对稳定、用户数量远大于商品数量的电商场景。这套系统选择的是ItemCF原因有三条。一是电商场景里商品之间的“关联购买”关系比较稳定东北特产里大米和杂粮、蘑菇和木耳天然存在搭配购买的倾向这种关系用共现次数就能捕捉。二是ItemCF推荐结果的可解释性好页面可以明确展示“因为你看过长白山木耳所以推荐东北榛蘑”老师一看就知道算法是怎么工作的。三是ItemCF的物品相似度矩阵可以离线计算线上推荐时只需要查矩阵累加打分响应速度快。2.2 相似度计算公式和一次手算演练ItemCF的第一步是计算任意两个商品之间的相似度。最常用的是余弦相似度w(i,j) |N(i) ∩ N(j)| / sqrt(|N(i)| × |N(j)|)其中N(i)是购买或行为过商品i的用户集合|N(i) ∩ N(j)|是同时行为过商品i和商品j的用户数。这个公式的含义不复杂两个商品被同一批用户喜欢得越多它们就越相似同时除以各自的行为用户数开根号是为了避免热门商品和谁都像。举个例子。假设有5个用户商品1被A、B、C三个用户买过商品2被A、B、C、D四个用户买过商品3只被A买过。那么w(1,2) 3 / sqrt(3×4) ≈ 0.866 w(1,3) 1 / sqrt(3×1) ≈ 0.577算出来以后商品1和商品2的相似度明显高于商品1和商品3推荐排序时商品2会排到前面。这就是整套推荐逻辑最核心的地基。放到工程实现里面不能真的每算一个相似度都去遍历用户行为表。常见做法是先扫描所有用户行为数据构建“用户到商品集合”的倒排结构然后对每个用户行为过的商品做两两组合累加共现次数得到一个共现矩阵再用余弦公式归一化。2.3 推荐打分逻辑与Java代码实现商品相似度矩阵算好之后给某个用户生成推荐列表就很直接了。流程分四步取出该用户行为过的商品集合N(u)不同行为类型给不同权重浏览1分、收藏2分、加购3分、购买4分。遍历N(u)里的每个商品i从相似度矩阵中取出与i最相似的若干商品j。对每个候选商品j累加得分score(j) Σ w(i,j) × r(u,i)其中r(u,i)是用户对商品i的行为权重。过滤掉用户已经行为过的商品按得分从高到低排序取前N个。核心代码可以浓缩成这样一个方法public ListLong recommendByItemCf(Long userId, int topN) { // 1. 取用户历史行为商品key为商品IDvalue为行为权重 MapLong, Double userItems behaviorMapper.selectUserItemsWithWeight(userId); if (userItems.isEmpty()) { // 冷启动兜底返回热门商品 return goodsMapper.selectHotGoodsIds(topN); } // 2. 遍历历史商品累加候选推荐商品得分 MapLong, Double scoreMap new HashMap(); for (Long itemId : userItems.keySet()) { ListItemSim simItems itemSimService.getTopSimItems(itemId, 50); for (ItemSim sim : simItems) { Long candId sim.getGoodsId(); // 过滤掉用户已经行为过的商品 if (userItems.containsKey(candId)) { continue; } double score sim.getSimScore() * userItems.get(itemId); scoreMap.merge(candId, score, Double::sum); } } // 3. 按得分降序取TopN return scoreMap.entrySet().stream() .sorted((a, b) - Double.compare(b.getValue(), a.getValue())) .limit(topN) .map(Map.Entry::getKey) .collect(Collectors.toList()); }代码不长但注意三个细节。第一个是行为权重设计如果只用0/1表示“有没有买过”推荐结果和热销榜区别不大引入浏览、收藏、加购、购买四档权重以后才能体现“用户加购了但没买”这种强意向信号。第二个是过滤逻辑必须放在累加之前否则用户买过的商品因为和自己相似度极高会反复出现在推荐结果里。第三个是冷启动兜底新用户没有任何行为数据时直接返回热门商品列表保证接口有数据返回、页面不为空。2.4 计算时机与性能取舍算法实现清楚了接着要解决“什么时候算”的问题。最粗暴的方案是每次请求推荐接口时现算但这样每次都要全表扫描行为数据、重建共现矩阵数据量稍微大一点就会把接口拖死。项目里的实际做法是定时离线计算。启动的时候加载一次相似度矩阵放到内存里然后每隔一段时间重新计算。数据量小的时候可以用Scheduled定时任务实现数据量大了以后换成消息队列或者分布式计算框架但那是后话毕设阶段定时任务完全够用。这个思路在论文里也能体现你考虑了性能问题而不是只会调接口。3. 数据库设计与前后端核心实现3.1 表结构设计要点数据库是整个系统的基础这套项目的表数量控制在合理范围内没有过度设计。核心表有这么几张表名核心字段职责userid, username, password, nickname, phone, avatar, create_time用户账号信息goods_categoryid, name, sort商品分类goodsid, category_id, name, main_image, price, stock, sales, status, detail商品信息cartid, user_id, goods_id, quantity, checked购物车ordersid, order_no, user_id, total_price, status, address_id, create_time订单主表order_itemid, order_id, goods_id, goods_name, goods_price, quantity订单明细user_behaviorid, user_id, goods_id, behavior_type, create_time用户行为记录addressid, user_id, receiver, phone, province, city, detail收货地址两个容易踩坑的点说一下。第一个是行为表。很多同学做推荐系统直接拿订单表当行为数据源这样不是不行但损失了大量信息。用户浏览了商品没买、收藏了没下单、加入购物车又删掉这些都是珍贵的信号。单独建一张user_behavior表用behavior_type字段区分行为类型推荐算法才有足够的数据去计算相似度。行为表的索引也很重要user_id和goods_id上都要建索引因为相似度计算要反复按用户和按商品查数据。第二个是订单表的价格字段。商品价格会变动订单明细里必须冗余存一份goods_name和goods_price不能下单之后再通过商品表关联查价格否则改价会影响历史订单。3.2 后端接口设计清单后端按业务模块划分Controller每个模块职责单一。接口清单大致如下模块接口方法说明用户/api/user/registerPOST注册用户/api/user/loginPOST登录返回token用户/api/user/infoGET获取当前用户信息商品/api/goods/listGET分页查询支持分类和关键字商品/api/goods/{id}GET商品详情购物车/api/cart/addPOST加入购物车购物车/api/cart/listGET购物车列表订单/api/order/submitPOST提交订单订单/api/order/listGET订单列表推荐/api/recommend/{userId}GET给用户生成推荐列表推荐/api/recommend/similar/{goodsId}GET查询和指定商品相似的商品登录这块要注意密码安全问题不要明文存储。项目里用的是BCrypt加密注册时加密入库登录时用BCryptPasswordEncoder.matches校验。比MD5和SHA-256更稳妥因为自带随机盐就算两个用户密码相同密文也不一样。这个细节在答辩时老师问到安全方面能加分不少。统一返回结构也值得养成习惯。定义一个泛型Result类里面放code、message、data三个字段所有接口都返回这个结构。前端拿到响应后统一判断code不用每个接口单独处理错误分支代码会清爽很多。3.3 前端Vue页面组织前端用的Vue2加Element UI页面结构围绕电商主流程设计。前台包括首页、商品列表、商品详情、购物车、订单确认、订单列表、个人中心后台管理端包括商品管理、订单管理、用户管理、数据看板。这里重点说推荐模块怎么展示。首页设计一个“猜你喜欢”区域数据来自/api/recommend/{userId}接口。在商品详情页底部再放一个“看了又看”的相似商品推荐调/api/recommend/similar/{goodsId}接口。这两个入口的好处是能直观展示算法效果——用户随便逛两个商品刷新首页推荐列表就会变化。前端还有两个关键工程配置。第一个是axios拦截器请求发出前从localStorage取token放到请求头里响应回来时如果code是401跳回登录页。第二个是跨域代理在vue.config.js里配置module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样前端请求/api/goods/list时开发服务器会自动转发到后端的8080端口绕开浏览器跨域限制。4. 从0到1部署运行的完整流程4.1 环境准备清单部署文档里第一步就是环境安装。版本对应关系捋清楚照着装就不会出问题组件版本要求说明JDK1.8SpringBoot 2.7默认兼容Maven3.6后端依赖管理Node.js16.xVue CLI运行环境MySQL5.7或8.0数据库IDEA2020后端开发IDENavicat任意版本数据库可视化工具前端还可以选装VSCodeIDEA装一个Vue插件也能凑合写前端看个人习惯。4.2 后端启动三步走第一步是初始化数据库。打开Navicat新建一个名为techan_system的数据库字符集选utf8mb4然后运行项目附带的techan_system.sql脚本。脚本里包含了建表语句和几千条基础数据商品、用户、行为记录都有省去了手动造数据的功夫。第二步是修改配置文件。打开application.yml把数据库地址、用户名、密码改成自己本机的配置。MySQL 8以上还要确保驱动类写的是com.mysql.cj.jdbc.Driver并且url里带上时区参数spring: datasource: url: jdbc:mysql://localhost:3306/techan_system?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver第三步是启动服务。两种方式都行在IDEA里直接运行主类或者在项目根目录执行mvn spring-boot:run。看到SpringBoot的启动日志、端口显示8080后端就起来了。4.3 前端启动与联调演示后端起完接着起前端。在项目目录下运行npm install安装依赖然后npm run serve启动开发服务器。浏览器访问http://localhost:8081能看到首页说明前后端已经打通。演示路线建议这样走效果最顺注册一个新账号登录。随便浏览几件商品把其中一两件加入购物车。提交一个订单模拟购买行为。回到首页往下拉到“猜你喜欢”这时推荐列表已经能看出偏好。管理端登录进去把订单状态改成已发货。这里的重点是顺序不能反。先产生行为数据再去看推荐结果。如果一上来就点推荐行为表是空的返回的就是热门商品兜底数据老师会以为推荐模块没生效。打包发布的时候后端用mvn clean package打成jar包java -jar运行前端用npm run build生成dist目录扔到Nginx里再把/api路径反向代理到8080端口就完成了生产环境的部署路径。5. 避坑指南与论文答辩备战5.1 高频问题的排查清单帮学生调试这套项目的时候遇到的坑来来回回就那么几个直接整理成清单式排查表现象大概率原因处理方法后端启动报数据库连接失败数据库账号密码不对或url写错核对application.yml配置控制台报ClassNotFoundException: com.mysql.cj.jdbc.DriverMySQL Connector版本和数据库版本不匹配检查pom.xml中的mysql依赖版本前端请求接口报404代理配置没生效或后端没启动重启前端dev server确认后端8080在跑查询中文乱码表和连接串不是utf8mb4建库时选utf8mb4url带characterEncoding推荐接口返回空列表行为表数据太少或没做热门兜底检查user_behavior数据量确认兜底逻辑打包时内存溢出Maven或Node的heap设置太小加大构建内存参数有一个坑特别值得强调很多同学用MySQL 8然后在pom里不加版本号Maven拉取的旧驱动类名是com.mysql.jdbc.Driver启动直接报驱动类找不到。解决方法是把依赖版本号显式加上并改成新驱动的类名。5.2 论文结构安排这篇项目配套的论文框架可以直接参考章节划分很清晰章节核心内容第1章 绪论选题背景、国内外研究现状、论文组织结构第2章 相关技术介绍SpringBoot、Vue、MySQL、协同过滤算法第3章 需求分析功能性需求、非功能性需求、用例分析第4章 系统设计总体架构、功能模块、数据库设计、推荐算法设计第5章 系统实现前后端关键模块实现配页面截图和核心代码第6章 系统测试功能测试用例、测试结果分析论文不需要写得像学术期刊那么深但一定要能自圆其说。特别是推荐算法那一章从算法原理、公式推导、代码实现到实验对比这条线要完整。很多同学论文里贴了代码却没有讲清楚数据从哪来、算出的结果怎么验证答辩时一问一个准。5.3 答辩高频提问的应答思路结合这几年的经验答辩老师对这类题目的提问其实很固定提前准备好人就能稳问1为什么用协同过滤而不用其他推荐算法回答思路协同过滤是推荐系统中应用最广泛的经典算法之一不依赖商品内容和用户画像只需要用户行为数据就能产生推荐。在商品特征标注不全、用户画像不完善的场景下协同过滤的数据要求更简单落地成本更低。问2为什么选基于物品而不是基于用户回答思路电商场景的特点是用户数量远大于商品数量基于物品的协同过滤计算的是商品之间的相似度矩阵商品相对稳定矩阵可以离线计算线上推荐速度快。同时基于物品的推荐结果解释性强用户可以理解“为什么推荐这个”。问3冷启动问题怎么处理回答思路新用户没有行为数据时用热门商品TopN兜底新商品没有行为数据时通过商品分类、标签等属性计算基于内容的相似度把它推荐给可能感兴趣的用户。项目里已经实现了热门商品兜底逻辑。问4如果数据量达到百万级以上这套方案还成立吗回答思路当前方案的关键瓶颈在相似度矩阵的计算规模。横向扩展的思路是把离线计算改为分布式计算框架处理线上相似度结果放入Redis缓存推荐接口只做查询和打分不再实时计算全量矩阵。这些问题的核心不在于答案多完美而在于你要真的把项目的代码打开指着某一段说“这就是处理冷启动的地方”“这是算余弦相似度的代码”。老师想看的是你有没有亲自做过而不是背了一堆理论。写在最后这套项目带完我最大的感受是——毕设其实不追求“新”追求的是“闭环”。电商业务闭环加上算法闭环每一块都能讲清楚答辩就有底气。当时A同学把推荐模块的日志打开一条条对数据发现新用户点“猜你喜欢”一直返回空就是因为行为表里没数据热门兜底逻辑没接上改完之后演示一遍过。后来每次跑推荐前我都让他先确认行为表有没有数据眼见为实。如果你也准备拿这套框架做类似的题目建议先把行为埋点做扎实推荐效果好不好很多情况下不是算法不行是数据没喂够。另外部署文档里的每一步我都建议自己重新走一遍别直接复制粘贴命令走的过程中踩过的坑回头都会变成论文里的测试用例和答辩时的谈资。