便利店小程序源码带教程：云开发部署与支付避坑指南

简介：便利店小程序源码是一套面向社区便利店、连锁便利店及超市场景的微信小程序解决方案，完整包含后端接口与前端页面，并附带教程，适合需要快速搭建线上商城、进行二次开发或学习小程序全栈流程的开发者与运营者使用。源码围绕门店与用户双端体验设计：可按地理位置展示离用户最近的便利店，支持最低配送金额与配送费设置、商品搜索、每日秒杀、优惠券领取，以及全国连锁场景下的分店地址查看，功能覆盖从下单到配送的完整闭环，能有效提高用户粘性和复购率。资源共1556个文件，压缩包约3.89MB，主要由php后端逻辑、js交互脚本、css样式、png图片、tpl/twig服务端模板，以及wxml/wxss小程序页面等构成，目录结构清晰，便于定位后台上架、订单处理、营销模块等关键代码。目前已有482人学习下载，适合具备一定小程序或后端基础的学习者，按教程逐步部署调试，可快速掌握便利店小程序从环境搭建到功能上线的完整思路。

1. 便利店小程序源码带教程：先别急着跑通代码，先算清这一步

一份便利店小程序源码（带教程），听起来像开箱即用：下载，改店名，上传审核，小店就能在线接单。但很多拿到源码的人，第一个下午就卡在支付回调上，最后怀疑源码缺了半个后端。真实情况是，这类源码通常已经包含商品展示、购物车、下单、支付、订单管理的完整主链路，教程负责带你走完部署。它解决的问题，是把便利店每天重复的收银、点单、会员记录整理成一套可运行的线上流程。适合三类人：想低成本试水小程序私域的个体店主，需要一套打底项目再改改就交付的外包开发者，以及刚学完小程序基础、想找一个完整案例练手的新手。

2. 源码拆解：便利店小程序的核心模块与三条数据链路

2.1 源码目录扫一眼：前端页面、云函数、初始数据各管什么

拿到这类源码，我一般先不急着导入开发者工具，而是先看目录结构。带教程的便利店小程序源码，无论代码写得精致还是粗糙，目录约定基本逃不出下面这个骨架：

mini-shop/ ├── miniprogram/ │ ├── pages/ │ │ ├── index/ # 首页：商品分类与商品列表 │ │ ├── cart/ # 购物车：数量增减、结算入口 │ │ ├── order/ # 订单列表与订单详情 │ │ └── member/ # 我的：会员信息、积分记录 │ ├── components/ # 商品卡片、数量步进器等复用组件 │ ├── config/ # 门店配置，通常只有一个文件 │ └── app.js ├── cloudfunctions/ # 下单、支付、库存更新等云函数 ├── database/ # 初始JSON：商品、分类、门店、轮播图 └── README.md # 教程入口

前端拆四个页面，对应一个小店店员最常用的四个场景：顾客进店看商品、加购物车、下单付款、查订单。tabBar 通常是首页、购物车、订单、我的，这个结构不要动，动了 tabBar 配置，编译期就会报错。components 目录里的商品卡片和步进器是复用组件，首页和购物车都会引用，如果你改了组件里的字段名，两处页面会一起失效，这是改代码时最容易牵连出问题的地方。

cloudfunctions 是这套源码能不能上线的关键。单店小程序没有太大的后端压力，云函数按业务拆开，每个函数独立部署、独立看日志。database 目录里的 JSON，是教程让你“导入数据库”用的初始数据。如果这个目录是空的，说明源码要你手动建商品，工作量会大不少，判断一份源码值不值得用，可以先看这里有没有数据和字段说明。

2.2 数据模型定边界：商品、购物车、订单这三类结构先理清

便利店小程序的业务不复杂，但数据关系一定要先理清，否则后面改需求会一直打架。常见做法是三类核心数据：商品、购物车、订单。商品集合决定首页卖什么，购物车决定用户结算时带了什么，订单决定钱和货怎么对账。

商品集合的典型字段长这样，导入数据库前先对着改：

{ "_id": "auto", "name": "农夫山泉550ml", "categoryId": "drink", "price": 200, "stock": 80, "sales": 156, "shelfStatus": 1, "images": ["cloud://env-id.xxx/water.png"], "createTime": 1690000000000 }

