企业官网建设流程全解析

简介：基于云开发的大学食堂点餐预约小程序，是一套可直接运行与二次开发的完整源码资源，面向小程序开发学习者、高校计算机相关专业学生，以及需要课堂设计或毕业设计参考的读者。压缩包共138个文件，以JavaScript业务逻辑、JSON数据配置、WXML/WXSS前端页面文件为主，搭配PNG、JPG图片素材与一份Markdown说明文档，整体仅577KB，结构紧凑、便于阅读。项目以云函数处理用户认证、订单创建、支付回调与通知推送，用云数据库存储菜品、订单和预约信息，实际覆盖了菜单浏览、购物车、下单、预约取餐、订单状态跟踪等核心流程，并设计了HTTPS传输与关键操作权限控制，展示了云开发架构在餐饮场景下的完整落地思路。目前已有204人浏览学习，既能帮助掌握小程序前端交互与云端协同，也能为食堂点餐效率优化提供高性价比的参考方案。

1. 基于云开发的大学食堂点餐预约小程序：不买服务器怎么把点餐系统跑起来

大多数做食堂点餐小程序的人，第一道坎不在前端，而在后端。买服务器、配域名、走备案，这套流程还没走完，课程设计的截止日期先到了。基于云开发的大学食堂点餐预约小程序，把后端整体搬进了微信云开发环境，云函数、云数据库、云存储三件套全在微信生态内闭环，不需要自己运维服务器，也不用碰 Linux 命令行。这套资源覆盖了用户注册登录、菜单浏览、购物车、下单支付（演示场景走模拟支付）、预约取餐时间、订单状态跟踪、评论发布，以及管理端的菜品发布、订单管理和数据统计。适合正在做课程设计、毕业设计，或者想快速验证一个校内餐饮点餐 demo 的开发者。新手可以直接导入微信开发者工具跑起来，熟手可以根据文件命名反推业务模块，再按需替换成自己的菜单和样式。下面按我实际拆解这套资源的顺序来写，先讲文件结构，再讲云开发配置，然后跑通完整流程，最后是踩坑记录。

2. 拆解页面文件与业务模块：dp.js、gwx.js、qccg.js 分别管什么

拿到这套资源的第一件事，不是急着跑代码，而是先看目录结构。微信小程序的项目里，JS 文件名基本决定了页面职责。这套资源里的页面文件不算多，但恰好覆盖了一个点餐小程序最核心的用户端和管理端两侧。

2.1 页面文件与职责映射：从文件名反推业务模块

先列一下这套资源里出现的文件：cszp.jpg、fbpl.js、ddgl.js、sjgl.js、qccg.js、dp.js、gwx.js、dingdan.js、my.js。cszp.jpg 是菜品相关图片素材，其余八个 JS 文件各对应一个业务页面。按微信小程序的命名习惯，每个页面通常是四件套：js、wxml、wxss、json，这套资源里以 js 文件为入口，导入后配套文件会一并带过来。

我按文件名反推的业务模块是这样的：

这个映射不是官方文档，是我根据文件名和点餐业务常识反推的。实际导入项目后，可以直接在 app.json 的 pages 数组里确认每个页面的路由和页面标题，页面标题可以在各页面的 json 文件里改 navigationBarTitleText。如果你拿到手的资源和我的推测有出入，优先以实际代码为准。

2.2 从购物车到取餐成功：用户端主链路在文件里的落点

用户端的主链路可以压缩成四条：浏览菜品、加购物车、下单支付、取餐完成。这四条链路分别落在 dp.js、gwx.js、dingdan.js、qccg.js 四个文件里。

dp.js 承担的是食堂首页的职责。微信小程序里页面加载数据一般写在 onLoad 或 onShow 里，dp.js 的逻辑大概率是调用云函数或直接查云数据库的 dishes 集合，按分类把菜品渲染到页面上。这里有个小程序开发里很常见的细节：菜品图片不要直接打包进项目，而是用云存储的 fileID 引用，否则主包体积很容易顶到 2MB 上限，后面第 5 章会展开讲。

