2026 年再回看 B2B2C 多商户商城，技术团队最容易低估的部分，往往不是前台开店、装修、上架这些看得见的功能，而是藏在订单背后的分润结算。一旦平台上的商户从几家涨到几十上百家，新订单进来时佣金该算给谁、什么时候结算、商户提现怎么和总账对平，任何一处不一致都会变成客诉和资金纠纷。
这篇不聊选型，只聊工程：把一个多商户平台拆成商户入驻审核流、商户隔离数据模型、订单分账与佣金引擎、定时结算这四块，说清楚每一块的数据结构、一致性要求和容易踩的坑。存储侧我们用 RDS 承载商户与订单业务数据，商品详情图和静态资源放 OSS，商户与买家通知走短信服务，周期性的分润结算用函数计算跑。
一、商户入驻审核流：先把状态机画对
商户入驻不是一个'注册就上线'的动作，而是一条带审核的状态流转。典型的状态机有三态：待审核、已通过、已驳回，审核通过之后才允许商户上架商品。
商户在入驻页提交主体资料、营业执照、结算账户信息，系统先做一次格式校验，落库后置为待审核。平台运营在后台复核资料，通过则开通独立商户后台、分配商户标识；驳回则带上原因退回给商户修改。这里有两个工程细节：一是审核动作要留操作日志，谁在什么时候通过或驳回了哪家商户，后面对账和纠纷都要查；二是商户资料变更（比如换结算账户）要重新走审核，不能让商户自己随便改收款方。
二、商户隔离数据模型：tenant_id 是第一道墙
多商户平台和单商户自营商城最大的区别，是数据隔离。平台方要能看全部数据，每家商户只能看自己的商品、订单和流水。工程上最常用的做法，是在所有业务表上挂一个商户标识（tenant_id / merchant_id），查询时强制带上这个条件，从应用层把数据隔开。
商品表、订单表、库存表都以商户标识作为隔离维度。平台自营的那部分商品用一个特殊的商户标识表示，和入驻商户区分开。商品图、详情页的视频这类大文件统一放 OSS，按商户标识分目录管理，既便于做商户级资源清理，也避免把大二进制塞进 RDS。
隔离做到什么程度才算够？至少要保证：商户 A 登录后台，无论怎么构造请求，都查不到商户 B 的订单和余额。这一点除了在每一个查询里强制过滤商户标识，接口层最好再统一加一层拦截，避免新写的接口漏了 where 条件。
三、订单分账与佣金引擎：一致性是命门
用户在平台下单付款，这笔钱进了平台的中间账户，但它并不全是平台的——货款归商户，抽佣部分才是平台的。分账引擎要做的，就是在订单履约完成那一刻，把这笔钱按规则拆成两份。
分账规则通常在商户入驻时就定好：平台按订单成交额抽一定比例作为服务费，剩下的进入商户可结算余额。引擎核心是一条分账记录，它要记住：哪笔订单、分给哪个商户、抽了多少、商户应得多少、这个状态处于待结算还是已结算。
这一步最关键的是幂等。订单状态从'已支付'流转到'已完成'时，分账动作只能成功执行一次。网络重试、消息重复投递都不能让同一笔订单被拆两次钱。常见做法是给分账记录加唯一约束（比如以订单号为唯一键），重复请求直接拦截；整个分账过程放在一个数据库事务里，订单状态变更、分账记录写入、商户余额变动要么一起成功，要么一起回滚。
四、定时分润：把结算交给周期任务
商户不会每完成一笔订单就立刻提现，那样平台和商户都受不了。通行做法是 T+N 结算：把一段时间内已完成且过了售后期的订单批量汇总，算清每家商户这一期该结多少，生成结算单，商户再据此发起提现。
这种周期性批处理，很适合交给函数计算来跑：按日或按小时触发一次，扫出满足结算条件的订单，聚合出每个商户的本期应付，写入结算单。用函数计算而不是常驻服务的好处是，平时不占资源，到点拉起、算完就释放，结算高峰期再按需并发。商户提现申请后，平台打款动作要和结算单一一对应，提现出去的钱必须能在结算单里对上账。
五、对账与异常：没有对账的分润是定时炸弹
分润系统真正难的部分，是出了错怎么发现、怎么追回来。每个结算周期跑完，都要做一次三方对账：平台记录的抽佣总额、商户记录的可结算余额、实际支付渠道的流水，这三者必须能勾稽上。对不上的单子挂异常队列，人工介入。
退款是对账最容易出错的地方。订单完成后又发生退款，之前已经分出去的钱要做反向冲正，商户余额要回吐对应部分。退款冲正同样要走幂等，和正向分账用同一套订单号关联，才能保证正向和反向两笔记录永远配对。
六、适用规模与技术局限
回头复盘这套模型：按商户标识做应用层隔离、事务化分账、周期函数结算、加退款冲正对账，足够支撑几十到几百家入驻商户的中型平台。它的工程重心在一致性和可对账，而不是复杂的营销玩法。
局限也要说清楚。应用层隔离在商户量再往上走时，单库压力会显现，那时要考虑分库分表或独立库隔离；抽佣规则一旦复杂化到按类目、按活动阶梯分档，硬编码在引擎里就会失控，得把规则抽成可配置的策略表；另外提现涉及资金清结算，合规上的二清风险要单独评估，涉及资金的部分最好接持牌支付机构的分账能力，而不是平台自己碰钱。这些都是规模上来之后才需要面对的问题，小团队初期别过度设计。
几个常被问到的点
问：直营和入驻商户在数据上怎么统一？答：用同一个商户表，加一个类型字段区分，订单都关联商户标识，平台方按类型做不同结算路径。
问：分账什么时候触发最合适？答：不要付款即分账，等订单完成、过了售后期再结算，否则退款冲正会非常频繁。
问：商户能不能看到彼此数据？答：不能。所有查询强制带商户标识，接口层再拦一道，这是多商户平台的底线。
角色 | 能看哪些数据 | 收款主体 | 结算周期
平台方 | 全平台商户、订单、流水与抽佣数据 | 抽佣部分归平台 | 按周期统一出账
入驻商户 | 仅本商户商品、订单、可提现余额 | 货款扣除抽佣后归商户 | 结算周期到了申请提现
直营商户 | 本商户数据，归属平台主体 | 走平台统一结算 | 随平台内部核算