price 用整数分存储，不要用小数。便利店毛利薄，饮料、零食价格带集中在 1 到 20 元，用分做单位可以避免 0.1 加 0.2 不等于 0.3 的浮点误差。shelfStatus 是上下架开关，1 展示、0 隐藏，首页查询时一定带这个条件，很多源码在列表页忘了过滤下架商品。images 建议用云存储的 fileID，不要用本地路径，后面避坑章会专门讲。

购物车这块，很多源码为了省事会把购物车数据放在本地缓存里，不建数据库集合。对便利店来说这是合理的：到店自提场景，顾客加购到结算通常几分钟内完成，缓存丢失可接受；如果把购物车放进云数据库，需要处理多端同步、过期清理，复杂度上了一个台阶。判断源码水平，就看购物车是本地缓存还是云端集合——两者都能用，但后者说明作者考虑了更完整的线上场景。

订单集合是整条链路的最终落点，字段设计直接决定后续核销、退款、对账怎么做：

// 订单集合核心字段 { orderNo: "202501011200001234", // 云函数生成：日期+时间戳+随机数 status: 0, // 0待支付 1备货中 2待自提 3已完成 4已取消 5退款中 items: [{ productId, name, price, count }], // 下单时的商品快照 totalAmount: 2450, // 实付金额，单位分 payTime: null, // 支付成功时间 pickupCode: "1342", // 到店自提核销码，4位数字 stockCompensated: false, // 取消/退款后是否已回补库存 openid: "用户openid" }

items 里必须存商品快照，不能只存 productId。便利店商品改价很频繁，如果订单详情实时去查商品表，历史订单的金额会跟着变，财务对不上账。快照的意思是下单那一刻的商品名、单价、数量全部复制进订单，以后再改商品价格不影响旧订单。pickupCode 是到店自提单的核销凭证，4 位数字足够一家小店用，用户报号店员确认，比扫码枪成本低。stockCompensated 这个字段在避坑章会用到，先在这里埋下。

2.3 选型判断：为什么带教程的源码多数用云开发，而不是自建服务器

看源码前先做选型判断。市面上带教程的便利店小程序源码，主流方案是小程序前端加云开发，也就是用云数据库、云函数、云存储，而不是自己买一台服务器部署后端。原因很直接：单店小程序的日访问量通常只有几百，自建服务器月成本至少几十上百元，还要处理域名备案、HTTPS 证书、数据库备份，这些对店主来说全是负担。

云开发的成本模型是按量付费，有免费额度，对便利店这种低频交易场景，一个月几乎花不了多少钱。这就是为什么聊便利店小程序开发费用时，大头不在服务器，而在你要不要做配送、要不要做会员储值、要不要接第三方 ERP。如果教程让你额外配一台云服务器部署后端，你需要评估自己有没有维护能力，别让架构复杂度超过业务体量。

下单支付链路是这套源码里最核心、也最容易出错的部分。以下单云函数为例，常见实现长这样：

// 下单云函数：预占库存、生成订单、返回支付参数 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 { items, totalAmount } = event // 1. 逐项校验并预占库存 for (const item of items) { const res = await db.collection('products').doc(item.productId).update({ stock: _.inc(-item.count) }) if (res.stats.updated === 0) { return { code: 1, msg: `${item.name} 库存不足` } } } // 2. 生成订单，状态置为 0 待支付 // 3. 调用支付接口取得支付参数，返回给前端 return { code: 0, orderNo, payParams: { timeStamp, nonceStr, package, signType, paySign } } }

逻辑说明：这里用的是“先减库存再支付”而不是“支付成功后再减库存”，目的是防止用户锁住最后一件商品却不付款。预占库存后，如果用户一直不支付，需要一个定时任务把超时订单取消并回补库存，否则库存会慢慢被无效订单吃光。

参数说明：timeStamp、nonceStr、package、signType、paySign 这五个参数是前端调起支付弹窗的必需品，它们必须由云函数返回，不能由前端自己拼。支付密钥一旦写进前端代码，小程序打包后任何人都能反编译拿到，资金风险不可控。选源码时重点看支付参数是从云函数返回，还是写死在页面里——写死的基本可以直接放弃。这类源码附带的教程通常会在支付这一章花最多篇幅，因为这是跑通全链路中最容易翻车的一段。

3. 把源码跑起来：从开发者工具导入到云开发环境配齐

3.1 导入源码：改appid和project.config.json，先让项目能编译

