从零落地一套 B2B2C 多商户商城:多租户、营销闭环与工程化打包实践
技术栈Spring Boot 2.7 MyBatis-Plus Vue3 UniApp MySQL最近一段时间我把一套「平台运营端 商家经营端 C 端 H5」的多商户商城从业务原型推到了可演示、可打包交付的状态。过程里踩坑不少也沉淀了一些可复用的设计。本文不讲空概念主要分享多租户怎么切、优惠券/积分怎么串起来、以及怎么把工程做成一键打包。一、先把角色边界画清楚很多同学一上来就建表、写 CRUD结果平台审核、商家发货、C 端下单缠在一起。我这边先强制拆成三条 API 前缀1/api/platform/** —— 平台运营入驻审核、店铺启停、全局订单/会员、RBAC2/api/merchant/** —— 商家商品、订单履约、发券、装修、本店账号3/api/mall/** —— 消费者逛店、领券、下单、积分兑换、钱包鉴权统一走 JWTclaims 里带上- utypePLATFORM / MERCHANT / MALL- mid / sid商家 ID / 店铺 IDC 端进店后绑定业务查询几乎都以 merchantId / shopId 过滤。这样即使库表里保留了多租户字段单商户交付时也可以固定 shopId1不必拆库重写。小建议平台端和商家端做成两个 Vue 工程或至少两套路由与布局。菜单权限、审核流、经营流差异很大硬揉一个后台后期会很痛苦。二、多租户隔离要够但别过度设计1. 商家账号不等于平台用户平台账号走 sys_user 多角色商家账号走 merchant_account通常是单角色店长 / 店员。店员权限我用「菜单权限码」控制前端入口例如- 店长*:*:*或绑定全部商家菜单- 店员订单列表、发货、退款、会员查看等子集有个容易忽略的点角色如果做成全局共享表商家改店员权限会污染所有店。更稳妥的做法是- 内置「店长 / 店员」作为全局模板只读- 商家可「复制为自定义角色」写入 merchant_id只影响本店这样既支持 B2B2C SaaS也方便单店买断场景自己管账号。2. 审核闸门商家注册后先完善资质平台审核通过才允许上架/改支付配置。服务端用统一的 assertMerchantApproved() 卡写操作避免「前端藏按钮、接口仍可写」。三、营销闭环优惠券 积分别做成两个孤岛1. 优惠券容易算错的两件事折扣率语义库里如果用「百分制应付比例」8 折应存 80不是 8。否则 12.9 会被算成约 1 元客诉会来得很快。商家后台录入时建议 UI 填「8 折」落库自动 ×10。门槛券的体验未达门槛时不要静默隐藏。确认订单接口最好返回- meetThreshold- unusableReason如「差¥xx可用」并在可用券里自动选最优。C 端首页放一条紧凑「领券」入口商品详情给提示条转化会明显好于「藏在个人中心深处」。2. 积分商城放在哪积分如果只做「账户数字」用户感知弱。更有效的是1确认收货累计积分2C 端底栏给「积分商城」Tab或二级入口3「我的」资产区同时展示余额 / 积分 / 优惠券张数这样营销资产在下单前、下单中、下单后都有露出。3. 后台也要看见「券抵」商家/平台订单列表金额下补一行「券抵」详情合计展示券名与抵扣额。否则客服对账只能翻支付流水效率极差。四、C 端UniApp几个实用细节- 进店URL / 本地缓存带 shopId购物车按店隔离禁止跨店合并结算除非你真要做平台聚合购物车。- 支付先打通余额/Mock再接微信预留统一支付入口避免页面里写死通道。- 图片OSS 可配签名 URL管理端上传组件统一封装减少每页复制粘贴。演示环境建议准备固定账号会员 / 店长 / 店员 / 平台管理员写进 README方便自测与对外演示。五、工程化让「能跑」变成「能交」源码要交付或私有化部署时最怕两件事密钥进仓库、打包靠人肉。1. 配置分层- application.yml只放占位与环境变量- application-local.yml本机真实库、JWT、OSSgitignore- 交付只给 application-local.yml.examplePrivate 仓库也不等于安全协作者误改 Public、历史提交残留密钥都很常见。AccessKey 一旦出现过直接轮换。2. 一键打包我用根目录 bat 调 PowerShell按版本输出到 release/- 平台版server jar 平台端 商家端 H5 官网静态页- 单商户版去掉平台端即可官网是纯静态index.html config.js打包时拷贝即可不必强行塞进 Vite 工程。release/ 体积大、常含环境相关产物建议同样 gitignore。六、单商户版要不要重做结论一般不需要新仓库。平台版本身已包含商家端 C 端。单商户版更像「减配交付」1不交付平台前端2SQL 预置 1 商户 1 店且已审核3C 端默认 shopId4商家端补齐本店账号 / 角色否则买家无法自己加店员库表继续保留 merchant_id / shop_id固定一家店就行。硬删多租户字段成本高、收益低。七、还可以继续打磨的方向- 后端补齐权限注解不要只靠前端 v-perm- 支付正式通道、对账与退款状态机细化- 平台聚合首页多店逛与单店首页的产品边界- 观测慢 SQL、订单状态流转埋点如果你也在做类似系统欢迎在评论区交流你更痛的是审核流、营销算价还是多端打包发布

相关新闻