简介一款基于Spring Boot的智能推荐点餐系统设计与实现完整项目适合正在学习Spring Boot整合开发、推荐算法落地及餐饮系统设计的开发者。项目采用前后端分离架构业务逻辑涵盖登录、点餐、支付等核心流程并利用协同过滤或基于内容的推荐算法依据用户历史订单与浏览行为生成个性化菜品推荐。资源包大小约107.95MB包含开发说明文档、操作演示视频、项目源码及PPT演示文稿等材料可系统了解从环境搭建到项目部署的关键环节。目前已有78人浏览学习。开发者可结合源码和文档快速搭建运行环境理解系统分层与推荐模块实现观看演示视频可直观掌握用户注册、菜品浏览、点餐推荐等完整操作PPT与常见问题说明则有助于梳理设计思路、应对部署中的典型问题是深入实践Spring Boot与智能推荐系统的理想参考。1. SpringBoot智能推荐点餐系统把“人找菜”变成“菜找人”中午打开点餐小程序菜单翻了三屏还没决定餐厅老板看着后厨数据想知道哪些菜该置顶、哪些菜适合推给哪类客人。智能推荐点餐系统做的事就是把“人找菜”倒过来变成“菜找人”。它不是一个普通的管理后台核心在“智能推荐”四个字上根据用户历史点餐记录、菜品共现关系和菜品本身属性实时算出一份带个人偏好的菜单排序再通过SpringBoot框架暴露成接口供前端调用。对开发者来说这是理解SpringBoot集成推荐算法最合适的载体。它不需要引入Spark、Flink这类重组件纯靠JVM内存和标准SQL就能跑通完整的协同过滤流程。对准备做毕业设计、或者想从CRUD转向推荐方向的Java工程师这套系统的技术密度刚刚好——算法逻辑不复杂到劝退工程化程度又足够写进简历。2. 推荐算法选型Slope One、物品协同过滤与TF-IDF在点餐场景的取舍2.1 点餐数据只有隐式反馈矩阵分解容易过拟合点餐系统的反馈和电商评分不一样。用户不会在点餐页给每道菜打五星系统拿到的真实信号只有一个点过、没点过、点了几次。这是典型的隐式反馈。用显式反馈算法处理时矩阵里的空值并不是“用户不喜欢”而是“用户没机会尝试”。如果直接用SVD做矩阵分解空值补零会引入极大偏差训练出来的隐向量往往把热销菜和任何用户都算得“相似”个性化反而消失。Slope One的优势在数据稀疏时反而更明显。它不试图刻画用户或物品的隐向量只统计一个统计量同一用户点过的两道菜评分差平均是多少。这个差值矩阵可以用一条SQL聚合出来也能在内存里用双重循环构建天然支持增量维护——新来一条评分只需要更新涉及到的物品对。提示如果你的用户-物品矩阵填充率低于5%不要一上来就上矩阵分解。先用简单模型跑通闭环再谈精度。2.2 Slope One原理物品间的平均偏差是推荐的全部依据Slope One的核心假设很朴素用户对物品j的评分大概率等于“用户对物品i的评分”加上“i与j在所有用户眼中的平均偏差”。加权预测公式如下pred(u, j) Σ [ (dev(i,j) r_ui) × freq(i,j) ] / Σ freq(i,j) 其中 i ∈ R(u)R(u) 是用户u点过的菜品集合 dev(i,j) 所有同时点过i和j的用户对i的评分减对j的评分的平均值 freq(i,j) 同时点过i和j的用户数freq(i,j)是权重同时点过两道菜的用户越多这个平均偏差越可信。实现时不需要真的造一个密集矩阵一条SQL就能把偏差矩阵算出来SELECT a.dish_id AS item_a, b.dish_id AS item_b, AVG(COALESCE(a.rating / 5.0, 0.5) - COALESCE(b.rating / 5.0, 0.5)) AS dev, COUNT(*) AS freq FROM order_item a JOIN order_item b ON a.user_id b.user_id AND a.dish_id b.dish_id WHERE a.created_at DATE_SUB(NOW(), INTERVAL 90 DAY) GROUP BY a.dish_id, b.dish_id HAVING COUNT(*) 3;dish_id b.dish_id保证每对菜只统计一次HAVING COUNT(*) 3是数据质量闸门——只点过一次的偶然共现没有统计意义。这条SQL导出的结果可以直接接Excel验证数据形态再决定要不要写进Java代码。用户评分优先用订单里的rating字段归一化到0~1没评分时用点餐频次映射点一次0.5点两次0.8三次及以上1.0。2.3 用Jaccard相似度做物品协同过滤物品协同过滤的直觉是经常被同一桌点到的菜是“搭子”。比如“水煮鱼”和“酸梅汤”共现次数高推荐水煮鱼时自然带上酸梅汤。Jaccard相似度是处理共现关系最稳的度量sim(i, j) |U(i) ∩ U(j)| / |U(i) ∪ U(j)|分子是同时点过i和j的用户数分母是点过i或j的用户总数。Jaccard天然惩罚热门菜——如果一道菜被所有人点过分母巨大相似度被压低这恰好符合“推荐要有惊喜感”的需求。实现时维护一张用户→菜品集合的哈希表双重循环求交集占比时间复杂度O(n²)n是用户平均点过的菜品数常见系统里n不超过50性能完全能接受。2.4 TF-IDF内容画像解决新菜品冷启动协同过滤对“零行为”的新菜完全无能为力此时需要走内容推荐。把“菜名描述分类名”拼成文档例如“麻辣 水煮鱼 川菜 花椒 豆芽”分词后计算TF-IDF向量再算余弦相似度public MapString, Double tfidf(ListString words, MapString, Integer df, int totalDocs) { MapString, Integer tf new HashMap(); for (String w : words) { tf.merge(w, 1, Integer::sum); } MapString, Double vec new HashMap(); for (Map.EntryString, Integer e : tf.entrySet()) { double idf Math.log((double) totalDocs / (1 df.getOrDefault(e.getKey(), 0))); vec.put(e.getKey(), e.getValue() * idf); } return vec; }df是每个词出现在多少个菜品文档中的数量totalDocs是菜品总数。IDF公式里加1是防止某个词在所有文档都出现时除数为0。这路特征不依赖任何用户行为新菜上架后立即参与推荐和协同过滤形成互补。2.5 点餐场景算法对比与混合策略算法数据要求点餐场景表现实现成本冷启动表现物品协同过滤Jaccard用户行为搭配推荐效果好有热门偏移低新菜无效Slope One用户评分把点餐频次映射成评分稳定可增量低新菜无效TF-IDF内容推荐菜品文本适合新菜召回和相似菜替换低新菜有效热度排序下单量兜底推荐任何时候不报错极低有效但无个性化实际系统我不会只跑一个模型。混合策略是对候选菜品池同时用多路算法打分加权求和权重随数据量动态调整——新系统热度权重0.7协同过滤0.2内容推荐0.1跑满一个月有足够行为数据后协同过滤权重升到0.5。这个权重不需要动态学习按周手动调整即可。3. SpringBoot落地推荐链路数据表设计、相似度矩阵与REST接口3.1 三张核心表就够user、dish、order_item常见错误是把推荐结果落库当主数据实际上推荐结果是派生物每次请求现算或者走缓存即可。我只建三张业务表再加一张埋点表用于效果评估CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, nickname VARCHAR(32) NOT NULL, taste_tags VARCHAR(128) DEFAULT NULL, -- 口味偏好, JSON数组串: [辣,清淡] created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE dish ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, category_id BIGINT NOT NULL, price DECIMAL(8,2) NOT NULL, description TEXT, status TINYINT DEFAULT 1, -- 1上架 0下架 first_on_shelf_at DATETIME, -- 首次上架时间, 热度衰减计算用 created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, user_id BIGINT NOT NULL, dish_id BIGINT NOT NULL, dish_name VARCHAR(64) NOT NULL, -- 冗余, 防止菜品改名影响历史统计 price DECIMAL(8,2) NOT NULL, -- 冗余, 防止菜品改价影响历史订单 quantity INT NOT NULL DEFAULT 1, rating TINYINT DEFAULT NULL, -- 1-5星, NULL表示未评价 created_at DATETIME DEFAULT CURRENT_TIMESTAMP );order_item冗余dish_name和price是刻意设计菜品改名、改价后历史订单的统计口径不能跟着变。rating允许为空为空时用quantity和下单频次映射成隐式评分见2.2节的说明。3.2 用Spring Data JPA定义实体与仓储接口SpringBoot的自动装配会自动扫描JpaRepository接口并生成代理实现数据源配置写进application.yml即可不需要手写连接池代码Entity Table(name order_item) public class OrderItem { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private Long userId; private Long dishId; private Integer quantity; private Integer rating; private LocalDateTime createdAt; // getter / setter 省略 } public interface OrderItemRepository extends JpaRepositoryOrderItem, Long { ListOrderItem findByUserId(Long userId); Query(SELECT DISTINCT oi.userId FROM OrderItem oi WHERE oi.createdAt :start) ListLong findActiveUsers(LocalDateTime start); }findByUserId直接用方法名解析SQL是Spring Data JPA的命名约定findActiveUsers用JPQL查最近有行为的用户集合供推荐引擎构建矩阵时过滤活跃用户。读取全部行为数据时注意加时间范围条件全表扫描百万级order_item会把内存撑爆。3.3 Slope One推荐引擎的完整Java实现推荐引擎做成Spring组件启动后由定时任务调rebuild构建矩阵接口调用predict做实时预测Component public class RecommendEngine { private static final int MIN_FREQ 3; // 共现次数少于3的物品对直接丢弃 private final MapLong, MapLong, Double deviation new ConcurrentHashMap(); private final MapLong, MapLong, Integer frequency new ConcurrentHashMap(); public void rebuild(ListOrderItem items) { MapLong, MapLong, Double diffSum new HashMap(); MapLong, MapLong, Integer freqSum new HashMap(); MapLong, MapLong, Double userRatings items.stream() .collect(Collectors.groupingBy(OrderItem::getUserId, Collectors.toMap(OrderItem::getDishId, this::toRating, Double::max))); for (MapLong, Double rated : userRatings.values()) { ListLong dishIds new ArrayList(rated.keySet()); for (int i 0; i dishIds.size(); i) { for (int j i 1; j dishIds.size(); j) { Long a dishIds.get(i), b dishIds.get(j); double diff rated.get(a) - rated.get(b); diffSum.computeIfAbsent(a, k - new HashMap()).merge(b, diff, Double::sum); diffSum.computeIfAbsent(b, k - new HashMap()).merge(a, -diff, Double::sum); freqSum.computeIfAbsent(a, k - new HashMap()).merge(b, 1, Integer::sum); freqSum.computeIfAbsent(b, k - new HashMap()).merge(a, 1, Integer::sum); } } } deviation.clear(); frequency.clear(); for (Long a : diffSum.keySet()) { for (Long b : diffSum.get(a).keySet()) { int freq freqSum.get(a).get(b); if (freq MIN_FREQ) continue; deviation.computeIfAbsent(a, k - new HashMap()).put(b, diffSum.get(a).get(b) / freq); frequency.computeIfAbsent(a, k - new HashMap()).put(b, freq); } } } public double predict(Long targetDishId, MapLong, Double userRatings) { double numerator 0, denominator 0; for (Map.EntryLong, Double e : userRatings.entrySet()) { Long rated e.getKey(); if (rated.equals(targetDishId)) continue; Double dev deviation.getOrDefault(rated, Collections.emptyMap()).get(targetDishId); Integer freq frequency.getOrDefault(rated, Collections.emptyMap()).get(targetDishId); if (dev null || freq null) continue; numerator (e.getValue() dev) * freq; denominator freq; } return denominator 0 ? Double.NaN : numerator / denominator; } private double toRating(OrderItem oi) { if (oi.getRating() ! null) return oi.getRating() / 5.0; return Math.min(1.0, 0.3 0.2 * oi.getQuantity()); } }代码里两个关键点。第一diffSum的双重遍历会同时写入(a,b)和(b,a)两个方向偏差值取相反数天然对称第二MIN_FREQ 3是工程上最值得调的参数定太低会产生幻觉相关性定太高矩阵变得稀疏预测返回NaN的概率增大。toRating的映射逻辑是有显式星级用星级除以5没有则按点餐频次累加频次越高的菜隐式评分越高。3.4 推荐服务与REST接口串联推荐服务把引擎、菜品仓储和热度兜底串起来核心逻辑是协同过滤结果不够时用热度补位Service public class RecommendService { private final RecommendEngine engine; private final DishRepository dishRepository; public ListRecommendItem recommendForUser(Long userId, int limit) { MapLong, Double scores new LinkedHashMap(); if (userId ! null) { MapLong, Double userRatings loadUserRatings(userId); for (Long dishId : candidateDishIds()) { double score engine.predict(dishId, userRatings); if (!Double.isNaN(score)) { scores.put(dishId, score); } } } if (scores.size() limit) { scores.putAll(hotDishes(limit - scores.size())); } return scores.entrySet().stream() .sorted(Map.Entry.Long, DoublecomparingByValue().reversed()) .limit(limit) .map(e - new RecommendItem(dishRepository.findById(e.getKey()).orElse(null), e.getValue())) .collect(Collectors.toList()); } }Controller层只做参数接收和统一返回不写业务逻辑RestController RequestMapping(/api/recommend) public class RecommendController { private final RecommendService recommendService; public RecommendController(RecommendService recommendService) { this.recommendService recommendService; } GetMapping(/{userId}) public ResultListRecommendItem recommend(PathVariable Long userId, RequestParam(defaultValue 10) int limit) { return Result.ok(recommendService.recommendForUser(userId, limit)); } }limit参数控制推荐列表长度前端首页一般传10点餐详情页的“搭配推荐”传3。接口协议保持userId在路径里、limit在查询参数里前端Vue页面直接axios调用即可不需要引入额外的RPC框架。3.5 定时刷新与增量更新Component public class RecommendScheduler { Scheduled(cron 0 0 3 * * ?) // 每天凌晨3点全量重建 public void refreshMatrix() { ListOrderItem items orderItemRepository.findRecent(90); engine.rebuild(items); cache.clear(recommend:*); // 清空推荐缓存, 与重建动作对齐 } }cron 0 0 3 * * ?表示每天凌晨3点执行避开点餐高峰。Slope One的deviation矩阵完全可以增量维护某用户点了一道新菜只用更新这个用户历史菜品集合与新菜的偏差对。凌晨的全量任务是兜底修正白天的增量更新是日常路径。4. 参数调优与效果验证冷启动策略、A/B测试漏斗与反馈闭环4.1 新用户、新菜品、新系统三种冷启动分开处理新用户没有order_item记录推荐引擎返回NaN此时直接返回热度榜。新上架的菜没有共现数据用TF-IDF找到内容最相近的已上架老菜用老菜的推荐分映射给新菜相当于“蹭相似菜的热度”。整个系统运行不足一周、行为数据量太小时干脆切到纯热度模式别硬上协同过滤否则推荐结果全是噪声。热度分计算必须带时间衰减否则开业第一周的爆款菜会永远霸榜public double hotScore(long orderCount, LocalDateTime firstOnShelf) { double cnt Math.log1p(orderCount); // 压缩量级, 防百万销量碾压新菜 long days ChronoUnit.DAYS.between(firstOnShelf, LocalDateTime.now()) 2L; return cnt / Math.pow(days, 1.2); // 1.2是衰减指数 }log1p把销量从线性的“10000 vs 1”压成对数的“9.2 vs 0.7”新手店不会永远追不上老店。衰减指数1.2的意思是一道菜上架30天后哪怕销量翻倍热度分也只约等于刚上架第3天的水平。如果老板要求给新品更多曝光把指数降到0.8。4.2 用A/B测试验证推荐真的有效不要直接全量上协同过滤。策略A用协同过滤策略B用纯热度按user_id % 2分流。前提是埋点表设计得对CREATE TABLE recommend_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, dish_id BIGINT NOT NULL, strategy VARCHAR(16) NOT NULL, -- hot 或 item_cf position INT NOT NULL, -- 推荐位序号 1-10 session_id VARCHAR(64) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE behavior_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, dish_id BIGINT NOT NULL, action VARCHAR(16) NOT NULL, -- click order favorite session_id VARCHAR(64) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );一周后跑漏斗查询SELECT e.strategy, COUNT(DISTINCT e.user_id) AS exposure_uv, COUNT(DISTINCT c.user_id) AS click_uv, COUNT(DISTINCT o.user_id) AS order_uv, COUNT(DISTINCT o.user_id) / COUNT(DISTINCT e.user_id) AS cvr FROM recommend_log e LEFT JOIN behavior_log c ON c.session_id e.session_id AND c.dish_id e.dish_id AND c.action click LEFT JOIN behavior_log o ON o.session_id e.session_id AND o.dish_id e.dish_id AND o.action order WHERE e.created_at DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY e.strategy;cvr 下单UV / 曝光UV是判断推荐质量的核心指标。点击率会骗人——用户可能因为菜名猎奇点进来但不想吃下单率则代表真实转化。如果策略A的CVR显著高于B用卡方检验或直接看置信区间才值得全量切换。4.3 三个最常调的参数位置参数位置默认值调参影响共现次数阈值 MIN_FREQRecommendEngine3太低噪声多太高矩阵稀疏邻居数量 Top-Kpredict循环不限制越大越平滑但计算变慢推荐列表长度 limitController10过短无惊喜过长选择困难热度衰减指数hotScore1.2直接决定新老菜品曝光比例全量重建cronScheduler0 0 3 * * ?需要与缓存TTL对齐MIN_FREQ是数据质量闸门数据量大可以提到5Top-K限制在50能挡住长尾噪声limit由前端产品决定点餐场景10个结果已经足够超过15个转化率反而下降因为用户又陷入选择困难。每个参数调完都要回4.2节的漏斗看CVR变化凭感觉调参等于白调。5. 排错与进阶矩阵膨胀、SpringBoot版本陷阱与缓存一致性5.1 相似度矩阵膨胀从全量矩阵到稀疏Top-K算法跑通后第一个炸的是内存。10000道菜的全量偏差矩阵是1亿个double约800MB直接压垮小型服务器。解法是只在共现频次超过阈值的地方存值再对每个菜只保留相似度最高的Top-K个邻居。1万道菜、每道菜保留50个邻居约50万个double4MB内存加Map键开销也就十几MB完全驻留JVM。用ConcurrentHashMap做存储而不是Hashtable因为推荐矩阵是读多写少的场景并发读无锁写时只在需要分段锁的桶上加锁。5.2 SpringBoot版本太高的兼容性坑SpringBoot 3.x要求JDK17背后的javax.servlet包名迁移成jakarta.servlet老项目直接编译失败SpringBoot 2.6之后spring.main.allow-circular-references默认关闭老代码升上来启动就报循环依赖错误。如果暴露了actuator的heapdump端点又没做鉴权堆转储文件被下载后数据库账号密码和Token都可能被提取出来——这是生产事故级别的配置错误上线前记得把management.endpoints.web.exposure.include里只留health和info。5.3 接手现成SpringBoot项目时的检查顺序接手别人的SpringBoot项目不用急着读全部代码按文件顺序排查先看pom.xml的parent版本和依赖树确认JDK版本再看application.yml的数据源和Redis配置然后扫描RestController搞清对外暴露了哪些接口最后看resources下有没有schema.sql或data.sql初始化脚本。这套流程跑完项目骨架基本就摸清了。5.4 把推荐日志和缓存TTL绑在一起是上线前最重要的小事最容易翻车的点是缓存一致性。推荐结果用Caffeine或Redis缓存后TTL设24小时结果凌晨3点定时任务重算了矩阵用户端看到的还是旧矩阵算出来的结果。做法是定时任务结束时主动执行cache.clear(recommend:*)而不是等TTL自然过期。TTL本身设5分钟即可既挡住并发穿透又不会让错误结果存留太久。每次推荐请求都把strategy和position字段写进recommend_log将来做模型迭代时这批日志就是最便宜的训练样本。所以我的建议是定时任务重建矩阵后的第一行代码写清缓存别把刷新和失效的时间差交给侥幸。本文还有配套的精品资源点击获取
SpringBoot点餐推荐系统实战：Slope One与协同过滤算法融合
简介一款基于Spring Boot的智能推荐点餐系统设计与实现完整项目适合正在学习Spring Boot整合开发、推荐算法落地及餐饮系统设计的开发者。项目采用前后端分离架构业务逻辑涵盖登录、点餐、支付等核心流程并利用协同过滤或基于内容的推荐算法依据用户历史订单与浏览行为生成个性化菜品推荐。资源包大小约107.95MB包含开发说明文档、操作演示视频、项目源码及PPT演示文稿等材料可系统了解从环境搭建到项目部署的关键环节。目前已有78人浏览学习。开发者可结合源码和文档快速搭建运行环境理解系统分层与推荐模块实现观看演示视频可直观掌握用户注册、菜品浏览、点餐推荐等完整操作PPT与常见问题说明则有助于梳理设计思路、应对部署中的典型问题是深入实践Spring Boot与智能推荐系统的理想参考。1. SpringBoot智能推荐点餐系统把“人找菜”变成“菜找人”中午打开点餐小程序菜单翻了三屏还没决定餐厅老板看着后厨数据想知道哪些菜该置顶、哪些菜适合推给哪类客人。智能推荐点餐系统做的事就是把“人找菜”倒过来变成“菜找人”。它不是一个普通的管理后台核心在“智能推荐”四个字上根据用户历史点餐记录、菜品共现关系和菜品本身属性实时算出一份带个人偏好的菜单排序再通过SpringBoot框架暴露成接口供前端调用。对开发者来说这是理解SpringBoot集成推荐算法最合适的载体。它不需要引入Spark、Flink这类重组件纯靠JVM内存和标准SQL就能跑通完整的协同过滤流程。对准备做毕业设计、或者想从CRUD转向推荐方向的Java工程师这套系统的技术密度刚刚好——算法逻辑不复杂到劝退工程化程度又足够写进简历。2. 推荐算法选型Slope One、物品协同过滤与TF-IDF在点餐场景的取舍2.1 点餐数据只有隐式反馈矩阵分解容易过拟合点餐系统的反馈和电商评分不一样。用户不会在点餐页给每道菜打五星系统拿到的真实信号只有一个点过、没点过、点了几次。这是典型的隐式反馈。用显式反馈算法处理时矩阵里的空值并不是“用户不喜欢”而是“用户没机会尝试”。如果直接用SVD做矩阵分解空值补零会引入极大偏差训练出来的隐向量往往把热销菜和任何用户都算得“相似”个性化反而消失。Slope One的优势在数据稀疏时反而更明显。它不试图刻画用户或物品的隐向量只统计一个统计量同一用户点过的两道菜评分差平均是多少。这个差值矩阵可以用一条SQL聚合出来也能在内存里用双重循环构建天然支持增量维护——新来一条评分只需要更新涉及到的物品对。提示如果你的用户-物品矩阵填充率低于5%不要一上来就上矩阵分解。先用简单模型跑通闭环再谈精度。2.2 Slope One原理物品间的平均偏差是推荐的全部依据Slope One的核心假设很朴素用户对物品j的评分大概率等于“用户对物品i的评分”加上“i与j在所有用户眼中的平均偏差”。加权预测公式如下pred(u, j) Σ [ (dev(i,j) r_ui) × freq(i,j) ] / Σ freq(i,j) 其中 i ∈ R(u)R(u) 是用户u点过的菜品集合 dev(i,j) 所有同时点过i和j的用户对i的评分减对j的评分的平均值 freq(i,j) 同时点过i和j的用户数freq(i,j)是权重同时点过两道菜的用户越多这个平均偏差越可信。实现时不需要真的造一个密集矩阵一条SQL就能把偏差矩阵算出来SELECT a.dish_id AS item_a, b.dish_id AS item_b, AVG(COALESCE(a.rating / 5.0, 0.5) - COALESCE(b.rating / 5.0, 0.5)) AS dev, COUNT(*) AS freq FROM order_item a JOIN order_item b ON a.user_id b.user_id AND a.dish_id b.dish_id WHERE a.created_at DATE_SUB(NOW(), INTERVAL 90 DAY) GROUP BY a.dish_id, b.dish_id HAVING COUNT(*) 3;dish_id b.dish_id保证每对菜只统计一次HAVING COUNT(*) 3是数据质量闸门——只点过一次的偶然共现没有统计意义。这条SQL导出的结果可以直接接Excel验证数据形态再决定要不要写进Java代码。用户评分优先用订单里的rating字段归一化到0~1没评分时用点餐频次映射点一次0.5点两次0.8三次及以上1.0。2.3 用Jaccard相似度做物品协同过滤物品协同过滤的直觉是经常被同一桌点到的菜是“搭子”。比如“水煮鱼”和“酸梅汤”共现次数高推荐水煮鱼时自然带上酸梅汤。Jaccard相似度是处理共现关系最稳的度量sim(i, j) |U(i) ∩ U(j)| / |U(i) ∪ U(j)|分子是同时点过i和j的用户数分母是点过i或j的用户总数。Jaccard天然惩罚热门菜——如果一道菜被所有人点过分母巨大相似度被压低这恰好符合“推荐要有惊喜感”的需求。实现时维护一张用户→菜品集合的哈希表双重循环求交集占比时间复杂度O(n²)n是用户平均点过的菜品数常见系统里n不超过50性能完全能接受。2.4 TF-IDF内容画像解决新菜品冷启动协同过滤对“零行为”的新菜完全无能为力此时需要走内容推荐。把“菜名描述分类名”拼成文档例如“麻辣 水煮鱼 川菜 花椒 豆芽”分词后计算TF-IDF向量再算余弦相似度public MapString, Double tfidf(ListString words, MapString, Integer df, int totalDocs) { MapString, Integer tf new HashMap(); for (String w : words) { tf.merge(w, 1, Integer::sum); } MapString, Double vec new HashMap(); for (Map.EntryString, Integer e : tf.entrySet()) { double idf Math.log((double) totalDocs / (1 df.getOrDefault(e.getKey(), 0))); vec.put(e.getKey(), e.getValue() * idf); } return vec; }df是每个词出现在多少个菜品文档中的数量totalDocs是菜品总数。IDF公式里加1是防止某个词在所有文档都出现时除数为0。这路特征不依赖任何用户行为新菜上架后立即参与推荐和协同过滤形成互补。2.5 点餐场景算法对比与混合策略算法数据要求点餐场景表现实现成本冷启动表现物品协同过滤Jaccard用户行为搭配推荐效果好有热门偏移低新菜无效Slope One用户评分把点餐频次映射成评分稳定可增量低新菜无效TF-IDF内容推荐菜品文本适合新菜召回和相似菜替换低新菜有效热度排序下单量兜底推荐任何时候不报错极低有效但无个性化实际系统我不会只跑一个模型。混合策略是对候选菜品池同时用多路算法打分加权求和权重随数据量动态调整——新系统热度权重0.7协同过滤0.2内容推荐0.1跑满一个月有足够行为数据后协同过滤权重升到0.5。这个权重不需要动态学习按周手动调整即可。3. SpringBoot落地推荐链路数据表设计、相似度矩阵与REST接口3.1 三张核心表就够user、dish、order_item常见错误是把推荐结果落库当主数据实际上推荐结果是派生物每次请求现算或者走缓存即可。我只建三张业务表再加一张埋点表用于效果评估CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, nickname VARCHAR(32) NOT NULL, taste_tags VARCHAR(128) DEFAULT NULL, -- 口味偏好, JSON数组串: [辣,清淡] created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE dish ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, category_id BIGINT NOT NULL, price DECIMAL(8,2) NOT NULL, description TEXT, status TINYINT DEFAULT 1, -- 1上架 0下架 first_on_shelf_at DATETIME, -- 首次上架时间, 热度衰减计算用 created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, user_id BIGINT NOT NULL, dish_id BIGINT NOT NULL, dish_name VARCHAR(64) NOT NULL, -- 冗余, 防止菜品改名影响历史统计 price DECIMAL(8,2) NOT NULL, -- 冗余, 防止菜品改价影响历史订单 quantity INT NOT NULL DEFAULT 1, rating TINYINT DEFAULT NULL, -- 1-5星, NULL表示未评价 created_at DATETIME DEFAULT CURRENT_TIMESTAMP );order_item冗余dish_name和price是刻意设计菜品改名、改价后历史订单的统计口径不能跟着变。rating允许为空为空时用quantity和下单频次映射成隐式评分见2.2节的说明。3.2 用Spring Data JPA定义实体与仓储接口SpringBoot的自动装配会自动扫描JpaRepository接口并生成代理实现数据源配置写进application.yml即可不需要手写连接池代码Entity Table(name order_item) public class OrderItem { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private Long userId; private Long dishId; private Integer quantity; private Integer rating; private LocalDateTime createdAt; // getter / setter 省略 } public interface OrderItemRepository extends JpaRepositoryOrderItem, Long { ListOrderItem findByUserId(Long userId); Query(SELECT DISTINCT oi.userId FROM OrderItem oi WHERE oi.createdAt :start) ListLong findActiveUsers(LocalDateTime start); }findByUserId直接用方法名解析SQL是Spring Data JPA的命名约定findActiveUsers用JPQL查最近有行为的用户集合供推荐引擎构建矩阵时过滤活跃用户。读取全部行为数据时注意加时间范围条件全表扫描百万级order_item会把内存撑爆。3.3 Slope One推荐引擎的完整Java实现推荐引擎做成Spring组件启动后由定时任务调rebuild构建矩阵接口调用predict做实时预测Component public class RecommendEngine { private static final int MIN_FREQ 3; // 共现次数少于3的物品对直接丢弃 private final MapLong, MapLong, Double deviation new ConcurrentHashMap(); private final MapLong, MapLong, Integer frequency new ConcurrentHashMap(); public void rebuild(ListOrderItem items) { MapLong, MapLong, Double diffSum new HashMap(); MapLong, MapLong, Integer freqSum new HashMap(); MapLong, MapLong, Double userRatings items.stream() .collect(Collectors.groupingBy(OrderItem::getUserId, Collectors.toMap(OrderItem::getDishId, this::toRating, Double::max))); for (MapLong, Double rated : userRatings.values()) { ListLong dishIds new ArrayList(rated.keySet()); for (int i 0; i dishIds.size(); i) { for (int j i 1; j dishIds.size(); j) { Long a dishIds.get(i), b dishIds.get(j); double diff rated.get(a) - rated.get(b); diffSum.computeIfAbsent(a, k - new HashMap()).merge(b, diff, Double::sum); diffSum.computeIfAbsent(b, k - new HashMap()).merge(a, -diff, Double::sum); freqSum.computeIfAbsent(a, k - new HashMap()).merge(b, 1, Integer::sum); freqSum.computeIfAbsent(b, k - new HashMap()).merge(a, 1, Integer::sum); } } } deviation.clear(); frequency.clear(); for (Long a : diffSum.keySet()) { for (Long b : diffSum.get(a).keySet()) { int freq freqSum.get(a).get(b); if (freq MIN_FREQ) continue; deviation.computeIfAbsent(a, k - new HashMap()).put(b, diffSum.get(a).get(b) / freq); frequency.computeIfAbsent(a, k - new HashMap()).put(b, freq); } } } public double predict(Long targetDishId, MapLong, Double userRatings) { double numerator 0, denominator 0; for (Map.EntryLong, Double e : userRatings.entrySet()) { Long rated e.getKey(); if (rated.equals(targetDishId)) continue; Double dev deviation.getOrDefault(rated, Collections.emptyMap()).get(targetDishId); Integer freq frequency.getOrDefault(rated, Collections.emptyMap()).get(targetDishId); if (dev null || freq null) continue; numerator (e.getValue() dev) * freq; denominator freq; } return denominator 0 ? Double.NaN : numerator / denominator; } private double toRating(OrderItem oi) { if (oi.getRating() ! null) return oi.getRating() / 5.0; return Math.min(1.0, 0.3 0.2 * oi.getQuantity()); } }代码里两个关键点。第一diffSum的双重遍历会同时写入(a,b)和(b,a)两个方向偏差值取相反数天然对称第二MIN_FREQ 3是工程上最值得调的参数定太低会产生幻觉相关性定太高矩阵变得稀疏预测返回NaN的概率增大。toRating的映射逻辑是有显式星级用星级除以5没有则按点餐频次累加频次越高的菜隐式评分越高。3.4 推荐服务与REST接口串联推荐服务把引擎、菜品仓储和热度兜底串起来核心逻辑是协同过滤结果不够时用热度补位Service public class RecommendService { private final RecommendEngine engine; private final DishRepository dishRepository; public ListRecommendItem recommendForUser(Long userId, int limit) { MapLong, Double scores new LinkedHashMap(); if (userId ! null) { MapLong, Double userRatings loadUserRatings(userId); for (Long dishId : candidateDishIds()) { double score engine.predict(dishId, userRatings); if (!Double.isNaN(score)) { scores.put(dishId, score); } } } if (scores.size() limit) { scores.putAll(hotDishes(limit - scores.size())); } return scores.entrySet().stream() .sorted(Map.Entry.Long, DoublecomparingByValue().reversed()) .limit(limit) .map(e - new RecommendItem(dishRepository.findById(e.getKey()).orElse(null), e.getValue())) .collect(Collectors.toList()); } }Controller层只做参数接收和统一返回不写业务逻辑RestController RequestMapping(/api/recommend) public class RecommendController { private final RecommendService recommendService; public RecommendController(RecommendService recommendService) { this.recommendService recommendService; } GetMapping(/{userId}) public ResultListRecommendItem recommend(PathVariable Long userId, RequestParam(defaultValue 10) int limit) { return Result.ok(recommendService.recommendForUser(userId, limit)); } }limit参数控制推荐列表长度前端首页一般传10点餐详情页的“搭配推荐”传3。接口协议保持userId在路径里、limit在查询参数里前端Vue页面直接axios调用即可不需要引入额外的RPC框架。3.5 定时刷新与增量更新Component public class RecommendScheduler { Scheduled(cron 0 0 3 * * ?) // 每天凌晨3点全量重建 public void refreshMatrix() { ListOrderItem items orderItemRepository.findRecent(90); engine.rebuild(items); cache.clear(recommend:*); // 清空推荐缓存, 与重建动作对齐 } }cron 0 0 3 * * ?表示每天凌晨3点执行避开点餐高峰。Slope One的deviation矩阵完全可以增量维护某用户点了一道新菜只用更新这个用户历史菜品集合与新菜的偏差对。凌晨的全量任务是兜底修正白天的增量更新是日常路径。4. 参数调优与效果验证冷启动策略、A/B测试漏斗与反馈闭环4.1 新用户、新菜品、新系统三种冷启动分开处理新用户没有order_item记录推荐引擎返回NaN此时直接返回热度榜。新上架的菜没有共现数据用TF-IDF找到内容最相近的已上架老菜用老菜的推荐分映射给新菜相当于“蹭相似菜的热度”。整个系统运行不足一周、行为数据量太小时干脆切到纯热度模式别硬上协同过滤否则推荐结果全是噪声。热度分计算必须带时间衰减否则开业第一周的爆款菜会永远霸榜public double hotScore(long orderCount, LocalDateTime firstOnShelf) { double cnt Math.log1p(orderCount); // 压缩量级, 防百万销量碾压新菜 long days ChronoUnit.DAYS.between(firstOnShelf, LocalDateTime.now()) 2L; return cnt / Math.pow(days, 1.2); // 1.2是衰减指数 }log1p把销量从线性的“10000 vs 1”压成对数的“9.2 vs 0.7”新手店不会永远追不上老店。衰减指数1.2的意思是一道菜上架30天后哪怕销量翻倍热度分也只约等于刚上架第3天的水平。如果老板要求给新品更多曝光把指数降到0.8。4.2 用A/B测试验证推荐真的有效不要直接全量上协同过滤。策略A用协同过滤策略B用纯热度按user_id % 2分流。前提是埋点表设计得对CREATE TABLE recommend_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, dish_id BIGINT NOT NULL, strategy VARCHAR(16) NOT NULL, -- hot 或 item_cf position INT NOT NULL, -- 推荐位序号 1-10 session_id VARCHAR(64) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE behavior_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, dish_id BIGINT NOT NULL, action VARCHAR(16) NOT NULL, -- click order favorite session_id VARCHAR(64) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );一周后跑漏斗查询SELECT e.strategy, COUNT(DISTINCT e.user_id) AS exposure_uv, COUNT(DISTINCT c.user_id) AS click_uv, COUNT(DISTINCT o.user_id) AS order_uv, COUNT(DISTINCT o.user_id) / COUNT(DISTINCT e.user_id) AS cvr FROM recommend_log e LEFT JOIN behavior_log c ON c.session_id e.session_id AND c.dish_id e.dish_id AND c.action click LEFT JOIN behavior_log o ON o.session_id e.session_id AND o.dish_id e.dish_id AND o.action order WHERE e.created_at DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY e.strategy;cvr 下单UV / 曝光UV是判断推荐质量的核心指标。点击率会骗人——用户可能因为菜名猎奇点进来但不想吃下单率则代表真实转化。如果策略A的CVR显著高于B用卡方检验或直接看置信区间才值得全量切换。4.3 三个最常调的参数位置参数位置默认值调参影响共现次数阈值 MIN_FREQRecommendEngine3太低噪声多太高矩阵稀疏邻居数量 Top-Kpredict循环不限制越大越平滑但计算变慢推荐列表长度 limitController10过短无惊喜过长选择困难热度衰减指数hotScore1.2直接决定新老菜品曝光比例全量重建cronScheduler0 0 3 * * ?需要与缓存TTL对齐MIN_FREQ是数据质量闸门数据量大可以提到5Top-K限制在50能挡住长尾噪声limit由前端产品决定点餐场景10个结果已经足够超过15个转化率反而下降因为用户又陷入选择困难。每个参数调完都要回4.2节的漏斗看CVR变化凭感觉调参等于白调。5. 排错与进阶矩阵膨胀、SpringBoot版本陷阱与缓存一致性5.1 相似度矩阵膨胀从全量矩阵到稀疏Top-K算法跑通后第一个炸的是内存。10000道菜的全量偏差矩阵是1亿个double约800MB直接压垮小型服务器。解法是只在共现频次超过阈值的地方存值再对每个菜只保留相似度最高的Top-K个邻居。1万道菜、每道菜保留50个邻居约50万个double4MB内存加Map键开销也就十几MB完全驻留JVM。用ConcurrentHashMap做存储而不是Hashtable因为推荐矩阵是读多写少的场景并发读无锁写时只在需要分段锁的桶上加锁。5.2 SpringBoot版本太高的兼容性坑SpringBoot 3.x要求JDK17背后的javax.servlet包名迁移成jakarta.servlet老项目直接编译失败SpringBoot 2.6之后spring.main.allow-circular-references默认关闭老代码升上来启动就报循环依赖错误。如果暴露了actuator的heapdump端点又没做鉴权堆转储文件被下载后数据库账号密码和Token都可能被提取出来——这是生产事故级别的配置错误上线前记得把management.endpoints.web.exposure.include里只留health和info。5.3 接手现成SpringBoot项目时的检查顺序接手别人的SpringBoot项目不用急着读全部代码按文件顺序排查先看pom.xml的parent版本和依赖树确认JDK版本再看application.yml的数据源和Redis配置然后扫描RestController搞清对外暴露了哪些接口最后看resources下有没有schema.sql或data.sql初始化脚本。这套流程跑完项目骨架基本就摸清了。5.4 把推荐日志和缓存TTL绑在一起是上线前最重要的小事最容易翻车的点是缓存一致性。推荐结果用Caffeine或Redis缓存后TTL设24小时结果凌晨3点定时任务重算了矩阵用户端看到的还是旧矩阵算出来的结果。做法是定时任务结束时主动执行cache.clear(recommend:*)而不是等TTL自然过期。TTL本身设5分钟即可既挡住并发穿透又不会让错误结果存留太久。每次推荐请求都把strategy和position字段写进recommend_log将来做模型迭代时这批日志就是最便宜的训练样本。所以我的建议是定时任务重建矩阵后的第一行代码写清缓存别把刷新和失效的时间差交给侥幸。本文还有配套的精品资源点击获取