拿到一份便利店小程序源码后，第一步是用开发者工具导入。导入不是打开文件夹那么简单，项目能不能正常编译，取决于 project.config.json 里的三个字段。这份文件在源码根目录下，看起来像这样：

// project.config.json 关键配置 { "appid": "你的小程序AppID", "miniprogramRoot": "miniprogram/", "cloudfunctionRoot": "cloudfunctions/", "compileType": "miniprogram" }

appid 必须换成你自己的小程序账号。没有注册小程序账号的话，先去小程序管理后台注册，类型选企业或个体工商户。用测试号虽然能看页面，但测试号没有云开发权限，也调不起支付，跑通全流程必须用自己的 appid。

miniprogramRoot 指向小程序前端代码所在目录，如果导入后提示“找不到 app.json”，就是这里指错了。少数源码会把前端代码直接放在根目录，此时这个字段要留空。cloudfunctionRoot 指定云函数目录，必须和前端目录分开，否则云函数会被当成页面代码一起编译。

依赖安装是另一个坑。带云函数的源码，前端不一定要 npm install，但每个云函数目录都要单独装依赖。常见做法是在终端里逐个目录执行：

# 进入每个云函数目录，安装各自依赖 cd cloudfunctions/order npm install cd ../pay npm install

逻辑说明：云函数是独立部署的，每个函数目录都有自己的 package.json，部署时会单独打包上传。如果在项目根目录统一安装依赖，云函数上传后依然找不到模块。安装完成后，在开发者工具左侧文件树里选中云函数目录，右键菜单选择“上传并部署（云端安装依赖）”，这一步会把本地代码连同 node_modules 一起送到云端。注意选择“云端安装依赖”，而不是“上传所有文件”，后者会把本地多余的依赖文件也打进去，导致函数包过大、冷启动变慢。

3.2 建数据环境：六个集合、两个索引、一份商品JSON导入

云开发环境创建好之后，进入云开发控制台，在数据库页面按顺序创建集合。便利店小程序最少需要六个集合，少一个后面跑业务都会在某个角落报错：

# 在云开发控制台 → 数据库 → 创建集合 products # 商品表 categories # 商品分类 orders # 订单表 members # 会员表 settings # 门店配置 analytics # 埋点日志（部分源码没有，建议手动加）

创建集合后，先不要急着导入数据，先把索引建好。索引是云数据库查询性能的关键，单店小程序数据量不大，但索引仍然必要。常见做法是给 products 建一个复合索引：categoryId 升序加 shelfStatus 升序，这样首页按分类查询上架商品时不会全表扫描；给 orders 建一个 status 加 createTime 的复合索引，订单列表按状态刷新时速度差很多。

初始商品数据导入，以 products 集合为例，database 目录下通常有一个 JSON 文件，改动字段后通过控制台里的“导入”按钮上传：

[ { "name": "可口可乐330ml", "categoryId": "drink", "price": 300, "stock": 120, "sales": 0, "shelfStatus": 1, "images": [] }, { "name": "乐事薯片原味70g", "categoryId": "snack", "price": 650, "stock": 50, "sales": 0, "shelfStatus": 1, "images": [] } ]

逻辑说明：控制台导入要求 JSON 必须是数组，单条记录导入时也要加方括号。导入前对照源码里商品列表页用到的字段，确认 name、price、stock、shelfStatus 这些必填字段都存在，否则页面能打开，但商品列表是空的，而且控制台不会给任何报错，只能靠肉眼对字段。

参数说明：categoryId 建议用英文标识，和中文分类名分开存。categories 集合里维护“drink 对应饮料”“snack 对应零食”的映射，这样以后改分类名不用批量改商品数据。price 单位是分，300 表示 3 元，650 表示 6.5 元，导入前检查一遍别把单位弄混，上架后才发现价格差十倍就晚了。

3.3 部署云函数与环境变量：支付密钥进云端，不进源码

云函数部署是跑通全链路的临门一脚。每个云函数目录在上一节已经装好依赖，现在要做的是逐个上传并部署。常见做法是每个函数分别操作，不要用批处理一次全传，因为支付、订单、库存这几个函数部署顺序有讲究，分开部署方便单独看日志：

# 每个云函数目录执行：右键 → 上传并部署（云端安装依赖） # 部署完成后，在云开发控制台 → 云函数 → 选中支付相关函数 → 配置环境变量 MCH_ID=你的商户号 PAY_KEY=支付密钥 APP_ID=你的小程序AppID NOTIFY_URL=https://xxxxxxxx.cloudfunctions.net/notify ADMIN_OPENID=店主的openid

