协同过滤算法驱动的美食推荐微信小程序全栈开发实践

做美食推荐小程序这个项目起因倒是很简单想给自己和身边几个朋友做一个能“越用越懂我”的找饭工具。市面上能看评分、看距离的App不少但真正能根据你过去点过什么、喜欢什么口味来给出个性化推荐的体验做得好的其实不多。于是干脆自己动手用 Node.js PHP Vue 再加一个协同过滤算法把它做成了微信小程序。先说结论这套组合干活完全够用。PHP 负责业务接口和算法计算Node.js 承担定时任务和数据预处理Vue 搭管理后台小程序端面向用户。重点不在技术栈多新而在协同过滤算法怎么在真实业务里落地。项目里的用户行为采集、菜品评分矩阵构建、相似度计算这几块踩了不少坑也总结了一些可以少绕弯子的经验。这篇文章就把从环境配置到算法实现、从小程序联调到上线维护的完整过程都梳理一遍适合正在做毕设、想入行小程序开发、或者自己折腾美食/电商类项目的朋友参考。1. 项目选型与整体架构设计1.1 技术栈组合与分工先说一个很多人问的问题为什么 PHP 和 Node.js 同时用一个项目里搞两套后端语言听着像是没事找事但实际用下来是分工考虑。PHP 主业务接口、管理员操作、菜品和用户的数据管理这套东西用 PHP 写起来快生态也成熟随便一台服务器就能跑Node.js 则是处理定时任务和算法预处理比如每天凌晨拉取前一天的用户行为、构建矩阵、跑推荐结果。Node 对高并发的 I/O 任务处理比 PHP 更自然写定时脚本配合 cron 也方便。Vue 在这套项目里负责管理后台。商家和管理员需要维护菜品库、查看用户行为数据、手动干预推荐结果——比如某个新店想冲排名可以临时加权重。这部分如果用传统模板渲染也能做但 Vue 的双向绑定和组件化让表格、表单这类频繁交互的操作舒服很多尤其是菜品列表的批量编辑、推荐分区的拖拽排序体验远超传统写法。小程序端是用户的直接入口。推荐列表、菜品详情、评分交互、收藏和点餐记录都在这里完成。小程序的性能虽然比不上原生 App但胜在开发效率高、分发成本低。微信生态里还有现成的登录体系和支付能力对个人开发者和中小项目非常友好。1.2 协同过滤算法在美食场景中的业务映射协同过滤算法有多版演进版本但在美食推荐这个场景里我选了用户协同过滤为主、物品协同过滤为辅的组合策略。基础逻辑不复杂用户 A 和用户 B 的口味相近A 喜欢吃的菜B 大概率也喜欢。具体落到业务上有三个层面用户对菜品的评分行为显式反馈比如用户打了 5 星用户的点餐/收藏行为隐式反馈点了一份麻辣香锅说明大概率接受这个口味用户浏览行为弱反馈只看不点可能是犹豫权重放低。这三种行为组成一个“用户-菜品”行为矩阵矩阵里的值加权合并变成算法输入。输出是每个用户的 TopN 推荐列表。这个列表不是实时算的而是每天定时批量算好写入 Redis 或者 MySQL 的推荐结果表用户打开小程序时直接读取。用户量不大时这样最划算不用每次请求都跑一遍矩阵计算后面容量不够再上实时计算也来得及。这套设计里最关键的一点是算法不是全部行为采集才是地基。行为数据如果没采集干净矩阵再漂亮也是白搭。我在项目里单独做了一个行为日志表每次曝光、点击、下单、评分都会异步写入Node.js 那边定时清洗然后落库。2. 环境搭建与工程初始化2.1 Node.js 安装和那个烦人的 npm 报错网上搜这个项目的人很大概率同时在搜“npm 无法加载文件 npm.ps1”说明大家卡在了同一个地方。先说安装Windows 下直接去 Node.js 官网下载 LTS 版本安装包一路 Next 就行。安装完验证是否成功在命令行里敲node -v npm -v能看到 v18.x.x 之类的版本号就说明装好了。多数人偏偏卡在了 npm 上——敲任何 npm 命令都提示npm : 无法加载文件 D:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本这个错的原因是 PowerShell 默认脚本执行策略是 Restricted不允许运行 .ps1 脚本。解决思路不是绕过安全机制而是把策略改为针对当前用户有效即可。以管理员身份打开 PowerShell执行Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser然后选 Y重新打开终端npm 命令就正常了。这里不建议直接改成 UnrestrictedRemoteSigned 已经足够覆盖开发需要也更稳妥。Node.js 装好后顺便把镜像源换成国内镜像下载依赖的速度会差出好几个量级。执行npm config set registry https://registry.npmmirror.com再执行一下 npm config get registry确认输出是上面那个地址就可以。2.2 Vue 管理后台创建与依赖安装Vue 项目我用 Vite 创建相比 vue-cli 启动速度快、依赖安装也干净。执行npm create vitelatest food-admin -- --template vue cd food-admin npm install核心依赖这么几个vue-router管理后台的路由跳转pinia全局状态管理比 Vuex 更轻axios请求后端接口element-plus后台管理的 UI 组件库表格、表单、弹窗都有现成的。安装命令合在一起写npm install vue-router4 pinia axios element-plusVue 这边要提醒一个入门常见问题vue-router 传参有 query 和 params 两种方式跳详情页的时候用 query 最简单刷新页面参数还在params 在新版路由里需要使用动态路由配置否则刷新就丢参。管理后台的菜品编辑页我用的是动态路由方式路径类似/dish/edit/:id详情页可以直接从route.params.id取菜品 ID体验更干净。2.3 PHP 环境准备与接口骨架搭建PHP 我用的是 phpstudy 作为集成环境版本直接上 PHP 8.1 以上。项目里 PHP 端做了一个简单的 MVC 结构没有引入完整框架控制器、模型、服务三层分开。为什么不用 Laravel 或者 ThinkPHP一方面是小程序接口路径比较固定另一方面是算法部分我自己写得比较多框架反而碍事。接口以 JSON 格式返回PHP 端统一封装一个响应函数function apiResponse($code, $data, $msg ok) { header(Content-Type: application/json;charsetutf-8); echo json_encode([ code $code, data $data, msg $msg ]); exit; }写接口的第一个坑就是跨域。小程序端请求通常没跨域问题但 Vue 管理后台开发环境跑在 5173 端口请求 PHP 接口跑在 80 端口跨域就来了。PHP 端要提前把响应头加上header(Access-Control-Allow-Origin: *); header(Access-Control-Allow-Methods: GET, POST, OPTIONS); header(Access-Control-Allow-Headers: Content-Type, Authorization);还有更隐蔽的一个问题PHP 8 之后数组和对象的转换经常让刚从老教程入门的人摸不着头脑。比如数据库取出来的二维数组json_encode 之后到了前端可能是对象而不是数组。Vue 里用v-for遍历前最好Array.isArray()确认一下或者 PHP 端统一用array_values()重置下标再返回给前端。3. 协同过滤推荐算法的核心落地3.1 行为数据采集与矩阵构建算法部分不是上来就写余弦相似度第一步是把行为数据变成矩阵。我设计了三张核心表user用户表小程序登录后自动创建dish菜品表包含分类、口味标签、价格、图片;user_behavior用户行为表记录曝光、点击、收藏、评分、下单五类行为。行为表结构简化如下CREATE TABLE user_behavior ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, dish_id int(11) NOT NULL, behavior_type varchar(20) NOT NULL, -- view / click / favorite / rate / order rating tinyint(1) DEFAULT NULL, -- 只有 rate 行为有值 create_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_user (user_id), KEY idx_dish (dish_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;行为数据要转成矩阵里的分值不能直接用 0 和 1 平铺不同行为权重差异很大。我的权重定义如下下单order5 分。这是最强的正向反馈用户真金白银买了单评分rate直接用评分值乘以 0.8比如打了 5 星等于 4 分收藏favorite3 分。收藏代表明确偏好点击click1 分。弱反馈但量大能补足稀疏矩阵曝光view不计分只用于后面算 CTR 之类的辅助指标。Node.js 的定时任务每天凌晨 2 点跑一次数据清洗任务。脚本逻辑是读取前一天新增的 user_behavior按用户和菜品分组聚合算出每个用户对每个菜品的综合得分。写入一张独立的user_dish_scores表字段就是 user_id、dish_id、score。这样矩阵不是临时在内存里拼的而是每天固化到数据库里后续算法直接查表即可调试也方便。3.2 用户协同过滤余弦相似度计算用户协同的核心是找相似用户。常用算法是余弦相似度公式是similarity (A向量 · B向量) / (|A向量| * |B向量|)在 PHP 里实现一个简化版本直接查user_dish_scores表取两个用户的共同菜品维度算相似度public function userSimilarity($userIdA, $userIdB) { // 取出两个用户对所有菜品的评分 $scoresA $this-getUserScores($userIdA); $scoresB $this-getUserScores($userIdB); // 寻找两个用户共同评分过的菜品 $common array_intersect_key($scoresA, $scoresB); if (count($common) 0) { return 0; } $dot 0; $normA 0; $normB 0; foreach ($scoresA as $dishId $score) { $normA pow($score, 2); } foreach ($scoresB as $dishId $score) { $normB pow($score, 2); } foreach ($common as $dishId $score) { $dot $score * $scoresB[$dishId]; } if ($normA 0 || $normB 0) { return 0; } return $dot / (sqrt($normA) * sqrt($normB)); }这里特别注意算共同菜品时必须用 array_intersect_key而不是遍历某个用户的所有菜品去判断另一方有没有。为什么因为用户菜品矩阵非常稀疏一个用户可能只对几十个菜品有过行为全部菜品上千个遍历全库再判断存在性会慢很多用 PHP 的 hash 查找能快一个量级。相似用户取多少个实践中 TopK 取 10~20 比较合理。太少了推荐结果太窄太多了计算量大增益却不明显。我的策略是取相似度排名前 15 的用户再把这些用户评分过的菜品按加权分数聚合候选菜品过滤掉用户已经买过/评过分的剩下的按分数排序取前 20 作为推荐候选。3.3 物品协同过滤用户冷启动的补充方案只有用户协同过滤会有个明显问题新用户没有任何行为数据矩阵里全是空的余弦相似度直接算不出来。所以项目里同时实现了物品协同过滤作为冷启动补充。物品协同的核心逻辑是如果有很多用户同时喜欢 A 菜品和 B 菜品那么 A 和 B 之间就存在关联。给一个用户推荐时根据他最近喜欢的菜找到关联度最高的其他菜。这个实现比用户协同简单。PHP 里先统计所有用户的偏好菜品集合生成“喜欢菜品 A 也喜欢菜品 B”的共现矩阵。每天 Node.js 定时任务会计算各菜品之间的共现次数存到 dish_similarity 表里。用户端展示时老用户走用户协同结果为主新用户没有行为数据时走物品协同连一个行为都没有的纯新用户直接返回全局热门菜品 Top20用户行为很少比如只有一两单时用物品协同比用户协同更靠谱因为两三个行为不足以找到相似用户。冷启动的策略优先级实现代码如下public function getRecommendList($userId, $limit 20) { $behaviorCount $this-countUserBehavior($userId); if ($behaviorCount 0) { // 完全没有行为返回热门排行 return $this-getHotDishes($limit); } if ($behaviorCount 5) { // 行为太少用物品协同推荐 return $this-getItemBasedRecommend($userId, $limit); } // 行为足够走用户协同 物品协同融合 $userBased $this-getUserBasedRecommend($userId, $limit * 0.7); $itemBased $this-getItemBasedRecommend($userId, $limit * 0.3); return $this-mergeAndFilter($userBased, $itemBased, $userId); }这里融合策略有个细节用户协同结果占 70%物品协同占 30%而不是简单的 50% 对 50%。因为用户协同对偏好的捕捉更准确物品协同更多是补充多样性。按这个比例融合实测下来推荐的点击率比纯用户协同高不少因为物晶协同引入了一些用户自己都没想到但确实相关的菜。3.4 Node.js 定时任务与推荐结果缓存PHP 负责算法计算逻辑没问题但用户每次打开小程序都跑一遍计算就不行了。所以真正的生产链路是Node.js 写定时任务调 PHP 的算法服务算好的结果存到数据库和 Redis小程序请求走缓存。Node.js 这边用 node-cron 做定时调度const cron require(node-cron); const axios require(axios); cron.schedule(0 2 * * *, async () { console.log(开始执行推荐任务计算...); try { const res await axios.post(http://127.0.0.1:80/api/recommend/compute); if (res.data.code 0) { console.log(推荐结果更新成功); } } catch (error) { console.error(推荐任务执行失败:, error.message); } });推荐结果表要设置合理过期时间避免用户看到的数据太陈旧。我的做法是 generated_date 字段记录生成日期小程序端请求时如果发现缓存结果超过 3 天就临时触发一次实时计算并提示“推荐结果正在更新”。这样既能保证日常响应速度也不会让用户觉得推荐“永远不变”。缓存这块踩过一个坑一开始我把推荐结果存在 MySQL 里每次请求都查一次结果数据量一上来接口响应从几十毫秒变成几百毫秒。后来改成 Redis响应时间基本稳定在 30 毫秒内。Redis 键结构是recommend:user:{userId}值是一串菜品 ID前端拿到后再根据 ID 批量查菜品信息。4. 小程序端与 Vue 管理后台的对接实现4.1 微信小程序的请求封装与推荐页渲染小程序端不是直接用 wx.request 到处写而是封装了一个统一的请求模块。封装的核心原因有三个统一处理 token、统一处理错误码、统一处理 loading 状态。请求模块核心逻辑// utils/request.js const BASE_URL https://api.example.com; function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) }, success(res) { if (res.data.code 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); } module.exports { request };推荐页的渲染我用了 scroll-view 做无限滚动。首次进入加载 20 条推荐下拉到底部再加载下一批。需要注意的坑是onReachBottom在页面高度不够时不会触发所以要在onReady里先判断一次内容高度不足就自动加载更多。这个小问题折腾了我一晚上。推荐列表的卡片设计上除了菜品图、名称、价格以外还做了一个“为什么推荐给你”的小标签——如果来自相似用户的偏好就显示“和你口味相似的人都在点”如果来自物品协同就显示“你喜欢的XX很多人也点了这道菜”。这个设计加分很明显用户对推荐结果的信任感直接提升后面的点击率数据也验证了这一点。4.2 用户行为采集与评分交互推荐算法要持续变准行为采集必须从小程序端严谨埋点。我在三个位置埋了行为数据推荐列表曝光每张卡片露出屏幕视口时上报 view 行为点击卡片进入详情上报 click 行为详情页点“收藏”和“下单”上报 favorite 和 order 行为。埋点上报统一走一个/api/behavior/report接口PHP 端异步写队列避免高频上报阻塞业务接口。评分交互这里多说一嘴很多项目只做“点赞/不点赞”但显式评分对协同过滤的帮助远超想象。我做了五星评分弹窗用户下单完成后弹出愿意评分的用户虽然比例不高但每一个评分都是高质量训练样本。在矩阵里一个明确打 5 星的用户价值顶得上几次隐式下单行为。埋点上报里有个隐蔽的问题小程序端频繁请求会触发微信的并发限制。批量埋点数据不用一条一条发前端先在本地攒 10 条或者每隔 30 秒再一次性批量上报。PHP 端接数组参数循环入库即可。4.3 Vue 管理后台菜品管理与推荐干预管理后台是 Vue Element Plus。核心功能三块菜品管理、用户行为看板、推荐干预。菜品管理就是一个标准 CRUD表格组件绑定数据编辑用对话框。其中图片上传使用小程序的临时文件接口转存到服务器这部分的关键是处理图片压缩不然用户上传一张手机原图可能好几 MB直接把服务器打满。PHP 端用了imagecreatefromjpeg重新采样输出压缩到 800px 宽以内。用户行为看板展示当天各行为数据量以及行为趋势折线图。数据接口就是查询 user_behavior 表按天分组返回给 ECharts 或 Element 的图表组件。这个看板的价值在于你可以直观地看到埋点是否正常上线第一天如果曝光量很高但点击率极低多半是推荐结果和用户预期偏离太远。推荐干预这个功能是我自己加的。管理后台有个“推荐配置”页可以对特定菜品设置推荐权重加成。比如新店开业临时把某道菜的权重乘上 2让它在推荐列表里排名靠前push。实现上就是在推荐结果合并排序时权重加成体现在分数计算里if ($dish-boost_weight 1) { $finalScore $dish-alg_score * $dish-boost_weight; }4.4 接口联调抓包与调试技巧小程序开发最难受的地方是没办法直接看浏览器 Network所有接口请求都是黑盒。调试阶段我用抓包工具抓 HTTPS 请求手机上装好证书后能清楚看到小程序发给后端每个接口的完整参数和返回结果。抓包时的经验首先要确认小程序的合法域名是否配置正确。开发阶段可以在微信开发者工具里勾选“不校验合法域名”但实际预览或者上线时必须在小程序后台配置 request 合法域名并且接口必须 HTTPS。HTTP 接口在真机上直接不通这个被坑过的人应该有一大批。然后提一下微信开发者工具的 Network 面板其实它自带一个调试器但只显示小程序前端层面的请求状态看不到服务器返回的具体数据结构。用抓包工具的好处是能完整看到 app 端到服务器端的数据流转尤其是 PHP 接口报错时响应内容到底返回了 HTML 错误页还是 JSON 错误信息一目了然。还有一个细节小程序发布体验版之后建议在测试机上开启调试模式抓一次正式环境包因为体验版和开发版的请求域名策略不完全一样。这个环节很多文档没强调但排查线上问题的时候非常关键。5. 上线踩坑与性能优化实录5.1 高频报错与排查思路速查做完这个项目整理了一下自己在开发过程中遇到的高频问题和排查思路。这些坑你十有八九也会撞上提前看了能省好几个晚上的时间。问题表现根本原因解决方法npm 命令提示禁止运行脚本PowerShell 执行策略限制Set-ExecutionPolicy RemoteSigned 当前用户小程序请求接口报 502PHP 接口异常返回了 HTML 错误页检查 PHP 错误日志关掉 display_errors 改为记录日志Vue 后台请求接口跨域端口不同缺少 CORS 头PHP 统一加响应头预检请求 OPTIONS 也要处理协同过滤推荐结果全是热门行为数据稀疏相似度计算退化为 0冷启动用物品协同加热门兜底不要硬算相似度用户当天推荐没更新Redis 缓存过期时间过长设置推荐缓存为每天凌晨计算后刷新有效期设置为 12 小时图片上传后显示失败小程序临时文件路径已失效上传后必须将临时文件复制到服务器存储目录返回持久化 URL管理后台详情页刷新参数丢失使用了 query 传参而路由没有动态段改用动态路由/edit/:id获取参数Node 定时任务不执行服务器时区偏移在脚本内显式指定时区TZAsia/Shanghai或 node-cron 传 timezone5.2 算法计算的性能瓶颈与优化协同过滤计算在数据量小的时候毫无压力但用户量一旦过千、菜品铺到几百道PHP 里纯数组循环计算相似度就会开始吃力。几个优化手段按性价比排序第一向量稀疏化。用户-菜品矩阵里大量维度是 0存完整的 m×n 矩阵非常浪费。我只存有值的位置用哈希表存储。PHP 里直接用一个 dict 表示稀疏向量键是菜品 ID值是评分。这样相似度计算遍历的长度只跟用户实际行为数有关而不是跟菜品总量有关。用户行为 30 天内的数据控制在几百条的规模遍历成本极低。第二相似用户候选集裁剪。不需要拿当前用户和全量用户算相似度只和他有过相同菜品行为的用户比较。SQL 里先查当前用户有行为的菜品集合再查对这些菜品也有行为的用户集合然后用IN条件取这批用户出来算相似度。这一步能把计算量缩小几个数量级。第三结果预计算。推荐结果全部走定时任务预计算在线接口只是读取缓存。算法模块和在线服务模块彻底分离算法怎么改都不影响线上稳定性改动后重新跑一次定时任务即可。Node.js 那边跑算法预处理同样要控制内存。PHP 脚本本身占内存不高但如果你把整个相似度矩阵一次性加载进内存再计算内存立刻飙到几十 MB 甚至上百 MB。我的做法是分用户批次处理每次只取 200 个用户的数据算他们之间的相似度批次跑完写库释放内存。大规模数据下这种“分而治之”比一次性全量计算靠谱得多。5.3 数据质量比算法更重要这是做推荐系统最深刻的一个体会。算法模型再花哨行为数据采集不干净输出的推荐结果就是垃圾。我在这套项目里最重视的不是余弦相似度实现而是行为上报的准确性。举个例子用户在小程序里只是快速滑过某个菜品曝光接口如果就上报了矩阵里就会多出一条“伪反馈”。我处理曝光行为时做了去重同一用户对同一菜品 10 分钟内只记一次曝光。点击行为则要防误触进入详情页超过 3 秒才算一次有效点击低于 3 秒就退出的大概率不是真实兴趣。评分弹窗的设计也影响数据质量。一开始我把评分弹窗放在下单成功后立即弹出用户体验并不好评分数据偏低。后来改成延迟 10 秒弹出并且一天最多弹 3 次数据明显正常了很多。算法里最怕的不是用户不评分而是被引导产生的低质量评分这种数据会污染相似度计算。这套项目做完之后我又在数据清洗和推荐解释性上花了不少心思。比如推荐结果里加上“为什么推荐”的标签不仅用户感知好调试算法时也能快速定位是哪个相似的用户或哪个口味标签带来的推荐。后续如果想继续扩展可以做用户画像标签系统把口味偏好拆成“麻辣”“清淡”“甜口”等标签在物品协同的基础上叠加标签过滤推荐可解释性和准确性都能再上一个台阶。反正技术底座已经搭好了玩出更多花样只是时间问题。