简介这份资源是微信小程序「我厨」的完整源码包面向正在学习小程序开发、需要实战项目练手的初学者与进阶开发者可用于研究电商类小程序的页面组织、数据请求与组件复用方式。压缩包共50个文件以wxml页面结构、wxss样式、js逻辑脚本和json配置为主另含11张png图片资源整体约125KB体量轻巧便于快速导入微信开发者工具运行调试。目录中划分出api、pages、utils、images等模块涵盖首页、分类、购物车、帖子等典型页面配合app.js与app.json可直观理解小程序的生命周期与路由配置。目前已有133人学习下载适合作为课程设计、毕业设计或自学练手的参考案例帮助读者掌握从页面搭建到接口调用的完整开发思路。1. 从一份「我厨」小程序压缩包说起生鲜电商前端到底要解决什么打开一份名为「微信小程序我厨」的压缩包你大概率会看到 pages、components、utils、images 这几类目录外加 app.js、app.json、project.config.json 三个根文件。它不是一个能直接跑起来的成品而是一套生鲜电商场景的前端骨架首页轮播、分类导航、商品列表、购物车、订单确认、个人中心。真正值得研究的不是它长什么样而是它为什么这样组织——生鲜电商和普通商城最大的差别在于「时效」和「库存」两个变量会同时压在前端上菜品今天有明天可能就下架配送时段是按小时切的购物车里的东西可能在你结算前就没了。这套骨架要解决的就是在微信小程序的运行环境里用尽可能少的请求把「可售状态」准确地呈现给用户并且让加购、改数量、切时段这些高频操作不卡顿。适合谁看正在做小程序商城、准备接手一个半成品前端、或者想搞清楚生鲜类目前端该怎么分层的人。下面我按「先跑起来、再拆结构、再抠参数、最后避坑」的顺序讲每一步都能照着复现。2. 把压缩包跑起来目录结构、依赖与最小可运行路径拿到一个 zip 之后最忌讳的就是直接双击打开看代码。先让它跑起来跑不起来再好的结构都是纸上谈兵。这一章讲清楚三件事目录怎么读、依赖怎么装、开发者工具里怎么配。2.1 解压后的目录该按什么顺序读一个典型的小程序项目解压后大致是这样weixin_wochu/ ├── app.js ├── app.json ├── app.wxss ├── project.config.json ├── sitemap.json ├── pages/ │ ├── index/ │ ├── category/ │ ├── cart/ │ ├── order/ │ └── user/ ├── components/ │ ├── goods-card/ │ ├── stepper/ │ └── empty/ ├── utils/ │ ├── request.js │ ├── cart.js │ └── format.js └── images/读的顺序建议是先看app.json的pages数组它决定了页面注册顺序和默认首页再看app.js的globalData那里通常放着用户 token、购物车缓存、当前配送时段然后看utils/request.js这是所有网络请求的出口能一眼看出后端接口风格最后才进 pages 逐个看。很多人一上来就翻 pages/index结果看到一堆this.data.xxx完全不知道数据从哪来就是因为跳过了前三步。project.config.json里有两个字段必须确认appid和miniprogramRoot。如果miniprogramRoot指向的是一个子目录而你把整个 zip 解压到了外层开发者工具就会报「找不到 app.json」。常见做法是把miniprogramRoot改成./或者把子目录里的内容整体上移一层。2.2 依赖安装与开发者工具配置小程序本身不强制 npm但如果项目里出现了miniprogram_npm目录或者package.json说明用了构建 npm。步骤是# 在项目根目录执行安装依赖 npm install # 如果 package.json 里没有依赖只是需要生成 miniprogram_npm # 在微信开发者工具里点「工具 - 构建 npm」即可构建完成后app.json里如果引用了组件路径要写成miniprogram_npm/xxx/index这种形式而不是node_modules/xxx。这是新手最容易翻车的地方本地npm install成功了工具里却一直提示组件找不到就是因为没点「构建 npm」。开发者工具里还需要检查三项设置。第一「详情 - 本地设置」里的「不校验合法域名」要勾上否则本地调试时所有请求都会被拦。第二基础库版本不要选太新的生鲜类小程序常用的wx.getLocation、wx.chooseAddress在过高版本上行为有变化选一个稳定版即可。第三如果项目用了sitemap.json确认rules里的action是allow不然页面不会被索引虽然不影响本地运行但上线后搜索流量会受影响。2.3 让首页真正渲染出数据的三个改动压缩包里的首页通常是「静态骨架 假数据」或者「直接请求后端但域名已失效」。要让它跑通我一般做三处改动。第一处在utils/request.js里把 baseURL 换成一个可用的地址或者干脆用本地 mock// utils/request.js const BASE_URL https://example.com/api; // 换成你自己的后端或 mock 服务 function request(options) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { content-type: application/json, // token 从缓存取没有就传空 Authorization: wx.getStorageSync(token) || }, success(res) { // 统一处理业务码这里假设 0 表示成功 if (res.data res.data.code 0) { resolve(res.data.data); } else { // 业务失败也要 reject让调用方统一处理 reject(res.data); } }, fail(err) { reject(err); } }); }); } module.exports { request };这段代码的关键在于把「网络失败」和「业务失败」都收敛到 reject调用方只需要一个 catch。参数上header里的 Authorization 是生鲜类接口的标配因为购物车和订单都跟用户绑定content-type用 application/json 而不是表单是因为加购接口通常要传嵌套结构。第二处在pages/index/index.js的onLoad里把假数据替换成真实请求并加上 loading 和空态const { request } require(../../utils/request); Page({ data: { banners: [], goodsList: [], loading: true }, onLoad() { this.fetchHomeData(); }, async fetchHomeData() { try { const [banners, goodsList] await Promise.all([ request({ url: /home/banners }), request({ url: /home/goods, data: { page: 1, size: 10 } }) ]); this.setData({ banners, goodsList, loading: false }); } catch (e) { // 失败时至少要把 loading 关掉否则页面一直转圈 this.setData({ loading: false }); wx.showToast({ title: 加载失败, icon: none }); } } });用Promise.all并发两个请求是因为轮播和商品列表互不依赖串行会白白多等一个 RTT。loading状态必须在 catch 里也关掉这是血泪经验很多人只写成功分支结果接口一挂页面就永远停在骨架屏。第三处检查app.json里的window配置navigationBarTitleText和backgroundColor要和生鲜的视觉一致否则跑起来会显得很怪。这一步不影响功能但影响你判断「这个骨架到底能不能用」。3. 生鲜电商前端的核心购物车状态与库存同步怎么设计跑起来之后真正决定这套骨架能不能用于生产的是购物车。生鲜购物车和普通商城购物车有三个本质区别数量调整极频繁、库存变化极快、配送时段会反向影响可售商品。这一章把状态设计讲透。3.1 为什么购物车不能只存在本地缓存很多半成品项目把购物车直接放在wx.setStorageSync(cart, ...)里页面一读就渲染。这在 demo 阶段没问题但生鲜场景会立刻出问题用户在 A 设备加了菜在 B 设备打开看不到用户加购后过了十分钟某样菜已经下架本地缓存里还在用户切换配送时段某些菜其实不支持该时段本地完全不知道。常见做法是「本地缓存 服务端校验」双层结构。本地缓存负责即时渲染让加减数量不卡服务端负责在关键节点进入购物车页、进入结算页、提交订单前做一次全量校验把失效商品标出来。这样既保住了交互流畅又保住了数据准确。具体实现上我一般把购物车拆成两个数据源数据源存放位置作用更新时机本地快照Storage即时渲染、离线可看每次加减数量后服务端购物车后端权威数据、跨端同步进入购物车页、结算前库存状态后端标记可售/失效与购物车一起返回3.2 加购与改数量的最小实现加购接口通常要传商品 ID、数量、配送时段。下面是一个可复用的加购函数// utils/cart.js const { request } require(./request); // 本地购物车结构{ [goodsId]: { count, selected, price, name } } function getLocalCart() { return wx.getStorageSync(cart) || {}; } function saveLocalCart(cart) { wx.setStorageSync(cart, cart); } // 加购先更新本地再异步同步服务端 async function addToCart(goods, count 1) { const cart getLocalCart(); const id goods.id; if (cart[id]) { cart[id].count count; } else { cart[id] { count, selected: true, price: goods.price, name: goods.name }; } saveLocalCart(cart); // 同步服务端失败时回滚本地 try { await request({ url: /cart/add, method: POST, data: { goodsId: id, count } }); } catch (e) { // 回滚把刚才加的数量减回去 cart[id].count - count; if (cart[id].count 0) delete cart[id]; saveLocalCart(cart); throw e; } return cart; } module.exports { getLocalCart, saveLocalCart, addToCart };这段代码的核心是「乐观更新 失败回滚」。参数上count默认 1但步进器会传具体值selected默认 true因为生鲜用户加购通常就是要买。回滚逻辑必须写否则网络抖动时本地和服务端会长期不一致用户下次进购物车看到数量对不上就会怀疑整个系统。3.3 库存校验与失效商品的呈现进入购物车页时应该调一次服务端校验接口返回结构大致是{ code: 0, data: { items: [ { goodsId: 1, count: 2, stock: 10, available: true }, { goodsId: 2, count: 1, stock: 0, available: false, reason: 已售罄 }, { goodsId: 3, count: 3, stock: 5, available: false, reason: 当前时段不支持配送 } ] } }前端拿到之后要做三件事把available: false的商品置灰并显示 reason把这些商品从「已选合计」里剔除如果用户点了结算要拦截并提示。这里有个细节失效商品不要直接从列表里删掉用户会以为自己的操作丢了置灰加原因才是正确做法。库存为 0 和时段不支持要区分文案因为用户的下一步动作不同售罄只能删时段不支持可以换时段。这个区分在数据层就要做好不要在前端靠字符串判断。4. 接口层与性能请求封装、缓存策略和首屏优化生鲜小程序的用户耐心极低首页超过两秒没内容基本就划走了。这一章讲接口层怎么设计以及首屏怎么压时间。4.1 请求封装里必须有的四个能力一个能用于生产的request.js至少要具备统一 baseURL、统一鉴权、统一错误码处理、请求取消。前三个前面提过重点说请求取消。生鲜首页经常有「切换分类」的操作用户快速点了三个分类前两个请求的结果回来时已经没用了如果不取消可能出现后回来的旧数据覆盖新数据。// utils/request.js 增加取消能力 const pending {}; function request(options) { const key options.url JSON.stringify(options.data || {}); // 同一请求如果还在进行中先取消 if (pending[key]) { pending[key].abort(); } return new Promise((resolve, reject) { const task wx.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { content-type: application/json, Authorization: wx.getStorageSync(token) || }, success(res) { if (res.data res.data.code 0) resolve(res.data.data); else reject(res.data); }, fail(err) { // 主动取消不算失败不往外抛 if (err.errMsg err.errMsg.indexOf(abort) -1) return; reject(err); }, complete() { delete pending[key]; } }); pending[key] task; }); }参数说明key用 url 加序列化后的 data 拼成保证同一请求能识别abort是wx.request返回的 task 自带方法complete里删除 pending避免内存泄漏。注意 fail 里要过滤 abort否则取消会触发错误提示用户会看到莫名其妙的 toast。4.2 首屏数据的缓存与预取生鲜首页的轮播和分类导航变化频率很低完全可以缓存。我一般用「缓存优先 后台刷新」的策略async function fetchWithCache(key, fetcher, expire 5 * 60 * 1000) { const cached wx.getStorageSync(key); const now Date.now(); if (cached now - cached.time expire) { // 先返回缓存同时后台刷新 fetcher().then(data { wx.setStorageSync(key, { data, time: Date.now() }); }).catch(() {}); return cached.data; } const data await fetcher(); wx.setStorageSync(key, { data, time: now }); return data; }expire默认五分钟生鲜的轮播和分类五分钟内基本不会变。商品列表不要用这个策略因为库存和价格变化快缓存会导致用户看到错误价格。这个区分很重要缓存用错地方比不用缓存更危险。4.3 图片与列表渲染的优化点生鲜小程序的图片量很大一个列表页十几张图很常见。三个必须做的优化图片用modeaspectFill并给固定宽高避免布局抖动列表用wx:key且 key 用商品 ID 而不是 index长列表用recycle-view或者分页加载不要一次性渲染几百个节点。!-- 商品卡片 -- view classgoods-card wx:for{{goodsList}} wx:keyid image src{{item.image}} modeaspectFill stylewidth: 200rpx; height: 200rpx; lazy-load / text classname{{item.name}}/text text classprice¥{{item.price}}/text /viewlazy-load让图片进入视口才加载wx:keyid保证列表更新时节点复用正确。如果 key 用 index删除中间某个商品时后面所有节点的状态都会错位步进器的数量会串到别的商品上这是很典型的翻车现场。5. 避坑与排查这类小程序最常见的五个问题这一章按「现象 → 原因 → 解决」写都是我在实际项目里反复遇到的。现象一开发者工具里正常真机上首页白屏。原因通常是请求域名没配。开发者工具勾了「不校验合法域名」真机不生效。解决在小程序后台配置 request 合法域名或者真机调试时打开调试模式。另外要检查app.json里pages第一项是不是首页真机对默认首页的判断比工具严格。现象二购物车数量加减后合计金额不更新。原因是setData只改了 count没有重新计算合计。解决把合计金额做成计算属性每次 cart 变化后统一重算不要在各个事件里分别算。更隐蔽的情况是直接修改了this.data.cart[id].count而没有调setData视图不会更新。现象三切换配送时段后购物车里部分商品没有重新校验。原因是时段切换只更新了本地状态没有触发服务端校验。解决时段变化时强制调一次购物车校验接口把返回的 available 状态覆盖本地。这个逻辑要放在时段组件的 change 事件里不要指望用户手动刷新。现象四订单提交后重复下单。原因是提交按钮没有防抖用户快速点了两次。解决提交前把按钮置为 disabled请求返回后再恢复同时后端要做幂等前端防抖只是第一层。我一般还会在提交时生成一个 requestId 传给后端同一 requestId 只处理一次。现象五分包后主包体积还是超限。原因是图片和公共组件都放在主包。解决把非首屏页面的图片移到分包目录公共组件如果只有分包用也移到分包。主包只保留 tabBar 页面和真正全局的 utils。检查方法是在开发者工具的「代码依赖分析」里看主包构成通常能发现几个大图片是罪魁祸首。6. 从骨架到可用一个可复用的购物车校验技巧最后讲一个我一直在用的技巧把购物车校验做成「差异更新」而不是「全量替换」。全量替换的问题是用户正在操作时如果校验结果回来会把用户刚改的数量覆盖掉体验很差。差异更新的做法是只更新 available 和 stock 这两个字段count 以本地为准。// 差异更新购物车校验结果 function mergeCartCheck(localCart, serverItems) { const map {}; serverItems.forEach(item { map[item.goodsId] item; }); Object.keys(localCart).forEach(id { const server map[id]; if (!server) { // 服务端已经没有这个商品标记失效 localCart[id].available false; localCart[id].reason 已下架; } else { localCart[id].available server.available; localCart[id].reason server.reason || ; localCart[id].stock server.stock; // count 不覆盖保留用户当前操作 } }); return localCart; }这个函数的关键注释已经写在代码里count 永远以本地为准。为什么因为用户正在加减数量的时候服务端返回的 count 是上一次同步的值用它覆盖会让用户觉得「我点的没生效」。available 和 stock 则必须以服务端为准这两个字段本地无法判断。验证这个技巧是否生效可以做一个简单测试在购物车页打开的情况下用另一个账号或后台把某个商品库存改成 0然后触发一次校验看该商品是否置灰且数量没有被重置。如果数量被重置了说明哪里还在做全量替换。我自己的习惯是任何涉及「本地状态 服务端状态」的功能都先问一句这个字段谁说了算想清楚再写代码比写完再 debug 省事得多。生鲜电商的前端复杂度不在页面多而在状态多且变化快把状态的归属和更新时机定清楚剩下的就是体力活。希望帮到你。本文还有配套的精品资源点击获取