逻辑说明：环境变量不能写死在源码里。小程序前端代码打包后可以被反编译，云函数代码虽然没有直接暴露给用户，但一旦源码被分享出去，里面的密钥也跟着泄露。把密钥放到云开发控制台的环境变量里，代码里通过 process.env 读取，换环境时改配置不用动代码。

参数说明：NOTIFY_URL 是支付回调地址，支付平台在用户付款成功后请求这个地址，通知后端订单已支付。这个地址必须是 HTTPS，而且外网能访问。云开发环境可以给云函数绑定 HTTP 触发路径，把触发路径填进 NOTIFY_URL 即可。ADMIN_OPENID 用来标识店主，核销自提码、查看后台统计时只能店主操作，建议单独配置，不要靠判断用户名来实现权限。

部署完后做一次冒烟测试：清掉开发者工具缓存，重新编译，用测试账号下一笔 1 元订单，走完整个支付流程。如果卡在“调起支付失败”，优先去云开发控制台点开支付云函数，看运行日志里的错误码。这一步跑通了，后面上线基本就顺畅了。

4. 避坑指南：便利店小程序源码从跑通到能上线的五个坑

4.1 商品图真机不显示：开发者工具正常，真机全是红点

现象：开发者工具里商品图显示正常，用手机预览或上线后，商品图片全部裂开，控制台报“downloadFile:fail”。原因：商品图使用了本地相对路径或 HTTP 地址，小程序真机环境要求图片资源必须来自 HTTPS，且域名要加入白名单。如果图片是云存储的 fileID，反而没有这个问题，因为云存储自动走安全通道。解决：把商品图片全部上传到云存储，在商品集合的 images 字段里替换成云存储 fileID。本地图片路径只在开发者工具里有效，真机包不会把本地图片打包进去，这是新手最容易踩的坑。

4.2 支付按钮点了没反应：AppID、商户号、回调地址三处对不上

现象：点击“立即支付”，页面转圈后没有拉起支付弹窗，或者弹窗一闪而过并提示“fail cancel”。很多人的第一反应是源码有问题，实际上三处配置没对上。原因：小程序 AppID 和商户号没有绑定，支付云函数里读到的 APP_ID 跟你登录开发者工具的 AppID 不一致，或者 NOTIFY_URL 还是源码自带的示例地址。解决：先在云开发控制台打开支付云函数，看运行日志中订单号与错误码，然后逐项核对环境变量。AppID 必须与请求支付时前端传上来的一致，商户号必须已在支付平台完成与小程序 AppID 的关联绑定，NOTIFY_URL 必须能被公网访问。这三项是支付链路最常见的故障源，按顺序排查比瞎改代码有效。

4.3 云函数批量导入超时：默认执行时长扛不住整表写入

现象：把 50 个商品一次性通过云函数写入数据库，函数执行到一半报“调用超时”，或部分商品写入成功、部分丢失。原因：云函数默认执行超时时间短，单次调用里循环逐条写入 50 条数据，数据库写入有并发限制，慢请求拖到超时。解决：分批写入，或者绕过云函数直接在控制台导入 JSON。分片写入的代码改造很简单，把循环改成按批次提交：

// 分片批量写入，避免单次调用写入过多触发限流 const BATCH_SIZE = 20 for (let i = 0; i < products.length; i += BATCH_SIZE) { const batch = products.slice(i, i + BATCH_SIZE) await db.collection('products').add({ data: batch }) }

逻辑说明：BATCH_SIZE 设为 20，用 slice 把商品列表切成小段，每段一次写入。不要用 forEach 逐条 add，那样请求数多且无法批量控制；也不要一次 add 全部 50 条，超出单次请求数据量限制会直接失败。参数说明：云开发数据库单次 add 最多支持 1000 条或一定大小限制，但网络传输和并发处理时 20 到 50 条更稳妥。如果是首次开店导入商品，直接在控制台导入 JSON 文件最省事，云函数批量写入适合后续运营中用的批量上架工具。

4.4 库存越卖越多：取消订单没有补偿预占库存

现象：运营发现后台库存数据和实际货架对不上，负库存、越卖越多、退款后商品库存没变。原因：下单云函数做了预占库存，也就是下单即减库存，但订单取消或支付超时后，没有把库存加回来。订单状态变了，库存却留在原地。解决：在订单状态迁移的地方做统一库存补偿，并且用幂等标记避免重复加库存。常见实现如下：

