做过单商户商城的人，转向多商户商城时，通常会先被两个问题卡住：订单怎么拆？钱该怎么分？这两个环节处理不好，后面的对账、售后和结算都会变得很麻烦。
一、商家入驻别只做一张表
在搭建或开发多商户商城系统时，我更倾向于把商家拆成三层：基础信息、资质信息、运营配置。
基础信息用于登录和店铺展示；资质信息单独存储，便于审核与更新；运营配置则包含运费模板、结算周期、抽佣比例等。这样做的好处是，后期扩展多商户商城APP/小程序时，不需要频繁修改核心商家表。
审核流程建议采用状态机设计：待提交、待审核、驳回、已通过、已冻结。后台只修改状态，不直接删除数据，排查问题会轻松很多。
二、订单拆分的关键时机
用户购物车可能同时包含多家店铺商品。
实践中，我会在“提交订单”阶段完成拆单：
- 按 merchant_id 分组商品
- 生成一个主订单
- 为每个商家生成子订单
- 记录主子订单映射关系
这样支付只发生一次，但发货、退款、售后都能独立处理。数据库层面建议给子订单增加 merchant_id、settlement_status、commission_rate 等字段，后续结算无需跨表反复计算。
三、订单分账与平台抽佣
很多团队把抽佣写死在代码里，后期调整非常痛苦。
更稳妥的方式是：
- 平台默认抽佣比例
- 商家级覆盖配置
- 类目级特殊配置
- 订单创建时固化佣金快照
订单支付成功后，只记录“待结算”金额，不立即修改商家余额。真正的入账放在结算任务中执行，可避免退款导致的反复回滚。
结算任务通常按日跑批：
- 汇总已完成订单
- 扣除平台佣金
- 扣除退款金额
- 生成结算单
- 更新商家可提现余额
这一层最好保持幂等，同一批次重复执行也不会重复入账。
四、多端同步的实现细节
多商户商城APP/小程序最容易出现的体验问题，其实是状态不同步。
我一般会采用：
- Redis 缓存店铺和商品热点数据
- 消息队列处理支付、库存、结算事件
- WebSocket 推送新订单通知
- 延迟队列关闭超时未支付订单
例如支付成功后，先写订单，再发送支付成功事件。库存扣减、积分发放、结算标记分别异步消费，主链路响应会更稳定。
五、关于多商户商城系统源码
无论使用 Java、PHP 还是其他技术栈，多商户商城系统源码最值得关注的不是页面数量，而是数据边界是否清晰。
至少要确认：
- 商家之间是否做数据隔离
- API 是否校验 merchant_id
- 订单与结算是否可追溯
- 配置修改是否留有日志
- 重复回调是否具备幂等处理
这些地方往往决定系统后期维护成本。
六、结语
对于多商户商城系统来说，页面开发只是基础，真正影响系统稳定性的，是商家体系、订单链路以及资金结算流程能否保持一致、高效地协同运转。把入驻审核、订单拆分、分账结算和异步事件提前设计清楚，后续无论扩展多商户商城APP/小程序，还是迭代多商户商城系统源码，都会顺手得多，也更容易应对真实业务中的变化。
