企业官网建设流程全解析

1. 项目全景拆解：当SpringBoot、小程序和大数据凑到一起

1.1 这个项目到底在做什么

先说结论：这是一个典型的前后端分离 + 推荐系统落地的全栈项目，技术关键词是SpringBoot、微信小程序和大数据。它做的核心事情是——让用户打开小程序后，能看到一个“懂你口味”的外卖点餐界面，系统根据你过去的下单记录、浏览行为、菜品类别偏好，从成千上万个菜品里找出你大概率会点的那些，排到前面展示。

很多同学看到“大数据”这三个字就怕，觉得一定是Hadoop、Spark、Flink一整套分布式集群，没有8G内存16核CPU跑不起来。实际上在外卖点餐这个场景下，真正让系统“聪明”起来的东西，是一套完整的用户行为数据链路：用户看了什么、点了什么、加购了什么、在哪个时间段下单、倾向什么价位，这些数据被采集、清洗、分析最后变成推荐结果。大数据在这里更重要的是“思维方式”和“数据处理流程”，而不是非要堆出一套集群来。

从毕设的角度看，这个项目的定位也很精准：它同时覆盖了后端开发、小程序前端、数据库设计、推荐算法、数据可视化这几个模块。每一块都是可以单独拿出来讲半天的点，组合在一起就是一个结构完整、能演示、能答辩、能写进简历的项目。

1.2 为什么选这套技术栈（选型逻辑）

这个技术组合不是随便凑出来的，每一层都有它的合理性和不可替代性。

SpringBoot负责后端接口服务。它最大的价值是“开箱即用”，内置Tomcat、自动配置、starter机制，让你把精力放在业务逻辑而不是环境搭建上。相比传统的SSH框架，SpringBoot省掉了大量XML配置，同时也非常贴合企业级开发的主流技术栈。在一线开发中，SpringBoot + MyBatis Plus + MySQL这套组合基本是中小型项目的标配，拿去面试也不虚。

小程序负责用户端。选择微信小程序而不是独立APP，核心原因有两个：一是开发成本低，一套WXML + WXSS + JS就能跑起来，不需要上架应用商店、不需要考虑iOS和Android双端适配；二是微信生态自带用户体系和分享裂变能力，外卖点餐这个场景天然适合在微信里传播。毕设答辩的时候，老师掏出手机扫码就能看效果，比在电脑上装APK方便太多。

大数据板块则负责整个系统的“智商担当”。它的落地形态包括用户行为日志采集、订单数据统计分析、基于协同过滤的推荐算法、以及管理后台的数据可视化大屏。技术实现上不一定非要用分布式框架，但整个数据处理流程——从数据采集、清洗、特征提取到建模和推荐——是完整的大数据思维链路。

1.3 “大数据”在这个项目里的完整数据流

很多人做毕设最容易犯的错误是：数据库里建了几张表、用SQL查一下数据，就管自己叫“大数据项目”。答辩的时候老师一问数据量多大、怎么处理的，就答不上来。

真正的“大数据处理思路”是有一套完整链路的。在外卖点餐推荐这个系统里，整个数据流是这样的：

• 数据采集层：用户在小程序端的每一个关键行为（浏览商品、搜索关键词、点击菜品详情、加入购物车、提交订单、取消订单、收藏店铺）都会通过埋点接口记录到后端日志表或消息队列中。
• 数据存储层：原始行为日志存在日志表，业务数据（用户、店铺、菜品、订单）存在MySQL，统计结果和推荐结果可以存到Redis缓存，或者额外的中间表中，兼顾实时性和查询效率。
• 数据处理层：通过定时任务（如Spring的@Scheduled或者xxl-job）对行为日志进行清洗、汇总、分析，计算每个用户的偏好矩阵、每个菜品的被偏好度、相似度矩阵。
• 数据应用层：推荐算法基于处理好的偏好数据，为用户生成个性化菜品列表；管理后台基于统计结果渲染ECharts可视化图表。
• 数据反馈层：用户对推荐结果的点击、下单行为再次被记录，成为下一轮推荐的训练数据，形成闭环。

