微信小程序餐饮商户模板：从解压到上线的完整改造指南

简介一套面向餐饮商户与微信小程序开发者的实用源码模板涵盖在线点餐、外卖配送、订单管理等核心业务流程能够帮助商户快速搭建自有小程序减少从头开发的重复工作也为初中级开发者提供贴近真实业务的项目范例。压缩包共含202个文件其中包括84个png图片资源、32个js脚本、28个wxss样式表、28个json配置文件以及27个wxml页面结构整体体积仅689KB目录划分清晰方便按模块查阅和复用。目前已有46人学习下载。源码在菜品展示、促销信息、在线支付等环节提供了可运行的前后端衔接示例开发者既可以将其作为起点直接改造成符合自身需求的商户应用也可以通过阅读页面样式、数据绑定与事件交互代码系统学习微信小程序的开发思路和常见技巧。需要注意的是该模板仅供学习交流使用请勿用于商业用途。1. 餐饮商户模板.zip解压前先搞清楚它是不是你要的那道菜你在网盘里下了一个【微信小程序源码】餐饮商户模板.zip解压之后对着一堆 js、wxml、json 文件发懵这种状态我带过很多人经历过。微信小程序不像网页那样双击一个 html 就能看到画面它要先通过微信开发者工具编译、预览、真机调试才算真正跑起来。这个压缩包的套路也很统一底部导航一般放首页、菜单、订单、我的四个入口中间用一组模拟 JSON 当作菜品数据接口域名多半写着示例地址。它的核心价值不是给你一个能直接上线的成品而是帮你省掉从零搭 tabBar、写页面结构、设计购物车状态这一大截重复工作。你真正要做的是把模板的菜品换成自己店的把示例接口换成真实后端把样式改成客户想要的色系。这篇内容适合刚接了餐饮客户单子想快速出效果的开发者也适合想学小程序页面结构但不想从 hello world 起步的人我会按“摸清结构—跑通工程—改业务—避坑—上线”的顺序把整套路径讲完。2. 打开模板工程目录结构、导入步骤与第一次编译通过2.1 先看 zip 里装了什么每个目录的职责边界解压之后不要急着双击 app.js先站在根目录看一遍结构。餐饮商户模板的目录布局大同小异常见的是这样一张表目录 / 文件职责你最先要关注的点pages/所有页面每个页面一个文件夹含 wxml、wxss、js、json首页、菜单页、购物车页、订单页、我的页是否齐全components/自定义组件比如购物车栏、数量加减、菜品卡片组件是否耦合了写死的菜品数据utils/公共方法config.js 和 api.js 通常在这里baseUrl、appid、请求封装是你第一个要改的文件images/静态图片资源tabBar 图标是否要替换成客户的店招app.json全局配置决定入口页面、tabBar、窗口样式pages 数组第一项就是启动页app.js全局生命周期和全局数据是否塞了模板作者自己的逻辑project.config.json开发者工具的工程配置里面可能残留作者的 appid 和 projectname很多模板还会带一个 README但别指望它写得清楚。以我的经验最靠谱的做法是先把 utils/config.js 和 app.json 通读一遍这两个文件能告诉你模板的接口地址、页面路由、还有作者留没留后门。project.config.json里的 appid 是模板作者自己的导入后必须换成你的否则真机预览会白屏后面第 5 章会专门讲这个坑。2.2 导入开发者工具之前先做三个准备动作动作一把压缩包放到一个路径干净的地方。别放在桌面那种带空格和中文的目录里也不要放进网盘同步盘某些同步工具会把编译产物同步到云端导致莫名奇妙的报错。我一般会建一个专门放小程序源码的目录mkdir -p ~/dev/miniprogram cd ~/dev/miniprogram unzip 餐饮商户模板.zip ls -lals -la是为了确认解压后是不是只有一层目录。许多压缩包解压后会出现两层同名目录比如餐饮商户模板/餐饮商户模板/如果你导入后报 app.json 找不到大概率就是选到了外层那一层。正确的导入路径应该是直接包含 pages 和 app.json 的那一层。动作二打开微信开发者工具选择“小程序”点“导入”目录指到包含 app.json 的文件夹。导入时后端服务会问你用不用云开发如果模板里没有cloudfunctions目录就选“不使用云服务”。很多餐饮模板是纯前端加后端接口的写法硬开云开发只会多一层环境配置反而拖慢节奏。动作三编译之前在开发者工具的“详情—本地设置”里勾选“不校验合法域名、web-view 业务域名、TLS 版本以及 HTTPS 证书”。这是开发期偷懒用的模板里的示例接口大多数不是 HTTPS或者域名没配进白名单不勾选会直接请求失败。上线前要记得关掉这个选项并在小程序后台配置真实域名。2.3 app.json 是模板的门面路由、tabBar 和窗口配置app.json 是理解一个模板最快的地方。pages 数组的第一个页面就是启动页很多餐饮模板会把首页和菜单页合并也有的把点餐页当作 tabBar 的第一项。下面是一段典型的配置{ pages: [ pages/menu/menu, pages/cart/cart, pages/order/order, pages/user/user ], window: { navigationBarTitleText: 某某食堂, navigationBarBackgroundColor: #FF6B35, navigationBarTextStyle: white }, tabBar: { list: [ { pagePath: pages/menu/menu, text: 点餐 }, { pagePath: pages/cart/cart, text: 购物车 }, { pagePath: pages/order/order, text: 订单 }, { pagePath: pages/user/user, text: 我的 } ] } }pages 里每一项对应一个页面目录数组的顺序决定加载优先级但启动页是数组第一个不是 tabBar 第一个。tabBar 的 list 最少 2 项、最多 5 项每一项的 pagePath 必须存在于 pages 数组里否则编译直接报错。改完 tabBar 之后必须重新编译开发者工具有时候不会自动刷新 tabBar。初次编译通过之后你会看到模板自带的模拟数据全部渲染出来。此时不要急着改样式先做一件事在模拟器里把每个 tab 都点一遍看哪些页面能跳转、哪些按钮是死的。很多压缩包作者会把结算、提交订单这类后端强依赖的按钮写成 console.log 占位你要做的就是把这些占位点全部找出来列成一个清单后面改业务的时候逐个替换。3. 菜单点餐与购物车结算模板的业务核心怎么改才顺手3.1 菜单数据是写死的 JSON找到它就能换菜品餐饮模板的菜单页基本都长一个样左侧分类列表右侧菜品卡片点“加入”按钮往购物车里塞。页面本身不复杂麻烦的是数据源。模板为了开箱即用通常会把菜品数据直接写在某个 js 文件的常量里const foodData [ { id: 1, name: 招牌红烧肉, price: 38, categoryId: 1, imageUrl: /images/dish_01.png, sales: 120 }, { id: 2, name: 清炒时蔬, price: 18, categoryId: 1, imageUrl: /images/dish_02.png, sales: 86 } ];这里的 id 是购物车关联的唯一标识不能重复也不能为 0很多新手把 id 写成数组下标后续删除菜品时会出现引用错乱。price 字段必须用 Number 类型不要写成字符串否则后面算总价时会变成字符串拼接。imageUrl 如果以后要换成网络图片记得把图片的域名加进小程序后台的 downloadFile 合法域名不然菜品图裂掉。页面渲染用的是 wx:for仔细看模板里是怎么写wx:key的view wx:for{{foodList}} wx:keyid classdish-item image src{{item.imageUrl}} modeaspectFill/image view classdish-name{{item.name}}/view view classdish-price¥{{item.price}}/view button sizemini bindtapaddToCart>addToCart(e) { const id e.currentTarget.dataset.id; const dish this.data.foodList.find(item item.id id); if (!dish) return; const cart this.data.cart; const exist cart.find(item item.id id); if (exist) { exist.count 1; } else { cart.push({ ...dish, count: 1 }); } this.setData({ cart }); }这个写法在功能上没问题但有两个隐患。第一直接在exist上改count属于就地修改对象属性微信的 setData 会做浅对比如果视图层没有正确更新排查时很难第一时间想到是这里的问题。更稳妥的做法是不可变更新用map生成一个新数组再整体 setData。第二如果菜品有规格比如“大份”“小份”这个写法会把同一个 id 的不同规格算成同一条正确的做法是把skuId也作为购物车唯一的判断条件规格选择用radio-group或者自绘单选按钮。购物车数量加减、清空、删除这些交互模板大多写了但结算按钮往往只是弹一个 toast。这里要重点看模板对购物车缓存的处理方式wx.setStorageSync(cart, cart);模板可能会在每次变更购物车时同步缓存下次启动再从缓存恢复。这本身没问题但当你改了菜品结构、调整了 price 字段类型之后旧缓存还在就会导致金额对不上、菜品显示异常。遇到这种“缓存幽灵”最简单的办法是在代码里加一个版本号缓存结构变化时主动清掉旧数据或者开发期直接把wx.setStorageSync先注释掉。3.3 结算金额口径前端算的和后端算的是两回事提交订单时前端展示的总金额和后端实际生成的订单金额经常对不上。常见的做法有两种一种是前端把 total 传给后端后端只取数量、不信任前端价格按服务端数据库里的最新价格重新算另一种是后端返回价格前端只做展示。餐饮模板基本都走第一种因为菜品价格会变门店可能会临时打折。结算页的金额计算一般长这样const total cart.reduce((sum, item) sum item.price * item.count, 0); const deliveryFee total minFreeDelivery ? 0 : baseDeliveryFee; const payable total deliveryFee; if (total minOrderAmount) { wx.showToast({ title: 未达到起送价, icon: none }); return; }这里的minFreeDelivery免配送费门槛、baseDeliveryFee基础配送费、minOrderAmount起送价是三个独立参数模板里往往写死成常量要改成从后端配置接口拉取。配送费经常被忽略但餐饮订单里它是金额纠纷的高发区起送价到底是按商品金额算还是按券后金额算免配送费门槛到底含不含餐盒费这些口径必须前后端对齐。优惠券的分摊逻辑也是矛盾重灾区。优惠券按整单减、按品类减、按满减阶梯前端算出来的券后金额和后端算的经常差几毛钱。我一般会把用户实付部分的计算全部丢给后端前端只负责把购物车明细传上去然后展示后端返回的payableAmount。前端那个计算逻辑只保留两个用途给用户一个实时预估以及在下单前做起送价和库存的即时校验。4. 手机号授权与登录链路在餐饮场景里怎么接才不碰壁4.1 手机号快速验证旧模板里的登录写法基本过时了很多餐饮模板的登录页还在用老一套button open-typegetPhoneNumber配合getUserInfo拿头像昵称。这套组合在现在的审核规则下基本走不通头像昵称获取权限早就收回了手机号那段也改成了手机号快速验证组件。现在的标准做法是用户点按钮微信侧完成验证前端拿到一个 code把这个 code 交给后端由后端调用接口换取手机号。button open-typegetPhoneNumber bindgetphonenumberonGetPhoneNumber 微信一键登录 /buttononGetPhoneNumber(e) { if (!e.detail.code) { // 用户点了取消这里不要反复弹框 return; } wx.request({ url: ${apiBase}/auth/phone, method: POST, data: { code: e.detail.code }, success: (res) { wx.setStorageSync(token, res.data.token); // 下一步跳回下单流程 } }); }有几个关键点。第一e.detail.code是一次性的后端拿它换手机号前端永远拿不到手机号明文也不要去尝试解密。第二这个能力要求小程序主体是企业或个体工商户且已完成认证个人主体的小程序没有这个权限调用会直接报错。第三开发者工具模拟器里点这个按钮不会触发真实的微信验证测试时必须真机预览。模板里如果还留着旧版加密数据解密的代码比如用session_key自己解encryptedData的逻辑直接删掉。新的快速验证组件把解密完全放到了后端前端代码反而更干净了。我见过不少开发者死磕这个解密过程最后发现只是基础库版本太旧、组件压根没生效升级基础库就好了。4.2 先逛再登录把登录时机放在提交订单上餐饮场景的转化漏斗是“看到菜单—加购—提交订单”一进小程序就弹登录框会流失一大半用户。模板默认的登录时机如果是在首页弹授权我的做法是先改成游客模式菜单能看、购物车能加等到用户点“提交订单”时才触发登录。submitOrder() { const token wx.getStorageSync(token); if (!token) { this.showLoginModal(); return; } this.buildOrderAndPay(); }这里有两个容易忽略的细节。第一wx.login获取 code 是静默的不需要用户任何操作你可以用它换一个匿名身份标识让用户在未登录状态下也能把购物车和订单草稿同步到服务端。等用户点了微信一键登录再把匿名身份和手机号绑定。这套“先匿名后绑定”的流程很多模板没做但运营起来差距很大。第二token会过期不能只看本地有没有 token 就放行下单。后端接口遇到过期 token 会返回 401常见做法是在wx.request的响应拦截器里统一判断401 时清除本地 token 并重新拉起登录流程。模板的“我的”页面通常会显示用户头像昵称。现在官方推荐头像昵称填写能力也就是open-typechooseAvatar配合 input 输入昵称而不是直接读取微信资料。这块在餐饮场景里优先级不高可以靠后做但不要在登录环节强行要求用户填昵称头像会平白增加阻挡。下单链路最为关键的校验只有一个这个手机号能联系到用户。5. 餐饮模板必踩的 6 个坑从白屏到金额对不上的排查路径下面六个坑是我实际交付模板时反复遇到的按排查顺序写每条都是“现象—原因—解决”你遇到哪个直接对号入座。5.1 真机白屏模拟器却一切正常现象开发者工具里预览流畅扫码到手机上打开却是白屏或者一直转圈。原因无外乎三种。第一导入时用的是测试号真机预览要求有合法 AppID测试号的权限范围根本撑不起来。第二模板里有明文 HTTP 请求真机环境默认拦截非 HTTPS 和未配置域名。第三页面 onLoad 里抛了异常没被捕获模拟器容错能力强真机直接卡死。解决先看详情里的 AppID 是不是你自己的再看 console 有没有request:fail报错最后全局搜索http://全部替换成https://并把接口域名加进小程序后台的 request 合法域名。5.2 顶部导航栏高度适配别写死 44px现象模板用了自定义导航栏navigationStyle: customiPhone 上正常换成带返回键的安卓机型标题被状态栏挡住按钮位置偏移。原因状态栏高度每个机型不一样微信小程序的导航栏高度并不是固定值模板里写死的 44px 只是 iPhone 的视觉高度。解决动态计算导航栏占位高度。用wx.getMenuButtonBoundingClientRect()拿到右上角胶囊按钮的位置再叠加状态栏高度const menuRect wx.getMenuButtonBoundingClientRect(); const systemInfo wx.getSystemInfoSync(); const navHeight (menuRect.top - systemInfo.statusBarHeight) * 2 menuRect.height; const statusBarHeight systemInfo.statusBarHeight;navHeight就是自定义导航栏的总高度statusBarHeight是顶部状态栏高度。页面里用一个占位 view 动态绑定这个高度而不是写死在 wxss 里。这个改动要覆盖所有使用了自定义导航栏的页面模板里通常不止一个。5.3 手机号按钮没反应或报 no permission现象真机上点了“微信一键登录”没反应回调里返回 fail提示getPhoneNumber:fail no permission。原因小程序主体是个人未认证或者基础库版本太低再或者是在开发者工具模拟器里点的。解决先去小程序后台确认主体类型和认证状态个人主体没有这个权限这是硬门槛。基础库在详情里切到最新版本。然后必须真机预览测试模拟器上永远测不出真实结果。5.4 店铺地图位置偏了一公里现象模板里用 map 组件或wx.openLocation显示店铺位置部分安卓机型上定位点和实际店铺差很远。原因两套坐标系的问题。国内地图用的是 gcj02 坐标而wx.getLocation默认返回 wgs84不转换直接画点就会偏移。另外模板里写死的店铺经纬度可能是作者自己随手填的旧数据。解决wx.getLocation调用时指定type: gcj02店铺坐标也统一维护成 gcj02 格式。如果用的是地图服务商的 SDK需要单独申请 key 并在后台配置域名。这个坑在模拟器上通常测不出来必须真机验证。5.5 购物车总金额与后端订单金额对不上现象用户加购、改数量后前端展示 100 元提交订单后端算出来是 96 元。原因前端缓存里存的是旧价格后端从服务端数据库拿的是最新价格另外优惠券分摊逻辑两边不一致。解决进入结算页前先请求一次最新菜品价格以服务端为准重建购物车。起送价、配送费、优惠券全部由后端计算前端只展示结果。订单生成时后端把前端 total 和自己计算的 total 比对差异超过阈值就记录异常方便排查。5.6 模板里残留着作者的 AppID、接口域名和调试日志现象小程序上线后被用户看到 console 里打印了接口地址或者请求打到模板作者自己的服务器上。原因模板作者把 AppID、baseUrl、测试密钥写在 config.js 里下载者没改就发布了。解决上线前做一轮全局搜索grep -r appid --include*.js --include*.json . grep -r https:// --include*.js . grep -r console.log --include*.js .第一个命令查 AppID第二个查请求域名第三个查调试输出。把搜索结果逐个过一遍AppID 换成自己的请求域名换成自己的后端地址console.log该删的删。调用的第三方 key 也要查比如地图 key、支付密钥这些一旦漏了别人可以直接盗用你的配额。6. 上线前的一轮“瘦身与加固”让模板变成你自己的项目模板跑通只是第一步能不能上线交付还要做三件事。第一件是瘦身删掉模板里用不到的页面和示例数据压缩 images 目录里的大图注意 tabBar 图标尺寸要控制在 40KB 以内。第二件是加固全局搜索 AppID 和域名替换干净在开发者工具详情里关闭“不校验合法域名”在小程序后台配置 request 合法域名、downloadFile 合法域名和业务域名首次提交审核前把隐私协议弹窗接好。第三件是验证我习惯按这个清单过一遍验证项操作路径预期结果真机登录预览二维码 → 真机打开 → 点微信一键登录能拿到手机号token 写入缓存下单链路加购 → 结算 → 提交订单 → 模拟支付状态流转正常金额与后端一致地图定位真机打开店铺位置定位与实际店铺吻合请求域名后台配置后关闭本地校验接口全部走 HTTPS 且无 domain 报错最后一个值得投入的进阶改造是分包。餐饮模板的图片资源多主包很容易超过 2MB 限制。把菜单页、订单列表这类非首屏页面拆到分包里主包只保留 tabBar 页面和公共组件能显著降低首次加载耗时。app.json 里加一段subpackages字段即可{ subpackages: [ { root: packageMenu, pages: [pages/detail/detail, pages/checkout/checkout] } ] }分包里的页面路径在跳转时要写成/packageMenu/pages/detail/detail完整路径带分包根目录。我交付第一个餐饮模板时图省事没清 console 日志结果在体验版里被客户截图指出接口地址和测试 key 全暴露在外面那次改得很狼狈。从那以后我每次上线前都保留一个固定动作全局搜索 AppID、域名、console.log把模板的作者痕迹清干净再检查一遍页面跳转路径有没有硬编码。这个习惯帮我躲过不少次发布后的尴尬也让我对模板里的每一行代码都心里有数。希望帮到你。本文还有配套的精品资源点击获取