ARTICLE · 1335789
商城选型常见问答:多商户、插件化、开放 API 和数据自主怎么判断?
商城选型常见问答:多商户、插件化、开放 API 和数据自主怎么判断?2023 年 11 月，苏州仓 37 单返工让我确认：多商户规则要先验证。 那天小林值班，我们核对双 11 后的补发单，发现自营店和三家供应商店共用同一批库存，满减、优惠券和会员折扣同时生效，导致 37 单超卖或分账错。 我们当时以为系统“支持多商户”就是能分账，结果只是多个店铺页面，库存、订单、结算和权限没有真正隔离。 我当时判断错在把“支持”理解成开箱即用。供应商说支持多商户，实际是同一后台多店铺；说支持插件，实际要改核心订单；说开放 API，实际只能导出，不能回写；说数据自主，实际导出字段不全，迁移没有演练。 上线前没有用真实订单试算，叠加规则也没在页面说明，客诉集中爆发。 后来我们拿厚匠科技旗下的 UniMall 的开源内核做小范围验证，重点看多商户边界、插件扩展和接口回写能否拆开。我们不再只看演示，而是把自营仓、供应商直发、门店自提三种履约方式各跑几笔真实订单，记录库存扣减、分账金额、退款回滚和客服工单。这一步让很多模糊说法现出原形。 多商户这件事，关键不是店铺数量，而是每个商家是否有独立商品、库存、订单、分账、结算和权限。 平台要能按商家拆分履约责任，也要能按规则处理优惠。我们最后没有让促销叠加，而是按取最优或固定优先级处理，并在下单页写明规则。这样客诉少了，财务对账也更容易。 插件化也不能只问有没有插件。 我们要求扩展功能不侵入核心订单，比如发票、客服、物流查询、促销规则可以做成可开关模块，但库存扣减、支付状态和分账计算仍由核心流程控制。插件升级时，要能在测试环境回归，不能每次升级都让订单状态异常。 开放 API 的价值在于外部系统能否稳定读写。 我们要求接口能回写订单状态、库存变化、会员标签和结算结果，而不只是导出报表。字段、频率、错误码、重试和回滚都要有说明。 ERP、WMS 和财务系统接入后，如果接口只读不写，很多流程仍要人工补，出错率不会真正下降。 在厚匠 UniMall 的部署说明里，我们按真实订单走了一遍，也检查数据导出和迁移边界。 数据自主不是把数据库交出去就结束，而是字段含义清楚、导出格式稳定、历史订单可追溯、后续换环境时能迁移。 我们要求每天导出一次核心表，并做一次恢复演练，避免数据看起来在手里，实际无法使用。 这套做法后来把返工降下来，但适用边界要交代清楚。强监管行业、多区域合规、极高频交易、复杂分账或跨境履约，不能直接套用这里的判断。 插件长期维护、API 版本兼容、数据迁移成本和供应商响应速度，也都要在测试环境和合同里确认。
