电商业务梳理

由于是测试性能，本次业务抽象介绍聚焦于订单，其它部分在强调容易出问题的点后，尽量从简。 内容适合对电商业务没有了解的读者。

用户

用户的唯一性定义往往是以手机号为准，但手机号会注销换人，一个人可有多个手机号，虚拟手机号可来回换任用，所以在业务关于用户的定义往往还辅助身份证号+银行卡号。不过业务上来讲，一个手机号往往对应一个用户。

WARNING

多账号合并成一个账号等涉及账号所有权变更的问题，尽量不要做，至多走后台申请，移除账号手机号、身份证等信息。

商品

商品需要分类，根据业务场景不同，主要有三类：实体商品（需要快递）、虚拟商品（账号/游戏货币/充值/会员）、服务商品（代办、跑腿）。 我们这里主要关注实体商品，根据商品属性分类还可以分到三级以上（服装/上衣/衬衫），还有 规格、快递费（不同目的地、不同快递商都会有差异）、参加活动（秒杀、满减、免运费等）、多SKU、赠品等逻辑。

关于库存需要重点说下，后台修改库存要走增加、减少、清零，不可直接修改库存数字，容易产生逻辑库存偏差，尤其在库存在剧烈变化中。若粗糙一点做，可设置一条规则：只有下架商品30秒后，才允许修改库存。

优惠券

优惠券种类繁多，扣钱方式主要是折扣、满减，但会有时间限制（有无）、特定商品品类、特定商品组合、特定活动等。

一般还会构建优惠券模版和优惠券自动发放系统，方便运营来分发优惠券。

储值

储值一般用储值卡来抽象，可抽象成一个品类的商品，其下单交付结果是应用户储值账户里的余额和储值流水，在用户使用储值过程中，存在锁定金额问题（待支付订单包含第三方支付+储值支付）。

积分

积分的消费存在有效期、优先抵扣（越接近有效期的优先抵扣）、积分撤回、积分冻结等业务逻辑。这里容易产生的问题是：

1. 有效积分在订单中被抵扣，订单过期，有效积分此时过期，该如何处理？
2. 若何确保扣除的积分没有被消费（下单所用的积分正好早1分钟失效）？
3. 积分的获取标志性行为被撤销后，如何扣除已消费的积分。

这三个问题代码实现难度较高，建议产品初期尽量简化处理，例如：积分永久有效。

会员

在一些电商平台中，不同会员等级对应不同的权益，例如：每月获取不同的优惠券、特定or全平台商品折扣、免运费等。

购物车

购物车核心的需要关注如何展示商品信息的变更，例如：

1. 价格上升或下降的多少钱
2. 商品名称、图片产生了变化，此时用户如何确认自己加入的商品就是先前看到的商品。

这些都可通过商品快照表来解决。

售后（退货、维修）/撤销订单申请

上面订单状态部分已讲了些，这里再补充下。 售后单/撤销订单申请单需要对接商家售后系统和库存系统，记录售后解决方案和结果，例如退货退款，不退货退款，这些会影响订单状态、财务对账、库存对账、赠品处理。

订单

订单涉及多个动态信息点，例如：

1. 商品库存，商品价格、商品参加的活动、商品下架。
2. 用户选择的优惠券。
3. 储值/积分抵扣。
4. 会员等级对应的权益对价格造成影响时，会员等级变化。
5. 交付目标（用户地址） 以上很多会对下单产生影响，下一章会讲，我们这里以订单状态梳理一遍业务流程：

订单状态

