电商剖析:解密购物车逻辑

在电商的核心交易流程中，购物车是一其中非常重要的一环，也是其中最复杂的一个环节。在做电商流程中，可以简单的把业务领域划分成两部分，一部分是底层支撑业务模块，一部分是上层流程串流程的模块。

底层支撑的模块，比如，库存系统、会员系统。这些模块的特点是，所处理的业务流程相对单一、闭环，不需要太多依赖外部系统既可以完成领域内的逻辑。

如会员系统最重要的流程就是注册、登录、校验登录态。这几个流程基本只依赖会员系统自身，没有对外部系统产生强依赖，强耦合。

比较复杂的是串业务流程的系统，这部分系统业务逻辑会相对更复杂些，比如商详或者购物车。因为商祥或者购物车所展示给用户看到的东西需要串联非常多的业务模块，将其中的信息进行封装组合展示给用户，这里的业务逻辑非常复杂，系统内部的交互非常多。

我们以京东的购物车为例，简单的剖析一下京东的购物车大体背后的业务逻辑，实现方式。

购物车中所展示的东西，无非就是加入购物车中的商品以及一些促销信息。那么第一个问题是，这些购物车中的商品、促销信息是静态的还是动态获取的？

所谓静态就是指用户在将商品加入购物车的时候，在购物车中存储加入购物车的商品所需要展示的各种信息。例如上面展示的商品的主图文描，促销等等。

动态获取就是在查看购车的时候，再去实时调用相应的系统获取最新的信息。

答案是，购物车的数据只会存储必要的商品信息，其他的信息完全是动态获取的。

因为在加入购物车的时候如果是静态存储的，那么在下一次查看购物车的时候，所展示的信息可能就不是最准确的。这中间可能商品信息会发生变化，比如商品被下架了、商品的主图被调整了、或者主题被修改了、商品的促销信息也可能会发生变化，在加入购物车的时候可能会命中一个促销，但是过了一段时间之后，这个促销可能结束了。所以比较精准的做法是在展示购物车的时候，再去实时拉取一次商品的详细信息以及当前的最新促销信息。

但是购物车中还是会存储一部分数据，主要存储哪些数据呢？主要如下图所示。

那么下面我们来看一下，查看购物车背后到底有哪些逻辑？

第一步首先是校验会员的登录态。上面购物车存储的结构中，我们看到购物车的存储是以用户维度进行数据存储的，所以要展示购物车的时候，首先要拿到用户的ID。所以这里第一步就会校验登陆态，因为只有用户登录后才能识别当前的用户具体是谁？才可以从购物车的存储中获取响应的数据。然后购物车会根据取到的商品ID列表再去实时调用一次商品系统来获取最新的商品信息，最终组装后进行展示。

下一步是获取库存信息。库存情况由于变更比较频繁，所以每次查看购物车的时候也需要实时的去查看当前商品的库存情况。如果购物车中的商品没有库存，那么就要进行提示，如下图所示，在购物车中将此商品置灰，提示此商品“无货”。

库存这里还有一个比较特殊的逻辑，就是赠品的逻辑。赠品分为两种情况，一种是满多少元送一个赠品，简称“满赠”。另外一个是买一个东西送一个赠品，简称“买赠”。两种都是赠品，但是对于库存的逻辑处理完全不一样。

这两种情况都会要求主商品跟赠品必须要在同一个仓。不然就会出现主品从一个仓发货，赠品从另外一个仓发货。要承担两份运费的成本。本来就是赠送一个赠品，如果还需要额外承担运费的话，那么肯定不划算。所以在校验库存的时候，一定会校验主品跟赠品是否都在同一个仓有货

当赠品跟主品不在同一个仓或者赠品没货的时候。对于满赠这种场景，如果赠品没有库存，那么还是可以正常下单的。因为满赠这种促销类型会给用户进行提示“赠品数量有限，先到先得”。所以赠品没货的时候也是可以正常下单的，用户也是能接受的。但是买赠这种场景，如果赠品没有货，那么会提示用户赠品无货，不可以下单。因为这种场景用户会认为赠品是主品的一部分，没有赠品也就不会去买这个主品了。

