一、先说痛点：多平台对接到底有多恶心

做过电商ERP的同学应该都有体会——你接的不是几个平台，而是一堆"方言"。

淘宝的订单接口叫 taobao.trades.sold.get，京东的叫 jingdong.vc.item.search，拼多多的叫 pdd.order.list.get……光是接口命名风格就各玩各的。更要命的是：

• 数据格式不统一：同一个"订单状态"字段，淘宝用数字枚举（WAIT_BUYER_PAY / WAIT_SELLER_SEND_GOODS），京东用另一套数字，抖音直接给你返回中文。你得给每个平台写一套状态映射。
• 认证机制五花八门：淘宝用OAuth 2.0 + SessionKey，京东用AccessToken + AppKey/AppSecret，有些小平台甚至还在用MD5签名。
• 同步频率和限流策略不同：淘宝允许你每分钟调1000次，有些平台只给100次，还有的平台压根不推送，只能你自己轮询。
• 接口版本迭代不同步：淘宝升级了v2接口，京东还在用v1，拼多多突然改了字段名……你永远在追着各平台跑。

二、统一API网关：把多种"方言"翻译成一种"普通话"

2.1 核心思路：平台无关的抽象层

网关的核心职责就一句话：对外提供统一的内部接口，对内屏蔽各平台的差异。

典型的三层架构设计：

┌─────────────────────────────────────────────┐
│           业务层（ERP/WMS/财务系统）            │
│         调用统一内部接口，不感知平台差异          │
─────────────────────────────────────────────┤
│              统一API网关层                      │
│   ┌──────────┬──────────┬────────────────┐   │
│   │ 路由引擎  │ 适配器注册 │  限流/熔断/重试  │   │
│   └──────────┴──────────┴────────────────┘   │
├─────────────────────────────────────────────┤
│             平台适配层（Adapter）               │
│  ┌────┐ ┌──── ┌────┐ ┌────┐  ┌────────┐   │
│  │淘宝│ │京东│ │拼多多│ │抖音│  │ 更多... │   │
│  └────┘ └────┘ └──── └────┘  └────────┘   │
└─────────────────────────────────────────────┘

2.2 适配器模式：每个平台一个Adapter

关键设计是适配器模式（Adapter Pattern）。定义一个标准接口，每个平台实现自己的适配逻辑：

// 统一的平台适配器接口
public interface PlatformAdapter {
    
    // 平台标识
    String getPlatformCode();
    
    // 拉取订单（统一入参和出参）
    PageResult<UnifiedOrder> fetchOrders(OrderQueryRequest request);
    
    // 推送库存
    SyncResult pushInventory(String skuCode, int quantity, List<String> warehouseIds);
    
    // 推送物流信息
    SyncResult pushLogistics(LogisticsInfo info);
    
    // 认证管理
    AuthToken refreshToken(AuthToken expiredToken);
    
    // 签名校验
    boolean verifySign(Map<String, String> params, String sign);
}

// 以淘宝适配器为例
@Component
public class TaobaoAdapter implements PlatformAdapter {
    
    @Override
    public String getPlatformCode() {
        return "TAOBAO";
    }
    
    @Override
    public PageResult<UnifiedOrder> fetchOrders(OrderQueryRequest request) {
        // 1. 构建淘宝特有的请求参数
        TaobaoTradeRequest tbRequest = new TaobaoTradeRequest();
        tbRequest.setMethod("taobao.trades.sold.get");
        tbRequest.setStartCreated(request.getStartTime());
        tbRequest.setEndCreated(request.getEndTime());
        tbRequest.setFields("tid,status,payment,created,...");
        
        // 2. 调用淘宝API
        TaobaoTradeResponse tbResponse = taobaoClient.execute(tbRequest);
        
        // 3. 把淘宝的订单模型转换成统一模型
        return tbResponse.getTrades().stream()
            .map(this::convertToUnifiedOrder)
            .collect(Collectors.toList());
    }
    
    private UnifiedOrder convertToUnifiedOrder(TaobaoTrade trade) {
        UnifiedOrder order = new UnifiedOrder();
        order.setPlatformOrderId(String.valueOf(trade.getTid()));
        order.setPlatformCode("TAOBAO");
        // 关键：状态映射
        order.setStatus(mapTaobaoStatus(trade.getStatus()));
        order.setPayment(new BigDecimal(trade.getPayment()));
        // ... 其他字段映射
        return order;
    }
    
