名词速查

一句话

后台里几个反复出现、但第一次见容易理解错的词。看不懂哪一项就回来查。

SPU 和 SKU

词	是什么	例子
SPU（商品）	一件"商品"本身	「景德镇青花茶杯」
SKU（规格）	买家真正下单的那一条	「景德镇青花茶杯 · 大号 · 蓝」

单规格商品也有 1 条 SKU

就算这个商品没有颜色尺码之分，系统也会给它生成 1 条 SKU。

这不是多余的：库存、价格、下单、发货全部走 SKU。如果单规格走另一套逻辑， 就会有两份代码，而其中一份迟早会漏掉某个规则（比如"库存不足不许下单"）。

你在后台的实际操作：

• 商品编辑 → 规格模式选「单规格」→ 系统自己生成那 1 条
• 选「多规格」→ 先在「规格」页配好属性（颜色/尺寸），再到「SKU」页生成矩阵

最小单位金额

价格填错 100 倍就是从这儿来的

后台所有金额输入框，填的都是主单位（元/美元），系统内部按最小单位存。

• USD：58.00 → 存 5800（美分）
• JPY：5800 → 存 5800（日元没有小数位）

同一个数字 5800，在美元站是 $58.00，在日元站是 ¥5,800 —— 差 100 倍。

所以：

• 用后台的金额输入框填（它会自动换算），不要去猜内部数字
• 改站点货币不会换算老订单的金额，老订单记着下单那一刻的币种和数字（见下面「快照」）

快照

下单那一刻，系统会把商品名、规格文案、图片、单价、币种原样抄一份写进订单。

为什么：商品后来改名、改价、下架，都不能影响已经发生的交易。 买家看到的订单详情，永远是他下单时看到的那个样子。

有一样东西故意不快照

商品采购来源（供应商、采购链接）是实时读的。因为采购发生在下单之后 —— 你换了供应商，该看到的是新链接。快照只会让人照着已经失效的地址去下单。

站点 / 单站点模型

一台服务器 = 一个店 = 一个域名 = 一种语言 = 一种货币。

所以后台的「站点设置」全站只有一份，没有站点列表、没有新增站点。 C 端也没有任何语言或货币切换器 —— 买家看到的就是你配的那一种。

要开第二个市场（比如日本站），再部署一套，不是在这个系统里加一条记录。

沙箱 / 测试模式

支付通道可以标为「沙箱」。沙箱通道下的订单照常计入报表和 GMV —— 这是故意的：上线前会清测试数据、停用沙箱通道，在那之前把它们藏起来只会让 整个仪表盘一片 0，让人以为报表坏了。

上线前必须做

把沙箱通道停用、把测试订单清掉。deploy.py check 会检查"还有没有沙箱通道启用着"。

订单状态

状态	含义
待付款	下单了还没付 —— 不计入 GMV
已付款	钱到了，等发货
已发货	填了运单号
已完成	买家确认收货，或超时自动确认
已关闭 / 已取消	超时未付、手动取消

售后状态是另一个维度，和订单状态并排显示。 「已发货 + 买家申请退货」是两件事，都得看到。

售后

买家发起的退款/退货/换货申请，走工单。

有未结案的售后，发货会被拦下

不是提醒，是拦住。买家申请了退款你还照常发货，等于货和钱一起送出去。

真要发就先去售后页把工单拒掉 —— 那是一次有痕迹的决定。

Webhook（回调）

支付平台在收到钱之后，主动打一个请求到我们的服务器告诉我们"这单付了"。

不配 webhook 会怎样

买家付完钱跳回来，订单还是待付款，然后被超时关单 —— 钱收了，货没发，买家来投诉。

「支付成功页」看到的那个状态是前端轮询出来的，真正让订单变成已付款的是 webhook。

详见 回调（webhook）是什么。

幂等

同一个操作重复做，结果和做一次一样。

支付平台的回调一定会重复（网络抖动、我们正好在重启，它就会重推）。 系统对同一笔支付只会认一次 —— 所以你不会看到"付一次钱订单被加了两次款"。