gwx.js 对应的购物车逻辑，是这套资源里最考验数据同步的地方。常见做法是购物车数据不落云数据库，直接存在本地缓存 wx.setStorageSync 里，因为购物车是强实时、低持久化需求的数据。我拆过的项目里也有把购物车同步到云端 cart 集合的，好处是换设备不丢，坏处是每次增减都要调接口，体验会差一些。判断标准很简单：购物车要不要支持多端同步。如果只是单设备演示，本地缓存完全够用。

qccg.js 是这套资源里比较有特色的页面。取餐成功页通常展示一个取餐码，食堂窗口凭码出餐。这个小程序的核心卖点在"预约"——用户先选好取餐时段，到点再去窗口拿，避开排队高峰。取餐码的生成逻辑一般放在云函数里，随机生成六位数字码，同时把订单状态从"准备中"改成"待取餐"，用户凭码取餐后，食堂端再确认完成。

2.3 管理端模块：fbpl.js、ddgl.js、sjgl.js 的数据边界

管理端三个文件相对独立：ddgl.js 管订单，sjgl.js 管数据，fbpl.js 管评论。

ddgl.js 订单管理页，管理端看到的是所有用户的订单，而用户端 dingdan.js 只能看到自己的订单。这个差异靠云数据库的权限规则实现，第 3 章会细讲。订单管理页最常见的操作是把订单状态往前推：待支付、已支付、准备中、待取餐、已完成，每一步都是一个状态变更，对应一次云数据库 update 或云函数调用。

sjgl.js 数据管理页，在课程设计场景里通常是按菜品维度统计销量，比如今天哪些菜卖得最多、哪个时间段的预约最集中。这类统计如果直接在小程序端做，数据量一大页面就会卡，正确做法是用云函数做聚合查询，把结果算好再返回给前端渲染。榜单数据还可以顺带写回一个 stats 集合，前端读起来更轻。

fbpl.js 发布评论页，用户对已完成订单里的菜品打分和写文字评价。这里有个权限细节：评论的写入资格应该限定为"订单归属人才有权限"，而不是任何人随便写。判断逻辑放在云函数里做，前端只负责收集表单内容后调用接口。

管理端和用户端的数据边界，核心一句话：用户端只能读写自己的数据，管理端通过云函数操作全局数据，前端页面不要直接放开管理集合的写权限。这个边界如果设计反了，就会出现用户能改订单金额这种事故。判断一个操作该走云函数还是直连数据库，就看它操作的数据是不是跨用户维度的。

3. 云开发三件套落地：云函数、云数据库与权限模型

这套资源的技术底座是微信云开发，核心组件就是云函数、云数据库、云存储。第 2 章把页面文件拆完了，这一章把后端怎么接讲清楚。

3.1 云函数选型与订单创建实现

云函数在微信云开发里是一个 Node.js 运行环境，每个函数对应一段业务逻辑。这套资源里至少需要四个云函数：createOrder（创建订单）、updateOrderStatus（更新订单状态）、generatePickupCode（生成取餐码）、sendNotify（发送订阅消息）。如果还想做销量统计，再加一个 dailyStats 定时触发器。

先看订单创建的云函数，这是整个小程序里逻辑最密集的一个函数：

// cloudfunctions/createOrder/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() exports.main = async (event, context) => { const { OPENID } = cloud.getWXContext() const { items, pickupTime, note } = event if (!items || items.length === 0) { return { code: -1, msg: '订单不能为空' } } // 从菜品集合重新拉价格，不信任前端传过来的金额 let totalPrice = 0 for (const item of items) { const dishRes = await db.collection('dishes').doc(item.dishId).get() if (!dishRes.data || dishRes.data.status !== 'on') { return { code: -2, msg: `菜品 ${item.dishName} 已下架` } } totalPrice += dishRes.data.price * item.count } // 生成六位取餐码 const code = String(Math.floor(100000 + Math.random() * 900000)) const orderRes = await db.collection('orders').add({ data: { _openid: OPENID, items: items.map(i => ({ dishId: i.dishId, dishName: i.dishName, price: i.price, count: i.count })), totalPrice, pickupCode: code, pickupTime: new Date(pickupTime), status: 'pending', // pending 待支付 / paid 已支付 / preparing 准备中 / ready 待取餐 / done 已完成 note: note || '', createTime: db.serverDate() } }) return { code: 0, orderId: orderRes._id, totalPrice, pickupCode: code } }