获取完库存之后，下一步会计算购物车中商品促销的情况。这也是整个购物车中逻辑最复杂的一部分。促销本身就比较复杂，因为会存在多种促销类型，如果某个商品同时命中多个促销怎么办？如果商家设置了非常多的促销，每一次都需要拿购物车中的商品去遍历计算每个商品命中哪个促销规则，整个计算过程也非常耗时。所以购物车会将商品列表传给促销系统，促销系统根据购物车中传递过来的商品去计算，这些商品会命中哪些促销，然后将这些商品按照命中的促销进行分门别类返回给购物车。比如一个购物车中一个商家下有若干个商品。其中两个命中了a促销，另外两个命中了b促销，还有三个没有民主促销。那么要按照结构返回给购物车，购物车再展示给到用户，这样用户看的会比较清晰些。

在购物车中除了展示基本的商品信息，还有很多额外的功能，比如计算运费。上图中会显示这一个商品包邮免运费。那么运费是如何计算出来的呢？

其实在商家后台有一个叫做运费模板的东西。商家会设置运费的策略，主要分为两种规则。一种是根据单个商品去设置运费的规则，一种是根据订单维度去设置模板。

单品维度指的是某一个商家的某个商品在某些地址需要收多少钱运费。这种的应用场景是当商家发现有些商品发到偏远地区比较贵的时候，会设置这样一个单品模板。

比如某个商品发到新疆、西藏、甘肃比较贵，那么就可以设置这个商品在这三个省收学费15元，反之只要收货地址不是这三个省的，那么这个商品就不收运费。

另外一种是订单维度的模板，也就是按照订单维度来计算，整个订单收多少运费。

举个例子，比如我们经常见的江浙沪包邮。那么这个模板应该如何设计呢？首先是选好一个商家，然后选好江浙沪的地址。在这些地址设置一个规则订单，不满0元运费0元。江浙沪之外需要收10元的运费，那么再设置一下，除了江浙沪之外的省份。订单不满100元收取10元运费。这样就达到了江浙沪包邮，江浙沪之外的地区需要有门槛，达到100元不收运费，但是不足100元需要收10元运费。

购物车中每一个商家头部有一个领券的标识。来标识这个商家目前可以有优惠券可以领。这个领券设计的目的是为了让用户能够在最关键的环节知道有券可以用，从而提升购物车的转化率。那么这个功能是如何做到的呢？

在购物车中会将商品按照商家的维度分成不同的块。每一个块代表一个商家，商家里面的商品如果有促销信息，按照块的维度再去展示促销的信息。领券的计算单位是商家的维度，在购物车中首先将商品根据不同的商家计算好分块之后，每一个块都代表一个商家，购物车会去计算当前商家下面以及当前商家购物车中的商品是否有可以领用的优惠券。如果这个商家制了10个批次的优惠券，其中2个批次的券可以使用当前购物车的商品，并且用户还没有领券，那么就会在这个地方进行提示，告诉用户有可以领用的券。

购物车中还有一个叫做预估到手价。之前购物车中只展示了哪些商品可以命中哪些促销，但是每一个单品最终成交的价格需要用户自己去算一下。由于促销叠加起来比较复杂，有些用户自己也算不清楚。所以这个预估到手价就是系统根据当前叠加促销、券之后算出来的一个最终成交的价格。这个功能省去了用户自己去计算的过程，并且很直观明了的展示出来了，最终的成交价对用户提升转化也有很大的帮助。那么这个预估到手价是如何实现的呢？

首先会先去计算购物车中商品的价格。有没有单品维度的价格促销，比如，价格直降或者秒杀、拼团之类的价格优惠。也就是上图显示的“119”，这个是价格维度的计算。在计算好单品价格维度之后，会再去计算一下当前商品是否有命中订单维度的促销，比如满减或者折扣。这个时候会在单品的价格基础上再减去命中促销的价格，算出一个优惠价。然后在这个价格基础上会再去命中一次优惠券的逻辑，去看一下用户手中有哪些券可以使用。最终再去减去优惠券可以使用的价格，那么就是用户实际成交的价格，也就是一个预估到手价。

这里举一个例子，一个商品原价100块。做了一个价格直降的活动，拼团或者秒杀，价格降到90。然后这个商品还享受了一个满减的优惠，满80减20。这个时候这个单品的价格就变成了90-20=70。如果这个用户的账户中，还有一张可以用于这个商品的现金10元券。那么这个商品最终到手的价格就是70元，再减去10元的优惠券等于60元。

通过上面几个过程，系统就可以帮你算出来每一个商品在当前情况下的一个预估到手的价格。

总结下，购物车是整个电商交易流程中比较复杂的一个环节，需要串联会员、商品、库存、促销、优惠券等大部分逻辑进行最终的购物车的呈现。为了保证购物车展示给用户信息的准确性，购物车只存了最基本的一些信息，绝大部分的信息都是在用户查看购物车那一刹那实时计算出来的。