运营降价了，用户来投诉"为什么我的订单还是原价"

运营把一款商品从 299 降到 199，价格改了之后，已经下单未支付的订单里显示的还是 299。

用户来问：现在 199，为什么我付 299？

---

价格是下单时刻的快照

这其实不是 bug，而是一个设计决策——下单时对价格做快照。

用户下单的瞬间，系统把当时的价格、优惠金额、商品名称一起写入订单记录，之后商品价格怎么变都不影响这笔订单。

CREATE TABLE order_item (
    id            BIGINT PRIMARY KEY,
    order_id      BIGINT,
    product_id    BIGINT,
    product_name  VARCHAR(256),   -- 下单时的商品名
    unit_price    DECIMAL(10,2),  -- 下单时的价格（快照）
    quantity      INT,
    subtotal      DECIMAL(10,2)
);

为什么要快照而不是关联商品表的实时价格？

如果订单直接关联商品表价格，商品改价后订单金额会自动变——用户支付的钱可能和下单时确认的金额不一样，这个问题远比"为什么我没享受到新价格"更严重。

---

价格降了，用户要不要受益

用户投诉"为什么还是原价"，背后是两个不同诉求：

诉求 A：我订单没付款，降价了应该给我最新价。 诉求 B：商品页上显示 199，我下单确认页也是 199，结果付款时变成了 299（价格不一致）——这才是真正的坑。

诉求 A 是业务策略问题，平台可以不同意；诉求 B 是功能 bug，必须解决。

对于诉求 A，常见的处理方式是：未支付订单到期作废，用户可以重新下单享受新价格（这也是超时取消的副作用之一）。对于诉求 B，要在支付时做一次价格校验：

// 支付前二次确认价格
BigDecimal currentPrice = productService.getCurrentPrice(productId);
if (currentPrice.compareTo(order.getUnitPrice()) < 0) {
    // 价格下降了，主动提示用户，给选择：继续支付原价 or 取消重下
    return PriceChangedResponse.dropped(order.getUnitPrice(), currentPrice);
}
if (currentPrice.compareTo(order.getUnitPrice()) > 0) {
    // 价格上涨，不允许以旧价格支付（防薅羊毛）
    throw new PriceChangedException("商品价格已调整，请重新下单");
}

价格上涨时不允许以旧价格支付，是必须的。价格下降时怎么处理，是产品决策。

---

SKU 和价格版本

商品有 SKU（不同规格的子商品），价格变更可能只影响某个 SKU。订单里要存的是 SKU ID 和 SKU 级别的价格快照，不是商品大类的价格。

有些系统引入"价格版本"概念：每次改价生成新版本，订单记录对应的价格版本号。这样可以追溯历史价格，也方便处理"这批订单用的是哪个版本的价格"的问题。

---

快照的其他字段

价格快照往往不只是价格：

• 商品名称（商品改名后历史订单不受影响）
• 规格描述（"颜色：白色 / 尺寸：M"）
• 优惠金额明细（满减了多少、优惠券抵扣了多少）
• 图片 URL（商品主图可能被替换）

对账、客诉、售后都会需要这些快照数据。漏了任何一个，出问题时都很难还原当时的交易上下文。