京东经常出现实物商品不变，但旧 SKU 下线、生成全新 SKU 的现象。常见于商品改版、规格重组、店铺迁移、类目调整。旧 SKU 调用接口返回查无商品、已下架，但同款商品依然在售。如果没有处理逻辑，会出现：同步中断、比价失效、采购系统找不到货源、历史业务数据和新商品割裂。
一、识别 SKU 切换发生的信号
调用接口返回以下特征，就要怀疑 SKU 发生迭代切换：
原 SKU 返回查无此商品、已删除、已下架，但业务侧确认该商品还在京东正常售卖
HTTP 请求正常，业务返回码提示 sku 无效，但 SPU 信息历史记录存在
复核多次，旧 SKU 持续失效，并非临时网络问题
同 SPU 下，原有子 skuId 消失，出现一批全新的 skuId
注意：不要把单纯库存为 0、临时下架判定为 SKU 切换。库存为 0 只是卖断货，后续可恢复；SKU 切换是 ID 本身作废。
二、数据库层设计，做好新旧 SKU 关联
数据表需要增加映射能力，不能简单用单个 skuId 作为唯一主键。
保留 SPU 维度记录，一个 SPU 可以关联多条 SKU 记录。
增加 SKU 生命周期字段：有效、已迭代作废、已删除。
维护一张 SKU 映射关系表：存储旧 skuId、新 skuId、spuId、切换发生时间。
旧 SKU 数据不能删除，保留历史价格、参数快照，用于历史报表、比价溯源。
示例数据表关键字段
表格
三、技术处理流程
检测旧 SKU 失效：接口返回业务状态错误，多次复核确认不是临时故障。标记旧 SKU 状态为已迭代作废，停止对旧 SKU 高频轮询。
通过历史保存的spu_id，查询该 SPU 下全部可用子 SKU 列表。
对比规格、标题、参数，匹配出和原商品规格一致的新 skuId。
建立新旧 SKU 映射关系，把新 SKU 加入正常同步任务队列，开始定时拉取价格库存。
如果同一个 SPU 下无法匹配到规格一致的 SKU，则标记为待人工处理，不自动猜测新 SKU。
风险点：一个 SPU 下会有几十种规格，不能直接取 SPU 下第一个 SKU，很容易匹配错规格。必须比对规格文本、参数。
四、上层业务系统兼容逻辑
采购中台 / ERP
历史单据继续使用旧 SKU 做归档查询，不修改历史数据。
新建业务自动走映射关系，优先使用新生效 SKU。
页面提示：该商品SKU已迭代，已切换至新编码。
如果找不到匹配新 SKU，则禁止创建新采购单据。
比价监控系统
比价链路自动读取映射表，旧 SKU 的监控任务平滑迁移到新 SKU。
历史价格曲线做合并展示，把旧 SKU 历史快照和新 SKU 数据做时间轴拼接，保证比价连续性。
五、边界异常场景处理
SPU 也发生变更：商品改版后连 SPU 都更换，无法自动匹配，直接进入人工处理队列，由运营录入新 SKU。
一个旧 SKU 对应多个新 SKU：规格拆分，程序无法自动抉择，人工介入选择或者全部记录。
新老 SKU 参数差异较大：外观、配置发生改动，不属于简单 ID 切换，不做自动映射，避免把不同商品混为一谈。
六、复核与告警策略
检测到 SKU 迭代切换时输出日志；单条切换不告警。
短时间大批量 SKU 出现迭代作废，触发告警，排查是否店铺迁移、类目整体调整。
自动匹配失败的 SKU 统一落异常列表，定期运营巡检。
七、禁止的错误做法
旧 SKU 失效直接删除数据库记录，丢失历史比价数据。
旧 SKU 报错，不停循环重试，造成风控。
拿到 SPU 之后直接取任意子 SKU 作为新 SKU，规格错乱。
修改历史订单里的旧 sku_id，破坏业务单据真实性。
总结
SKU 切换本质是商品 ID 生命周期管理，核心思路：识别失效、保留历史数据、依靠 SPU + 规格双重匹配寻找新 SKU、建立映射关系、业务层平滑迁移，匹配失败交给人工兜底。只简单根据 skuId 拉取数据的系统，长期运行一定会遇到大量数据断裂问题。
