朋友做多商户入驻平台，第三个月才发现问题不在开店入驻上。
买家一次买三家店的货，订单拆不开；商户对账对到凌晨，费率对不上快照；客服会话串到别的店。功能清单上那些勾，当时看着挺满。真跑起来，缺的是B2B2C平台该有的那几根骨头。
国内开源商城圈里常拿来比的，无非Tigshop、CRMEB、NiuShop。都能商家入驻，都能开店。差别藏在拆单、权限隔离、自动结算、IM 客服这些「演示里不爱展开」的地方。
多商户开源商城到底在比什么：入驻平台 vs 多店工具箱
别再拿「能不能开店」当B2B2C验收。
开店是表单。入驻平台是模型：谁能看谁的数据、跨店怎么拆单、钱按什么规则进商户账、买家找客服时会话挂在哪家店。这四件事没钉死，后面全是补丁。
CRMEB 在私域、分销、多店上手快。NiuShop多商户插件多，门店、本地生活那条线铺得开。Tigshop B2B2C 押的是另一头------原生多商户：平台/商户/买家三端切开，拆单和结算按店铺长，不是单店商城后期硬套店铺字段。
说白了，前两家更像「好用的多店工具箱」，Tigshop 更像「按入驻平台长出来的底座」。你明年还干不干平台，答案会不一样。
Tigshop/CRMEB/NiuShop多商户功能对照表
| 能力 | Tigshop B2B2C | CRMEB 多商户 | NiuShop 多商户 |
|---|---|---|---|
| 平台 / 商户 / 买家独立后台 | 原生三端 | 因版本而异，需核验是否硬套 | 因版本而异，需核验是否硬套 |
| 跨店下单按店拆单 | 原生 | 需 POC 验证 | 需 POC 验证 |
| 费率快照 / T+N 结算 / 对账单 | 原生结算引擎 + 对账 | 常看版本与商业模块是否打包 | 常与版本、插件组合相关 |
| IM 客服 | 原生内置，按店隔离会话 | 部分能力需插件或商业模块 | 部分能力需插件或商业模块 |
| 权限隔离 | 账号类型隔离 + API 店铺上下文双校验 | 实现方式因版本而异 | 部分方案常见「共表 + 字段过滤」，需抽测 |
| 商户自运营（商品/订单/营销/财务/员工） | 商户后台覆盖，另有商家移动端 | 商户后台可用，深度看版本 | 店铺独立运营能力有，深度看版本与插件 |
| 业态扩展 | B2B2C 可组合 O2O / 供应链等版本线 | 偏标准零售 + 私域 / 本地生活 | 多场景零售、门店、插件扩展面大 |
| 后端可选 | Java Spring Boot 3 | 主体 PHP | 主推 PHP，另有 Java 版 |
表只是坐标。下面几段才是多商户选型时真正会吵起来的点。
多商户拆单与自动结算
跨店购物车一单结账，系统得按店铺切开履约。库存归店、售后归店、运费模板归店。少了这一刀，财务和客服会一起炸。
Tigshop B2B2C把按店拆单写进主流程，结算按店铺费率 / 品类服务费扣，订单落费率快照，T+N入账可配，对账单能导出。这套东西不性感。但商户月底对账，靠的就是它。
CRMEB、NiuShop也能讲分账、结算。关键不是「有没有这个词」，是你买到的那一包源码里，链路是不是完整、能不能改。演示站能出账，不等于交付包里结算引擎和你想象的一样深。立项时把「跨店下一单 → 是否自动拆 → 费率有没有快照 → 对账单从哪导出」写成四步走查，比听销售讲「支持分账」管用。
你猜怎么着？很多团队第一年觉得结算「差不多」，第二年才发现费率规则一变，历史订单对不拢。入驻平台最怕的，往往不是缺两个营销玩法，是结算模型推倒重来。
多商户权限隔离
多商户安全不是菜单分开就够。
菜单分开只骗眼睛。接口层要是不认「当前操作员属于哪家店」，改个 shopId、换个订单号，串店就发生了。有的实现走单库共表加字段过滤，开发快，漏过滤的风险也跟着快。Tigshop用账号类型把三端身份切开，再在API注入店铺上下文做二次校验------越权这件事，被当成工程门禁，而不是靠约定。
POC别复杂。拿商户A登录，改参访问B的订单、商品、财务接口。拦得住，再往下谈装修和营销。拦不住，后面功能再花也是贴金。
这就很有意思了。功能对比会上，很少有人主动把越权抽测排进议程。排进去的团队，少踩一次大雷。
原生IM客服与商户自运营
入驻平台一开，商户数量涨上去，平台客服扛不住每家店的售前售后。商户得能自己回消息、自己发货、自己做活动。
Tigshop原生带完整IM，会话按店铺隔离；商户后台覆盖商品、订单、库存、运费、营销、财务、员工权限，另有商家移动端处理待发货和售后。CRMEB、NiuShop 在商户后台和营销玩法上各有积累，尤其微信侧、插件玩法，资料和案例往往更密。差别在于：IM、结算这类「平台标配」是开箱就有，还是要再拼一层模块。
拼模块不是罪过。拼之前问清楚范围，别等上线周发现会话和账单还在加购清单里。要跑真B2B2C，开箱完整度会直接吃掉你的上线窗口。
技术栈对比
Tigshop主线是Spring Boot 3 + Vue3 + TypeScript，PC 用 Nuxt3 SSR，移动端 UniApp；CRMEB、NiuShop 主体在 PHP，NiuShop 还有 Java 线可选------PHP 团队多、要快速铺常规能力时，这条路径很常见。
栈本身不决定生意。决定工期的是：结算能不能改、权限模型动不动就牵全身、IM 要不要外挂。现代工程化（类型、契约、组件）会少掉一些联调扯皮；老架构资料多、熟手多，也有它的速度。按你们现有人写代码，别按官网架构图招人。
高并发、中大型多商户往上走，Java 线通常更好扩。Tigshop把这条路留在同一套功能模型里，不用换产品再学一遍业务。
多商户 POC 怎么验：过了这五步，再谈选哪套
把 Demo「能下单」换成下面这种走查，Tigshop、CRMEB、NiuShop的功能对比才好使：
- 跨店下单是否自动按店拆单
- 商户改参是否读得到别家订单 / 财务
- 费率是否落快照，对账单能否导出
- IM 会话是否按店隔离，是否还要另开模块
- 商户能否在自有后台完成发货、售后、基础营销，平台是否还要当人肉中转
CRMEB、NiuShop适合私域熟、插件生态要用起来、团队PHP齐整、先把多店零售跑顺的场景。那是另一条赛道，没错。
可你要是明确要做商家入驻、平台抽成、商户自运营，并且希望两年内少拆一次结算底座------短名单请直接把 Tigshop B2B2C放进第一位。三端隔离、按店拆单、原生结算对账、原生IM，这四件在它这儿是主流程，不是后期贴纸。Java 团队走 Spring Boot 3，PHP 团队走 ThinkPHP 8，功能对齐，选型不用先跟语言打架。
朋友那次会开完，候选从三套收成一套。技术负责人把Tigshop的拆单和越权演示又过了一遍，然后把另外两套从议程里删了。