#WorkBuddy# 顶层三价改不动之谜：京东价保存后回读永远是旧值，原来框架在替你挡

#WorkBuddy# 顶层三价改不动之谜：京东价保存后回读永远是旧值，原来框架在替你挡

场景

批量改价时遇到一个灵异现象：通过接口把商品顶层的"京东价"从 2499 改成 2699，保存成功，可回到列表刷新一看——还是 2499。换一家店再试，同样。不是接口失败，不是缓存，是这个值天生改不动。这篇把"三价陷阱"讲透。

什么是顶层三价

商品编辑页顶部有三行价格：京东价、市场价、成本价。它们和下面 SKU 表格里每个规格行的价格是两套体系：

顶层三价   → 商品级展示价，受平台框架保护
SKU 行价格 → 规格级真实售价，改价的主战场

实测：框架在替你挡

在两家店分别实测，用接口改顶层 jdPrice：

店A: 2499 → 2699, 保存返回成功, 回读仍是 2499
店B: 同样操作, 回读仍是旧值

保存成功了，值却没变——说明服务端/框架层对顶层三价有保护逻辑，提交了也会被挡回去。这不是 bug，是设计：顶层价由 SKU 价格体系推导或受平台管控，不允许从这条通道直接改。

由此立下三条规矩

1. 别白费力气：任何"改顶层三价"的尝试直接跳过，实测命中率是零。
2. 更别因此误判失败：保存后回读顶层价没变，不代表你的保存流程坏了。判失败只会引发无意义的重试风暴，触发限流反而真出事。
3. 判定达标只看 SKU 行：改价任务是否完成，唯一标准是 SKU 行的价格/库存字段回读正确。顶层三价是"背景板"，不是验收对象。

正确的加 SKU 姿势

有一处例外要记住：新增 SKU 之前，需要先给顶层市场价填一个数值——这是为了让 SKU 能增加成功而填的引导值。但 SKU 保存成功之后，顶层三价就彻底不要碰了，让它保持原样。

加 SKU 前要做什么？
答：先填顶层市场价，确保 SKU 增加成功
加 SKU 后呢？
答：顶层三价一律不动，验收只看 SKU 行的 price / stockCount

总结

自动化批量操作里，最贵的错误不是"改不动"，而是"以为该改得动"——于是重试、报警、限流连环炸。先花十分钟实测一次边界，把"天生改不动"的字段从任务清单里划掉，后面每一条流程都因此变快。知道哪些字段不用碰，和知道哪些字段要改，是同一种能力。