这段代码有几个必须注意的点。第一，价格必须在云函数里重新从数据库拉取，绝不能信任前端传过来的 totalPrice，这是防止篡改订单金额的底线。第二，取餐码在服务端生成，避免用户端伪造重复码。第三，订单状态用一个字符串字段维护，配合注释里的状态字典，后续状态机流转全靠这个字段。

云函数的超时时间默认是 3 秒，上面这个函数涉及多次数据库查询和写入，首次调用还可能触发冷启动，建议在云开发控制台把这个函数的超时时间调到 10 秒以上。云函数是按调用次数和资源使用量计费的，像 createOrder 这种低频但重的函数，整体成本很低。

3.2 云数据库集合设计与权限规则

数据库集合的设计直接决定后续开发的顺畅程度。这套资源至少需要四个集合：dishes（菜品）、orders（订单）、reviews（评论）、users（用户扩展信息）。如果有购物车云端同步的需求，再加一个 cart 集合。

dishes 集合的典型字段结构：

orders 集合的关键字段是 status、pickupTime、pickupCode。pickupTime 建议存成 Date 类型，方便后续做"按时间段统计预约人数"这类范围查询。冗余字段能省则省，云数据库按读写次数计费，字段越少读写越便宜。

权限规则这块是新手最容易翻车的地方。微信云数据库的默认权限是"仅创建者可读写"，用户只能读写自己创建的数据。这个默认规则对 orders、cart、reviews 是合理的，但对 dishes 不适用——菜品是管理端创建的，用户端要读。所以 dishes 的权限必须改成"所有用户可读，仅创建者可写"，设置路径在云开发控制台 → 数据库 → 集合 → 权限设置。

管理端对订单的全局修改，不能靠放开数据库权限来实现，而是走云函数。云函数运行在服务端环境中，不受前端权限规则限制。也就是说，ddgl.js 页面里管理订单的所有操作，都应该封装成云函数调用。

// cloudfunctions/updateOrderStatus/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() exports.main = async (event, context) => { const { orderId, newStatus } = event const validStatus = ['paid', 'preparing', 'ready', 'done', 'canceled'] if (!validStatus.includes(newStatus)) { return { code: -1, msg: '非法状态' } } await db.collection('orders').doc(orderId).update({ data: { status: newStatus, updateTime: db.serverDate() } }) // 状态变为 ready 时，触发订阅消息推送 if (newStatus === 'ready') { // 这里调用 sendNotify 下发模板消息，订单状态变更及时告诉用户 } return { code: 0 } }

用白名单校验 validStatus，防止管理端误传一个不存在的状态值。订单状态机设计成线性流转，不做跳跃式更新，比如"已支付"不能直接跳到"已完成"，必须经过"准备中"和"待取餐"。这样食堂操作记录可追溯，出了纠纷也能从状态变更时间倒查。

3.3 云存储托管静态资源与图片加速

云存储在这套资源里的角色很简单：放菜品图片、评论配图、用户头像。cszp.jpg 就是典型的菜品图片素材，使用前先传到云存储，拿到 fileID 后再写到 dishes 集合的 image 字段里。

为什么不让图片直接打包进小程序？微信小程序主包限制 2MB，一张高清菜品图动辄几百 KB，放十张就超了。云存储的 fileID 在小程序端可以直接通过 image 组件的 src 渲染，不需要拼接完整 URL。云存储自带 CDN 分发，宿舍弱网环境下加载图片也不会太慢。

