简介这是一份面向微信小程序初学者的菜谱大全完整项目基于原生小程序框架实现适合用来学习页面布局、数据交互与模块化开发。项目共26个文件压缩包仅19KB体积非常轻量文件以js逻辑、wxml页面结构、wxss样式、json配置文件为主另含png图片素材与md说明文档目录按pages下list、menu、search、detail等模块划分便于快速定位和对照学习。功能上涵盖菜谱列表、分类筛选、搜索、收藏与详情展示等常见模块涉及wx.request网络请求、本地缓存、页面跳转、事件绑定、轮播图展示等典型知识点可帮助初学者完整走通一个小程序的开发流程。目前已有2106人学习下载适合作为课程设计、毕业设计参考或日常练手项目。 不知道你有没有这种时刻晚上七八点回到家拉开冰箱看着一堆食材发呆想了半天也不知道该做啥。我去翻菜谱App结果满屏是推荐的短视频搜个番茄炒蛋还得先看30秒广告。后来我干脆决定自己动手做一个微信小程序版的菜谱大全只保留最核心的找菜、看做法、收藏三个能力。做完之后我最大的感受是这类工具型小程序难的不是写代码而是数据怎么组织、交互细节怎么打磨、弱网环境下怎么不露怯。这篇文章把从0到1的完整过程拆给你看适合正在做菜谱类小程序、或者准备上架个人内容类小程序的开发者参考按我的路子走能省下不少弯路。1. 菜谱小程序的定位和骨架先想清楚做什么1.1 用户场景与功能取舍我做这个微信小程序菜谱大全的起因很简单晚上下班回家不知道吃什么。市面上的菜谱App信息太杂短视频占了主流想看个图文步骤反而要翻半天。所以我的定位是一个干净、快速的图文菜谱工具不搞社区、不做长视频只解决找菜和做菜这两个核心问题。有了这个定位功能边界一下就清晰了首页推荐、分类浏览、关键词搜索、菜谱详情、收藏。五块不能再多了。很多新手容易犯的毛病是需求越加越多今天想加我的动态明天想加食材购买结果开发周期拖到三个月最后上线一看核心体验都没打磨好。做个人小程序尤其要克制。MVP的功能列表我列出来供你参考首页搜索入口、今日推荐菜谱按时间或热度、分类快捷入口分类页菜系川菜、粤菜、场景早餐、夜宵、食材鸡肉、豆腐搜索页关键词搜索、搜索历史、热门搜索详情页封面大图、食材清单、图文步骤、小贴士、收藏按钮收藏页收藏的菜谱列表支持取消收藏1.2 tabBar怎么设计两栏还是四栏tabBar我用了首页、分类、收藏、我的四个入口这是菜谱类小程序比较成熟的结构。但如果你只想快速跑通砍到两个tab首页、收藏也不是不行关键在于想清楚导航的职责首页是发现分类是找收藏是回访我的是设置和个人数据。tab一多用户反而容易迷路。一个容易被忽略的细节是tabBar图标。小程序要求81px×81px的png不能带中文文件名透明背景要处理干净。我第一版直接拿设计稿的大图塞进去结果真机上图标又大又糊还得重新导出。建议一开始就按81×81、96×96两套尺寸准备防止不同机型渲染差异。1.3 导航栏默认的够用吗菜谱类小程序首页通常需要在顶部放一个大的搜索框默认导航栏只能放菜谱大全这种文本标题所以我选择了自定义导航栏。自定义导航栏最大的坑就是不同机型顶部高度不一致刘海屏、灵动岛、普通屏安全区高度完全不同。我的做法是在app.js里读取胶囊按钮位置统一计算导航栏高度这里贴一下核心代码const menuButton wx.getMenuButtonBoundingClientRect(); const systemInfo wx.getSystemInfoSync(); const navBarHeight (menuButton.top - systemInfo.statusBarHeight) * 2 menuButton.height; const statusBarHeight systemInfo.statusBarHeight;这段逻辑是标准的胶囊按钮定位法计算出来的导航栏高度在各个机型上都能精确贴合右侧胶囊按钮。如果图省事写死一个44px真机上一对比就会发现有的机型标题偏上、有的偏下观感差很远。2. 菜谱数据怎么建模字段设计决定开发效率2.1 菜谱表的核心字段菜谱数据是整个小程序的心脏字段设计的好坏直接决定后续开发是否顺畅。我采用的是单表 冗余字段的思路没有做复杂的关系建模。核心字段如下字段类型说明idstring菜谱唯一标识namestring菜名coverstring封面图URLcategorystring一级分类如家常菜tagsarray标签数组如[番茄,鸡蛋,酸甜]difficultystring简单/一般/困难cookTimenumber预计制作时间单位分钟ingredientsarray食材清单格式为[{name, amount}]stepsarray步骤格式为[{text, image}]tipsstring小贴士likeCountnumber收藏/热度计数这个结构是我踩过坑之后的版本。一开始我用的是非常标准的范式建模食材单独一张表、菜谱食材关系一张表、分类一张表做查询的时候要连三张表。在小程序云开发这种NoSQL环境里复杂关联查询既难写又慢后来全部改成了在菜谱表里直接存数组。简单需求就该用简单结构这个道理说起来容易真踩过坑才知道痛。2.2 按食材找菜用tags数组而不是关系表家里有番茄和鸡蛋能做什么菜是菜谱搜索里最高频的场景之一。用tags数组实现起来非常直接插入菜谱时把食材名、菜品特色、分类都塞进去查询时用数据库的in或者正则匹配。云开发里类似这样const db wx.cloud.database(); const _ db.command; const res await db.collection(recipes) .where({ tags: _.in([番茄, 鸡蛋]) }) .get();这里还有一个经验tags里不要只放食材要把菜系口味场合这些搜索词也塞进去比如[川菜,麻辣,下饭,鸡肉]。用户搜下饭菜也能命中大大提高了搜索的覆盖率。在一开始设计数据的时候让tags丰富一些后面搜索模块会省很多事这个投入非常值得。2.3 图片资源封面图和步骤图的处理菜谱是强图片内容图片处理不好整个小程序就显得很廉价。封面图我建议用宽高比接近4:3的压缩图宽度控制在750px左右就够用了不要直接上传原图否则首屏加载会非常吃力。步骤图建议统一宽度640px压缩成WebP格式体积能小一半以上。存储方案上个人开发者用云开发自带的云存储是最省事的一个环境里就能管理数据库和文件不需要额外买对象存储。但要注意云存储的读权限配置默认权限是所有用户可读仅创建者可写这样图片URL才能被所有用户访问。我见过不少人在这一步配错导致首页图片全部裂掉。3. 搜索模块从搜菜名到搜食材的多种匹配3.1 搜索入口与搜索历史搜索入口放在首页最顶部自定义导航栏区域用一个假的搜索框样式点击后跳转到独立搜索页。不要直接在首页做真输入框否则滚动时输入框的键盘弹出、失焦逻辑会很烦。搜索页单独搞一个页面输入框自动聚焦配合历史记录和热门词体验会好很多。搜索历史我直接用wx.setStorageSync存本地每次搜索把关键词放到数组头部、去重、截取前10条。这里要提醒一个细节不要每次setStorageSync都写入完整大数组频繁写本地缓存会带来性能损耗正确做法是内存里改完数组再一次性写入。3.2 多字段匹配的查询实现菜谱搜索不能只匹配菜名否则搜鸡肉就找不到宫保鸡丁这种菜名里没有鸡肉的菜。我最后的查询逻辑是对name、tags、category三个字段同时做模糊匹配。云开发数据库用正则就行const db wx.cloud.database(); const _ db.command; const keyword 鸡; const res await db.collection(recipes) .where(_.or([ { name: db.RegExp({ regexp: keyword, options: i }) }, { tags: db.RegExp({ regexp: keyword, options: i }) }, { category: db.RegExp({ regexp: keyword, options: i }) } ])) .limit(20) .get();搜索页的请求要加防抖用户输入停顿300ms后再发起请求不然每敲一个字都触发一次数据库查询既浪费资源又容易造成界面闪烁。防抖函数网上有很多现成的十分钟就能写好。3.3 搜索结果的排序策略排序直接决定用户对搜索质量的感知。我现在的策略是优先返回菜名完全等于关键词的结果其次是菜名包含关键词的最后才是tags命中的。简单做法是在查询前先判断一下是否有完全匹配结果没有的话再降级。对于内容量还不到几千条的小程序这种多级召回的方式比上搜索引擎简单得多也够用。这里还有一个很实用的技巧给菜谱表加一个hot字段每次收藏时hot加1搜索结果里如果前两类没啥结果就按hot排序返回热门菜谱。用户搜一个冷门词的时候不至于面对空结果页干瞪眼。4. 菜谱详情页图片加载、收藏和分享的细节4.1 图片懒加载与预览菜谱详情页会把步骤图一张张排下来如果一次性全部加载用户流量和页面渲染都会压力很大。小程序image组件自带lazy-load属性开启后图片进入视口附近才加载这一步必须加上。另外就是给每张步骤图绑定点击事件调用wx.previewImage实现全屏预览用户做菜时手上全是油能点一下看大图是非常实用的小功能。这里还有个移动端的经验详情页如果图像是服务端返回的URL建议在URL后面拼接尺寸参数比如?imageMogr2/thumbnail/750x让CDN按需裁剪。这样列表页加载小图、详情页加载大图不会浪费流量。4.2 收藏功能本地存储还是云数据库收藏是菜谱小程序里最基础也最重要的互动功能实现方案有两种本地缓存和云数据库。本地缓存的优点是零延迟、不依赖网络缺点是换设备数据就丢了也没法统计收藏数据云数据库则相反。我的建议是个人项目先用本地缓存跑通后续真要上用户体系再迁移到云数据库。两种方案的对比对比项本地缓存云数据库实现难度低中实时同步无有跨设备不支持支持适合场景小工具、无登录有账号体系的产品收藏按钮的状态切换要小心不要在每次点击后都重新读一遍整个storage数组而是在进入详情页时把收藏状态读进页面data里点击时只更新当前菜谱id的收藏标记并同步修改storage。这样逻辑清晰也不会造成页面卡顿。4.3 分享朋友圈和转发给好友菜谱类内容天然适合被分享所以详情页我重点做了分享配置。onShareAppMessage里动态设置title和imageUrl让用户分享出去的卡片直接显示菜谱封面和菜名。另外微信有一个隐藏入口是分享到朋友圈需要用户在右上角菜单里手动打开这个能力要在页面的onShareTimeline里单独配置。两个函数不一起写的话很多用户会发现能转发给好友但无法分享到朋友圈白白损失了传播渠道。分享卡片的封面图有一个注意点不能直接用数据库里的cover字段因为分享卡片对图片尺寸有要求最好专门准备一张带文字标题的分享图。可以在详情页请求数据时顺便请求一张分享图平时不展示只在分享时使用。5. 弱网和请求异常不能让用户对着白屏干等5.1 全局网络状态监听菜谱小程序大部分页面都要请求数据如果用户在地铁里、电梯里网络一断默认表现就是页面白屏。我后来加了一个全局的网络监听在app.js里用wx.onNetworkStatusChange监听网络变化断网时通过全局状态控制所有页面顶部弹出一个网络不可用的提示条恢复网络后自动消失。wx.onNetworkStatusChange((res) { if (!res.isConnected) { // 触发全局通知页面订阅后展示网络异常提示条 } });页面侧的联动方式是在网络监听回调里调用一个事件总线所有页面在onShow时订阅、onHide时取消订阅。这样新增页面不用额外写逻辑自动具备弱网提示能力。这个思路比每个页面各自判断loading错误再弹toast要统一得多用户也不会觉得是bug。5.2 请求封装与错误处理我所有的网络请求都走同一个封装函数统一处理loading、错误码、token携带、超时。这样可以保证整个小程序的行为一致。具体来说封装函数会做这几件事拼接基础URL、设置超时时间、请求前检查网络状态如果已经断网就直接提示不发请求、响应后统一判断code码、网络错误时给用户一个重新加载按钮而不是无声失败。这个封装函数是整个小程序稳定性的基石。建议从一开始就写好不要图省事每个页面各自用wx.request。我第一版就是每个页面各发各的请求后面改封装函数的时候几十个页面全部要动改了一整个周末。5.3 列表页的数据缓存策略菜谱首页是有强缓存价值的页面。我现在的做法是每次请求成功后将数据存一份到storage下次启动时先展示缓存数据同时后台重新请求等新数据返回后替换页面。这样即使用户在完全离线的状态下打开小程序也能看到上一次的推荐菜谱。很多用户是做饭时打开小程序才发现没有网的能看到缓存内容比一个加载失败的页面体验好太多。数据缓存和网络异常提示是配套使用的。缓存数据配上一个上次更新于xx分钟前的小字用户心里就有底了他知道自己看到的是旧数据但依然能正常使用这比一个加载失败的页面强得多。6. 如果要做付费菜谱或会员微信支付v3对接的实操坑6.1 什么时候需要接触微信支付菜谱类小程序做付费内容精品菜谱、会员订阅、视频教程是很常见的变现路径。只要涉及支付就必须对接微信支付。这里先泼一盆冷水个人开发者主体的小程序无法开通微信支付必须要企业主体或个体工商户。如果你只是个人主体想尽快上线可以考虑先不做支付功能或者用暂不接入支付、后续通过服务号跳转的过渡方案。6.2 v3接口的关键配置项微信支付现在新商户默认使用APIv3和老的v2相比签名和验签机制完全不同。对接v3时要准备这些东西商户号、商户API私钥、商户证书序列号、APIv3密钥、微信支付平台证书或者新商户平台里的微信支付公钥。我自己最开始就是在这里迷路的因为平台证书不像APIv3密钥那样是一串固定的字符串它是一个需要下载的公钥文件而且有有效期。用Node.js后端对接时请求头里需要拼接AuthorizationWECHATPAY2-SHA256-RSA2048 mchid商户号,nonce_str随机串,signature签名,timestamp时间戳,serial_no商户证书序列号其中signature是用商户API私钥对HTTP方法URL时间戳随机串请求体拼接字符串做的SHA256-RSA签名。签名用不对请求一律报错。这一步没有任何捷径只能照着文档一点一点对。6.3 最容易踩的三个坑第一个坑是无可用的平台证书这个错误。很多教程会让你去下载平台证书文件但新商户平台里更常见的是申请微信支付公钥。申请之后要在商户平台的API安全里配置不是下载下来就行还要把公钥保存到本地并记录公钥ID对应serial_no。第二个坑是回调验签和解密。支付结果回调不是明文返回微信会用平台证书私钥对回调内容做加密。你需要先用平台证书验签再用APIv3密钥对resource里的ciphertext做AES-256-GCM解密。这几个步骤顺序错了或者密钥弄反了回调就一直报签名失败。回调处理是我整个对接过程中耗时最长的地方白天怎么调都报错后来发现是有一个参数类型错了。第三个坑是金额单位。微信支付所有金额单位都是分不是元。我见过有人在业务层传了9.9当金额结果用户支付了9分钱还觉得占了便宜。这个低级错误排查起来特别费劲建议在接口层统一用整数分处理后端收到前端传来的金额时做一次严格校验避免线上事故。6.4 调试建议微信支付v3对接一定要善用微信官方提供的Postman脚本库里面已经把签名逻辑封装好了可以直接生成合法的请求去调测试接口。另外用一个小的测试商户号专门做联调不要在你的正式商户号上反复发支付请求否则很容易触发风控。一旦商户号被风控冻结解冻流程非常漫长会严重影响正式上线节奏。7. 从开发到上架审核和发布流程的经验7.1 类目选择和备案小程序提审之前首先要确认类目和ICP备案。菜谱这类工具/美食内容通常选择工具-效率或者生活服务-美食类目如果你只做菜谱浏览、不做交易审核相对容易通过。现在上线小程序必须完成ICP备案备案的流程是走平台内提示按步骤操作主体信息和服务器信息要提前准备好。这里最耗时间的往往是等待备案审核所以要提前规划不要等开发完了再备案那就只能干等着。7.2 容易被拒的细节菜谱小程序虽然内容简单但审核也有几处容易踩雷一是用户隐私保护指引里如果涉及收集用户信息比如头像昵称必须明确填写二是所有页面不能出现测试字样或明显的调试占位图三是分享出来的卡片和落地页要完整可用不能分享出去点开是广告或者空页面。我第一版被拒就是因为隐私弹窗里没有写清楚收集数据的目的改一下说明就过了。审核没有想象中可怕但要细心。7.3 上线后的基础数据观察小程序上线只是开始。我建议至少盯三个数据启动页到详情页的转化率看推荐菜谱是否吸引人、收藏率判断内容质量、搜索词看用户真正想搜什么。搜索词尤其重要我后来用搜索词反向补充了tags标签把用户搜得多的下饭快手菜这类词都加入到了对应菜谱的tags里搜索命中率提升非常明显。这些数据在小程序后台的分析模块里都能看到不需要额外埋点。这里分享一个从数据里发现的意外结论用户收藏最多和分享最多的菜谱并不是同一批。收藏多的是三菜一汤这类日常组合分享多的是火锅烤鱼这类聚会场景菜谱。后来我把首页推荐分成了今日家常和聚餐硬菜两个板块整体点击率明显高了不少。数据会告诉你真实的需求比拍脑袋强。补充一些我实际开发中的碎片经验给详情页步骤图加上点击预览是真的会被用户记住的细节收藏按钮的反馈一定要有动效哪怕只是简单的scale缩小放大用户的互动意愿会明显更高菜谱数据的维护很费精力建议一开始就把录入工具做好哪怕是个简单的管理系统也比直接在数据库里改强一百倍。如果你正准备做一个微信小程序版的菜谱大全我的建议是先花一周把数据结构和搜索体验做好再去碰花哨的功能。工具类小程序的核心永远是让用户快速找到想要的内容剩下的都是锦上添花。本文还有配套的精品资源点击获取