★ FEATURED ARTICLE 从零做一个微信小程序购物系统最容易被什么东西坑到我自己的体验是大部分都不是代码写不出来而是前面章节提到过的那些“看上去不是问题”的决策——比如到底要不要用云开发、商品模型怎么设计、订单状态怎么流转——这些搞不定后面越写越乱。这篇就是基于我实际做过的一个模拟购物项目“基于微信小程序的购物系统”整理出来的整套开发思路。它不是某本教科书的大而全方案而是一套能直接跑起来、适合个人开发者或小团队快速落地的垂直切面小程序端以用户购物为主线配合云开发或自建后端的选择对比、商品/订单/购物车/支付/审核的完整链路。适合正在规划小程序电商项目、或者已经被各种方案绕晕的开发者。1. 启动项目时最该想清楚的事平台、技术路线与商品模型先说结论微信小程序购物系统技术上没有多少高不可攀的东西真正决定项目能不能顺利走下去的是你一开始怎么选型。很多做商城项目的开发者在起步阶段就卡在“用什么写后端“上结果小程序首页还没做出来先被一堆部署问题搞崩了。1.1 技术路线选云开发还是自建后端小程序购物系统目前主流是两条路一条是用微信云开发也就是微信官方的后端服务另一条是自建后端服务常见的是 Node.js 或 Java 写接口部署在云服务器上。两者怎么选我建议你按下面的思路来判断而不是凭感觉如果你是自己独立开发、预算有限、希望尽早跑通全流程优先选云开发。云开发自带数据库、云函数、存储免鉴权获取用户 openid 非常方便不需要自己再去搭鉴权体系。如果你的项目未来要扩展到 Web 端、App 端或者有复杂的后台运营管理系统、第三方服务对接需求自建后端更合理。因为云开发虽然是微信生态的一部分但数据和服务如果要被外部访问还是得自己把控接口层。我实际做的时候选了云开发路线理由很简单购物系统这种项目核心业务在小程序端后台管理可以后面再补。云开发让前端可以直接调用数据库免去了大量接口联调的时间。不过这里要提醒一句云开发的数据库权限设置非常重要容易配错后面专门讲。1.2 商品模型的重要性比想象中大购物系统开发时很多人一上来就建商品表字段呼啦呼啦地加一堆商品名称、图片、价格、库存、销量……结果到后面发现商品有多规格需求就傻眼了。商品模型至少要拆成三级商品 SPUStandard Product Unit标准产品单元也就是你看到的某个商品比如“夏季棉麻衬衫”规格 SKUStock Keeping Unit库存量单位比如“白色 / M码”“黑色 / L码”每个 SKU 有自己的价格和库存商品分类建议做两级分类一级是服装、数码、食品这种大分类二级是细分比如女装下的衬衫、T恤如果一开始不拆 SKU后面做购物车、做订单、做库存管理全部要返工。我见过一个项目就是因为商品表里直接塞了“颜色:白色, 尺码:M”这样的字符串结果订单统计和库存扣减都是灾难现场。所以商品模型这件事宁可一开始多想两天也不要在开发中期推倒重来。2. 小程序前端的核心模块怎么落地以购物车和商品详情为例前端是小程序购物系统的门面用户所有操作都发生在这里。表面看就是页面布局、组件交互实际上每个模块都有隐藏的点。我挑最核心的购物车和商品详情展开说说。2.1 商品列表与搜索筛选怎么做商品列表不是简单循环渲染就完事了。这里有两个点值得注意。一是分页加载。数据少的时候无所谓数据量大了以后一次性拿几十上百条数据页面渲染会明显卡顿。我采用的做法是每次加载 10 到 20 条配合滚动到底部触发下一页的加载方式。用云开发时可以用 skip 和 limit 配合也可以用更合理的游标方式但简单项目 skip 够用。二是筛选条件怎么设计。分类、价格区间、销量排序、上架时间排序这几个条件是标配。在云开发上做多条件组合查询的时候注意给数据库建立必要的索引否则查询效率会差很多。我遇到过的情况是价格排序怎么都不生效排查到最后发现是数据库索引没建全。商品搜索简单的用正则匹配名称字段就可以如果商品量大、搜索词复杂再考虑接入全文检索但初期不要过度设计。2.2 购物车为什么要本地存而不是直接读数据库这是很多人最容易搞错的地方。早期我的做法是每次加购都往数据库写一条记录购物车页再从数据库读。结果用户体验差因为用户每点一次“加入购物车”就要等网络请求完成而且数据频繁写入对数据库压力也大。后来我参考了很多成熟电商项目的做法购物车数据存本地缓存也就是存放在微信小程序的 Storage 里。用户加购时先把数据写入本地再异步同步到服务端。这样做的好处是响应快失败也不会打断用户操作。但本地存储有个合并问题用户退出登录、换设备、或者清掉缓存后购物车数据就没了。所以建议逻辑上这样做用户未登录时购物车使用本地缓存用户登录后把本地缓存与云端购物车合并每次加购、修改数量、删除时不只是更新本地也同步到云端合并逻辑可以用一个简单的标识本地购物车里的商品 SKU ID 数量拉到云端数据后按 SKU ID 做数量累加和去重。2.3 商品详情页的隐藏细节商品详情页看起来简单核心就几件事展示商品信息、选择规格、加购、立即购买。但规格选择的交互一定要处理好。用户选了规格之后页面要立刻显示所选规格对应的价格如果某个规格组合库存为零要置灰不可选。这里用到一个叫做“规格联动”的逻辑。比如一件衣服选了颜色后尺码的可选项要根据该颜色下的库存实时变化。我在云开发上实现的时候商品详情接口返回的是该商品下的所有 SKU 列表然后前端做规格矩阵的匹配而不是让后端在你每次点击规格时都发一次请求。另外在商品描述区域图片建议用压缩后的长图并且做好懒加载。很多小程序购物项目一进入详情页就疯狂加载图片导致页面卡白影响体验。3. 订单链路与库存校验最容易被忽视的业务底线购物系统的核心不只是“能下单”而是下单之后的订单状态流转和库存一致性。这块业务逻辑如果设计得不对线下测试时可能看不出什么问题一旦上线几单并发就能把库存搞成负数。3.1 订单状态流转设计订单状态不要搞太复杂但节点必须清楚。我的设计是七种状态状态含义触发动作待付款订单创建成功等待用户支付用户提交订单待发货已付款等待商家发货支付成功回调待收货已发货等待用户确认收货商家发货已完成订单完结用户确认收货或系统自动确认已取消用户主动取消或超时未支付系统取消用户点击取消、定时任务触发申请退款用户申请退款用户发起退款流程已退款退款完成商家同意退款并处理关键点是状态变更必须记录操作时间和操作人或者系统触发并保留一张操作日志表。哪怕是个人项目也建议做。因为后排查问题的时候光靠一张订单表很难还原当时发生了什么。3.2 库存扣减与并发安全库存扣减是所有购物项目里最容易出事故的地方。最不推荐的做法是下单时先查询库存库存够就减少然后创建订单。两个用户同时下单都查询到了库存是 1都以为可以买最后库存变成 -1。正确做法是在数据库层面做原子扣减。云开发上可以用db.command.inc(-1)这种方式来做原子减法并且配合一个条件只有在当前库存大于 0 的时候才执行扣减。这样即便并发请求同时到达数据库也能确保扣减后的值不会为负数。另外要注意扣减库存的时机。我强烈建议创建订单时就锁定库存而不是等到支付成功才扣。这样用户看到库存有货就能下单锁定避免下单时显示有货、支付完却缺货的尴尬局面。未支付订单超时后要释放锁定库存这部分靠定时任务处理。3.3 未支付订单的超时释放机制小程序购物系统的订单一般都有支付超时限制常见的是 15 分钟到 30 分钟。实现方式有两种一种是云开发定时触发器每隔几分钟执行一次把超时未支付订单改成“已取消”并回补库存。另一种是在查询订单列表时对订单创建时间做判断超过时限的自动置为失效状态。这种方式不是实时生效但对于访问频率较高的商城也能接受。我实际用的是云开发定时触发器每隔 5 分钟执行一次。注意回补库存和修改状态必须在同一个事务里完成否则可能出现状态改成取消、库存没回补的情况。云开发数据库支持多文档事务这一步别省。3.4 订单号生成规则订单号直接给用户看尽量不要用自增数字。我的项目里用的是这种格式时间戳 用户ID后四位 4位随机数大约 20 位左右。这样既不会有规律性风险下单选错订单时也方便客服按订单号搜索。生成订单号时要注意不要在小程序端生成必须在服务端或者云函数端生成确保唯一性。因为如果两个用户同一毫秒在后端生成订单号重复概率虽然小但一旦撞上就是连锁问题。4. 支付、登录与发布审核微信生态绕不开的三道关口购物系统不是单纯的前后端开发它绑定在微信生态里支付、登录、审核这三件事做得顺不顺利直接决定项目能不能正常上线。4.1 微信登录与用户身份管理小程序登录跟传统的用户名密码登录完全是两码事。小程序端通过wx.login获取临时 code发送到后端换取 openid然后后端生成自定义登录态比如 token 或 session返回给前端。云开发模式下更简单云函数里可以直接拿到用户的 openid不需要搞 code 换 session 这套流程。有一点提醒在云开发里如果加了自定义登录态你要自己维护用户表和 token。但很多初学项目其实没必要做这么重直接用 openid 作为用户唯一标识就够了。用户信息表里再关联上头像、昵称、手机号字段后续做订单查询、会员体系都以这个 user 表为准。手机号快速验证组件是个坑。要使用获取手机号功能小程序必须完成企业主体认证个人主体的小程序是用不了的。所以如果你做的是个人开发者项目不要在这个功能上浪费过多时间让用户手动填手机号即可。4.2 微信支付的接入步骤与常见障碍微信支付接入要走商户号申请流程普通个人开发者没有营业执照一般申请不了。如果你做的是模拟项目或者课程设计可以用微信支付沙箱环境测试流程。如果要真实上线必须要有企业资质。支付流程的大致链路如下小程序端发起支付请求携带着订单号后端在微信支付系统创建预支付单得到支付参数小程序端调用wx.requestPayment拉起微信支付界面用户输入密码支付微信服务器异步通知你的后端服务器确认支付结果后端更新订单状态为“待发货”这里有两个重点支付成功必须以后端接收到的异步通知为准不能只看小程序端回调结果。因为小程序端回调可能因为用户杀进程、断网等原因丢失。异步通知处理要保证幂等性也就是说同一笔订单的支付通知可能被微信发送多次后端必须判断订单当前状态如果已经处理过就不要再重复处理。4.3 发布审核时的那些隐藏规则辛苦写完代码最后还可能卡在发布审核上。小程序审核对购物类应用的审核比其他类型严格我踩过的和听到的坑主要包括小程序类目选择要正确。购物类的应该选“电商平台”或“商家自营”等相关类目同时要提供对应的资质。个人主体基本无法申请电商类目所以这又是一个企业主体的门槛。虚拟商品支付问题。微信小程序里虚拟商品比如知识付费、在线课程是不支持微信支付的只有实物商品可以。如果你想做的不是实物商品购物恐怕要调整产品方向。隐私协议必须配置。小程序审核时对用户隐私保护越来越严格项目中凡是需要收集用户信息的地方都要在隐私协议里明确说明用途。我自己的项目在审核时因为没配置完整的隐私弹窗被拒了一次改完之后才顺利通过。5. 上线之后复盘数据维护、反馈闭环和那些可以提前避开的坑项目上线才是开始。小程序购物系统的后续维护技术含量不在写代码上而在你处理数据和反馈的速度上。5.1 数据库备份与敏感字段加密云开发自带自动备份功能可以直接使用但也要确认备份周期和恢复流程。实际上很多开发者对数据库备份这件事不敏感直到某一天误操作删除了商品表才后悔。用户手机号、地址这些敏感信息在数据库里建议加密存储或者至少做字段级脱敏展示。购物系统的收货地址尤其需要注意因为它是完整的个人隐私信息。5.2 用户反馈入口不可省购物项目必须给用户一个反馈入口否则用户遇到问题只能去应用商店打一星。最简单的方式是做一个“意见反馈”页面提交内容到数据库。然后在小程序后台定期查看和回复。哪怕是一个人维护的项目也应该保证有人在看。很多用户不会因为你做得好而回来夸你但一定会因为找不到人处理问题而放弃你的产品。5.3 版本发布要小步快跑而不是憋大招这一点是我个人体会很深的地方。第一次做购物系统时总想把所有功能都做全了再发布优惠券、秒杀、拼团、会员积分一样不少结果开发周期拖得很长项目差点烂尾。后来改成先上线基础购物链路再迭代扩展。上线之后根据实际用户反馈判断到底要不要加优惠券而不是一开始就拍脑袋设计一堆所谓“肯定有用”的功能。另外每次发版之前一定要在小程序后台配置体验版自己在真机上完整跑一遍浏览商品、加购、下单、支付、查看订单。不要只在小程序开发者工具里测试开发者工具里的支付模拟和真实环境存在差异。5.4 关于性能优化的一点复盘购物页面最容易拖慢速度的一个是首页的商品列表图片太大一个是从数据库查询商品时没有做字段筛选。前端加载时应该优先展示文本信息图片则使用缩略图参数。云开发存储里的图片可以在链接上带裁剪参数比如在图片 URL 后面拼接宽度和裁剪参数生成一张宽度较小的缩略图。商品列表页用小图商品详情页再用原图这种细节看似不起眼实际上能够极大提升页面加载速度。查询数据库时后端只返回前端需要的字段不要一次性把整条商品记录包括很长的详情富文本内容都返回。这个在云开发上可以用.field()指定字段白名单来做。最后再分享一点我的体会做小程序购物系统这类项目技术难点反而都在业务逻辑的细节里订单状态怎么流转、库存扣减怎么保证安全、审核标准怎么满足。把这些细节在方案阶段想清楚后面写代码基本就是翻译工作。如果你目前正准备做类似的项目我建议你把开发范围收敛到最小闭环先把“商品——购物车——下单——支付——订单管理”这条主链路跑通再考虑优惠券、拼团等花活。这个思路让我少走了很多弯路希望你也能用得上。
阅读完成 · 觉得有帮助？