    private OrderStatus mapTaobaoStatus(String tbStatus) {
        switch (tbStatus) {
            case "WAIT_BUYER_PAY": return OrderStatus.PENDING_PAYMENT;
            case "WAIT_SELLER_SEND_GOODS": return OrderStatus.PAID;
            case "WAIT_BUYER_CONFIRM_GOODS": return OrderStatus.SHIPPED;
            case "TRADE_FINISHED": return OrderStatus.COMPLETED;
            case "TRADE_CLOSED": return OrderStatus.CLOSED;
            default: return OrderStatus.UNKNOWN;
        }
    }
}

2.3 适配器注册中心：热插拔

数百个适配器不可能硬编码，需要做一个注册中心，支持运行时动态加载：

@Component
public class AdapterRegistry {
    
    // 平台编码 -> 适配器实例
    private final ConcurrentHashMap<String, PlatformAdapter> adapterMap 
        = new ConcurrentHashMap<>();
    
    // 启动时扫描所有适配器，自动注册
    @PostConstruct
    public void init() {
        Map<String, PlatformAdapter> beans = applicationContext
            .getBeansOfType(PlatformAdapter.class);
        beans.values().forEach(adapter -> 
            adapterMap.put(adapter.getPlatformCode(), adapter));
        log.info("已注册 {} 个平台适配器", adapterMap.size());
    }
    
    // 根据平台编码获取适配器
    public PlatformAdapter getAdapter(String platformCode) {
        PlatformAdapter adapter = adapterMap.get(platformCode);
        if (adapter == null) {
            throw new PlatformNotSupportException(
                "不支持的平台: " + platformCode);
        }
        return adapter;
    }
    
    // 支持运行时动态注册新平台（比如接到一个新平台对接需求）
    public void register(String platformCode, PlatformAdapter adapter) {
        adapterMap.put(platformCode, adapter);
    }
}

这样业务层调用就非常简单了：

// 业务层完全不需要关心具体是哪个平台
public class OrderSyncService {
    
    @Autowired
    private AdapterRegistry adapterRegistry;
    
    public void syncOrders(String platformCode, OrderQueryRequest request) {
        PlatformAdapter adapter = adapterRegistry.getAdapter(platformCode);
        PageResult<UnifiedOrder> orders = adapter.fetchOrders(request);
        // 统一处理逻辑...
        orderRepository.batchSave(orders.getData());
    }
}

三、订单同步：轮询、推送、还是混合？

订单同步是整个系统的心脏。不同平台的同步机制差异巨大，通常采用混合模式。

3.1 三种模式对比

模式	适用场景	优点	缺点
定时轮询	不支持消息推送的小平台	实现简单，可控性强	有延迟，浪费请求配额
消息推送（Webhook）	淘宝、京东等大平台	实时性好，不浪费配额	依赖平台稳定性，丢消息风险
混合模式	推送为主 + 轮询兜底	兼顾实时性和可靠性	实现复杂度高

3.2 混合模式的实现

大平台（淘宝、京东、抖音、拼多多等）走消息推送，但推送不可靠——消息可能丢、可能延迟。所以需要加一层轮询兜底：

消息推送通道（实时）
    │
    ▼
──────────┐    写入     ┌──────────┐
│ 消息队列  │ ────────▶ │ 订单表    │
│(RocketMQ) │            └──────────┘
└──────────┘                  ▲
                              │ 兜底补偿
┌──────────┐    定时拉取      │
│ 轮询调度  │ ────────────────┘
│ (XXL-Job) │
└──────────┘

伪代码描述：

// 1. Webhook接收推送消息（实时通道）
@PostMapping("/webhook/{platformCode}")
public String handleWebhook(@PathVariable String platformCode,
                            @RequestBody String payload) {
    // 验签
    PlatformAdapter adapter = adapterRegistry.getAdapter(platformCode);
    if (!adapter.verifySign(payload)) {
        return "FAIL";
    }
    // 解析并投递到消息队列
    UnifiedOrder order = adapter.parseWebhookPayload(payload);
    orderMessageProducer.send(order);
    return "SUCCESS";
}

// 2. 消息消费者（处理推送来的订单）
@RocketMQMessageListener(topic = "ORDER_SYNC", 
                          consumerGroup = "order-sync-group")
public class OrderSyncConsumer implements RocketMQListener<UnifiedOrder> {
    