// 取消订单时的库存补偿：只回补一次 async function onOrderCancel(orderNo) { const order = await db.collection('orders').where({ orderNo }).get() if (!order.data.length || order.data[0].stockCompensated) return await db.runTransaction(async t => { const orderDoc = order.data[0] for (const item of orderDoc.items) { await t.collection('products').doc(item.productId).update({ stock: _.inc(item.count) }) } await t.collection('orders').doc(orderDoc._id).update({ stockCompensated: true }) }) }

逻辑说明：stockCompensated 字段在订单文档里，置为 true 表示这笔订单的库存已经回补过。为什么需要这个字段：取消操作可能被用户触发、被超时任务触发，甚至被管理员在后台手动点一次，没有幂等保护，库存会被重复加。事务保证“加库存”和“标记已补偿”要么都成功要么都失败，不会出现库存加了标记没写这种中间状态。参数说明：_.inc(item.count) 是云数据库的原子自增操作，避免读出、计算、写回三步非原子导致的并发覆盖。便利店忙时同时处理多笔退款，原子操作是必须的。

4.5 审核被拒：服务类目选错，比代码报错更难排查

现象：小程序提交审核后收到“涉及食品销售，需补充资质”的拒绝理由，而且一个月内连提三次都被打回。代码本身没问题，卡在了服务类目上。原因：小程序后台的服务类目选成了“食品”相关类目，平台要求对应资质。便利店经营预包装食品，很多个体店办不下完整的食品经营许可证，于是反复被拒。解决：在服务类目里优先选择“生活服务 > 便民服务 > 线下超市/便利店”这类常见对应选项，并根据实际经营范围选择，不卖生鲜、不卖散装食品的话，不要把类目选到食品销售上。不同时期审核尺度有差异，这也是大家常说的“审核有点玄学”，但类目选错是最常见的原因，提交审核前先过一遍资质清单，比收到拒绝后乱改代码靠谱得多。

5. 上线定制：把通用便利店源码改成你门店的配置与流程

5.1 门店配置集中放一处：店名、营业时间、配送半径改一次生效

源码里最容易被改乱的部分，是门店信息散落在各个页面里。首页写一句欢迎语，订单页写一个地址，会员页再写一个电话，改起来要翻三四个文件。拿到源码后第一件事，就是把所有门店信息收拢到一个配置文件里。常见做法是在 miniprogram/config 目录下建一个 shop.js：

// miniprogram/config/shop.js module.exports = { shopName: 'A同学便利店', shopPhone: '400-800-0000', businessHours: '07:00-23:00', pickupAddress: '某市某区xx路xx号', deliveryEnabled: false, deliveryRadius: 3000, // 开启配送时的配送半径，单位米 paymentTimeoutMin: 15, // 待支付订单超时自动取消时间，单位分钟 minOrderAmount: 0 // 起送金额或最低消费，单位分 }

逻辑说明：页面里不要直接写店名和电话，通过 require 引入 shop.js。改营业时间、改地址，只动这一个文件，所有页面同步生效。deliveryEnabled 是配送总开关，便利店前期建议先关掉，只做到店自提，跑顺了再开。

参数说明：deliveryRadius 单位是米，3000 表示 3 公里内可配送。如果源码没有这个字段，自己加一个并不难，结算页判断用户位置距离是否在半径内。minOrderAmount 用分做单位，0 表示不限制。paymentTimeoutMin 是超时取消时间，便利店场景 15 分钟比较合适，太短顾客犹豫一下就丢单，太长库存会被无效订单占住。

改配置文件后有个隐蔽问题：小程序有本地缓存，已经打开过的页面可能还在读旧值。测试时在开发者工具里点“清除缓存”后重新编译，真机上退出小程序再重新进入。

5.2 订单状态机补全：给“店员核销自提码”留一个人工动作

很多源码的订单状态只有“待支付”和“已完成”两个状态，支付成功就自动完成。这对便利店来说不够用：备货需要时间，顾客到店后要报码核销，你不能让系统自动把订单变成完成状态。常见做法是补全状态机：

// 订单状态：0待支付 1备货中 2待自提 3已完成 4已取消 5退款中 const NEXT_STATUS = { 0: [1, 4], // 待支付 → 支付成功进入备货中，或超时取消 1: [2], // 备货完成 → 待自提 2: [3], // 核销自提码 → 已完成 3: [], // 终态 4: [], // 终态 5: [3, 4] // 退款中 → 退款完成或拒绝退款 }

