简介这是一款基于云开发的大学食堂点餐预约小程序完整项目适合具备微信小程序基础、希望掌握云开发模式的学生开发者及高校信息化项目实践者。方案围绕云函数、云数据库、云存储展开覆盖用户注册登录、菜单浏览、购物车、在线支付、预约取餐、订单状态跟踪及消息推送等核心环节可直接作为课程设计、毕业设计或练手原型。资源共138个文件以35个json配置、27个js逻辑文件、22个wxml页面结构、23个wxss样式及29个png图片为主另有1个md说明文档其中json负责页面数据配置js实现订单、店铺等业务逻辑wxml与wxss搭建界面png存放图标素材压缩包仅577KB结构精简易部署。目前已有201人学习从内容预览可见订单、店铺、数据管理等核心模块的代码文件说明项目功能链路完整。通过研读源码与页面设计读者可快速理解云开发架构下的前后端交互方式掌握云函数与数据库的调用方法并能在此基础上扩展菜品管理、消费数据分析等功能。1. 从“预约”到“履约”云开发点餐小程序真正要解决的不是点餐大学食堂的高峰期柜台前排队 10 分钟、取餐再等 5 分钟真正有效的用餐时间反而被压缩。点餐预约小程序的价值不在“线上下单”这个动作而在把“选餐、支付、出餐、取餐”这条链路的时间成本拆开用户提前把单下了食堂按预约批次备餐取餐时扫码即走。而“基于云开发”这几个字决定了这套系统不需要自购服务器、不需要自己维护鉴权会话微信云开发天然提供了云函数、云数据库、云存储和调用微信支付的能力适合课程设计、创业项目 Demo 以及校内小型食堂的轻量落地。但很多团队做完第一版就卡在“能点餐但不敢上线”原因集中在三个地方预约时段和出餐产能对不上、支付回调与订单状态不同步、云函数冷启动导致的高峰期超时。这篇文会把一个可运行的点餐预约小程序从数据建模、云函数实现、预约队列设计到压测排查讲透重点落在云开发环境里那些不调会出事、调了能救命的参数上。2. 数据建模与云开发环境初始化订单状态机先于代码2.1 集合设计与预约批次的关系云开发用的是文档型数据库集合之间的关系靠冗余字段或引用维护不能用 JOIN。点餐预约涉及的几个核心集合是dishes菜品、orders订单、batches预约批次、canteens食堂档口。batches是这套设计里容易被忽略但最重要的集合它不存订单只存“某个档口在某个时间段内最多能出多少份餐”。菜品集合的典型结构{ _id: dish_001, name: 红烧肉套餐, price: 15, stock: 100, // 当日可售总量 batch_limit: 30, // 单个预约批次最多份数 category: 套餐, status: on_sale, update_at: Date.now() }订单集合的结构里必须包含batch_id和status两个字段batch_id用于定位预约批次status用于驱动后续的支付、出餐、取餐流转{ _id: order_202609121001, openid: oXXXX, dish_id: dish_001, batch_id: batch_20260912_1130, quantity: 2, total_fee: 30, status: pending, // pending - paid - ready - picked create_time: Date.now(), pay_time: null, pick_code: 2567 }状态用字符串而不是数字是为了在云函数日志里直接可读。pending表示已提交但未支付paid表示已支付等待出餐ready表示餐已做好picked表示已取走。不要省pick_code用户取餐时靠订单号后四位或自取号确认比靠人脸和名字可靠。2.2 创建云环境与初始化集合索引在微信开发者工具中点击“云开发”按钮创建环境时建议直接选择“按量付费”而不是“免费额度”免费版有单日数据库操作次数限制高峰期很容易被打爆。创建完成后在小程序端app.js里初始化App({ onLaunch() { wx.cloud.init({ env: your-env-id, traceUser: true }) } })traceUser: true会在数据库操作时自动带上用户身份标识后续在云函数里用cloud.getWXContext()拿openid时依赖这个开关。如果设置为 false云函数里拿到的OPENID可能为空支付和订单归属都会出问题。数据库索引在云开发控制台的“数据库-索引管理”里配置。orders集合需要给openid status建联合索引因为用户查询“我的待取餐订单”是最频繁的路径batches集合需要给canteen_id start_time end_time建联合索引用于查询某个档口当前可预约的批次。不建索引在数据量超过几百条后查询延时从几十毫秒跳到几秒直接在控制台看日志就能发现慢查询。2.3 云函数的目录组织与权限边界云函数按业务域拆分不建议把所有逻辑写进一个index.js。常见做法是拆成createOrder创建订单、payOrder发起支付与回调处理、confirmPickup确认取餐、getBatches查询可预约批次、getMenu获取菜品列表。每个云函数独立部署独立配置超时时间和内存。权限边界一条原则数据库的读写权限不要开放给客户端直接操作否则任何人可以在小程序控制台里改订单状态。所有写操作都走云函数数据库权限设为“仅创建者可读写”云函数通过cloud.database()操作时使用管理员权限。3. 预约批次与下单云函数实现并发扣减库存的正确写法3.1 确定性批次生成与容量控制食堂预约最怕的是“全天的量一次性放出中午 11 点全被预约完后面来的人没得选”。批次生成按档口设定比如每个档口每 30 分钟一个批次从 10:30 到 13:00。批次不是定时任务生成的而是每次查询时动态计算并落库避免云函数定时触发器因为冷启动延迟错过生成时间。批次生成的云函数核心逻辑const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() const _ db.command exports.main async (event) { const { canteen_id } event const now new Date() const slots [] // 当日 10:30 - 13:00每 30 分钟一个批次 for (let t new Date(now); t new Date(now).setHours(13, 0, 0, 0); t new Date(t.getTime() 30 * 60 * 1000)) { const start new Date(t) const end new Date(t.getTime() 30 * 60 * 1000) const batchId batch_${formatDate(start)}_${start.getHours()}${start.getMinutes()} const existed await db.collection(batches).where({ _id: batchId }).get() if (existed.data.length 0) { slots.push({ _id: batchId, canteen_id, start_time: start, end_time: end, capacity: 100, // 该批次最多出餐份数 booked: 0, status: open }) } } if (slots.length 0) { await db.collection(batches).add({ data: slots }) } return await db.collection(batches) .where({ canteen_id, status: open }) .orderBy(start_time, asc) .get() }这个函数被用户每次进入预约页时调用通过“先查存在性、不存在才插入”的方式保证幂等。capacity是单个批次的产能上限booked是当前已预约份数。判断批次是否可预约不能只看booked capacity在下单云函数里必须做原子更新。3.2 原子扣减事务与 update 的配合用户提交预约时云函数需要同时做两件事扣减batches.booked、写入orders记录。如果分两步执行高并发下会出现超卖——两个请求同时读到booked99同时减到 100实际写入两单capacity 超了。正确做法是使用云数据库的事务或者利用whereupdate的条件原子性。事务更适合这里const transaction await db.startTransaction() try { const batchRes await transaction.collection(batches).doc(batchId).get() const batch batchRes.data if (batch.booked quantity batch.capacity) { await transaction.rollback() return { code: 4001, msg: 该时段预约已满 } } await transaction.collection(batches).doc(batchId).update({ data: { booked: _.inc(quantity) } }) await transaction.collection(orders).add({ data: { openid, dish_id, batch_id: batchId, quantity, total_fee: dish.price * quantity, status: pending, create_time: db.serverDate(), pick_code: String(Math.floor(1000 Math.random() * 9000)) } }) await transaction.commit() return { code: 0, order_id: orderRes._id } } catch (e) { await transaction.rollback() throw e }db.serverDate()保证时间以数据库服务器时间为准不依赖用户手机时间。pick_code用四位随机数在取餐确认时凭这个码核销。注意一个细节total_fee必须在服务端根据数据库里的菜品价格计算不能信任前端传入的金额否则用户改一下请求参数就能以 1 分钱下单。3.3 起订时间窗口与截止规则预约不能无限提前。食堂备餐有原料采购周期建议设置“可预约未来 3 天每个批次开售前 1 小时截止”。这个规则放在批次查询逻辑里查询时过滤start_time now 1h。不要只在前端隐藏按钮服务端必须拦截否则用户直接调云函数接口就能跨过时间限制。截止触达可以在用户预约成功后用小程序的订阅消息提醒模板选择“预约成功通知”或“订单待取餐提醒”。订阅消息的template_id需要在小程序后台申请云函数里发送时需要先在云开发控制台的“订阅消息”中关联模板。4. 支付回调与订单状态机避免“用户付了钱但订单没更新”4.1 云函数发起微信支付小程序端拿到code后传给云函数云函数调用cloud.cloudPay.unifiedOrder下单。注意cloudPay在云函数中使用时不需要自己处理签名和证书云开发环境已经对接好了微信支付商户号。const res await cloud.cloudPay.unifiedOrder({ body: 食堂点餐预约- dishName, outTradeNo: orderId, spbillCreateIp: 127.0.0.1, subMchId: your_sub_mch_id, totalFee: total_fee * 100, // 单位为分 envId: your-env-id, functionName: payCallback })functionName指定支付结果回调的云函数名。这里有一个容易踩的坑totalFee是整数分后端计算价格时如果用浮点数做乘法会出现14.999999这种结果转成整数后变成 14 元。建议后端用Math.round(price * quantity * 100)而不是乘法后直接取整。4.2 回调幂等与订单状态推进支付回调云函数可能被微信服务器调用多次必须在回调里做幂等判断先查订单当前状态如果已经是paid直接返回成功不再重复改状态。exports.main async (event) { const { returnCode, resultCode, outTradeNo, transactionId } event if (returnCode ! SUCCESS || resultCode ! SUCCESS) { return { errcode: 4002, errmsg: payment failed } } const orderRes await db.collection(orders).doc(outTradeNo).get() if (!orderRes.data || orderRes.data.status ! pending) { return { errcode: 0 } // 已处理过直接返回成功 } await db.collection(orders).doc(outTradeNo).update({ data: { status: paid, pay_time: db.serverDate(), transaction_id: transactionId } }) return { errcode: 0 } }回调函数返回的报文必须是微信支付规定的 XML 格式云开发里cloudPay封装了这部分云函数直接返回 JSON云开发会自动转换成微信要求的格式。不需要在代码里手动拼接 XML。4.3 超时未支付订单的释放用户下单后 15 分钟内未支付预约到的批次名额应该释放给其他人。释放逻辑放在云函数定时触发器里每 5 分钟执行一次db.collection(orders) .where({ status: pending, create_time: _.lt(new Date(Date.now() - 15 * 60 * 1000)) }) .get() .then(async (res) { for (const order of res.data) { await db.collection(batches).doc(order.batch_id).update({ data: { booked: _.inc(-order.quantity) } }) await db.collection(orders).doc(order._id).update({ data: { status: cancelled } }) } })这里用的是_.lt查询 create_time 早于当前时间 15 分钟的记录。云函数定时触发器的最小粒度是分钟级实际使用时设置成0 */5 * * * * *每 5 分钟跑一次。释放名额和改订单状态之间没有事务保护极端情况下可能出现“订单刚被释放用户刚好支付成功”的竞争但概率极低。如果业务要求严格一致需要把支付回调里的状态判断加上时间校验比如只有create_time在 15 分钟内的pending订单才允许推进到paid。5. 取餐核销与预约队列展示从“点完就没事”到“到店即取”5.1 取餐码核销的后端校验用户到食堂后展示订单详情里的四位取餐码食堂工作人员在小程序员工端输入或扫描二维码完成核销。核销云函数不能只把订单状态改成picked必须校验当前时间是否在批次时间内。exports.main async (event) { const { order_id, pick_code } event const orderRes await db.collection(orders).doc(order_id).get() const order orderRes.data if (!order || order.status ! paid) { return { code: 4003, msg: 订单状态异常无法取餐 } } if (order.pick_code ! pick_code) { return { code: 4004, msg: 取餐码错误 } } const batchRes await db.collection(batches).doc(order.batch_id).get() const now Date.now() if (now batchRes.data.start_time || now batchRes.data.end_time) { return { code: 4005, msg: 不在取餐时段内 } } await db.collection(orders).doc(order_id).update({ data: { status: picked, pick_time: db.serverDate() } }) return { code: 0, msg: 取餐成功 } }这个函数需要注意一个边界云函数的调用者可以是用户自己也可以是食堂员工。如果只开放给员工端需要额外鉴权。最轻量的做法是在staff_users集合里维护员工openid白名单核销云函数第一步先检查调用者是否在白名单内。5.2 候补队列与预约进度可视化当某个批次容量满了用户应该能选择“候补”而不是直接放弃。候补队列不需要单独建集合可以在batches文档里加一个waitlist数组字段存候补者的openid和数量。当有订单取消或超时释放时在释放名额的定时触发器里检查waitlist是否有候补者有则按先来后到自动创建订单并推送订阅消息。用户在预约页看到“当前已预约 80/100剩余 20 份”这类信息需要实时获取batched.booked和capacity。每次进入页面调用getBatches查询即可不需要通过 WebSocket 长连接推送数据库读操作的响应时间在 30ms 以内用户体验上可以接受。5.3 防止重复预约与一人多单控制食堂预约场景需要限制同一用户在同一批次只能下一单。在创建订单云函数里增加检查const dupOrder await db.collection(orders) .where({ openid, batch_id: batchId, status: _.in([pending, paid]) }) .count() if (dupOrder.total 0) { return { code: 4006, msg: 您已预约该时段请勿重复下单 } }_.in是数据库指令匹配pending或paid状态的订单。如果允许用户帮同学代点可以把这里的限制放宽为“同批次同一菜品仅限一单”但代点他人的份数需要另加备注字段。从食堂产能角度看限制一人一单更能保证公平建议默认开启。6. 用性能监控与参数调优避开云开发上线后的 3 个暗坑6.1 云函数超时与内存的配置基准云开发控制台为每个云函数提供超时时间配置默认 3 秒创建订单和支付下单这两个函数建议调到 20 秒因为unifiedOrder调用外部支付接口网络波动在高峰期可能超过 3 秒。但注意不要把超时设成 60 秒超时越长云函数实例的并发连接占用越久在高峰期更容易触发并发上限。内存配置对应计费和性能128MB 足够处理数据库操作但支付回调涉及 JSON 解析和数据库写入256MB 更稳妥。不要盲目调 512MB冷启动时间反而可能增加。云函数日志中如果出现Task timed out after 3 seconds先看是不是数据库慢查询而不是直接调超时。检查batches集合的capacity字段如果容量很大的文档被频繁更新会产生写锁竞争事务重试次数增加也会拖慢响应。6.2 数据库连接数与并发上限的应对云开发数据库单实例最多支持 100 个并发连接免费环境更低。当小程序同时在线人数超过几千人时大量云函数实例同时操作数据库会把连接打满报错信息通常是-502001 database request fail。缓解手段有三个按顺序做第一在getBatches这类高频读函数中启用数据库的“本地缓存”策略把批次数据缓存到云函数内存或使用wx.setStorageSync缓存到用户端设置 30 秒过期减少对数据库的压力。第二把orderBy排序挪到查询里不要查出全部记录再在云函数里排序。第三给orders集合加上status索引后分页查询用_id游标而不是skip因为skip在数据量大时性能急剧下降。6.3 使用云开发监控面板定位慢请求云开发控制台的“云函数-日志”和“性能监控”面板能直接看到每个函数的调用次数、平均耗时、错误率。上线后第一周每天看一次这两个指标。重点关注的阈值创建订单云函数 P95 耗时超过 2 秒需要优化支付回调错误率超过 1% 需要检查回调日志里的return_code和result_code。还有一个容易被忽视的配置云函数“环境变量”中的NODE_OPTIONS不要手动设置成--max-old-space-size云开发默认按内存配置管理手写堆大小会导致内存溢出重启。数据库的自动备份默认开启但恢复粒度是隔天如果涉及订单数据建议每日用云函数把paid状态的订单导出到自己的对象存储中防止误删集合导致纠纷。本文还有配套的精品资源点击获取
云开发点餐预约小程序实战：数据建模、事务与性能调优
简介这是一款基于云开发的大学食堂点餐预约小程序完整项目适合具备微信小程序基础、希望掌握云开发模式的学生开发者及高校信息化项目实践者。方案围绕云函数、云数据库、云存储展开覆盖用户注册登录、菜单浏览、购物车、在线支付、预约取餐、订单状态跟踪及消息推送等核心环节可直接作为课程设计、毕业设计或练手原型。资源共138个文件以35个json配置、27个js逻辑文件、22个wxml页面结构、23个wxss样式及29个png图片为主另有1个md说明文档其中json负责页面数据配置js实现订单、店铺等业务逻辑wxml与wxss搭建界面png存放图标素材压缩包仅577KB结构精简易部署。目前已有201人学习从内容预览可见订单、店铺、数据管理等核心模块的代码文件说明项目功能链路完整。通过研读源码与页面设计读者可快速理解云开发架构下的前后端交互方式掌握云函数与数据库的调用方法并能在此基础上扩展菜品管理、消费数据分析等功能。1. 从“预约”到“履约”云开发点餐小程序真正要解决的不是点餐大学食堂的高峰期柜台前排队 10 分钟、取餐再等 5 分钟真正有效的用餐时间反而被压缩。点餐预约小程序的价值不在“线上下单”这个动作而在把“选餐、支付、出餐、取餐”这条链路的时间成本拆开用户提前把单下了食堂按预约批次备餐取餐时扫码即走。而“基于云开发”这几个字决定了这套系统不需要自购服务器、不需要自己维护鉴权会话微信云开发天然提供了云函数、云数据库、云存储和调用微信支付的能力适合课程设计、创业项目 Demo 以及校内小型食堂的轻量落地。但很多团队做完第一版就卡在“能点餐但不敢上线”原因集中在三个地方预约时段和出餐产能对不上、支付回调与订单状态不同步、云函数冷启动导致的高峰期超时。这篇文会把一个可运行的点餐预约小程序从数据建模、云函数实现、预约队列设计到压测排查讲透重点落在云开发环境里那些不调会出事、调了能救命的参数上。2. 数据建模与云开发环境初始化订单状态机先于代码2.1 集合设计与预约批次的关系云开发用的是文档型数据库集合之间的关系靠冗余字段或引用维护不能用 JOIN。点餐预约涉及的几个核心集合是dishes菜品、orders订单、batches预约批次、canteens食堂档口。batches是这套设计里容易被忽略但最重要的集合它不存订单只存“某个档口在某个时间段内最多能出多少份餐”。菜品集合的典型结构{ _id: dish_001, name: 红烧肉套餐, price: 15, stock: 100, // 当日可售总量 batch_limit: 30, // 单个预约批次最多份数 category: 套餐, status: on_sale, update_at: Date.now() }订单集合的结构里必须包含batch_id和status两个字段batch_id用于定位预约批次status用于驱动后续的支付、出餐、取餐流转{ _id: order_202609121001, openid: oXXXX, dish_id: dish_001, batch_id: batch_20260912_1130, quantity: 2, total_fee: 30, status: pending, // pending - paid - ready - picked create_time: Date.now(), pay_time: null, pick_code: 2567 }状态用字符串而不是数字是为了在云函数日志里直接可读。pending表示已提交但未支付paid表示已支付等待出餐ready表示餐已做好picked表示已取走。不要省pick_code用户取餐时靠订单号后四位或自取号确认比靠人脸和名字可靠。2.2 创建云环境与初始化集合索引在微信开发者工具中点击“云开发”按钮创建环境时建议直接选择“按量付费”而不是“免费额度”免费版有单日数据库操作次数限制高峰期很容易被打爆。创建完成后在小程序端app.js里初始化App({ onLaunch() { wx.cloud.init({ env: your-env-id, traceUser: true }) } })traceUser: true会在数据库操作时自动带上用户身份标识后续在云函数里用cloud.getWXContext()拿openid时依赖这个开关。如果设置为 false云函数里拿到的OPENID可能为空支付和订单归属都会出问题。数据库索引在云开发控制台的“数据库-索引管理”里配置。orders集合需要给openid status建联合索引因为用户查询“我的待取餐订单”是最频繁的路径batches集合需要给canteen_id start_time end_time建联合索引用于查询某个档口当前可预约的批次。不建索引在数据量超过几百条后查询延时从几十毫秒跳到几秒直接在控制台看日志就能发现慢查询。2.3 云函数的目录组织与权限边界云函数按业务域拆分不建议把所有逻辑写进一个index.js。常见做法是拆成createOrder创建订单、payOrder发起支付与回调处理、confirmPickup确认取餐、getBatches查询可预约批次、getMenu获取菜品列表。每个云函数独立部署独立配置超时时间和内存。权限边界一条原则数据库的读写权限不要开放给客户端直接操作否则任何人可以在小程序控制台里改订单状态。所有写操作都走云函数数据库权限设为“仅创建者可读写”云函数通过cloud.database()操作时使用管理员权限。3. 预约批次与下单云函数实现并发扣减库存的正确写法3.1 确定性批次生成与容量控制食堂预约最怕的是“全天的量一次性放出中午 11 点全被预约完后面来的人没得选”。批次生成按档口设定比如每个档口每 30 分钟一个批次从 10:30 到 13:00。批次不是定时任务生成的而是每次查询时动态计算并落库避免云函数定时触发器因为冷启动延迟错过生成时间。批次生成的云函数核心逻辑const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() const _ db.command exports.main async (event) { const { canteen_id } event const now new Date() const slots [] // 当日 10:30 - 13:00每 30 分钟一个批次 for (let t new Date(now); t new Date(now).setHours(13, 0, 0, 0); t new Date(t.getTime() 30 * 60 * 1000)) { const start new Date(t) const end new Date(t.getTime() 30 * 60 * 1000) const batchId batch_${formatDate(start)}_${start.getHours()}${start.getMinutes()} const existed await db.collection(batches).where({ _id: batchId }).get() if (existed.data.length 0) { slots.push({ _id: batchId, canteen_id, start_time: start, end_time: end, capacity: 100, // 该批次最多出餐份数 booked: 0, status: open }) } } if (slots.length 0) { await db.collection(batches).add({ data: slots }) } return await db.collection(batches) .where({ canteen_id, status: open }) .orderBy(start_time, asc) .get() }这个函数被用户每次进入预约页时调用通过“先查存在性、不存在才插入”的方式保证幂等。capacity是单个批次的产能上限booked是当前已预约份数。判断批次是否可预约不能只看booked capacity在下单云函数里必须做原子更新。3.2 原子扣减事务与 update 的配合用户提交预约时云函数需要同时做两件事扣减batches.booked、写入orders记录。如果分两步执行高并发下会出现超卖——两个请求同时读到booked99同时减到 100实际写入两单capacity 超了。正确做法是使用云数据库的事务或者利用whereupdate的条件原子性。事务更适合这里const transaction await db.startTransaction() try { const batchRes await transaction.collection(batches).doc(batchId).get() const batch batchRes.data if (batch.booked quantity batch.capacity) { await transaction.rollback() return { code: 4001, msg: 该时段预约已满 } } await transaction.collection(batches).doc(batchId).update({ data: { booked: _.inc(quantity) } }) await transaction.collection(orders).add({ data: { openid, dish_id, batch_id: batchId, quantity, total_fee: dish.price * quantity, status: pending, create_time: db.serverDate(), pick_code: String(Math.floor(1000 Math.random() * 9000)) } }) await transaction.commit() return { code: 0, order_id: orderRes._id } } catch (e) { await transaction.rollback() throw e }db.serverDate()保证时间以数据库服务器时间为准不依赖用户手机时间。pick_code用四位随机数在取餐确认时凭这个码核销。注意一个细节total_fee必须在服务端根据数据库里的菜品价格计算不能信任前端传入的金额否则用户改一下请求参数就能以 1 分钱下单。3.3 起订时间窗口与截止规则预约不能无限提前。食堂备餐有原料采购周期建议设置“可预约未来 3 天每个批次开售前 1 小时截止”。这个规则放在批次查询逻辑里查询时过滤start_time now 1h。不要只在前端隐藏按钮服务端必须拦截否则用户直接调云函数接口就能跨过时间限制。截止触达可以在用户预约成功后用小程序的订阅消息提醒模板选择“预约成功通知”或“订单待取餐提醒”。订阅消息的template_id需要在小程序后台申请云函数里发送时需要先在云开发控制台的“订阅消息”中关联模板。4. 支付回调与订单状态机避免“用户付了钱但订单没更新”4.1 云函数发起微信支付小程序端拿到code后传给云函数云函数调用cloud.cloudPay.unifiedOrder下单。注意cloudPay在云函数中使用时不需要自己处理签名和证书云开发环境已经对接好了微信支付商户号。const res await cloud.cloudPay.unifiedOrder({ body: 食堂点餐预约- dishName, outTradeNo: orderId, spbillCreateIp: 127.0.0.1, subMchId: your_sub_mch_id, totalFee: total_fee * 100, // 单位为分 envId: your-env-id, functionName: payCallback })functionName指定支付结果回调的云函数名。这里有一个容易踩的坑totalFee是整数分后端计算价格时如果用浮点数做乘法会出现14.999999这种结果转成整数后变成 14 元。建议后端用Math.round(price * quantity * 100)而不是乘法后直接取整。4.2 回调幂等与订单状态推进支付回调云函数可能被微信服务器调用多次必须在回调里做幂等判断先查订单当前状态如果已经是paid直接返回成功不再重复改状态。exports.main async (event) { const { returnCode, resultCode, outTradeNo, transactionId } event if (returnCode ! SUCCESS || resultCode ! SUCCESS) { return { errcode: 4002, errmsg: payment failed } } const orderRes await db.collection(orders).doc(outTradeNo).get() if (!orderRes.data || orderRes.data.status ! pending) { return { errcode: 0 } // 已处理过直接返回成功 } await db.collection(orders).doc(outTradeNo).update({ data: { status: paid, pay_time: db.serverDate(), transaction_id: transactionId } }) return { errcode: 0 } }回调函数返回的报文必须是微信支付规定的 XML 格式云开发里cloudPay封装了这部分云函数直接返回 JSON云开发会自动转换成微信要求的格式。不需要在代码里手动拼接 XML。4.3 超时未支付订单的释放用户下单后 15 分钟内未支付预约到的批次名额应该释放给其他人。释放逻辑放在云函数定时触发器里每 5 分钟执行一次db.collection(orders) .where({ status: pending, create_time: _.lt(new Date(Date.now() - 15 * 60 * 1000)) }) .get() .then(async (res) { for (const order of res.data) { await db.collection(batches).doc(order.batch_id).update({ data: { booked: _.inc(-order.quantity) } }) await db.collection(orders).doc(order._id).update({ data: { status: cancelled } }) } })这里用的是_.lt查询 create_time 早于当前时间 15 分钟的记录。云函数定时触发器的最小粒度是分钟级实际使用时设置成0 */5 * * * * *每 5 分钟跑一次。释放名额和改订单状态之间没有事务保护极端情况下可能出现“订单刚被释放用户刚好支付成功”的竞争但概率极低。如果业务要求严格一致需要把支付回调里的状态判断加上时间校验比如只有create_time在 15 分钟内的pending订单才允许推进到paid。5. 取餐核销与预约队列展示从“点完就没事”到“到店即取”5.1 取餐码核销的后端校验用户到食堂后展示订单详情里的四位取餐码食堂工作人员在小程序员工端输入或扫描二维码完成核销。核销云函数不能只把订单状态改成picked必须校验当前时间是否在批次时间内。exports.main async (event) { const { order_id, pick_code } event const orderRes await db.collection(orders).doc(order_id).get() const order orderRes.data if (!order || order.status ! paid) { return { code: 4003, msg: 订单状态异常无法取餐 } } if (order.pick_code ! pick_code) { return { code: 4004, msg: 取餐码错误 } } const batchRes await db.collection(batches).doc(order.batch_id).get() const now Date.now() if (now batchRes.data.start_time || now batchRes.data.end_time) { return { code: 4005, msg: 不在取餐时段内 } } await db.collection(orders).doc(order_id).update({ data: { status: picked, pick_time: db.serverDate() } }) return { code: 0, msg: 取餐成功 } }这个函数需要注意一个边界云函数的调用者可以是用户自己也可以是食堂员工。如果只开放给员工端需要额外鉴权。最轻量的做法是在staff_users集合里维护员工openid白名单核销云函数第一步先检查调用者是否在白名单内。5.2 候补队列与预约进度可视化当某个批次容量满了用户应该能选择“候补”而不是直接放弃。候补队列不需要单独建集合可以在batches文档里加一个waitlist数组字段存候补者的openid和数量。当有订单取消或超时释放时在释放名额的定时触发器里检查waitlist是否有候补者有则按先来后到自动创建订单并推送订阅消息。用户在预约页看到“当前已预约 80/100剩余 20 份”这类信息需要实时获取batched.booked和capacity。每次进入页面调用getBatches查询即可不需要通过 WebSocket 长连接推送数据库读操作的响应时间在 30ms 以内用户体验上可以接受。5.3 防止重复预约与一人多单控制食堂预约场景需要限制同一用户在同一批次只能下一单。在创建订单云函数里增加检查const dupOrder await db.collection(orders) .where({ openid, batch_id: batchId, status: _.in([pending, paid]) }) .count() if (dupOrder.total 0) { return { code: 4006, msg: 您已预约该时段请勿重复下单 } }_.in是数据库指令匹配pending或paid状态的订单。如果允许用户帮同学代点可以把这里的限制放宽为“同批次同一菜品仅限一单”但代点他人的份数需要另加备注字段。从食堂产能角度看限制一人一单更能保证公平建议默认开启。6. 用性能监控与参数调优避开云开发上线后的 3 个暗坑6.1 云函数超时与内存的配置基准云开发控制台为每个云函数提供超时时间配置默认 3 秒创建订单和支付下单这两个函数建议调到 20 秒因为unifiedOrder调用外部支付接口网络波动在高峰期可能超过 3 秒。但注意不要把超时设成 60 秒超时越长云函数实例的并发连接占用越久在高峰期更容易触发并发上限。内存配置对应计费和性能128MB 足够处理数据库操作但支付回调涉及 JSON 解析和数据库写入256MB 更稳妥。不要盲目调 512MB冷启动时间反而可能增加。云函数日志中如果出现Task timed out after 3 seconds先看是不是数据库慢查询而不是直接调超时。检查batches集合的capacity字段如果容量很大的文档被频繁更新会产生写锁竞争事务重试次数增加也会拖慢响应。6.2 数据库连接数与并发上限的应对云开发数据库单实例最多支持 100 个并发连接免费环境更低。当小程序同时在线人数超过几千人时大量云函数实例同时操作数据库会把连接打满报错信息通常是-502001 database request fail。缓解手段有三个按顺序做第一在getBatches这类高频读函数中启用数据库的“本地缓存”策略把批次数据缓存到云函数内存或使用wx.setStorageSync缓存到用户端设置 30 秒过期减少对数据库的压力。第二把orderBy排序挪到查询里不要查出全部记录再在云函数里排序。第三给orders集合加上status索引后分页查询用_id游标而不是skip因为skip在数据量大时性能急剧下降。6.3 使用云开发监控面板定位慢请求云开发控制台的“云函数-日志”和“性能监控”面板能直接看到每个函数的调用次数、平均耗时、错误率。上线后第一周每天看一次这两个指标。重点关注的阈值创建订单云函数 P95 耗时超过 2 秒需要优化支付回调错误率超过 1% 需要检查回调日志里的return_code和result_code。还有一个容易被忽视的配置云函数“环境变量”中的NODE_OPTIONS不要手动设置成--max-old-space-size云开发默认按内存配置管理手写堆大小会导致内存溢出重启。数据库的自动备份默认开启但恢复粒度是隔天如果涉及订单数据建议每日用云函数把paid状态的订单导出到自己的对象存储中防止误删集合导致纠纷。本文还有配套的精品资源点击获取
