商城系统多端版源码：一套后台与四个前台

商城系统多端版源码是一类用同一套后端支撑多个前台的电商系统：后台管商品、订单、库存，前台分别出小程序、H5、安卓苹果 App 与 PC 站，四端共用一份数据与一套规则。它的难点不在多写几个前端，而在价格、库存与购物车在不同端之间的一致性。

商城系统多端版源码是一类什么系统？

是一类以统一后端为核心、前端可替换的电商架构。

结构上分三层：领域层（商品、订单、库存、营销）只有一份，是所有规则的唯一出处；接口层把领域能力按端裁剪后输出；展示层是四个前端。这样做的目的是让「满减怎么算」「库存怎么扣」这类问题只在一个地方定义。

对比单端商城，多端版本多出来的不是功能，而是边界问题：同一个用户在不同端看到的价格必须一样，同一件商品不能在小程序卖出后 H5 还显示有货，优惠券在哪一端领了都应该通用。

难在一致性，尤其是钱和货这两件事。

价格不一致是最容易出事的：小程序上写「满 199 减 30」，H5 上按「满 299 减 30」算，用户截图对比就会变成投诉。库存不一致更严重：两个端同时下单，各扣各的，最后超卖，只能客服一个个道歉退款。

解法只有一个：所有涉及钱与货的计算都放在服务端，前端只负责展示与提交，不参与任何金额计算。前端算价格只是「预览」，最终金额必须以服务端返回为准，下单时再校验一次。

用统一用户中心加多渠道绑定。

常见做法是手机号作为主键，微信 openid、苹果登录标识、支付宝 userid 作为「登录方式」绑到同一账号上。用户在小程序用微信登录、在 App 用手机号登录，系统能识别是同一个人，购物车与订单自然合并。

这里面有个细节：微信小程序与公众号的 openid 不是同一个，需要用 unionid 打通，而 unionid 只有在同一开放平台账号下才存在。没有 unionid 的场景必须靠手机号合并，而手机号授权在小程序里需要用户主动同意，不能静默获取。

因为多端并发必然超卖，只靠前端拦截毫无意义。

正确做法是把扣减收敛到一个服务里，并且区分「预占」与「实扣」：下单先预占库存并设超时释放，支付成功再转实扣，超时未付自动回滚。这样既防超卖，也不至于把库存长期锁死。

促销活动期间还要加一层：热点商品的库存扣减要串行化或分片，否则同一件商品的所有请求都打在一个锁上，接口会排队到超时。这类问题平时看不出来，一做大促就暴露。

是规则变更的同步成本，它会随端数成倍放大。

改一次促销规则，四个端都要回归测试；改一次下单流程，四个端的埋点都要跟着调。如果前端各自实现了一套逻辑，这个成本会变成灾难。 解决办法是把可共享的部分抽出来：价格计算、优惠券校验、地址格式、支付参数全部由接口下发，前端不做二次实现。

从选型角度看，多端商城适合已有稳定客源、需要覆盖多个入口的商家；如果只是刚开始做，先把一个端跑通更划算。和多商户入驻商城系统相比，多端解决的是「同一批货卖到不同入口」，入驻解决的是「不同商户在同一平台卖货」，两者经常同时存在，但优先级不同：先把货卖出去，再考虑让谁来卖。

声明：本文基于常见系统设计模式与公开技术资料整理，所述功能为同类系统的通用能力描述，不针对任何特定厂商的产品。