这个策略解决什么问题

在零售与分销一体化的场景里，产品分类是后续商品同步、库存口径、销售统计的「地基」。一次实际项目中，某零售企业同时使用聚水潭管商品、用销帮帮管产品主数据与销售流程。最早他们让两边各自维护一份分类表，结果三个月后做品类分析时发现两边数字对不上——同一个「夏季连衣裙」在两边属于不同层级、不同名称。本策略的目标很简单：把销帮帮侧的分类作为唯一可信源，定时拉取并沉淀到轻易云数据集成平台，作为后续聚水潭商品映射和销帮帮自身业务单据的字典底座。

数据流向与字段映射

整体流向是「销帮帮 → 轻易云集成平台」。销帮帮侧通过POST /pro/v2/api/product/categoryList拉取分类列表，轻易云侧则以「写入空操作」的 WebAPI 占位承接，后续由同平台下游策略消费这份分类字典。

关键字段对照如下：

这里要注意，销帮帮源端启用了autoFillResponse，响应里corpid、enableSerialNumber等字段会以_autoFillResponse自动补齐，工程师只需要在轻易云里把它们标记为「由源端自动填充」，不要手工再传一遍。

在轻易云上如何配置

我们在客户现场通常按三步走：

第一步：注册源端连接器。在轻易云集成平台的「系统对接」里，把销帮帮作为外部业务系统接入，记下platform_id，并配置鉴权信息（公司 ID 与 userId）。这一对凭证要进凭证库统一管理，不要散落在策略里。

第二步：配置 QUERY_ONLY 策略。把源端的元数据 JSON 导入策略编辑器，轻易云会自动识别出 request 里的corpid、userId和 otherRequest 里的StrategyId。StrategyId在查询场景下一般为空，但保留字段方便后续在策略中心做反查与排障。

第三步：配置目标端「写入空操作」。目标端是轻易云集成平台自身的「写入空操作」WebAPI，effect 是EXECUTE，method 是POST，request 和 response 都为空。它的作用是给调度器一个明确的「落点」，让分类数据进入平台内部的主题表（topic）供其他策略订阅。这样编码映射可以集中管理，避免散落在多个目标系统里。

实施步骤

我们建议按三个阶段推进，避免一次性上线把脏数据带进生产：

阶段一：增量起点准备。先在轻易云里建一张分类字典表，把历史分类一次性全量初始化进去。这里采用「全量双轨」的做法：跑一次全量任务，把sync_time统一打上同一时间戳，作为后续增量比对的起点。

阶段二：调度策略上线。源端crontab是3 2 * * *，也就是每天凌晨 2:03 触发一次。建议轻易云侧的调度时间错开 1 分钟，比如设为4 2 * * *，给源端系统留出缓冲。目标端的crontab写作1 1 1 1 1，这是轻易云的「空跑占位」惯例：目标端不主动触发，而是由源端驱动完成后立即调用，落地延迟通常在秒级。

阶段三：分阶段投产。第一周只在测试租户跑，观察返回的分类数和层级是否对齐；第二周切换预发；第三周正式上线，并打开轻易云的运行告警。一旦发现「本次返回数量异常为 0」，要立刻人工确认源端接口是否限流。

踩坑复盘

1. 父分类编码缺失导致层级断裂。销帮帮部分一级分类的parentId返回为空字符串而不是 0，轻易云默认当成根节点处理，结果下钻时出现孤儿节点。稳妥做法是在轻易云的字段转换里把空串统一规整成0。
2. 同一分类被多次入库。早期我们没注意源端idCheck为 false，导致每次查询都重新拉一遍并覆盖。后续把轻易云侧的入库动作从「覆盖式」改为「按 id 存在则更新、不存在则插入」，并把idCheck在源端配置里勾选启用。
3. 凭证硬编码在策略里。第一次配置时把corpid和userId直接写在 request 字段里，换环境时要逐条改。正确做法是轻易云的凭证引用变量（${XIAOBANGBANG_CORPID}），由平台统一注入。
4. 空操作的「写入空操作」被误以为是 Bug。一些新同事看到目标端 request/response 都为空，会怀疑没写完。其实在 QUERY_ONLY 场景下，源端就是主驱动力，目标端只是落点；真正落地的字段在轻易云内部主题表里，不需要走业务系统接口。
5. 调度时间扎堆。默认源端 2:03、目标端「1 1 1 1 1」看似错开，但同租户还有其他五条策略在凌晨运行，容易引发瞬时压力。稳妥做法是把同租户的所有凌晨任务均匀分散到 02:00–04:00。