这套链路讲清楚之后，你的项目就已经比市面上80%的“假大数据毕设”要扎实了。哪怕数据量真的只有几千条，但你把这个处理框架搭起来了，老师看到的是一个完整的数据工程思维。

2. 核心推荐系统解析与代码落地

2.1 推荐系统在毕设里的合理定位

推荐系统是这个项目最大的亮点，也是最容易翻车的部分。很多同学一上来就想搞深度学习、搞神经网络，觉得这样才显得高级。但作为一个毕设项目，推荐系统的核心评价标准不是模型有多新，而是逻辑是否清晰、实现是否完整、效果是否可解释。

在外卖点餐场景下，用户的需求是“快速找到想吃的”，所以推荐策略应该围绕三个维度展开：

• 个性化偏好匹配：根据用户历史订单和浏览记录，推荐他常点的品类、口味和价位。
• 相似用户挖掘：找到“口味相似”的其他用户，把他们点过的、而你还没尝试过的菜品推荐给你。
• 热门与新品补充：避免推荐结果太“窄”，需要混入一定比例的全局热销菜品和新品，给用户新鲜感。

这三种策略正好对应了推荐系统领域最经典的三种算法思路：基于内容的推荐、基于用户的协同过滤、基于物品的协同过滤。毕设里面选协同过滤是最稳妥的，因为算法原理好讲、代码量可控、效果可见，而且面试的时候也是高频考点。

2.2 协同过滤的核心原理（通俗版）

协同过滤（Collaborative Filtering）的核心思想其实特别朴素：物以类聚，人以群分。

先看基于用户的协同过滤(UserCF：User Collaborative Filtering)。假设张三和李四都点过黄焖鸡米饭和麻辣香锅，说明两个人的口味比较接近。这时候李四又点了一份螺蛳粉，张三没点过，那系统就会把螺蛳粉推荐给张三——因为“口味相似的你喜欢的东西，你大概率也喜欢”。

再看基于物品的协同过滤(ItemCF：Item Collaborative Filtering)。它的逻辑反过来了，不是找相似的人，而是找相似的物品。比如大量点过“炸鸡”的用户同时也会点“可乐”，那这两样东西就被打上了“相似”的标签。以后用户在浏览炸鸡的时候，系统会自动把可乐附加上去。外卖平台上的“喜欢这道菜的人也点了……”就是典型的ItemCF。

两种策略的适用场景不太一样。用户量少的时候UserCF效果好一些，因为用户的行为数据更容易形成矩阵；物品数量少、用户量大的时候ItemCF效果更好。外卖点餐场景下，菜品数量通常远大于用户数量（对单一学校周边而言），所以我建议以ItemCF为主、UserCF为辅，这样计算量相对可控。

2.3 一个“能跑又好看”的推荐实现方案

下面直接给出一套可以落地的实现方案。这套方案我在实际项目中验证过，代码量不多，但效果和讲解空间都很好。

第一步：准备偏好数据矩阵

先通过SQL从订单表和浏览日志表统计出“用户-菜品”评分矩阵。评分规则可以这样定：

• 下单1次 + 3分
• 加入购物车 + 2分
• 浏览详情页 + 1分
• 收藏 + 2分

这个规则可以根据实际业务调整，但答辩时一定要能说出“为什么这么定”——低价值行为给低分，高转化行为给高分，这是评分设计的基本原则。

第二步：计算物品相似度

使用余弦相似度（Cosine Similarity）计算菜品之间的相似度。公式是：

similarity(A, B) = (A·B) / (|A| × |B|)

在代码里的实现思路是：