1. 失败：用户下单时，若发生库存不够、积分过期等事件，会导致订单失败，常规实现方案会先生成预订单（preOrder），扣减库存、金额确认后，再转为待支付订单。一般下单失败不会记录到订单状态里，会直接告知用户下单失败。
2. 待支付：用户尚未付款，一般会给用户保留5～30分钟的支付时间，此时订单关联的金额条件被锁定，不会触发变化，但根据业务需求，可能存在后台改价逻辑。
3. 正支付：这里以微信支付 为例，需要后台依据订单号去获取支付平台支付凭证字符串，并传递给前端调起三方支付。若支付平台允许相同订单号多次请求，则不需要记录此状态（PS: 支付凭证的字符串不建议随下单接口返回，简化下单接口逻辑）。大部分场景下该状态会被归纳到待支付中。
4. 已支付：后台通过支付平台回调或主动发起支付结果问询请求，拿到用户支付结果，根据支付平台不同，可能还会衍生出支付待确认，已支付确认两种状态。
5. 交付中：需快递商品对应快递单ID，虚拟物品（自动发货）应交付内容ID，服务对应服务单ID，以上简写为ref_id。一般情况下，交付中状态会简化至已支付，再根据是否填写 ref_id 给用户展示不同的信息，例如：需快递商品，无 ref_id 展示 已支付待发货，有 ref_id 展示 已支付发货中。另外需要注意的是：ref_id 可能为数组。
6. 完成：用户确认订单完成或用户在未定时间内确认（默认完成），根据售卖商品/服务，超时时间会有不同设定，需快递商品一般设置为2周。
7. 完成（部分退款）：一个订单包含多个商品，用户决定部分退款，且退多次，这种会关联多个售后申请单（退款）。
8. 撤销：用户反悔购买，而订单内容还未交付或可撤销时，会走撤销订单申请流程，让订单内容提供商确认撤销，供应商确认可撤销后，走退款逻辑并修改订单状态为撤销，若是供应商认为不可撤销，平台会预留渠道给用户申诉时间（可能会影响订单默认完成逻辑），由平台方审结用户的撤销订单申请或自动过期。
9. 异常：订单异常的原因很多，但常规来讲不会给客户展示（订单无异常状态），会尽量使其归为撤销、*完成（部分退款）*状态（此时的撤销订单申请异常造成方或客服发起，填写原因，后台审批，确认后由客服沟通和用户沟通，退款+相应补偿后，撤销订单）。

至于订单完成后，用户再发起退款申请，则走售后单（流程上和撤销订单申请单类似，但不影响现有订单状态）。

其它订单关联业务

用户修改配送地址

流程如撤销订单申请流程，结果可能涉及订单地址变更、总价变更（运费结算），但不会改订单状态。简单的处理方案直接告知用户撤销订单重新购买。

因为各种因素导致订单总价变更

如上述邮费变更，订单总价变更的规则会涉及部分退款、对账等一系列业务逻辑，建议不做总价变更相关的逻辑。

订单金额计算规则

以商品种类为计算单位：

sku_sum_amount =(价格*个数* 折扣)[小数取整]

order_sum_amount = max(0,sku1_sum_amount + sku2_sum_amount + ... - 满减)

不以商品为计算单位：

sku_sum_amount =(价格*个数)

order_sum_amount = max(0,((sku1_sum_amount + sku2_sum_amount)*折扣)[小数取整] - 满减)

这过程涉及小数，其取整时间点和取整规则不同会导致订单价格不同，例如：

在计算过程中，采用三位小数，向下取整，最终计算结果按照两位小数向下取整。实际举例：

在 B2B2C 平台中，用户购买3件价格为7.77商品A，7件价格为3.33的商品B，并使用7折优惠券。

商家A商品A总价：7.77*3*0.7 = 16.316 元（向下取整）

商家B商品B总价：3.33*7*0.7 = 16.317 元（向下取整）

订单总价：16.316+ 16.317 = 32.63 元（向下取整）

该方案对平台方有利：两家商家共获得32.62元，平台赚取1分钱差价。

积分

对于B2C商城，一般是在除积分外的扣减项扣减完毕后，再扣除一定比例积分。

小结

上文以订单为核心，梳理了B2C电商的通用业务逻辑，但电商关联业务很多，例如客服系统、仓储系统、通知推送（物流、积分变更、活动通知）、活动页面装修、用户行为分析等，还有一些商超+电商混合模式，都会有特别的业务流程和规则，限于篇幅，这里不做讨论。