    @Override
    public void onMessage(UnifiedOrder order) {
        // 幂等校验：用平台+订单号做唯一键
        if (orderRepository.exists(order.getPlatformCode(), 
                                    order.getPlatformOrderId())) {
            return; // 已存在，跳过
        }
        orderRepository.save(order);
        // 触发后续流程：库存扣减、物流分配等
        eventBus.publish(new OrderCreatedEvent(order));
    }
}

// 3. 轮询补偿任务（兜底通道，每5分钟跑一次）
@XxlJob("orderSyncCompensate")
public void compensate() {
    // 找出最近10分钟内可能遗漏的订单
    // 时间窗口往前多拉5分钟，靠幂等去重
    Date endTime = new Date();
    Date startTime = DateUtils.addMinutes(endTime, -15);
    
    for (String platformCode : getAllPlatformCodes()) {
        try {
            PlatformAdapter adapter = adapterRegistry.getAdapter(platformCode);
            OrderQueryRequest request = new OrderQueryRequest(startTime, endTime);
            
            PageResult<UnifiedOrder> orders = adapter.fetchOrders(request);
            for (UnifiedOrder order : orders.getData()) {
                // 幂等写入，已存在的自动跳过
                orderRepository.saveIfNotExists(order);
            }
        } catch (Exception e) {
            log.error("平台 {} 补偿同步失败", platformCode, e);
            // 不中断，继续下一个平台
        }
    }
}

关键设计点：

• 幂等：不管推送还是轮询，写入前都检查是否已存在，用platform_code + platform_order_id做唯一索引。
• 时间窗口重叠：轮询的时间范围比间隔大（15分钟窗口 vs 5分钟间隔），确保不会漏单。
• 平台隔离：一个平台拉取失败不影响其他平台，各自独立try-catch。

四、库存同步：最容易被超卖教做人的环节

库存同步是公认最难的。难点在于：你在多个平台卖同一个SKU，任何一个平台下单都要同步扣减其他平台的库存，但网络有延迟，并发会冲突。

4.1 超卖是怎么发生的

举个真实场景：

商品A（SKU001）总库存100件，分布在3个平台：
- 淘宝：40件
- 京东：30件
- 抖音：30件

同一秒内：
- 淘宝来了一个订单买5件 → 淘宝库存变成35
- 京东来了一个订单买3件 → 京东库存变成27
- 这时候抖音也来了一个订单买30件 → 抖音库存变成0

问题：实际总库存应该是 100 - 5 - 3 = 92，但三个平台显示的
可用库存是 35 + 27 + 0 = 62。差了30件！

原因：淘宝和京东的扣减还没同步到抖音，抖音就按旧的库存卖了。

4.2 解决方案：中心化库存 + 异步分

                    ──────────────┐
                    │  中心库存服务  │
                    │  (Redis + DB) │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │ 淘宝渠道  │ │ 京东渠道  │ │ 抖音渠道  │
        │ 库存:40  │ │ 库存:30  │ │ 库存:30  │
        ──────────┘ └──────────┘ ──────────┘

核心逻辑：

@Service
public class InventoryService {
    
    @Autowired
    private RedisTemplate<String, Integer> redis;
    
    /**
     * 扣减库存（带分布式锁）
     */
    public DeductResult deductInventory(String skuCode, int quantity, 
                                         String platformCode) {
        String lockKey = "inventory:lock:" + skuCode;
        String requestId = UUID.randomUUID().toString();
        
        try {
            // 1. 加分布式锁（Redis SETNX + 过期时间）
            boolean locked = redis.opsForValue()
                .setIfAbsent(lockKey, requestId, 5, TimeUnit.SECONDS);
            if (!locked) {
                // 获取锁失败，说明有并发操作，稍后重试
                throw new InventoryLockException("库存操作冲突，请重试");
            }
            
            // 2. 查询中心库存
            int totalStock = getCenterStock(skuCode);
            if (totalStock < quantity) {
                return DeductResult.fail("库存不足");
            }
            
            // 3. 扣减中心库存（Lua脚本保证原子性）
            String luaScript = 
                "local stock = tonumber(redis.call('GET', KEYS[1])) " +
                "if stock >= tonumber(ARGV[1]) then " +
                "    return redis.call('DECRBY', KEYS[1], ARGV[1]) " +
                "else " +
                "    return -1 " +
                "end";
            
            int remainStock = redis.execute(
                new DefaultRedisScript<>(luaScript, Long.class),
                List.of("inventory:" + skuCode),
                String.valueOf(quantity));
            
            if (remainStock < 0) {
                return DeductResult.fail("库存不足");
            }
            
            // 4. 异步同步到各平台渠道库存
            syncToChannels(skuCode, remainStock, platformCode);
            
            return DeductResult.success(remainStock);
            
        } finally {
            // 5. 释放锁（Lua脚本，只释放自己的锁）
            releaseLock(lockKey, requestId);
        }
    }
    