public double calculateSimilarity(Map<Integer, Double> itemVectorA, Map<Integer, Double> itemVectorB) { Set<Integer> commonUsers = new HashSet<>(itemVectorA.keySet()); commonUsers.retainAll(itemVectorB.keySet()); if (commonUsers.isEmpty()) { return 0.0; } double dotProduct = 0.0; double normA = 0.0; double normB = 0.0; for (Integer userId : itemVectorA.keySet()) { normA += Math.pow(itemVectorA.get(userId), 2); } for (Integer userId : itemVectorB.keySet()) { normB += Math.pow(itemVectorB.get(userId), 2); } for (Integer userId : commonUsers) { dotProduct += itemVectorA.get(userId) * itemVectorB.get(userId); } return dotProduct / (Math.sqrt(normA) * Math.sqrt(normB)); }

第三步：生成推荐列表

对用户u未购买过的菜品i，预测其偏好分数：

prediction(u, i) = sum( similarity(i, j) × rating(u, j) ) / sum( abs(similarity(i, j)) )

其中j是用户u已经评分过（点过）的物品。算完所有候选物品的预测分后，按分数从高到低取Top N（比如Top 10）推荐给用户。

这套算法的复杂量级是O(m×n×k)，其中m是物品数，n是用户数，k是平均评分物品数。当数据量真正大到单机算不动的时候，就可以引出Spark MLlib、分布式矩阵分解等进阶方案——这也可以作为论文里的“未来展望”，逻辑非常顺畅。

2.4 冷启动和数据稀疏问题怎么处理

这是推荐系统里最经典的两个问题，答辩时大概率会被问到，提前准备好回答思路。

冷启动问题指新用户没有任何行为数据，协同过滤无法计算。解决方案有三个层次：

• 给新用户默认推荐全局热销榜单（按照销量、评分、好评率综合排序）。
• 新用户注册时引导选择偏好标签（口味偏好：辣/不辣/清淡；品类偏好：中餐/西餐/快餐；价位偏好：10-20/20-30/30+），用标签匹配菜品。
• 用户产生少量行为后，立即切换到基于内容的推荐，再过渡到协同过滤。

数据稀疏问题指用户行为的交叉度太低，大部分用户只点过很少几个菜品，导致相似度矩阵中大量为0。解决方案是：

• 引入“类别降维”：不直接计算菜品和菜品的相似度，而是先算“品类”和“品类”的相似度，再映射回具体菜品。
• 使用“惩罚系数”降低过于热门菜品的影响，避免推荐的菜品都是人人都点过的爆款。
• 混合推荐策略兜底：当某用户可用的协同过滤数据不足时，自动降级为基于内容的推荐（根据菜品标签、口味、价格匹配）。

在代码实现中，可以设置一个“推荐策略路由”逻辑：