给管理端上传菜品图时，常见的做法是 wx.chooseMedia 选图，然后 wx.cloud.uploadFile 传到云存储，返回 fileID 后和菜品表单一起提交。这里有个小技巧：上传前先用 wx.compressImage 把图片压缩到宽度 750px 左右、质量 80%，一张图能从 500KB 压到 100KB 以内，既省存储费用又加快页面加载。

4. 跑通完整点餐预约流程：从浏览菜单到取餐成功的代码路径

第 3 章把云开发后端的骨架搭好了，这一章把用户端和管理端的完整流程串起来，每一步落一个代码块。

4.1 菜单加载与购物车逻辑

先看 dp.js 怎么把菜单从云数据库拉出来。常见做法是 onLoad 里面直接查云数据库，按分类分组渲染：

// pages/dp/dp.js const db = wx.cloud.database() Page({ data: { categories: [], currentCategory: '', dishList: [] }, async onLoad() { wx.showLoading({ title: '加载菜单中' }) try { const res = await db.collection('dishes') .where({ status: 'on' }) .orderBy('category', 'asc') .get() const categories = [...new Set(res.data.map(d => d.category))] this.setData({ categories, currentCategory: categories[0] || '', dishList: res.data }) } catch (err) { console.error('菜单加载失败', err) wx.showToast({ title: '菜单加载失败', icon: 'none' }) } finally { wx.hideLoading() } }, addToCart(e) { const { dish } = e.currentTarget.dataset let cart = wx.getStorageSync('cart') || [] const exist = cart.find(item => item.dishId === dish._id) if (exist) { exist.count++ } else { cart.push({ dishId: dish._id, dishName: dish.name, price: dish.price, count: 1 }) } wx.setStorageSync('cart', cart) wx.showToast({ title: '已加入购物车', icon: 'success' }) } })

这里用到 wx.getStorageSync 同步读取本地缓存，不用 await。addToCart 从事件对象的 dataset 里拿 dish 数据，要注意 wxml 里绑定数据时用>// pages/gwx/gwx.js Page({ data: { cartList: [], totalPrice: 0 }, onShow() { // 每次回到购物车页都重新加载，保证数据最新 this.loadCart() }, loadCart() { const cart = wx.getStorageSync('cart') || [] const totalPrice = cart.reduce((sum, item) => sum + item.price * item.count, 0) this.setData({ cartList: cart, totalPrice: totalPrice.toFixed(2) }) }, changeCount(e) { const { index, delta } = e.currentTarget.dataset const cart = this.data.cartList cart[index].count += delta if (cart[index].count <= 0) { cart.splice(index, 1) } wx.setStorageSync('cart', cart) this.loadCart() }, async checkout() { const cart = this.data.cartList if (cart.length === 0) { wx.showToast({ title: '购物车是空的', icon: 'none' }) return } wx.navigateTo({ url: '/pages/confirm/confirm?items=' + encodeURIComponent(JSON.stringify(cart)) }) } })

onShow 里加载购物车是关键，用户从其他页面返回购物车时，数据必须是最新的。checkout 把购物车数据序列化后拼到 URL 上跳转确认订单页，适合数据量不大的场景。如果购物车条目很多，URL 会过长，那种情况应该把数据放全局变量或直接存到暂存集合里。

4.2 下单与订单状态机设计

确认订单页收集取餐时段和备注，然后调用 createOrder 云函数。取餐时段组件建议用微信原生的 picker，mode 选 selector，食堂场景下取餐时段通常是固定的几个时间段，没必要让用户自由选分钟：