    /**
     * 异步同步渠道库存
     */
    private void syncToChannels(String skuCode, int totalStock, 
                                 String sourcePlatform) {
        // 计算各渠道应该分配的库存
        Map<String, Integer> channelAllocation = 
            allocationStrategy.allocate(skuCode, totalStock);
        
        for (Map.Entry<String, Integer> entry : channelAllocation.entrySet()) {
            String targetPlatform = entry.getKey();
            int channelStock = entry.getValue();
            
            // 投递到消息队列，异步推送
            channelStockProducer.send(new ChannelStockMessage(
                skuCode, targetPlatform, channelStock));
        }
    }
}

关键设计点：

• 中心库存：以中心库存为准，渠道库存只是"影子"。下单扣中心库存，再异步同步到渠道。
• 分布式锁：用Redis的SETNX保证同一SKU同一时刻只有一个扣减操作。
• Lua脚本原子操作：查库存和扣减在同一个Lua脚本里完成，避免竞态条件。
• 最终一致性：渠道库存允许短暂不一致，通过定时对账任务修正。

4.3 定时对账：兜底数据一致性

@XxlJob("inventoryReconciliation")
public void reconcile() {
    // 每小时跑一次，对比中心库存和各渠道库存
    List<String> allSkus = skuRepository.findAllActiveSkus();
    
    for (String skuCode : allSkus) {
        int centerStock = getCenterStock(skuCode);
        
        for (String platform : getAllPlatforms()) {
            try {
                // 从平台拉取当前渠道库存
                int channelStock = adapterRegistry
                    .getAdapter(platform)
                    .queryInventory(skuCode);
                
                // 计算期望的渠道库存
                int expectedStock = allocationStrategy
                    .getExpectedChannelStock(skuCode, centerStock, platform);
                
                if (Math.abs(channelStock - expectedStock) > THRESHOLD) {
                    // 差异超过阈值，强制修正
                    adapterRegistry.getAdapter(platform)
                        .pushInventory(skuCode, expectedStock);
                    log.warn("库存修正: SKU={}, 平台={}, 实际={}, 期望={}",
                        skuCode, platform, channelStock, expectedStock);
                }
            } catch (Exception e) {
                log.error("对账失败: SKU={}, 平台={}", skuCode, platform, e);
            }
        }
    }
}

五、物流对接：多物流平台的统一方案

物流对接的核心需求就三个：电子面单获取、物流轨迹跟踪、签收状态同步。

5.1 电子面单统一接口

物流平台众多，面单格式各不相同。可以抽象一个统一接口：

public interface LogisticsAdapter {
    
    // 获取电子面单
    WaybillResult getWaybill(WaybillRequest request);
    
    // 查询物流轨迹
    List<TrackingNode> queryTracking(String waybillNo);
    
    // 取消面单
    boolean cancelWaybill(String waybillNo);
}

// 统一的面单请求
public class WaybillRequest {
    private String senderName;        // 寄件人
    private String senderPhone;       // 寄件人电话
    private Address senderAddress;    // 寄件地址
    private String receiverName;      // 收件人
    private String receiverPhone;     // 收件人电话
    private Address receiverAddress;  // 收件地址
    private double weight;            // 重量(kg)
    private String cargoType;         // 货物类型
    private String remark;            // 备注
    // 各平台特有的扩展字段
    private Map<String, String> extParams;
}

// 统一的面单结果
public class WaybillResult {
    private String waybillNo;         // 运单号
    private byte[] waybillImage;      // 面单图片(PDF/PNG)
    private String waybillHtml;       // 面单HTML（用于打印）
    private String packageCode;       // 大包号（部分平台需要）
    private String logisticsCode;     // 物流编码
}

5.2 物流轨迹聚合

不同物流公司的轨迹数据格式差异巨大，有的用JSON，有的用XML，有的返回纯文本。需要做一层轨迹解析引擎：

