价格配置，在用户服务过程中修改了应该怎么处理

每笔订单，必然会记录当前的商品价格。商品加价降价是个很正常的商业行为。

重复又怎么样呢，设计有时候还要考虑冗余，另外你还是订单业务，你是害怕订单太多了吗？那订单多你加不了配置吗？订单少那你又考虑啥呢。

订单下单过程中，管理员修改价格，如果你要考虑这个场景，应该是在下单前有一个询价接口，然后下单把这个价格也发送给后端，如果支付金额高于下单前接口，可以弹窗给用户。

如果你没有活动可以减少价格，那你可以把商品做成多版本，订单把这个版本号存起来，通过版本号去查询历史配置，不过作为一个开发，我们以后可以去拒绝这块的需求变化？

存一下快照是必须的。

价格虽然是配置的一个数组,但是你用户下单的时候应该会明确使用的某个价格,那不存在说在订单表需要存一个数组的说法啊, 比方说我下单的时候使用了优惠券 那我肯定会存一个 订单应付价格,优惠券抵扣金额,订单实付金额(应付-优惠)

所以你应该在下单的时候根据用户的角色,这个订单会有一个价格策略固定成一个实际使用的金额 只需要记录实付金额就行了噻 没必要把所有的价格配置都记录下来噻

订单一旦生成，和订单相关的信息就已经锁定了，包括商品库存，商品价格等基本信息。

订单生成以后，进入待支付状态，支付订单使用的金额信息就是下单时生成的订单快照信息。同时，支付成功后，扣减的库存信息，也是快照信息中关联的库存信息。

试想一下，你在 12306 好不容易抢到一张票，结果到支付环节，弹窗告诉你，“对不起，涨钱了。”“不好意思，票没了。”你能忍么？

引用站内教程L05中6.3内容 传送门

做价格信息的冗余到订单里，退款只和冗余信息对比