// pages/confirm/confirm.js Page({ data: { items: [], totalPrice: 0, pickupSlots: ['11:00-11:30', '11:30-12:00', '12:00-12:30', '17:00-17:30'], slotIndex: 0, note: '' }, onLoad(options) { const items = JSON.parse(decodeURIComponent(options.items)) const totalPrice = items.reduce((sum, i) => sum + i.price * i.count, 0) this.setData({ items, totalPrice: totalPrice.toFixed(2) }) }, async submitOrder() { wx.showLoading({ title: '提交中' }) try { const res = await wx.cloud.callFunction({ name: 'createOrder', data: { items: this.data.items, pickupTime: this.data.pickupSlots[this.data.slotIndex], note: this.data.note } }) if (res.result.code === 0) { wx.removeStorageSync('cart') wx.redirectTo({ url: '/pages/dingdan/dingdan?orderId=' + res.result.orderId }) } else { wx.showToast({ title: res.result.msg, icon: 'none' }) } } catch (err) { console.error('下单失败', err) wx.showToast({ title: '网络异常，请重试', icon: 'none' }) } finally { wx.hideLoading() } } })

下单成功后的跳转用 redirectTo 而不是 navigateTo，目的是不让用户通过返回键回到确认订单页重复下单。这个细节看起来小，但实际使用中特别重要——如果用户下单成功后按返回，购物车已经清了，页面数据还是之前的，极易产生重复订单。

订单状态机在创建时是 pending（待支付），演示场景下点击"模拟支付"按钮后调用 updateOrderStatus 把状态改成 paid，食堂端看到 paid 订单后改成 preparing。状态流转的每一步都记录 updateTime，方便管理端排查问题。

订单列表页 dingdan.js 的核心是分页加载更多。云数据库查询默认最多返回 20 条，超出部分要用 skip 或游标翻页：

// pages/dingdan/dingdan.js const db = wx.cloud.database() Page({ data: { orders: [], page: 0, pageSize: 10, hasMore: true }, onShow() { this.loadOrders(true) // 每次进入页面刷新第一页 }, async loadOrders(reset = false) { const { page, pageSize } = this.data const targetPage = reset ? 0 : page const res = await db.collection('orders') .where({ _openid: '{openid}' }) .orderBy('createTime', 'desc') .skip(targetPage * pageSize) .limit(pageSize) .get() const orders = reset ? res.data : this.data.orders.concat(res.data) this.setData({ orders, page: targetPage + 1, hasMore: res.data.length === pageSize }) }, onReachBottom() { if (this.data.hasMore) { this.loadOrders(false) } } })

where 条件里用{openid}占位符是微信云数据库的语法糖，会自动替换成当前用户的 openid，等价于手动从云函数拿 openid 再拼进查询条件。onReachBottom 是页面滚动到底部的生命周期回调，配合 hasMore 标志避免 loading 更多时重复请求。如果要加"下拉刷新"，在页面 json 里开启 enablePullDownRefresh，onPullDownRefresh 里同样调 loadOrders(true) 重置列表。

4.3 预约取餐时段与订单状态跟踪

预约取餐的闭环在 qccg.js 取餐成功页收尾。订单状态流转到 ready（待取餐）时，用户打开订单详情能看到取餐码。取餐码页面建议做成大字号展示，方便食堂窗口核对。如果食堂没有扫码枪，数字码人工核对也够用。

订单状态跟踪的关键是让 dingdan.js 页面在 onShow 时刷新最新状态。用户从取餐成功页返回订单列表，onShow 触发 loadOrders(true)，列表里的状态文字就是最新的。这里有个体验优化点：状态变更时用 wx.showToast 做轻提示，而不是跳转页面，避免打断用户操作流程。

管理端 ddgl.js 的订单列表和用户端结构类似，只是查询条件从 _openid 换成按 status 分组。管理端的核心操作是状态推进，每个操作按钮对应一次 updateOrderStatus 云函数调用，按钮根据当前状态动态渲染。比如 pending 订单显示"确认收款"，paid 订单显示"开始制作"，preparing 显示"出餐"，ready 显示"完成订单"。

sjgl.js 数据管理页的销量统计，用云函数聚合查询比前端循环靠谱得多：