逻辑说明：状态迁移必须走这个映射表，不允许任意跳转。比如待支付订单不能直接变成已完成，必须经历备货和自提两个中间状态，这样店员才能看到订单进度并安排配货。

核销是店员每天用得最多的动作。自提码核销的云函数，要重点检查重复核销问题：

// 核销自提码：一个码只能核成功一次 exports.main = async (event) => { const order = await db.collection('orders').where({ pickupCode: event.code, status: 2 }).get() if (!order.data.length) return { code: 1, msg: '无效或已核销' } await db.collection('orders').doc(order.data[0]._id).update({ status: 3, finishTime: Date.now() }) return { code: 0, msg: '核销成功' } }

逻辑说明：where 条件里带 status: 2，意思是只有“待自提”状态的订单才允许核销。一个码核销成功后状态变成 3（已完成），第二次拿同一个码来查，查不到 status 为 2 的订单，直接返回失败。这比先查订单再判断状态少一次请求，也从根本上杜绝了重复核销。

参数说明：pickupCode 是 4 位数字，小店单量一天几十单，4 位数字足够，重复概率低；如果订单量大，可以换成 6 位。核销成功后要顺手把 finishTime 写进去，订单详情页展示完成时间要用。

5.3 上线前过一遍验证清单：支付回调、自提码、积分逐项测

上线前不要直接点发布，先按下面的清单在体验版里走一遍。每一项都是真实业务里会发生的路径，缺一项测试，上线后就要花十倍精力查。

这个清单听起来简单，但我见过不少源码在第一个场景就翻车。支付回调成功后订单状态没有更新，原因常常是回调云函数里忘记更新数据库。如果源码的支付回调是把状态写在内存里或只返回了成功字符串，这种代码必须改掉，否则用户付了钱，店员看不到订单，门店直接丢单。

还有一个容易被忽视的上线前动作：开通“附近的小程序”相关的地理位置接口。便利店这种即时消费业态，顾客大概率是在门店附近搜索后进店。在小程序管理后台申请位置接口权限，填写门店坐标，审核通过后小程序能在周边搜索里出现。这一步在教程里经常只字不提，但对便利店来说引流效果远好于群聊转发。

6. 上线后第一周：用三组数据验证源码靠不靠谱

源码跑通和业务可靠是两回事。新店上线第一周，我的习惯是不做任何营销投放，重点验证三组数据：支付回调成功率、购物车放弃率、自提核销率。这三组数据能直接判断源码是不是真的能用，而不是能用电脑演示。

支付回调成功率，去云开发控制台看支付云函数的运行日志，统计成功返回的次数占全部调用次数的比例。如果回调失败率超过百分之一，说明支付链路有隐患，常见原因是 NOTIFY_URL 不稳定或回调逻辑里还有未捕获的异常。购物车放弃率，看 analytics 集合里的结算动作和订单创建次数，用户在结算页停留却不下单，多半是配送费不透明或起送门槛让用户反悔。自提核销率，看订单从备货中转移到已完成的比例，如果顾客下单后不来自提，说明核销指引不清晰，需要在订单详情页加重提醒。

如果源码没带埋点，自己加一个最简单的上报方法，不影响主流程：

// 在结算、支付回调、核销三处追加上报 function reportAction(action) { wx.cloud.database().collection('analytics').add({ data: { action, ts: Date.now() } }).catch(() => {}) }

逻辑说明：action 传入一个动作名字，比如 checkout、pay_success、pickup_success，collect 到 analytics 集合里。catch 里什么都不做，埋点失败不能影响交易主流程。ts 用 Date.now()，方便按时间排序和过滤。

上线第一周每天花十分钟翻日志，比连续写七天营销文案更有价值。支付日志、数据库读写错误、云函数超时，这三个地方出现的任何异常都要当天处理，不要攒到周末一起查。我自己习惯把订单流程当顾客走三遍：第一遍是新用户路径，第二遍是退款路径，第三遍是库存对账路径，每一步都看数据库实际变成了什么。踩过库存越卖越多的亏之后，我现在对状态机和幂等字段特别敏感，凡是涉及金额和库存的更新，一律要求事务加标记。第一周数据稳定了，再开始做会员充值、满减活动也不迟。希望帮到你。

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