商城小程序开发实战避坑指南

去年帮一个做社区团购的朋友从零上线商城小程序，中途踩的坑比预想多得多。这篇不聊概念，只讲我实际写代码、调接口、过审时遇到的问题和解决办法，给准备动手的独立开发者做个参考。

先把商品模型想清楚，别急着写页面

很多人一上来就搭首页轮播、写商品列表，结果做到购物车发现 SKU 结构对不上，返工重来。我的建议是先定三张核心表：商品（spu）、规格（sku）、库存与价格挂在 sku 上。多规格商品用「规格组 + 规格值」的组合方式存，比如颜色:红/蓝，尺寸:M/L，前端做笛卡尔积生成可选项。

// sku 结构示例
{
  spuId: "1001",
  specs: [{ name: "颜色", value: "红" }, { name: "尺寸", value: "M" }],
  price: 5900,      // 单位：分，避免浮点误差
  stock: 20,
  skuCode: "1001-R-M"
}

价格一律用整数分存储，展示时再除以 100。这个习惯能帮你省掉后面大量对账问题。

选云开发还是自建后端

个人项目我倾向云开发：数据库、存储、云函数一把梭，省掉服务器运维和备案之外的麻烦。但要注意两点：

• 云数据库的查询有单次返回条数限制，商品列表要做分页，别指望一次拉全量。
• 下单、扣库存这类操作必须放云函数里，靠数据库事务或原子操作保证一致性，前端直接改库存迟早出事故。

如果商品量大、要做复杂促销（满减叠加、阶梯折扣），自建后端更可控。判断标准很简单：促销规则能不能用几行 if 写完，写不完就上服务端。

购物车与下单链路

购物车建议本地存一份、云端存一份。未登录时用本地缓存，登录后合并上传，冲突时以云端为准并提示用户。下单流程拆成三步：

1. 确认订单页：前端只做展示，金额、优惠、运费全部由服务端计算后返回，前端不参与算钱。
2. 创建订单：服务端校验库存、锁定库存、生成订单号，返回支付参数。
3. 支付回调：以微信支付回调为准更新订单状态，前端轮询或监听结果，不要信任前端上报的「支付成功」。

踩过的坑：曾经在前端算总价，结果优惠券和运费叠加顺序不一致，用户看到的金额和实付差了一块钱，客诉直接找上门。金额计算永远只信服务端。

性能优化：首屏和图片是大头

• 首页商品图用 CDN 加尺寸参数，列表用缩略图，详情页再加载大图，别一张原图走天下。
• 图片开启懒加载，长列表用分页或虚拟列表，一次渲染几百个节点手机会明显卡顿。
• 分包加载：把订单、个人中心这类非首屏页面拆到分包里，主包控制在 2MB 以内，否则审核和启动都难受。
• 接口能合并就合并，首页一次请求拿轮播、分类、推荐，比三次串行快得多。

上线前的检查清单

提交审核被拒是常事，提前把这些准备好能少折腾：

• 类目资质：商城类目通常要营业执照，食品、化妆品等特殊品类还要额外许可证。
• 隐私协议与用户信息授权：获取手机号、位置前要有明确说明，别默认勾选。
• 支付资质：微信支付商户号要提前申请，个人主体开不了支付，这点务必先确认。
• 测试环境跑一遍完整链路：加购、下单、支付、退款、订单查询，尤其是退款，很多项目上线才发现没做。

一点经验

商城小程序看着功能多，真正难的是资金和库存的准确性，页面反而是最容易的部分。把数据模型和金额计算这两块打牢，后面加营销功能就是往上叠。独立开发者时间有限，别追求功能全，先跑通「浏览—加购—支付—发货」这条主线，再逐步补优惠券、会员、分销。先能卖货，再谈增长。