// cloudfunctions/dailyStats/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() exports.main = async (event, context) => { const $ = db.command.aggregate const res = await db.collection('orders').aggregate() .match({ status: 'done', createTime: db.command.gte(new Date(new Date().setHours(0, 0, 0, 0))) }) .unwind('$items') .group({ _id: '$items.dishId', dishName: $.first('$items.dishName'), totalCount: $.sum('$items.count'), totalAmount: $.sum($.multiply(['$items.price', '$items.count'])) }) .sort({ totalCount: -1 }) .limit(10) .end() return res.list }

聚合管道先按当天已完成订单过滤，unwind 把 items 数组拍平，然后按菜品分组求和，最后按销量倒序取前十条。这个写法比前端逐条统计高效太多，数据量哪怕到几千单也扛得住。

5. 避坑手册：云开发小程序的五个高频翻车现场

云开发虽然省掉了服务器运维，但坑一点不少。这一章是我拆这套资源和实际跑小程序时遇到的高频问题，按"现象 → 原因 → 解决"的格式写。

5.1 云函数冷启动导致首次调用超时

现象：用户第一次进入点餐页，点击下单后 loading 转圈超过 3 秒，控制台报错提示云函数调用超时。

原因：云函数是按需运行的容器，首次调用或长时间闲置后的再次调用需要冷启动，Node.js 运行时加载加依赖安装，几秒到十几秒不等。云函数默认超时时间是 3 秒，冷启动很容易卡在这个阈值上。

解决：在云开发控制台找到对应云函数，把超时时间调到 10 秒以上。前端调用云函数时做一次重试机制，首次超时后自动重试一次，第二次基本能命中热启动。如果某个函数是高频入口，比如 createOrder，可以考虑设置固定并发预留让容器常驻，不过课程设计场景没必要。

5.2 数据库权限配置错误导致真机白屏

现象：微信开发者工具模拟器里菜单正常显示，一换到真机预览，菜品列表一片空白，控制台报权限错误。

原因：模拟器环境下默认以开发者身份读取数据，开发者对集合有完全权限；真机上小程序以普通用户身份运行，如果 dishes 集合权限还是默认的"仅创建者可读写"，用户端直接查 dishes 集合就会被拒绝。

解决：在云开发控制台数据库集合的权限设置里，把 dishes 改为"所有用户可读，仅创建者可写"。orders 和 cart 保持"仅创建者可读写"，reviews 改成"所有用户可读，创建者可写"。改完重新预览，真机上的菜单就出来了。以后每次新增集合，第一件事就是确认权限模型，别等真机测试才暴露。

5.3 主包体积超限与分包加载

现象：上传代码时提示 "main package source size 2612kb exceed max limit 2mb"，代码传不上去。

原因：菜品图片、UI 图片、第三方组件库都塞在主包里，主包体积超过了微信的 2MB 限制。

解决：把图片类资源全部上传到云存储，代码里用 fileID 引用，本地不再存放任何大图。代码层面按页面拆分分包，在 app.json 里配置 subPackages，把管理端页面 ddgl、sjgl 拆到单独分包，普通用户根本不需要加载管理端代码。拆完之后主包只保留用户端核心页面，体积能压到 1.5MB 以内。开发者工具详情面板里的"上传时压缩代码"选项勾上也能省一点体积，但这是辅助手段，治标不治本。

5.4 支付环节在个人主体下的替代方案

现象：调用 wx.requestPayment 发起支付，返回"商户号参数校验失败"。

原因：个人主体的小程序无法开通微信支付，必须企业或个体工商户主体，并且要申请微信支付商户号完成签约。课程设计场景下通常不具备这个条件。

解决：把支付节点抽象成一个状态字段。订单创建后状态是 pending，前端提供"模拟支付"按钮，点击后调用 updateOrderStatus 把状态改成 paid。按钮文案明确写成"模拟支付（演示）"，避免用户误解为真实扣款。如果做毕设答辩，模拟支付完全够用，答辩重点放在流程完整性和技术方案上，而不是真实交易。

