CRMEB Pro 订单二开避坑：为什么商品页和下单页的价格会不一致？
## 摘要
订单二开里最容易让人抓狂的问题，不是“价格算不出来”，而是“每一页都算出了不同的价格”。商品页看着是会员价，购物车里又变了，确认订单页再变一次，用户最后提交时还可能因为优惠券、积分、运费重算而出现第三个金额。表面上是价格不一致，底层其实是结算链路里缺少统一入口。
CRMEB Pro 的订单价格不是一个字段拍脑袋算完，而是从购物车快照、商品原价、会员价、等级价、活动价、优惠券、积分、运费、首单优惠一路叠出来的。真正能落单的金额，必须在确认页和创建订单时再次校验，不能直接信前端展示值，也不能直接信旧缓存。
本文基于 CRMEB Pro 真实实现，拆开订单从确认到创建的完整链路，重点讲清楚：商品页为什么只负责展示，确认页为什么要重算，创建订单为什么还要再算一次，以及哪些字段必须落库做快照。
本文涉及的真实目录：
```text
app/controller/api/v1/order/StoreOrder.php
app/services/order/StoreOrderServices.php
app/services/order/StoreOrderComputedServices.php
app/services/order/StoreOrderCreateServices.php
app/services/order/StoreCartServices.php
app/services/order/StoreOrderCartInfoServices.php
app/dao/order/StoreOrderDao.php
app/model/order/StoreOrder.php
app/model/order/StoreOrderCartInfo.php
app/services/user/level/SystemUserLevelServices.php
app/services/user/member/MemberCardServices.php
app/services/activity/coupon/StoreCouponUserServices.php
app/services/user/UserServices.php
```
## 一、先看结论：订单价格不是一个数，而是一串快照
CRMEB Pro 订单价格链路里，常见的价格字段至少有这些：
```text
sumPrice
商品原始总价。
totalPrice
会员价、等级价等处理后的商品总价。
couponPrice
优惠券抵扣金额。
firstOrderPrice
首单优惠金额。
payPrice
用户最终需要支付的金额。
payPostage
最终要付的运费。
deductionPrice
积分抵扣金额。
changePrice
改价优惠金额。
```
真正入库时，订单表会保存这些快照字段：
```text
total_price
coupon_price
first_order_price
promotions_price
pay_price
pay_postage
deduction_price
change_price
use_integral
gain_integral
level_extra_integral_level_id
level_extra_integral_ratio
```
这意味着订单不是“下单时实时算一个总价”就完事了，而是要把当时那次结算结果固化下来。否则后面商品改价、会员变更、活动结束，订单金额就会跟着飘。
## 二、第一道门：商品页只负责看，不负责最终结算
商品详情页和确认页看到的价格，很多时候都来自同一类商品价格计算，但它们不等于最终订单金额。项目里商品价格会受这些因素影响：
```text
普通售价 price
付费会员价 vip_price
用户等级折扣 discount
SKU 独立等级价 level_price
活动商品价
渠道价
首单优惠
```
这里最关键的不是“谁便宜”，而是“谁有资格参与计算”。比如 `StoreProductServices` 里会根据用户等级、付费会员、商品是否启用会员价，决定当前展示哪个价格类型。
你在前端看到的可能只是：
```text
这个商品是会员价
那个商品是等级价
这个 SKU 命中活动价
```
但真正下单时，CRMEB Pro 还要继续往下看：
```text
购物车里的 truePrice 是什么
cart_num 乘起来是多少
是否能叠加优惠券
是否能用积分
是否有首单优惠
运费怎么重算
```
所以二开时不要把会员价逻辑写到前端组件里就结束了，前端只能展示，不能替代结算。
## 三、确认页为什么要重算：旧缓存不可信
订单确认入口在：
```php
app/controller/api/v1/order/StoreOrder.php
```
确认数据方法是：
```php
public function getOrderConfirmData(array $user, $cartId, bool $new, int $addressId, int $shipping_type = 1, int $store_id = 0, int $coupon_id = 0, int $isSendGift = 0)
```
它做的第一件事不是直接返回购物车，而是重新拿地址、重新拿购物车、重新算价格组：
```php
$cartGroup = $cartServices->getUserProductCartListV1($uid, $cartId, $new, $addr, $shipping_type, $coupon_id, false, $isSendGift);
$priceGroup = $computedServices->getOrderPriceGroup($uid, $validCartInfo, $addr, $storeFreePostage, $isSendGift);
```
这里有个很重要的设计：
```text
确认页不是展示缓存，而是重新计算订单价格组。
```
因为用户可能在下单前做了这些动作：
```text
换了收货地址
切换了支付方式
改了购物车数量
优惠券已过门槛变化
会员等级变化
运费模板变化
```
如果你只信缓存，就会出现商品页和确认页金额不一致，甚至提交时再炸一次。
## 四、computedOrder：创建订单前还要再算一遍
订单最终创建时，`StoreOrderCreateServices::createOrder()` 还会再调用一次：
```php
$priceData = $computedServices->computedOrder($uid, $userInfo, $cartGroup, $addressId, $payType, $useIntegral, $couponId, $shippingType, $isSendGift);
```
这一步的意义很直接：
```text
确认页算的是给用户看的
创建订单算的是要真正落库的
```
这次计算里会重新处理：
```text
优惠券是否满足条件
首单优惠是否可用
积分是否可抵扣
运费是否变化
送礼附加费是否要加
```
例如优惠券不是拿了就算，`validateCoupon()` 会按商品分类、品牌、商品维度和活动叠加规则再判断一次；积分也不是看到能用就全用，而是按系统配置的上限、比例、用户可用积分重新压一遍。
这就是为什么订单创建时还要再算一次：
```php
'coupon_price' => $priceData['coupon_price'],
'pay_price' => $priceData['pay_price'],
'pay_postage' => $priceData['pay_postage'],
'deduction_price' => $priceData['deduction_price'],
'change_price' => $priceData['change_price'] ?? 0.00,
```
## 五、价格快照真正落库的位置
订单主表创建时，会把整单关键信息一次性写进去：
```php
$orderInfo = [
'uid' => $uid,
'order_id' => $this->getNewOrderId(),
'total_price' => $priceGroup['sumPrice'] ?? $priceGroup['totalPrice'],
'total_postage' => $priceData['total_postage'] ?? $priceGroup['storePostage'],
'coupon_price' => $priceData['coupon_price'],
'first_order_price' => $priceData['first_order_price'],
'promotions_price' => $priceData['promotions_price'],
'pay_price' => $priceData['pay_price'],
'pay_postage' => $priceData['pay_postage'],
'deduction_price' => $priceData['deduction_price'],
'use_integral' => $priceData['usedIntegral'],
'gain_integral' => $gainIntegral,
'level_extra_integral_level_id' => $levelIntegralMultipleLevelId,
'level_extra_integral_ratio' => $levelIntegralMultiple,
];
```
随后订单商品快照也会保存：
```php
$cartServices->setCartInfo($order['id'], $cartInfo, (int)$uid, $promotions_give['promotions'] ?? []);
```
商品快照里会记录：
```text
cart_num
total_price
pay_price
pay_postage
coupon_price
promotions_price
first_order_price
sku_unique
promotions_id
is_gift
is_support_refund
```
这一步很关键，因为后面改商品信息、改活动、改运费，订单详情页依然要按“当时那一单”的信息展示。
## 六、订单价格为什么会乱：通常是少了一个统一入口
如果你在二开时碰到订单金额不一致，优先排这几个点：
```text
1. 商品展示价和实际结算价是不是用了两套逻辑。
2. 购物车重算时有没有把地址、运费模板、会员价一起算进去。
3. 确认页有没有重新校验优惠券和积分。
4. 创建订单时有没有再次调用计算服务。
5. 落库的订单明细有没有保存价格快照。
```
最容易踩坑的地方，是把“展示价格”“确认价格”“提交价格”拆成三套逻辑写散了。CRMEB Pro 现在的思路其实很朴素：
```text
展示可以前置
结算必须统一
落库必须快照
```
## 七、二开建议
如果你要扩展订单价格，建议优先加在这些位置：
```text
StoreCartServices
购物车商品整合和活动上下文补齐。
StoreOrderComputedServices
统一计算商品总价、运费、优惠券、积分、首单优惠。
StoreOrderCreateServices
落库订单主表和订单商品快照。
StoreOrderCartInfoServices
保存和读取订单商品明细。
```
不要把规则散到 Controller、前端组件和临时 Job 里。订单是高风险链路，散开之后，最先坏的一定是金额一致性。
## 注意事项
1. 订单、支付、积分、优惠券、运费都属于高风险业务，改动前要先确认影响范围。
2. `computedOrder()` 和 `getOrderConfirmData()` 不是重复代码，而是两个不同阶段的重算入口。
3. 不要直接依赖前端传来的最终金额，后端必须重新校验。
4. 订单快照一旦入库，后续商品改价不应反向污染历史订单。
5. 价格相关字段尽量用项目现有的 `bc*` 计算方式，避免精度问题。
## 标签建议
#CRMEBPro #订单二开 #源码解析 #价格快照 #购物车 #优惠券 #积分抵扣 #运费计算 #会员价 #二开实战