┌──────────┐
│ 菜鸟物流  │──┐
├──────────┤  │   ┌───────────┐   ┌──────────┐
│ 顺丰速运  │────▶│ 轨迹解析引擎 │──▶│ 统一轨迹  │
├──────────  │   │ (规则引擎)  │   │  数据模型  │
│ 中通快递  │──┘   └───────────┘   └──────────┘
──────────┤        ▲
│ ......   │──┐     │ 规则配置
──────────┤  │  ┌─────────┐
│ 德邦物流  │──┘  │ 规则管理台 │
└──────────┘     └──────────┘

每个物流商对应一套解析规则，支持在管理后台配置，不需要改代码：

// 以圆通为例的轨迹解析规则配置
{
  "logisticsCode": "YTO",
  "responseFormat": "JSON",
  "trackingPath": "$.traces[*]",
  "fieldMapping": {
    "time": "$.time",
    "description": "$.desc",
    "location": "$.city",
    "status": {
      "rule": "REGEX",
      "patterns": [
        {"pattern": "已签收", "status": "SIGNED"},
        {"pattern": "派件", "status": "DELIVERING"},
        {"pattern": "到达", "status": "IN_TRANSIT"}
      ]
    }
  }
}

六、仓储平台对接：多仓协同方案

仓储对接的复杂度在于多仓协同和智能分仓。

6.1 多仓协同架构

                    ──────────────┐
                    │   订单路由    │
                    │   引擎       │
                    └──────┬───────┘
                           │
            ┌──────────────┼──────────────┐
            ▼              ▼              ▼
     ┌──────────┐   ──────────┐   ┌──────────┐
     │ 菜鸟云仓  │   │ 京东云仓  │   │ 顺丰云仓  │
     │ (华东仓)  │   │ (华北仓)  │   │ (华南仓)  │
     └──────────┘   ──────────┘   └──────────┘

分仓路由的核心逻辑：

@Service
public class WarehouseRouter {
    
    /**
     * 智能分仓：根据收货地址、库存、成本等因素选择最优仓库
     */
    public WarehouseRouteResult route(Order order) {
        List<WarehouseCandidate> candidates = new ArrayList<>();
        
        for (Warehouse wh : warehouseRegistry.getAll()) {
            // 1. 检查仓库是否支持该物流商
            if (!wh.supportsLogistics(order.getLogisticsCode())) {
                continue;
            }
            
            // 2. 检查库存是否充足
            int available = wh.checkStock(order.getSkuCode());
            if (available < order.getQuantity()) {
                continue;
            }
            
            // 3. 计算综合得分
            double score = calculateScore(wh, order);
            candidates.add(new WarehouseCandidate(wh, available, score));
        }
        
        // 按得分排序，选最优仓库
        return candidates.stream()
            .sorted(Comparator.comparingDouble(WarehouseCandidate::getScore).reversed())
            .findFirst()
            .map(c -> new WarehouseRouteResult(c.getWarehouse(), c.getScore()))
            .orElseThrow(() -> new NoWarehouseAvailableException("无可用仓库"));
    }
    
    /**
     * 综合得分计算
     */
    private double calculateScore(Warehouse wh, Order order) {
        double score = 0;
        
        // 距离得分：收货地址与仓库的距离越近越好
        double distance = geoService.calculateDistance(
            wh.getLocation(), order.getReceiverAddress());
        score += (1.0 / (1.0 + distance)) * 40;
        
        // 库存充足率得分：库存越充裕越好
        double stockRatio = (double) wh.getStock(order.getSkuCode()) 
                            / order.getQuantity();
        score += Math.min(stockRatio, 1.0) * 30;
        
        // 物流成本得分：运费越低越好
        double shippingCost = wh.estimateShippingCost(order);
        score += (1.0 / (1.0 + shippingCost)) * 20;
        
        // 仓库负载得分：负载越低越好（避免爆仓）
        double loadRate = wh.getCurrentLoadRate();
        score += (1.0 - loadRate) * 10;
        
        return score;
    }
}

七、扩展性设计：新平台接入的标准流程

沉淀出一套标准接入流程。一个新平台从拿到API文档到上线，熟练的情况下3-5个工作日就能完成：

Day 1: 接口调研
  └── 分析平台API文档，梳理接口清单、认证方式、数据格式

Day 2: 适配器开发
  └── 实现 PlatformAdapter 接口
  └── 完成认证模块（OAuth/签名/Token刷新）
  └── 实现核心方法：fetchOrders / pushInventory / pushLogistics

Day 3: 数据映射
  └── 订单状态映射
  └── 商品SKU映射
  └── 地址解析规则