5.5 订阅消息一次性限制与订单通知

现象：用户第一次接收到了"订单已就绪"的通知，第二次下单后就再收不到了。

原因：微信订阅消息是一次性订阅机制，用户每同意一次订阅，只能接收一条消息。用户第二次下单时没有重新点击订阅按钮，消息自然发不出去。

解决：在下单成功页主动引导用户点击"订阅取餐通知"按钮，每次下单触发一次订阅授权。消息发送时机放在云函数里，订单状态变成 ready 时调用 subscribeMessage.send 下发通知。食堂属于高频场景，长期订阅消息如果有对应类目资质是更好的选择，但大部分个人开发者申请不下来，先用一次性订阅顶着，埋点在订单确认页写清楚"订阅后可接收取餐提醒"即可。

云开发小程序的坑，绝大多数集中在权限配置、冷启动和体积控制这三块。遇到翻车不要慌，先看控制台报错信息，再对照权限配置和云函数日志，大多数问题三步内能定位。

6. 上线前的灰度验证与销量日报配置

代码跑通只是第一步，真正上线前还有几个环节值得花时间。这一章分享两个我每次必做的动作：发布前检查清单，以及用云函数定时触发器做销量统计。

6.1 上线前十分钟检查清单

按顺序过一遍，省得发布后手忙脚乱：

1. 数据库权限四类集合全部核对一遍，重点确认 dishes 是"所有用户可读"。
2. 云函数代码里检查有没有残留的测试 console.log 大量输出，避免日志费用虚高。
3. app.json 里的页面路由和分包配置检查一遍，确认管理端页面在分包里。
4. 真机预览完整走一遍流程：注册 → 浏览菜单 → 加购 → 下单 → 模拟支付 → 查看取餐码 → 评论。
5. 正式环境创建好，云函数环境变量和数据库集合在正式环境里重新配置一份。

其中第 4 步最花时间但也最值得。我每次都用同一个测试账号走完整链路，专门记录每一步的接口耗时，超过 1 秒的接口优先排查云函数冷启动和数据库索引问题。

6.2 用定时触发器生成食堂销量日报

第 4 章的 dailyStats 聚合查询是手动调用的，上线后可以改成定时触发器，每天早上 8 点自动跑一次，统计结果写入 stats 集合，sjgl.js 数据管理页直接读统计结果，前端零计算。

// cloudfunctions/dailyStats/config.json { "permissions": { "openapi": [] }, "triggers": [ { "name": "dailyStatsTrigger", "type": "timer", "config": "0 0 8 * * * *" } ] }

Cron 表达式0 0 8 * * * *表示每天 8 点触发，七段式从左到右是秒、分、时、日、月、周、年。定时触发器和手动调用共用一个 main 函数，函数内部通过 event 参数里是否有 TriggerName 字段来区分触发来源。上传方式是在微信开发者工具里右键云函数目录，选择"上传触发器"，然后到云开发控制台的云函数配置页确认触发器已生效。定时触发还有个好处：统计结果落库后，sjgl.js 前端查询压力大幅下降，不会再出现页面卡顿。

这套资源整体跑下来，我的感受是云开发的选型非常契合校园食堂这种中低频、强时段特征的业务场景。不买服务器、不备案、数据库按量付费，学生开发者的学习成本和落地成本都压得很低。我现在的习惯是，每次拿到一套小程序资源，先不动代码，花半小时把页面文件、数据库集合、云函数三个层面的关系画清楚再动手改——很多翻车其实都是因为没搞清楚数据边界就直接改代码导致的，这个习惯帮我省掉了大量返工时间。这套资源的文件结构、云开发配置、核心流程和踩坑记录我已经拆完了，实际动手时建议先用自己的菜单和菜品图片替换一遍，再考虑扩展多食堂切换、评价晒图这些需求，现有集合结构都撑得住。希望帮到你。

本文还有配套的精品资源，点击获取