18年沉淀高端建站经验
为企业持续赋能品牌新价值
"做一个商城小程序"听起来是一个需求，实际是五条相互咬合的链路：商品、购物车与库存、订单、支付、售后。任何一条设计不严谨，都会以"超卖""漏单""退不了款"的形式暴露出来。本文按链路顺序拆解，并标注每段的易错点。
商品模块最容易在后期推倒重来，因为 SKU 结构一旦定型，订单、库存、统计全都依赖它。
| 要素 | 设计要点 | 常见错误 |
|---|---|---|
| SPU / SKU | SPU 承载展示，SKU 承载价格与库存 | 只用一层结构，无法支持多规格 |
| 规格组合 | 支持二维规格（如颜色 × 尺码）与独立定价 | 规格价格只能全局设置 |
| 价格体系 | 原价、售价、会员价、阶梯价分层 | 促销价直接覆盖原价，无法追溯 |
| 库存模型 | 总库存与 SKU 库存联动，支持预占 | 下单不预占，导致超卖 |
| 商品状态 | 草稿、上架、下架、售罄、定时上架 | 只有上架/下架两态 |
| 内容字段 | 主图、详情、参数、运费模板、售后说明 | 详情用长图，加载慢且无法检索 |
其中库存预占是最关键也最常被省略的一项。用户下单后未支付期间应临时锁定库存，超时再释放。没有这一步，秒杀场景中超卖几乎是必然的。
有两种主流做法，适用场景不同。
无论选哪种，都要在商品页明确展示可售库存，并在库存不足时给出明确提示，而不是让用户支付后才发现没货。
购物车里的价格、库存、上下架状态会随时变化。正确做法是：购物车展示的是下单时刻的实时数据，而非加入时的快照；当价格或库存发生变化时，需在结算前明确提示用户。直接沿用旧数据会导致价格纠纷。
订单模块的核心是一张状态流转图。常见状态如下。
| 状态 | 触发条件 | 可执行动作 | 易错点 |
|---|---|---|---|
| 待支付 | 用户提交订单 | 支付、取消、超时关闭 | 超时未关闭，库存长期占用 |
| 待发货 | 支付成功 | 发货、改地址、申请退款 | 改地址未同步物流单 |
| 待收货 | 商家发货 | 确认收货、查看物流、延长收货 | 自动确认收货时间未设置 |
| 已完成 | 确认收货或超时 | 评价、申请售后 | 完成后无法发起售后 |
| 退款中 | 用户申请且商家同意 | 退货、退款 | 退款与退货流程未分离 |
| 已关闭 | 取消、超时、退款完成 | 不可操作 | 关闭后库存未回滚 |
两个必须提前定义清楚的边界：已发货订单能否拦截、已完成订单多久内可售后。这两条直接影响客服工作量与用户满意度。
支付回调的幂等性是这里最容易出生产事故的点，务必在测试阶段专门验证重复通知场景。
售后常被当成次要模块，实际它决定了复购率。至少应支持：
营销功能可以无限扩展，但**版建议只做三类，其余按数据决定。
| 类型 | 作用 | 复杂度 | 建议优先级 |
|---|---|---|---|
| 优惠券 | 拉新与转化 | 中 | **版必做 |
| 拼团/秒杀 | 冲量 | 高（需压测） | 第二版 |
| 分销 | 裂变 | 高（涉合规） | 需先评估合规性 |
| 会员等级 | 留存 | 中 | **版可选 |
分销模块要特别注意合规边界，多级分销存在法律风险，上线前应做合规评估。
电商类小程序需开通微信支付商户号，涉及特殊商品（食品、化妆品、医疗器械、出版物）还需对应经营许可。iOS 端若涉及虚拟商品，同样受平台支付规则限制。
我们服务过的企业覆盖新能源、高端制造、半导体、生物医药、物联网等行业，包括 SUNGROW、科大讯飞、默克、兆易创新、金赛药业、三安集成等。这类企业的商城往往不是标准电商，而是带审批流、带客户分级定价、带账期结算的 B 端交易——标准电商模板在这类场景中几乎无法直接使用，这也正是定制开发的价值所在。
判断标准很简单：如果你的交易需要"不同客户看到不同价格"或"下单后要经过审批"，那就不是标准商城，必须定制。
标准电商形态通常在五万到十二万；若涉及 B 端分级定价、审批流、与 ERP 对接，通常在十二万以上。具体需按功能清单评估。
标准商城 6–10 周；含定制业务规则或第三方系统对接 10–16 周。支付商户号申请应提前启动，通常需要数个工作日。
如需在小程序内完成交易，是的。需企业主体、对公账户与相关资料，审核需要时间，建议与开发并行启动。
核心是库存预占加超时释放，配合并发控制（乐观锁或队列）。同时商品页应展示实时可售库存。
多数可对接，但需在开发前确认接口文档、接口人与是否收费。库存与订单同步是联调阶段最耗时的部分。
明确三点：退款时效、优惠分摊方式、券与积分是否返还。规则应在下单页可查，而不是等用户申请时才告知。
一级分销通常可接受，多级分销存在法律风险。上线前应做合规评估，不要照搬其他平台的模式。
建议只做能跑通完整交易闭环的最小集：商品、购物车、订单、支付、基础售后。营销与会员留到二期，用真实数据决定优先级。
标准模板适合标准业务。若你的交易涉及分级定价、审批流、账期或存量系统对接，模板的底层结构会成为长期阻碍，改造成本往往高于定制。
建议先按上文第二节的两个库存问题与第三节的订单状态机核对需求文档，这两处最容易在后期返工。需要评估具体项目，可以，或了解我们的与。
围绕小程序开发的完整决策链，可以继续阅读：