public List<Dish> recommend(Integer userId) { int userBehaviorCount = userBehaviorMapper.countByUserId(userId); if (userBehaviorCount < 5) { // 行为数据太少，走冷启动策略 return hotDishRecommendService.recommend(); } else if (userBehaviorCount < 20) { // 行为数据一般，走基于内容的推荐 return contentBasedRecommendService.recommend(userId); } else { // 行为数据充足，走协同过滤 return collaborativeFilterRecommendService.recommend(userId); } }

这个“分级路由”的思路在真实互联网产品中非常常见，也能体现你对推荐系统落地问题的理解深度。

3. 数据库设计与SpringBoot后端落地

3.1 多角色实体关系设计

外卖点餐系统涉及的实体包括用户端和管理端多种角色，数据库设计是否合理直接影响后续开发的效率。可以直接参考下面这张表结构清单。

这里最核心的设计要点是user_behavior表。它不是一个普通业务表，而是整个推荐系统的“数据粮仓”。每条用户行为都会实时落库，然后由定时任务定期将行为数据聚合到评分矩阵中。有了这张表，你后续做报表、做可视化、做数据统计全都顺手了。

dish_similarity表是推荐算法的加速神器。如果推荐请求来了才实时计算相似度，响应时间会非常难看。正确做法是：每天凌晨用定时任务把相似度矩阵算好存进这张表，推荐接口直接查表取数，毫秒级返回。

3.2 Redis在推荐系统里的角色

一个容易被忽略但非常加分的点是利用Redis加快推荐接口的响应速度。推荐结果有一个特点：同一用户短期内多次访问首页，推荐结果其实没必要每次重新计算。完全可以把推荐结果缓存起来，设置过期时间，例如2小时或者一天。

具体做法是：用户第一次请求首页推荐时，SpringBoot服务查数据库、跑算法、拿到Top N菜品列表，然后用用户ID作为key把菜品列表JSON序列化后存进Redis，并设置过期时间。后续请求直接从缓存读取，命中率可以做到很高。

当用户产生了新的下单/浏览行为后，可以主动删除对应缓存，让下次请求重新计算推荐结果，保证推荐内容及时反映用户最新偏好。这比单纯依赖过期时间要“聪明”得多。

对应SpringBoot的实现思路如下：

@Service public class RecommendService { public List<DishVO> getRecommendDishes(Integer userId) { String cacheKey = "recommend:user:" + userId; String cachedData = redisTemplate.opsForValue().get(cacheKey); if (cachedData != null) { return JSON.parseArray(cachedData, DishVO.class); } // 缓存未命中，走推荐算法 List<DishVO> recommendList = doRecommend(userId); redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(recommendList), 2, TimeUnit.HOURS); return recommendList; } }

大一统业务的同时还能体现你对缓存策略、Redis数据结构的掌握，这本身就是答辩的加分项。

3.3 登录鉴权与小程序身份打通

小程序端的登录流程和传统网页APP不太一样。小程序的登录核心是调用wx.login()获取code，然后用这个code去后端换openid。openid是用户在微信生态里唯一标识，后端通过它来识别具体是哪个用户。

安全上有个重要细节：不要把openid直接返回给小程序前端做身份凭证。正确做法是后端拿到openid后查数据库，找到或创建对应user记录，然后生成一个自定义的token返回给小程序。小程序后续的所有请求都在header里带这个token，后端用一个Interceptor（拦截器）统一校验token是否有效。

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/api/user/login", "/api/shop/list", "/api/dish/list"); } }

这里还涉及一个热词中提到的“小程序备案”信息。小程序在正式上线前，微信要求完成ICP备案，也就是说需要填一个备案备注，通常就是一句话描述这个小程序的服务内容，例如“提供校园周边外卖点餐及个性化菜品推荐服务”。毕设阶段部署体验版不需要备案，但如果以后真的想上线运营，这个流程是绕不开的，提前了解没坏处。

4. 前端小程序与可视化大屏的实现

4.1 小程序端功能结构与页面拆解

小程序端的页面结构直接对应了外卖APP的核心功能闭环。建议按下面的tabBar来组织：

• 首页（推荐流核心页面）：顶部搜索框 + 轮播图 banner + 推荐菜品列表。推荐列表是核心中的核心，需要用scroll-view做滚动分页加载，给用户流畅浏览体验。
• 分类页：按品类（快餐便当、烧烤夜宵、甜品奶茶、麻辣烫等）筛选菜品，配合左侧一级侧边栏 + 右侧二级菜品列表。
• 购物车页：已选菜品列表、数量加减、价格汇总、结算按钮。
• 订单页：订单列表按状态分类（待付款/待收货/已完成/已取消）。
• 我的页：个人信息、收藏列表、地址管理、口味标签设置、联系客服。

每个页面都对应一套后端接口，典型接口清单如下：

POST /api/user/login 微信登录 GET /api/dish/recommend 获取推荐菜品列表 GET /api/dish/category/{cid} 按分类获取菜品 GET /api/dishes/search?kw=xx 菜品搜索 POST /api/cart/add 加入购物车 POST /api/cart/update 修改购物车数量 POST /api/cart/clear 清空购物车 POST /api/order/create 创建订单 GET /api/order/list?status=x 获取订单列表 POST /api/order/cancel 取消订单 POST /api/collect/add 收藏/取消收藏 GET /api/behavior/report 行为上报

关于“小程序动态设置标题”这个高频搜索点，实现起来其实很简单：调用小程序的wx.setNavigationBarTitle()方法，在onLoad里根据当前页面参数动态改标题。比如从分类页进入一个店铺时，可以把这个店铺的名字设为标题，体验会好很多。代码就是这样一行：

wx.setNavigationBarTitle({ title: '老王烧烤 - 外卖点餐' });

如果要在分享卡片里也显示特定标题，需要在onShareAppMessage里设置title字段。

4.2 数据可视化大屏怎么做

管理后台的数据可视化是整个项目里视觉冲击力最强、答辩最出效果的部分。技术选型推荐SpringBoot + ECharts，再套一个AdminLTE或自己写一个简单管理页面模板即可。

可以部署这几个核心图表：

• 近7日订单趋势图：折线图，X轴日期，Y轴订单量，直观展示业务增长情况。
• 菜品销量Top10排行榜：横向柱状图，一眼看出爆款菜品。
• 用户消费金额分布：饼图/环形图，展示不同消费区间用户占比。
• 分类销售占比：如饼图，展示快餐、甜品、烧烤等类别的销量占比。
• 时段下单热度图：柱状图，展示一天24小时的订单分布，可以看出中餐和晚餐两个高峰。

ECharts的数据来源接口也很直白：

@RestController @RequestMapping("/api/statistics") public class StatisticsController { @GetMapping("/daily-orders") public Result getDailyOrders() { // 按日期分组统计订单数 List<Map<String, Object>> list = orderMapper.selectOrderCountByDate(); return Result.success(list); } @GetMapping("/top-dishes") public Result getTopDishes() { // 按销量/热度取前10菜品 List<Dish> topDishes = dishMapper.selectTopBySales(10); return Result.success(topDishes); } }

把接收到的JSON数据喂给ECharts，图表就出来了。前端管理后台的开发量不算大，但它直接决定了答辩演示的“第一眼观感”。务必花时间把管理后台的UI和布局做得清爽一点，至少比普通表格多花一点心思。

4.3 地理位置与配送逻辑的处理

外卖点餐这个场景绕不开“配送”的话题。小程序可以通过wx.getLocation()获取用户当前位置，再把经纬度传给后端，后端匹配出当前位置附近一定范围内（比如3公里内）的商家。

附近商家的计算可以用MySQL原生的ST_Distance函数或者手动用Haversine公式：

distance = 2 × R × arcsin( sqrt( sin²((lat2-lat1)/2) + cos(lat1) × cos(lat2) × sin²((lng2-lng1)/2) ) )

其中R是地球半径，取6371公里。如果用户没授权地理位置，就默认展示全量商家。这个功能的代码量很小，但却能体现出你对实际业务场景的理解。

顺带提醒一个细节：清单里的搜索热词有“app字体设置”。小程序里全局设置字号，可以在app.json里配置"style": "v2"，然后用wx.getSystemInfo获取系统字体大小设置，针对字体放大的用户做好适配，避免页面文字溢出。这种小细节往往是大厂技术面试时喜欢问的“用户体感”问题。

5. 毕设答辩与远程调试避坑实录

5.1 数据量不足，推荐效果出不来怎么办

这是毕设项目里最扎心的一个场景：推荐算法辛辛苦苦写完了，结果库里只有30个测试用户、50个菜品、200条订单，算出来的相似度矩阵效果惨不忍睹，推荐出来的菜品看起来完全“不智能”。

解决这个问题的思路有两条线。

第一条线是造数据。可以写一个Mock数据生成器，模拟生成100个用户、200个菜品、每个用户10~30条行为数据，数据量达到几千条甚至几万条。造数据不是随便造，要注意逻辑合理性——用户的行为偏好要符合某种消费习惯。比如给用户A生成的订单里60%是川湘菜，那么浏览行为里川湘菜的比例也应该偏高；价格都落在15~30元区间。这样推荐算法算出来的结果才“像回事”，演示的时候才有说服力。

第二条线是展示策略。演示推荐效果时，不要只展示一个平面的推荐列表。可以故意找一个偏好特别明显的用户（比如全是湘菜订单的用户），展示给他推荐的湘菜比例明显高于其他用户，再对比一个口味清淡的用户，两者推荐结果形成鲜明差异。这样对比演示的逻辑远比“我的推荐准确率是95%”这种数字更有冲击力。

5.2 远程调试常见问题排查

“远程调试”是毕设交付时最耗心力的环节之一，因为你的代码跑在别人电脑或者服务器上，各种环境问题像开盲盒一样不可预知。根据经验，远程调试中最容易翻车的有以下几个点：

每次远程调试之前，先把对方的JDK版本、MySQL版本、Redis版本、端口占用情况全部问清楚，能省下一个下午的时间。还有一个细节：代码里所有绝对路径（比如上传图片保存的目录、日志文件路径）都改成相对路径，或者由配置文件去注入，不然换一台电脑就跪。

5.3 让答辩老师理解“大数据”的讲解话术

答辩环节最重要的能力是“把复杂的东西讲简单”。面对不同背景的老师，侧重点也要不一样。

如果老师是软件工程方向的，重点讲架构设计和技术选型：为什么要用SpringBoot、为什么用协同过滤而不是深度学习（数据量达不到深度学习的要求，协同过滤在中小规模数据下效果更好且可解释性更强）、表结构怎么设计的、缓存策略怎么做的。

如果老师是数据科学方向的，重点讲数据处理流程和算法细节：评分矩阵怎么构建的、相似度用什么公式算的、冷启动怎么解决的、数据稀疏怎么降维处理的。

如果老师是做业务的，重点讲系统解决了什么问题：用户点外卖时面对几百个菜品有选择困难，系统通过分析历史偏好帮他快速找到想吃的；商家可以通过系统洞察用户偏好，优化菜品排序和菜单结构。

准备2~3张清晰的技术架构图、数据流图，比背半个小时的稿子有效得多。图要自己画，不要直接贴网上找的模板，老师问到细节你答不上来就尴尬了。

提示：论文里的“大数据”章节，不要写一堆不相关的大数据发展史空话。直接写你项目里数据的采集方式、数据格式、存储方案、分析流程、应用结果，每句话都紧扣自己的系统，这才是论文评审老师想看到的。

5.4 常见问题速查表

最后整理一份我在开发这类项目时反复遇到的坑，收藏一下，能少走很多弯路。

• MyBatis Plus 分页失效：记得配置MybatisPlusInterceptor并添加PaginationInnerInterceptor，不然分页查询永远是全量数据。
• 小程序图片不显示：开发阶段在详情工具里勾选“不校验合法域名”，生产环境把图片上传到服务器并且使用HTTPS域名。
• 定时任务不执行：确认@Scheduled所在的类是否被Spring扫描到、是否在启动类上加@EnableScheduling。
• 局部会话失效：在做登录拦截时，排除掉所有不需要登录的URL，否则小程序第一次加载首页时会因为token不存在而报401。
• 大JSON传输慢：后端返回的菜品列表不要每次都把详情字段查全，列表接口只返回必要字段，详情接口再全量返回。
• Redis数据序列化乱码：配置RedisTemplate时用Jackson2JsonRedisSerializer或者FastJson的序列化方式，不然存进去是Java对象二进制，读出来是乱码。
• 多数据源事务问题：如果推荐计算涉及的写操作分散在多张表，用@Transactional统一管理；尤其注意在类内部调用this.xxx()时事务是不生效的。

6. 从“毕设能过”到“项目能打”的扩展思路

6.1 低成本高性价比的加分项

如果你做完基础功能后还有富余时间，下面几个方向投入产出比极高。

引入RabbitMQ做异步解耦。用户的行为上报接口如果每次都是同步写库，高峰期会拖慢主流程的响应速度。可以把行为写入MQ，后端用消费者异步落库。这既提升了接口性能，也让你在简历上多了一个“消息队列”的技术点。代码量不大，但面试时说到“为什么用MQ”就能展开讲一大段。

增加WebSocket实时通知。用户下单后，商家管理后台实时收到新订单提醒，不用刷新页面。这个小功能用SpringBoot的WebSocket实现，工作量不大，但演示效果特别“动感”，老师会觉得你的系统很鲜活。

引入Redis缓存店铺和菜品热点数据。这两个表属于读多写少的高频访问数据，做缓存后能显著减轻MySQL的压力，技术上来讲也符合真实系统的缓存设计思路。可以在答辩时给老师展示一个对比数据：缓存命中前后，接口响应时间从500ms降到了50ms，直接量化体现优化效果。

做一个A/B测试对比展示页面。管理后台同时展示“个性化推荐”和“热门排序”两个列表在相同用户上的差异，并用点击率指标对比两者效果。这会让你的项目在数据驱动决策这个维度上提升一个档次。

6.2 扩展成“真大数据”的演进路线

这个部分不用真的在毕设里做出来，但论文的“展望”章节或者面试场景下，如果你能说清楚演进路径，会让人觉得你是一个有架构视野的人。

当数据量增长到MySQL单机扛不住的时候，演进路线大致是：

• 存储层：MySQL做主从分离 + MyCat/ShardingSphere分库分表；行为日志迁移到HBase或者ClickHouse。
• 计算层：离线统计用Hive + Spark SQL跑批；相似度矩阵用Spark MLlib里的分布式协同过滤替代单机版本。
• 实时层：用户行为通过Kafka接入，Flink做实时特征计算，把热门榜、实时偏好结果写回Redis缓存。
• 算法层：当数据量足够时引入ALS交替最小二乘法做矩阵分解，或者用DeepFM一类深度推荐模型做排序。

这个演进路线不必全部实现，但答辩或面试时能把“当前阶段遇到的问题”和“下一阶段的解决方案”对应起来，会给人留下非常深刻的印象。

6.3 关于项目定制的最后一点建议

如果你不是从头开发，而是基于获取到的参考项目进行“定制”和“二次开发”，切记不要把别人的项目原封不动交上去。至少做到以下三点：

第一，跑通项目之后，把数据库表结构调整一两处（比如增加一个字段或一张新表），并同步修改对应的后端代码和前端页面，做到“从数据库到接口到页面”全链路通畅。

第二，给自己增加一个别人没有的小功能模块，比如“口味偏好标签设置”“好友分享点单”“营销优惠券系统”。不用多，一个就够，但这个功能最好要贯穿三层（表结构、后端接口、前端页面），这样讲解的时候从需求、设计到实现有完整的叙事线。

第三，把代码全部过一遍，确保每个文件你都看得懂。答辩现场最怕的是老师随便点开一个类文件，问你这个方法做了什么，结果你支支吾吾说不出所以然，前面的印象分全部归零。

我在开发类似项目时的体会是：毕设项目最大的价值不在于技术多牛，而在于你能否把一个完整的业务闭环讲清楚，并让听的人相信这里面确实有你自己的思考。与其堆砌十个你讲不明白的技术名词，不如把一个推荐逻辑讲透，把一个缓存策略讲明白，把一条数据链路讲顺畅。能做到这一点，这个项目已经不仅仅是“能过”，而是会成为你简历上真正能打的亮点。

最后再分享一个小技巧：把项目里所有接口的@Api注解用起来，生成一套完整的Swagger接口文档。演示的时候打开Swagger页面给老师看，几十个接口分门别类列在那里，比你说一万句“功能完善”都有说服力。而且面试的时候，知道用Swagger做接口管理和联调，本身就是一线开发的基本素养。