简介：这是一份基于Java的创创猫多商户电商平台（B2B2C）消费端前端源码，面向电商开发者、Vue前端工程师及毕业设计。前端采用uni-app开发，可打包成小程序、APP与H5，后台为Java技术，便于学习完整业务链路。压缩包共342个文件，约2.85MB，以197个Vue页面组件为主，另有64个PNG图片、51个JavaScript逻辑文件，以及SCSS、JSON、wxs、nvue等配置，覆盖商品展示、购物车、订单等模块。目前已有439人学习下载。通过这份源码可学习多商户电商平台前端的组件划分与交互实现，理解B2B2C模式下消费、商户、平台三端的协作关系；其uni-app跨端结构也有助于掌握多端打包适配，为二次开发或课程设计提供完整参考。
1. 为什么“多商户”不是一张表加一个商户ID
一听到“基于Java的创创猫多商户电商平台设计源码”，很多Java开发的第一反应是：给商品表、订单表加个merchant_id，查询时带上去，不就是一个多商户商城了吗？真把一套代码跑起来后才发现，多商户电商平台设计源码里最花时间的不是CRUD，而是权限边界、数据隔离、订单拆分、结算对账这一连串和“归属”有关的设计。这类源码名义上是设计稿加代码，实际落地时是在同时服务平台运营、商户后台和C端会员三套角色。如果你正准备照着这类源码改造自己的项目，或者想用Java快速搭一个多商户商城，这篇能直接给你一条可复现的路径。
2. 先立设计：从“平台、商户、用户”三角色看多商户源码的骨架
拿到一套多商户电商平台设计源码，不要急着打开Controller。第一件事是看它的数据模型和账号体系，因为多商户平台所有的复杂度，都源于“一个平台下有很多商户，每个商户又有自己的后台操作员”。这一章把骨架讲清楚，后面交易链路才能接得住。
2.1 账号体系：别把商户ID直接挂在会员表上
多商户平台表面是一套电商系统，实际是三个子系统的叠加：平台运营后台管商户审核和商品审核，商户后台管自己的商品和订单，会员端管浏览和购买。很多新手在第一次设计时，图省事把merchant_id直接加到member表上，结果后面店铺收藏、会员等级、订单归属全部绕不开这个字段，权限越查越乱。正确做法是，把“商户”当作组织，把“商户用户”当作组织下的操作账号，会员表只维护会员自身信息，不直接挂商户ID。
一个最简的账号体系SQL长这样：
CREATE TABLE `merchant` ( `id` bigint NOT NULL COMMENT '商户ID', `merchant_name` varchar(64) NOT NULL COMMENT '商户名称', `status` tinyint NOT NULL DEFAULT 0 COMMENT '状态：0待审核 1正常 2冻结', `contact_mobile` varchar(20) DEFAULT NULL, `created_at` datetime NOT NULL, PRIMARY KEY (`id`) ) COMMENT='商户表'; CREATE TABLE `merchant_user` ( `id` bigint NOT NULL COMMENT '商户后台账号ID', `merchant_id` bigint NOT NULL COMMENT '所属商户ID', `login_name` varchar(32) NOT NULL COMMENT '登录账号', `password_hash` varchar(128) NOT NULL COMMENT '密码哈希', `role_code` varchar(32) NOT NULL COMMENT '角色编码，如SHOP_ADMIN/SHOP_OPERATOR', PRIMARY KEY (`id`), KEY `idx_merchant` (`merchant_id`) ) COMMENT='商户后台账号表'; CREATE TABLE `member` ( `id` bigint NOT NULL COMMENT '会员ID', `nickname` varchar(32) DEFAULT NULL, `mobile` varchar(20) DEFAULT NULL, `status` tinyint NOT NULL DEFAULT 1 COMMENT '1正常 0禁用', PRIMARY KEY (`id`) ) COMMENT='C端会员表';这里的核心参数说明：merchant_user通过merchant_id关联商户，而不是在member表上冗余商户ID。登录商户后台时，身份信息里同时携带merchant_user_id和merchant_id，后续所有商户维度的业务表都直接按merchant_id过滤。会员表只存储会员个人属性，他买了哪个商户的商品通过订单表体现，属于“业务关系”而不是“账号属性”。这样设计的好处是，会员可以同时购买多个商户的商品，而不会在账号表里留下混乱的多租户痕迹。如果以后要支持一个人管理多个商户，只要把merchant_user改成“账号-角色-商户”多对多映射即可，不需要动会员表。
2.2 租户隔离选型：共享库 + 逻辑隔离是这类源码的主流
多商户比单商户多出来的首要问题，是“数据怎么隔离”。在设计源码时，通常有三种方案：独立数据库、独立Schema、共享库加租户字段。独立数据库隔离性最强，但一台机器跑一套，成本高；独立Schema需要数据库层面支持，运维复杂。绝大多数Java单体多商户平台采用“共享库+merchant_id逻辑隔离”，因为部署简单，恢复方便，适合中小型平台。
下表把这三种方案放在一起看：
| 隔离方案 | 隔离级别 | 部署成本 | 适用场景 |
|---|---|---|---|
| 独立数据库 | 物理隔离 | 高 | 大客户、金融级 |
| 独立Schema | 中等隔离 | 中 | SaaS多租户 |
| 共享库+租户字段 | 逻辑隔离 | 低 | 中小型多商户平台 |
逻辑隔离最大的坑是：查询时漏掉商户条件。你在读设计源码时，重点看它是“手写where”还是“插件拦截”。手写where直观，但接口一多就漏；插件拦截统一，但需要精确配置忽略表。我一般推荐在MyBatis-Plus里配置租户插件，这是这套技术栈里最不容易翻车的方式：
@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new TenantLineInnerInterceptor(new TenantLineHandler() { @Override public Expression getTenantId() { // 从当前登录上下文取商户ID，平台运营后台不需要隔离时返回0 return new LongValue(MerchantContextHolder.getMerchantId()); } @Override public String getTenantIdColumn() { return "merchant_id"; } @Override public boolean ignoreTable(String tableName) { // 平台账号、区域字典、支付渠道等公共表不拦截 return Arrays.asList("platform_user", "area", "pay_channel").contains(tableName); } })); return interceptor; }这段配置会让所有带merchant_id字段的表，在执行select、update、delete时自动追加merchant_id条件，插入时自动补这个字段。注意两个参数：getTenantIdColumn指定租户字段名，默认就是merchant_id；ignoreTable里的公共表如果没有配置，会导致平台管理员连登录菜单都查询不到。配置完成后，业务代码里几乎不需要再手写“where merchant_id = ?”，但前提是表中必须存在该字段，否则会被插件拦截成SQL异常。
2.3 三张核心账本：商品、订单、结算的主表设计
多商户电商平台的业务最终落在三组表上：商品表组、订单表组、结算表组。先把这三组表的主键和关键字段理清，看源码时就能抓住主干，不会被一堆活动表、优惠券表带偏。
商品表组一般由spu和sku两张表组成：
| 表名 | 关键字段 | 说明 |
|---|---|---|
| spu | id, merchant_id, category_id, title, status | 标准商品单元，status区分草稿、待审核、上架 |
| sku | id, spu_id, merchant_id, spec, price, stock | 销售单元，price用分存储，避免浮点数误差 |
订单表组建议拆成订单主表、订单明细、支付流水：
| 表名 | 关键字段 | 说明 |
|---|---|---|
| order | id, order_no, group_no, member_id, merchant_id, total_amount, pay_amount, status | 每笔订单只属于一个商户，group_no关联同一笔订单组 |
| order_item | id, order_id, spu_id, sku_id, merchant_id, num, price | 冗余merchant_id是为了后续按商户统计，避免join |
| payment_record | id, payment_no, order_no, merchant_id, amount, status | 支付流水，幂等控制的唯一依据 |
结算表组是很多开发容易忽略的，但它才是多商户平台能不能持续跑下去的关键：
| 表名 | 关键字段 | 说明 |
|---|---|---|
| merchant_settlement | id, merchant_id, period, total_amount, commission_amount, pay_amount, status | 按周期聚合的结算单 |
| settlement_detail | id, settlement_id, order_no, amount, commission, status | 结算明细，对账用 |
在阅读设计源码时，先打开SQL目录，把这三组表的关系画出来。我的习惯是：如果settlement表和order表之间没有关联字段，说明作者还没把结算逻辑想清楚，这类代码要谨慎参考；如果order表有group_no字段，说明作者已经考虑了多商户拆单。先看这些细节，再去看Controller和Service会轻松很多。
2.4 为什么常见组合是Spring Boot + MyBatis-Plus + Redis + MySQL
设计源码的技术选型通常会选国内团队最熟的组合：Spring Boot + Spring MVC + MyBatis-Plus + Redis + MySQL。原因很简单：Maven依赖容易拉，社区资料多，遇到问题能搜到答案。对需要快速落地多商户平台的团队来说，选这套组合不属于炫技，而是用最低的学习成本覆盖最核心的业务需求。
代码分层也基本是固定的：controller层只做参数校验和结果包装，service层写事务逻辑，mapper层对数据库操作。比如商品服务，一般会有ProductController、ProductService、ProductServiceImpl、SpuMapper、SkuMapper。你在读源码时，应该先在service层找@Transactional注解，再看事务边界是否覆盖了同一业务里的全部写操作。一个常见的坏味道是Controller类上直接加@Transactional，这会把事务范围扩大到HTTP请求解析和响应序列化，拉长数据库连接占用时间，并发一高就会出现连接池耗尽。多商户平台的正确事务边界是：单个业务操作，比如“创建商品并生成SKU”是一个原子操作，放到一个service方法里；而“批量上架商品”不应该在一个事务里处理，否则一批里有一个失败，全部回滚，商户操作体验会非常差。
这一章的落点是：骨架先立住，账号模型、隔离方案、账本表设计、技术组合四件事统一了之后，后续交易链路里的所有代码才有讨论的意义。多商户平台不是功能堆得越多越好，而是边界分得清楚。边界清楚了，商户才不会看到别人的数据，平台才敢让商户自己经营店铺。
3. 把核心交易链路翻译成Java代码：租户隔离、SPU、订单拆分
骨架定好后，核心交易链路是源码里最值得反复看的部分。多商户平台和单商户系统的本质差异，就藏在这几条链路里：商品发布、下单、支付回调、订单查询。每一条链路都要把“商户身份”放在第一位，否则数据就会串。
3.1 商品发布链路：SPU/SKU怎么在同一事务里完成
商品发布是商户第一次接触系统的入口，也是多商户权限的第一个边界。设计源码里，商品发布通常要求商户信息合法、商户状态正常，新商品默认进入待审核状态。SPU是描述商品的抽象层，SKU是具体可销售的规格单元。举一个例子，“红色M码T恤”是一个SKU，“T恤”本身是SPU。多商户平台上，每个商户发布的是自己的SPU/SKU，SKU必须冗余merchant_id，这样库存扣减和销量统计不用关联SPU表。
典型的商品发布Service代码：
@Override @Transactional(rollbackFor = Exception.class) public Long createProduct(ProductCreateDTO dto) { Long merchantId = dto.getMerchantId(); // 参数说明：merchantId由商户后台登录态获取，不能由前端传入 Merchant merchant = merchantMapper.selectById(merchantId); if (merchant == null || merchant.getStatus() != 1) { throw new BizException("merchant.not.available"); } Spu spu = new Spu(); spu.setMerchantId(merchantId); spu.setCategoryId(dto.getCategoryId()); spu.setTitle(dto.getTitle()); spu.setStatus(SpuStatus.PENDING_AUDIT); spuMapper.insert(spu); for (SkuDTO skuDTO : dto.getSkus()) { Sku sku = new Sku(); sku.setSpuId(spu.getId()); sku.setMerchantId(merchantId); sku.setSpec(skuDTO.getSpec()); sku.setPrice(skuDTO.getPrice()); sku.setStock(skuDTO.getStock()); skuMapper.insert(sku); } return spu.getId(); }逻辑说明：@Transactional保证SPU和SKU要么全部插入成功，要么全部回滚，如果出现一条SKU价格非法，整个商品都不会落库，避免商品主数据残缺。参数说明里最关键的是merchantId的来源——它必须来自商户后台的登录态或token，而不是前端json里传一个值，否则商户可以伪造身份创建别人的商品。状态字段使用枚举常量SpuStatus.PENDING_AUDIT，而不是直接写数字，这样代码里不会到处是魔法值。
3.2 下单链路：按商户拆单与幂等控制
当会员购物车里有商户A和商户B的商品时，一个“订单组”会被拆成多个“子订单”，每个商户一个订单，每个订单独立算价、独立结算。这是多商户平台在订单设计上和单商户系统最大的区别。如果不拆单，平台就没法人按商户清分结算，也没法让各商户分别发货。
下单链路还要解决幂等问题。会员点击“提交订单”的一瞬间可能会连续触发两次请求，如果没有幂等，库存会被扣两次。常见做法是前端生成一个唯一token，后端用Redis做互斥：
@Transactional(rollbackFor = Exception.class) public String createOrder(OrderCreateDTO dto) { // 幂等参数说明：token由前端生成，一次提交一个 boolean firstSubmit = redisTemplate.opsForValue() .setIfAbsent("order:token:" + dto.getToken(), "1", Duration.ofMinutes(30)); if (!firstSubmit) { throw new BizException("duplicate.submit"); } // 按商户分组，每个商户生成一张订单 Map<Long, List<CartItemDTO>> merchantGroup = dto.getItems().stream() .collect(Collectors.groupingBy(CartItemDTO::getMerchantId)); String groupNo = generateOrderNo("G"); for (Map.Entry<Long, List<CartItemDTO>> entry : merchantGroup.entrySet()) { Long merchantId = entry.getKey(); List<CartItemDTO> items = entry.getValue(); Order order = new Order(); order.setOrderNo(generateOrderNo("O")); order.setGroupNo(groupNo); order.setMerchantId(merchantId); order.setMemberId(dto.getMemberId()); order.setTotalAmount(items.stream() .mapToLong(item -> item.getPrice() * item.getNum()) .sum()); order.setStatus(OrderStatus.PENDING_PAY); orderMapper.insert(order); } // 扣减库存，减库存SQL在Mapper中完成 for (CartItemDTO item : dto.getItems()) { int rows = skuMapper.deductStock(item.getSkuId(), item.getNum(), item.getMerchantId()); if (rows != 1) { throw new BizException("stock.not.enough"); } } return groupNo; }逻辑说明：Redis的setIfAbsent是原子操作，同一token在30分钟内只会有一个请求成功，这是第一层幂等。订单表里的group_no把多张子订单关联成一组，会员下单后看到的是一笔付款单，商户后台看到的则是属于自己的子订单。库存扣减方法deductStock接收skuId、数量、merchantId三个参数，在SQL里做条件更新，而不是先查再改。参数说明里要注意金额计算用long类型存分，避免double的精度问题；generateOrderNo要保证全局唯一，最简单的方式是“日期 + redis自增 + 随机后缀”，不要用UUID当订单号，因为对账和客服系统里可读性太差。
3.3 支付回调链路：先幂等后记账
支付回调是多商户平台最容易出事故的地方。支付平台通知你的服务器“这笔订单已支付成功”，但这个通知可能因为网络原因重发多次。如果不做幂等处理，订单状态会被重复流转，结算流水也会多记。设计源码里一般会有一张payment_record表作为唯一键约束的依据。
支付回调处理的核心逻辑可以这样拆：
@Transactional(rollbackFor = Exception.class) public void handlePayCallback(PayCallbackDTO callback) { // 参数说明：paymentNo是支付平台流水号，orderNo是本系统订单号 PaymentRecord record = paymentRecordMapper.selectOne(new LambdaQueryWrapper<PaymentRecord>() .eq(PaymentRecord::getPaymentNo, callback.getPaymentNo())); if (record != null) { // 已处理过，直接返回，避免重复记账 return; } paymentRecordMapper.insert(PaymentRecord.builder() .paymentNo(callback.getPaymentNo()) .orderNo(callback.getOrderNo()) .merchantId(callback.getMerchantId()) .amount(callback.getAmount()) .status(PaymentStatus.SUCCESS) .build()); // 订单从待支付变为已支付 int updated = orderMapper.updateStatusByOrderNo(callback.getOrderNo(), OrderStatus.PENDING_PAY, OrderStatus.PAID); if (updated != 1) { throw new BizException("order.state.changed"); } // 触发商户结算记账，由单独结算服务处理 settlementService.recordPaySuccess(callback.getOrderNo()); }逻辑说明：先查payment_record表，同样的paymentNo如果已经存在就说明回调重复，直接忽略。这是订单状态之外的第三道幂等屏障。然后用条件更新“只有当前状态是PENDING_PAY时才更新为PAID”，如果订单已经被取消或关闭，updated为0，程序就会抛异常，不会继续往下走结算。参数说明：回调数据里必须有paymentNo和orderNo，并且orderNo可以找到对应的merchant_id；回调接口对外暴露时还需要验签，这里不做展示，但真实项目里绝不能省掉。
3.4 查询链路：会员订单和商户订单必须分两套查询
多商户平台里，同一个订单数据，会员端和商户端看到的是不同视角。会员端通过member_id查询，“我买过什么”；商户端通过merchant_id查询，“这个店铺卖出过什么”。它们的查询条件、字段展示、状态维度完全不同，设计源码时千万不要用一个通用接口同时处理两个视角。
商户后台的分页查询示例：
public PageResult<OrderVO> pageMerchantOrders(OrderPageQuery query) { Long merchantId = MerchantContextHolder.getMerchantId(); // 强制从上下文取merchantId，不允许前端传参覆盖 Page<Order> page = Page.of(query.getPageNum(), query.getPageSize()); LambdaQueryWrapper<Order> wrapper = new LambdaQueryWrapper<Order>() .eq(Order::getMerchantId, merchantId) .eq(StringUtils.hasText(query.getOrderNo()), Order::getOrderNo, query.getOrderNo()) .eq(query.getStatus() != null, Order::getStatus, query.getStatus()) .orderByDesc(Order::getCreatedAt); Page<Order> result = orderMapper.selectPage(page, wrapper); // 再关联查询会员昵称等信息，避免在订单表里存冗余昵称 return convertToVO(result); }这段代码看起来简单，但正是这些简单的条件拼接，决定了商户能否只能看到自己的订单。如果merchantId是通过前端表单传进来的，那商户把参数改成别人的merchantId，就能把别家的订单拉出来。所以设计源码里，MerchantContextHolder.getMerchantId()必须是从登录态解析出来的，和HTTP请求上下文绑定。会员端订单查询同理，用member_id过滤，不允许传商户ID。把这两个查询拆开，既是为了安全，也是为了各自的索引设计能够独立优化。
4. 从源码可读性到可扩展性：模块拆分与状态机
交易链路跑通之后，源码能不能长久维护，取决于状态管理和模块边界。这一章专门讲订单状态机、结算处理和异步上下架三个扩展点。多商户平台里，这些模块一旦混乱，后续加一个优惠券功能都可能动到核心代码。
4.1 订单状态机：状态字段别散落在if/else里
订单状态是多商户平台里最容易被写乱的地方。很多源码喜欢在Service里用一串if判断“如果状态是A，就改为B；如果状态是C，就允许退货”，结果各个接口判断逻辑不一致。订单状态机要做的是把合法流转集中定义，让代码只按照状态机规则走。
一个典型的Java枚举写法：
public enum OrderStatus { PENDING_PAY(10, "待支付"), PAID(20, "已支付"), DELIVERED(30, "已发货"), COMPLETED(40, "已完成"), CLOSED(50, "已关闭"), REFUNDING(60, "退款中"); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code = code; this.desc = desc; } public static boolean canChange(OrderStatus from, OrderStatus to) { switch (from) { case PENDING_PAY: return to == PAID || to == CLOSED; case PAID: return to == DELIVERED || to == REFUNDING; case DELIVERED: return to == COMPLETED || to == REFUNDING; case COMPLETED: return to == REFUNDING; case REFUNDING: return to == COMPLETED || to == CLOSED; default: return false; } } }使用这个枚举后，状态流转的逻辑收敛到一个方法里。任何接口想做状态变更，先判断canChange，不允许流转就直接抛异常。实际用的时候，还有一张order_status_log表记录每一次状态变更的operator和reason，这样售后纠纷时能看到操作痕迹。参数说明里尤其要注意：退款中到已完成的路径属于退款成功或部分退款成功，不是所有状态都能直接到CLOSED。
4.2 商户结算：按账期生成结算单，佣金自动计算
多商户平台如果没有结算模块，订单收了钱却分不清楚钱该给谁。设计源码里，结算通常是T+1或T+7：当天订单成功后，第二天进入待结算池，按商户和账期聚合成结算单，同时按平台设定的佣金比例扣掉平台分成。
一个按账期生成结算单的Service方法可以这样写：
@Transactional(rollbackFor = Exception.class) public void generateSettlement(String settlementPeriod) { // 参数说明：settlementPeriod格式为yyyy-MM-dd，例如2025-06-01 List<Order> paidOrders = orderMapper.selectList(new LambdaQueryWrapper<Order>() .eq(Order::getStatus, OrderStatus.COMPLETED) .isNull(Order::getSettlementNo) .likeRight(Order::getUpdatedAt, settlementPeriod)); // 按商户聚合 Map<Long, List<Order>> merchantOrders = paidOrders.stream() .collect(Collectors.groupingBy(Order::getMerchantId)); for (Map.Entry<Long, List<Order>> entry : merchantOrders.entrySet()) { MerchantSettlement settlement = new MerchantSettlement(); settlement.setMerchantId(entry.getKey()); settlement.setPeriod(settlementPeriod); settlement.setStatus(SettlementStatus.PENDING); long totalAmount = 0L; long commissionAmount = 0L; for (Order order : entry.getValue()) { Long merchantId = order.getMerchantId(); // 从商户配置取佣金比例，比如0.15代表15% int commissionRate = merchantConfigMapper.selectByMerchantId(merchantId).getCommissionRate(); long commission = order.getPayAmount() * commissionRate / 100; totalAmount += order.getPayAmount(); commissionAmount += commission; SettlementDetail detail = new SettlementDetail(); detail.setSettlementNo(settlement.getSettlementNo()); detail.setOrderNo(order.getOrderNo()); detail.setAmount(order.getPayAmount()); detail.setCommission(commission); settlementDetailMapper.insert(detail); } settlement.setTotalAmount(totalAmount); settlement.setCommissionAmount(commissionAmount); settlement.setPayAmount(totalAmount - commissionAmount); merchantSettlementMapper.insert(settlement); } }结算模块最怕重复生成。这里的条件isNull(Order::getSettlementNo)保证同一笔订单只会归属到一个结算单，同时在settlement_detail表对order_no建唯一索引，双保险。参数说明中，佣金比例存的是整数百分比，不是小数，这样在Java乘法里不会出现浮点误差。如果你的源码里没有settlement_no这个字段，说明结算模块还没闭环，这是需要补的第一优先级字段。
4.3 商品上下架消息：审核通过后同步缓存和索引
商品审核通过后，不只是改一个数据库状态，还要把商品信息同步到会员端查询的缓存或搜索引擎。这里如果同步失败，会员端就会看到商品缺失或下架不生效。设计源码里会用一个事件发布机制，把“审核通过”和“会员端可见”解耦。
使用Spring自带的ApplicationEvent就足够：
@Service public class ProductAuditService { @Autowired private ApplicationEventPublisher eventPublisher; @Transactional public void passAudit(Long spuId, Long merchantId) { int updated = spuMapper.updateStatus(spuId, merchantId, SpuStatus.PENDING_AUDIT, SpuStatus.ON_SALE); if (updated != 1) { throw new BizException("spu.status.not.pending"); } // 发布事件，同步Redis商品详情和搜索索引 eventPublisher.publishEvent(new ProductOnShelfEvent(spuId, merchantId)); } }事件监听器可以放在单独类里，负责写Redis和同步搜索引擎。为什么用事件而不是直接在事务里同步缓存？因为缓存写入失败不该让数据库事务回滚，商品已经审核通过是事实，缓存可以稍后重建。参数说明中updateStatus方法带了merchantId条件，是为了防止平台运营人员审核时把别的商户的同ID商品误改状态。这种写法的代价是缓存会存在短暂不一致，所以还要加一个定时任务，每隔几分钟把最近变更的商品重新刷一遍缓存。这个设计取舍，在很多源码里不一定写全，但你在落地时一定要补上。
5. 多商户电商平台设计源码避坑：从部署到上线的5个真实问题
这一章来自血泪经验。代码按设计跑通不难，难的是上线后在高并发、多商户真实数据下，各种边界问题才开始露头。下面5个坑，是我认为多商户平台里最值得提前堵住的。
5.1 商户ID没加索引，商户后台列表越查越慢
现象：商户后台打开“商品列表”“订单列表”时，响应时间从1秒慢慢变成3秒、5秒甚至超时。查看MySQL慢查询日志，发现大量语句都在扫描全表，过滤条件里明明有merchant_id和status，执行计划却显示possible_keys为NULL。
原因：建表时只给主键加了索引，后面为了实现租户隔离，所有查询都带merchant_id，这个字段却没有索引，数据量超过几十万后全表扫描代价极高。
解决：第一时间给每个核心业务表加上组合索引，索引顺序按“等值字段在前，范围字段在后”的原则：
ALTER TABLE `order` ADD INDEX idx_merchant_status_created (merchant_id, status, created_at); ALTER TABLE `spu` ADD INDEX idx_merchant_status (merchant_id, status); ALTER TABLE `sku` ADD INDEX idx_merchant_spu (merchant_id, spu_id);加完索引后，用EXPLAIN验证执行计划。注意新增索引不要盲目加，order表订单查询会有很多维度，加三个以内的组合索引即可。如果查询条件里还有order_no，也给order_no单独建唯一索引。这个坑的根源不是代码问题，而是对多商户数据量增长估计不足，上线前就应把索引设计在SQL迁移脚本里。
5.2 支付回调没有幂等，订单重复结算
现象：运营在对账时发现同一笔订单在结算明细里出现两次，或者在订单表里看到状态从待支付变成已支付后，又被回调改了一次，产生重复发货记录。
原因：支付平台为了确保通知必达，会多次发送回调。第一次回调成功后，应用正好重启或Redis缓存失效，第二次回调进来时，程序没检查支付流水，直接又做了一次订单状态更新和结算入账。
解决：在设计上用好三个幂等点。一是payment_record表给payment_no加唯一索引，重复回调时MySQL直接报错或让应用根据DuplicateKey捕获；二是在更新订单状态时使用条件更新，比如update order set status='PAID' where order_no=? and status='PENDING_PAY'；三是回调处理业务里先查后插：
public void handlePayCallback(PayCallbackDTO dto) { try { paymentRecordMapper.insert(PaymentRecord.from(dto)); } catch (DuplicateKeyException e) { // 已处理过，忽略本次回调 return; } // 后续更新订单与结算 }这一段代码把幂等从“应用层判断”下沉到了“数据库唯一约束”，比先查询再判断更可靠。如果命令行建表时没有唯一索引，现在数据库里还存在重复数据，需要先清理再补索引，否则索引建不上去。
5.3 库存扣减用“先查再改”，高并发下超卖
现象：秒杀场景或爆款商品促销时，明明页面显示库存还有10件，商户后台却看到卖出去了12件，和真实库存对不上。
原因：代码里先select stock from sku where id=?，在Java里判断stock >= num，再执行update sku set stock=? where id=?。两个并发请求同时读到同一库存，各自判断库存足够，分别扣减，导致超卖。
解决：把库存扣减做成一条原子SQL，把判断条件放进where：
@Update("UPDATE sku SET stock = stock - #{num} " + "WHERE id = #{skuId} AND merchant_id = #{merchantId} AND stock >= #{num}") int deductStock(@Param("skuId") Long skuId, @Param("merchantId") Long merchantId, @Param("num") Integer num);这个Mapper方法返回受影响行数，如果返回0，说明库存不足或商户不匹配，业务层再抛异常。注意，这里不能把merchant_id排除掉，否则可能扣了别人的货。参数说明中，stock字段不能设置为unsigned小于0，否则MySQL在strict mode下会直接报错，影响性能诊断。库存扣减和订单插入放在同一个事务里，事务提交后才会释放行锁，并发量太高时也可以走Redis预扣再异步同步，但那属于更复杂的方案，普通多商户平台用这条SQL就够。
5.4 图片上传到本地磁盘，多实例部署后图片丢失
现象：本地开发时商户上传商品图片一切正常，打包部署到测试环境后，图片偶尔能显示，偶尔404。重启服务后，之前上传的商品图全部打不开。
原因：开发期把图片写到了本地磁盘的某个目录，比如./upload，但部署环境是两台实例，每次请求可能被负载均衡分发到不同机器；加上服务重启时临时目录被清空，图片自然找不回。
解决：多商户平台的文件存储必须独立于应用进程。最普遍的做法是接入对象存储服务，代码里只保存相对路径或URL：
public String uploadImage(MultipartFile file, Long merchantId) { String ext = StringUtils.getFilenameExtension(file.getOriginalFilename()); String objectKey = "merchant/" + merchantId + "/" + System.currentTimeMillis() + "_" + UUID.randomUUID() + "." + ext; // 这里使用存储客户端的putObject，bucket固定或按业务分 storageClient.putObject(bucketName, objectKey, file.getInputStream()); return storageClient.buildUrl(objectKey); }这个方案的关键参数是objectKey，它必须按商户ID分目录，否则很难管理谁传了什么；文件名里加时间戳和随机串，是为了防重名。如果你的项目暂时没有对象存储，也要至少保证文件落在固定的、不走临时目录的独立磁盘路径，并且部署时把该路径挂在共享存储上。还有一点容易漏：上传接口要做文件类型白名单校验，不能只依赖前端后缀判断，否则恶意商户会传可执行文件。
5.5 定时关单任务误伤刚支付的订单
现象：用户在下单后立即支付，支付网关已经回调成功，但定时关单任务先一步执行，把订单状态改成“已关闭”，随后支付回调回来反而更新失败，用户付了钱却看不到订单。
原因：关单任务执行时，只判断“订单状态是待支付”以及“订单创建时间距今超过N分钟”，没有考虑支付回调可能正在路上。两个操作并发，关单任务抢先了。
解决：把“关单”也设计成条件更新，并且把时间阈值放在SQL的条件里，而不是先把数据查出来再判断：
@Update("UPDATE `order` SET status = 'CLOSED', close_time = NOW() " + "WHERE status = 'PENDING_PAY' AND created_at <= #{deadline} AND merchant_id = #{merchantId}") int closeExpiredOrders(@Param("deadline") Date deadline, @Param("merchantId") Long merchantId); ### 关于技术细节补充作者这里把SQL写到了一半，就是为了说明一个关键点：状态更新必须带原始状态条件，这样即使支付回调与关单任务并发，也只有一个能成功。支付回调更新时条件status='PENDING_PAY'，关单更新时条件也是status='PENDING_PAY'，数据库的行锁会保证这两个更新串行执行，后执行的那一个看到状态已经变化，更新行数为0，从而做出不同反应。定时关单任务不感知商户ID也行，但加上merchantId条件可以在多商户平台里按商户粒度控制关单策略。这5个坑解决后，多商户平台才敢从“能跑demo”走向“能上线运营”。
6. 进阶验证：给多商户平台加一个对账任务，用它对冲“数据扑朔迷离”
最后一个技巧，也是运维阶段最能救命的一件事：给平台写一个每日对账任务。很多设计源码只把订单、支付、结算做出来就结束了，但对账任务往往缺失。我的习惯是，新接一套多商户源码后，先写这个任务每天核对三组数字：支付平台流水是否和本地payment_record一致，本地订单金额汇总是否和支付流水一致，结算单金额是否和订单明细一致。
对账任务最核心的代码不是复杂算法，而是简单的分组聚合加状态标记：
@Component public class SettlementReconcileTask { @Scheduled(cron = "0 30 1 * * ?") public void reconcile() { String yestoday = LocalDate.now().minusDays(1).toString(); List<Map<String, Object>> orderAmounts = orderMapper.sumAmountByMerchant(yestoday); List<Map<String, Object>> payAmounts = paymentRecordMapper.sumAmountByMerchant(yestoday); Map<Long, Long> payMap = payAmounts.stream() .collect(Collectors.toMap(m -> (Long) m.get("merchantId"), m -> (Long) m.get("totalAmount"))); for (Map<String, Object> orderAmount : orderAmounts) { Long merchantId = (Long) orderAmount.get("merchantId"); Long orderTotal = (Long) orderAmount.get("totalAmount"); Long payTotal = payMap.getOrDefault(merchantId, 0L); if (!orderTotal.equals(payTotal)) { // 不一致时写入对账结果表，并触发告警通知 reconcileRecordMapper.insert(ReconcileRecord.builder() .merchantId(merchantId) .orderAmount(orderTotal) .payAmount(payTotal) .period(yestoday) .status("MISMATCH") .build()); } } } }这个任务的价值不在于能发现所有资金问题，而在于每天强制暴露一次数据不一致。多商户平台一旦商户数量多了，任何一笔手工改库、脚本修正都可能造成商户对账不平。对账任务的输出结果应该直接推给运营人员，而不是写进日志里等人翻看。我早期吃过这个亏，总觉得自己写的代码不会出账目问题，结果某天一个定时任务参数配错，连续三天结算金额少算了，商户来找才发现。从那以后，每个平台都先补对账任务，再补别的功能。多商户的复杂不在某一处代码，而在整体数据闭环；对账就是那个把一切拉回正轨的兜底手段。希望帮到你。
本文还有配套的精品资源，点击获取
