想做一个多家卖家同台卖货的市场，却发现单商户电商只能管一家店的商品和订单，供应商入驻、报价、佣金与打款都得自己从头写。Mercur 就是补这一块的开源平台：它在 Medusa 电商核心之上加了多供应商能力。本篇讲清楚：多供应商商城到底包含哪些能力、部署前先准备什么、装完先改哪几处配置，并给出部署方式的取舍结论。
Mercur 软件信息表
| 项目 | 内容 |
|---|---|
| 软件名称 | Mercur |
| 软件类型 | 开源无头多供应商市场平台 |
| 底层核心 | Medusa commerce core |
| 技术栈 | TypeScript、事件驱动、API-first |
| 运行要求 | Node.js 20.x 及以上、PostgreSQL 13.x 及以上、Redis |
| 适用业务 | B2C、B2B 与混合型多供应商市场 |
| 获取方式 | 官方仓库源码，自托管部署 |
版本选择：多供应商商城先定部署方式
结论先行：能维护 TypeScript、Medusa、PostgreSQL 与 Redis 技术栈的团队选自托管；维护不了这套栈的团队先不要上，先补运维能力或另选托管方案。自托管换来的是数据、基础设施与产品路线的完全控制，代价是数据库、缓存与第三方凭据都得自己管；这个代价付不起时，平台能力再全也落不了地。
| 部署方式 | 适合谁 | 不适合谁 |
|---|---|---|
| 自托管部署 | 要控制数据与基础设施、能维护整套技术栈的团队 | 不想维护数据库、缓存与第三方凭据的团队 |
| 托管平台部署 | 想快速验证市场模式、暂不投入运维的团队 | 对数据归属与定制深度有硬要求的团队 |
| 只用 Medusa 单商户核心 | 业务确实只有一家卖家、不需要供应商体系的项目 | 业务包含多卖家报价、佣金结算的项目 |
安装与部署：只抓关键卡点
- 先备齐基础设施：据官方文档说明，运行环境至少需要 Node.js 20.x、PostgreSQL 13.x 和 Redis，推荐使用 Bun，缺一项就不要开始安装，装到一半补环境最容易留隐患。
- 先跑通后端 API、管理面板与供应商面板三个入口，再接支付、邮件或搜索集成：三个面板有一个打不开，后面的集成调试都没有意义。
- 启用 Stripe Connect、Resend、Algolia 或 Meilisearch 这类集成之前，先把对应服务的凭据申请好并写进环境变量，凭据不到位时不要先把开关打开。
- 上线前走一遍完整交易链路：供应商入驻、商品上架、多卖家报价、订单拆分、佣金计算、自动打款，任何一环没跑通都不要对外开放入驻。
- 把数据库、缓存与第三方凭据的备份与恢复方案先写下来：生产部署细节在公开信息里有限，备份与故障恢复必须自己验证，不能假设默认就有。
装完必改设置：多供应商商城跑顺的四处配置
- 供应商入驻与审核配置（管理面板中的供应商规则）：把入驻字段、审核流程与卖家权限定下来，体感差别是新卖家按固定流程进来，运营不用每次手动补资料、逐个改权限。
- 佣金规则配置（管理面板中的佣金与结算规则）：按品类或卖家等级设好佣金比例与结算周期，体感差别是订单完成后佣金自动算清，财务不用月底再逐单对账。
- 打款与支付集成配置（环境变量中的支付服务凭据）：把自动打款的触发条件与失败重试策略配好，体感差别是卖家收款不再依赖人工转账，失败的单子也能被系统捕获而不是悄悄丢单。
- 搜索与邮件集成配置（环境变量中的搜索与邮件服务）：接通商品搜索与交易邮件通知，体感差别是买家能按卖家、价格与地区筛商品，下单、发货与打款的关键节点也能收到邮件提醒，不再靠人工逐个通知。
使用 Mercur 的注意事项
- 前端范围要先核对：据官方文档说明，平台面向无头架构，是否提供覆盖所有业务场景的预构建前台需要核对，缺的前台页面要自己接 API 实现，不要假设开箱就有完整买家端。
- 生产拓扑与容量规划要自己验证：据官方文档说明，摘要没有完整说明生产部署拓扑、容量规划与高可用配置，上线前必须结合文档与源码确认，不能直接按开发环境规模估算生产资源。
- 打款合规边界因地区而异：自动打款流程依赖具体集成配置，各地区支付、结算与合规边界在摘要里没有详细说明，涉及真实资金前必须先确认目标地区的规则。
- 升级要同步看四个组件：Mercur、Medusa、Node.js、PostgreSQL 与 Redis 的兼容性要一起核对，工作流扩展与数据库结构的变更可能互相牵连，单升一个组件容易埋下兼容问题。
- 凭据必须走环境变量管理：支付、邮件与搜索服务的凭据不要写进代码仓库，泄露后的轮换成本远高于一开始就规范管理。
适用人群与横向对比
适合的人群是：需要自托管 B2C、B2B 或混合型多供应商市场的开发团队，以及希望基于 TypeScript 与 Medusa 定制电商核心流程的企业技术团队。不适合的人群是：只需要单商户电商的项目，以及不希望维护数据库、缓存与第三方凭据的团队——这时 Mercur 的多供应商能力是多余成本，单商户方案反而更轻。
横向看，Mercur 的分工边界在市场模型层：它解决的是多卖家围绕同一商品报价、订单拆分、佣金与打款这一层问题；商品、订单、支付、配送、税费与库存这些电商基础能力则复用 Medusa 核心。如果把这两层混在一起自己重写，等于重复造一遍电商核心；反过来，只拿 Medusa 核心硬做多供应商市场，供应商体系又得全部手写，选型时按这一层分工判断最省事。
官方下载
源码与文档请从官方仓库获取：Mercur 官方仓库。
关注「软件教程管家」
回复软件名即取即下：网盘下载链接 + 提取码，一步直达，不用再跳转。
本站资源仅供个人学习交流，请勿用于商业用途。软件与资料版权归原作者所有；如有侵权，请通过公众号「软件教程管家」联系我们，我们将在 24 小时内下架处理。查看免责声明 ›
