一、业务背景
反向海淘面向海外华人消费者，把国内电商商品采购之后再发往海外。业务上需要同时兼容淘宝零售、1688 批发货源、微店小众商家货源。
早期不少方案选择网页爬虫获取商品数据，会面临验证码、IP 封禁、页面改版失效、合规风险等问题，长期维护成本很高。所以成熟系统大多选择各平台开放官方 API 来获取标准化货源数据。
但现实开发中会发现：并不是简单调用接口就可以完成业务，多平台 API 本身就是反向海淘系统一大核心技术壁垒。
淘宝、1688、微店三套开放平台，鉴权签名规则完全不一样；
商品、SKU、价格、库存返回字段命名、层级结构各不相同；
平台 QPS 配额、错误码体系、风控策略独立；
1688 存在阶梯批发价，和淘宝零售价格模型差异巨大；
代购业务对库存、价格实时性要求高，一旦数据不一致直接造成超卖、客诉；
海外用户访问，叠加国内接口网络延迟，对缓存、降级、容错提出更高要求。
二、三大平台 API 基础差异梳理
平台
鉴权方式
商品核心接口
价格模型
特点
淘宝
app_key+app_secret MD5 签名
taobao.item_get
零售单售价，多 SKU
字段丰富，限流严格，需要申请接口权限
1688
app_key+app_secret 签名
1688.item_get
阶梯批发价，多起批量
批发属性，存在供应商、起订量逻辑
微店
token 密钥模式
micro.item_get
零售价格，店铺私有货源
中小商家居多，部分字段返回为空
重点：三个平台没有统一标准，入参、出参、异常错误码完全不能直接复用。直接在业务服务里写多套 if‑else，后期迭代维护会变得难以维护。
例如：1688.item_get为 1688 商品详情接口，B2B 业务核心接口，传入商品num_iid获取完整商品业务数据。
接口简介
接口名称：1688.item_get（1688商品详情API，taobaoapi2014前往体验）
接口版本：2.0
调用限制：存在单秒频次、每日调用配额，高频场景需做限流、缓存 处理。
接口能力覆盖
商品基础信息：标题、子标题、划线价、展示价
B2B 核心：多档阶梯批发价格、最小起订量、混批规则
SKU 规格：规格名称、规格图片、各 SKU 价格、库存
多媒体：主图数组、详情 HTML、视频地址
属性参数：产品规格参数表
店铺信息：店铺 ID、店铺名称、实力商家标识、供应商地址
交易相关：销量、发货时效、是否支持代发
三、架构方案：搭建统一 API 适配中间层
工程上推荐引入独立的接口适配中间层（适配器网关），把第三方平台差异全部收敛在这一层，上层业务只调用内部统一标准接口，不需要感知是淘宝、1688 还是微店货源。
整体分层
代码语言：javascript
上层业务服务（商品展示、下单采购、价格校验）
↓
【API适配中间层】统一入参、统一出参、统一错误码
├─淘宝适配器：签名、参数组装、响应解析、字段映射
├─1688适配器：签名、批发价解析、起订量处理
└─微店适配器：token鉴权、特殊空值兼容
↓
多级缓存层 Redis
↓
第三方开放平台（淘宝/1688/微店官方API）
中间层要完成的核心工作
鉴权隔离：每个平台独立维护密钥、签名逻辑，业务层不需要关心签名算法；
参数标准化：上层只传source平台标识、goods_id商品编号，中间层转换成对应平台真实请求参数；
数据归一化：把不同平台返回的商品、SKU、价格、库存，统一转换成系统内部标准数据模型；
错误码归一：把各平台五花八门的错误，翻译成内部统一错误码（商品不存在、权限不足、限流、商品下架）；
流量管控：针对每个平台独立做令牌桶限流，遵守平台 QPS 配额；
缓存、熔断、重试：统一处理超时、429 限流、服务抖动，做指数退避重试、降级逻辑。