Day 4: 联调测试
  └── 沙箱环境联调
  └── 数据一致性验证
  └── 异常场景测试（超时、限流、签名错误）

Day 5: 灰度上线
  └── 小流量验证
  └── 监控告警配置
  └── 全量上线

核心原则是：新增平台只需要写一个Adapter，不需要改网关代码、不需要改业务代码。这就是适配器模式的价值。

八、性能优化：多平台并发同步怎么扛

8.1 分层限流

每个平台有自己的限流策略，不能把人家限流接口打爆：

@Component
public class PlatformRateLimiter {
    
    // 每个平台独立的限流器
    private final Map<String, RateLimiter> limiters = new ConcurrentHashMap<>();
    
    public void init(String platformCode, int permitsPer) {
        limiters.put(platformCode, 
            RateLimiter.create(permitsPerSecond));
    }
    
    public void acquire(String platformCode) {
        RateLimiter limiter = limiters.get(platformCode);
        if (limiter != null) {
            limiter.acquire(); // 阻塞等待，直到获得许可
        }
    }
}

// 在Adapter调用前限流
public PageResult<UnifiedOrder> fetchOrders(String platformCode, 
                                             OrderQueryRequest request) {
    rateLimiter.acquire(platformCode);  // 限流
    PlatformAdapter adapter = adapterRegistry.getAdapter(platformCode);
    return adapter.fetchOrders(request);
}

8.2 异步化 + 削峰

订单同步不是同步调用，全部走消息队列异步处理：

平台Webhook ─▶ RocketMQ ──▶ 消费者组（可水平扩展）──▶ 订单入库
                                    │
                                    ├── 库存扣减
                                    ├── 物流分配
                                    └── 财务记账

大促期间（双11、618），消息量会暴增10倍以上。应对策略：

• 消费者弹性扩缩容：平时10个消费者实例，大促前扩到50个。
• 消息优先级：新订单 > 物流更新 > 对账消息。
• 降级策略：非核心平台（日均订单<10的）在大促期间降低同步频率。

8.3 数据库层面

• 分库分表：订单表按platform_code分片，每个平台的数据隔离到不同的表。
• 读写分离：主库写入，从库查询。
• 2. 热点数据缓存：库存、商品等热点数据放Redis，减少数据库压力。

8.4 监控告警

多平台系统，任何一个出问题都要第一时间发现：

// 平台健康度监控
@Scheduled(fixedRate = 60000) // 每分钟检查一次
public void healthCheck() {
    for (String platformCode : getAllPlatformCodes()) {
        PlatformHealth health = healthChecker.check(platformCode);
        
        // 上报指标
        metricsService.gauge("platform.health", 
            Map.of("platform", platformCode), 
            health.getScore());
        
        // 异常告警
        if (health.getScore() < THRESHOLD) {
            alertService.send(String.format(
                "【告警】平台 %s 健康度 %.1f%%，最近错误率 %.1f%%，平均响应 %dms",
                platformCode, 
                health.getScore() * 100,
                health.getErrorRate() * 100,
                health.getAvgResponseTime()));
        }
    }
}

九、几个实战经验总结

1. 永远不要相信平台的推送是可靠的。 遇到过淘宝推送丢消息、京东推送延迟30分钟、拼多多推送重复发送的情况。所以轮询兜底是必须的。

2. 幂等不是可选项，是必选项。 推送可能重复，轮询可能重叠，重试可能多次。任何写入操作都必须幂等。

3. 日志要打到能还原现场。 和平台联调的时候，最怕的就是"我这里没问题啊"。把请求参数、响应内容、耗时、重试次数全部记下来，出了问题一查就知道。

4. 适配器要能热更新。 平台改接口是常事，不能每次改个字段都要重新发版。可以把数据映射规则放到配置中心（Nacos），改完配置实时生效。

5. 新平台接入一定要做压测。 有些小平台的API性能很差，响应时间动辄3-5秒，如果不做限流，会把你的线程池打满，拖垮整个网关。

十、写在最后

多平台的对接，听起来是个大工程，但核心思路其实不复杂：抽象统一接口，隔离平台差异，异步化处理，最终一致性保障。架构不是一开始就设计成这样的，而是在对接第10个平台、第50个平台、第200个平台的过程中，一步步演进出来的。

如果你也在做多平台对接，希望这篇文章里的方案和经验能帮你少走一些弯路。技术选型没有银弹，适合自己的业务场景才是最好的。