本文主要分为四个部分：简单说一下购物车、购物车与后台的密切关系、购物车中商品的分组和排序、关于购物车你至少应该知道些什么。
1.先简单说一下购物车
对前台电商产品经理来说，设计一个好的购物车，整个网站的灵魂基本上就有了，“设计购物车”可绝对不是说设计购物车的外观表现形式，而是它背后的东西——购物车的逻辑。
前台购物车主要与后台商品中心、库存中心、营销中心发生关系，你品味一下这三个问题：加车的商品是什么?加车的商品还有么?加车的商品有优惠么?
关于购物车的作用，大家可以类比一下线下商场的购物车，这种类比方法我已经在上一篇中提到过了。提一下购物车最直观的几个作用：
存储用户精挑细选的商品、方便多个商品组合起来做促销;如果你看得长远一点就会发现，购物车甚至能帮助自营平台节省物流成本，把同类型商品提前归集，统一派分到同一仓库。
思考一个问题：假设A书和B书在同一个仓库，如果没有购物车，A书和B书只能分两次结算，是不是意味着会生成两个订单?分配到仓库后，仓库管理员有这个能力合单?(当然，也不是完全做不到~)
在设计前台购物车的时候有两个重要的关乎用户体验的点：购物车中商品的分组和排序，即在购物车中，哪些商品需要归为一类?商品在购物车中怎么排列?
大家需要注意一点，购物车中的计算、商品数量调整、促销活动修改、优惠券领取，甚至是商品选中等等操作，都是后台逻辑，前台只是获取服务器端的数据加以展示而已。
2.举个例子说明购物车与后台的密切关系
举个例子：比如商品数量调整，需要从服务器端check该商品是否有对应数量的库存，对应两种情况：库存充足和不足。实时check商品库存能缓解‘结算按钮’的计算压力，同时能让用户购物更流畅。
怎么理解呢?其实在处理前台商品数量增减功能时，如何判断库存的问题上，有两种处理方式：一种是实时check商品库存，一种是非实时check商品库存。
说一下后者，第二种方式是在商品加车的那一瞬间(或者刷新购物车页面)服务器端就已经告诉前台某某商品购物车可加车数量是多少了。
再举个具体的例子对比2种方式的区别，希望能帮助大家深入理解：假设A商品库存为2，用户甲将A加入购物车，并在购物车中调整A的数量，最多能调整到2;这时用户乙也将A加入购物车，并且结算了一件A。此时，我们知道现在A的实际库存只有1件了。
实时check库存：用户甲购物车只能将A数量调整为1;
非实时check库存：用户甲购物车仍然能将A的数量调整为2，然而只有当用户甲点击“去结算按钮”时，才会再去check一遍库存，这时候前台告诉用户，A商品已经不足了，您需要返回购物车调整(或者直接在弹层提示上调整A的数量)。
这就是我之前说的实时check商品库存能缓解“结算按钮”的计算压力，同时能让用户购物更流畅。所以，对于前台产品来说，你的购物车基本上没有多少与你有关系的东西。
不过，你可以从用户体验上约定一些规则，比如check库存的实现方式，如果技术说有难度会造成服务器压力，那你该怎么办呢?只能尝试说服对方，或者退而求其次在‘结算按钮’附近优化弹层提示，尽量让用户体验更流畅，这就是一个好的前台产品了，绝对不是按钮多大、怎么摆放的问题了。
这么来看，对于一个前台产品，购物车的核心就落在了购物车中商品的分组和排序逻辑上。
所以，接下来的重点内容就是：
①如何制定相关规则，让购物车中的商品有序，让用户体验更好。
②关于购物车你至少还要知道些什么?
3.购物车中商品的分组和排序
说这个分组和排序问题之前，如果大家对这个概念还不太理解，建议先去淘宝或者京东这样的电商平台看看它们的购物车，特别是产品新人。
再说一说分组和排序大概是要解决一个什么问题，可以看一看下图：
从上图的结构可以看出来，购物车中的商品是按照活动A和B以及未参加活动三个组来展示的，由此也可以看出层级关系为：(店铺 >>)活动 >> 商品(注：别忘了店铺是一级)。
基本上每个电商平台都有店铺的概念，也就是允许第三方商家来平台开店，丰富平台商品类目、sku。在这种情况下，购物车中的商品按照店铺分组无可厚非了，但是今天为了让模型更简单一点，假设平台只有一个店铺(或者是纯自营平台)，这是大前提。所以，接下来要说的就只涉及到参与同一个活动的商品分到一组这种分组的形式(建议再回头看看上图)。
然后是关于排序，我们知道给任何一组数据排序都需要给定排序规则，不然就是随机紊乱呈现的。对于购物车中的商品，能作为排序依据的无疑是它的加车时间，每个商品加入购物车都会记录一个加车时间。
接下来需要解决三个问题：
①还原商品排序和分组的逻辑判断与过程;
②新加车商品D，该放在哪儿?
③如果修改某个商品参加的活动，购物车该如何变动?(第三点是最能体现用户体验的问题。)
假设有如下表所示5个商品，该表记录了它们的商品名、加车时间以及参加哪个活动5条记录。另外，需要补充一句是：一般新加车的商品，排在购物车最上方，不然有可能导致用户打开购物车看不到自己刚加车的商品。
先解决第一个问题：还原商品排序和分组的逻辑判断与过程;
购物车的分组与排序是结构化的，程序员的思路也是结构化的，所以大家在考虑产品逻辑的时候，也要有结构化的思维(为了和猿友好相处)，一个商品加入购物车首先第一步是判断(它是哪家店铺的?)，它是哪个活动底下的?它的加车时间是什么?(从大到小的逻辑顺序)有了这个过程之后，这个商品的位置自然也确定了，如下表所示：
你可以看到商品B1加车比商品A2晚，但是却排在了商品A2之后，这是什么原因呢?
这里需要将排序问题分为三类：组与组之间排序、组内排序、组与非组(单个商品)之间排序。
先说第一类，有一个规则是组内最晚加车的商品为该组的加车时间，以组的加车时间为依据进行组与组之间排序。
再说第二类，按照组内后加车商品在上规则排序。
最后说第三类，组的加车时间与单个商品加车时间，后加车者在上规则排序，类似于第二类情况。
下面再解决第二个问题：新加车商品D(12:00加车)，该放在哪儿?
如果D没有参加任何活动，很明显按照第三类规则，需要将D置于购物车第一位，这里不用表来展示了;但是如果D参加了活动B，那么当用户进入购物车页，他将看到什么呢?如下图所示。
注意，由于商品D参加了活动B，导致商品B1和B2都跟着往上移动了。
最后再来说最重要的一个问题：如果修改某个商品参加的活动，购物车该如何变动?
说这点之前，先说为什么它很重要，第2个有关排序的问题发生场景其实不在购物车页，而是用户在进入购物车场景前，就已经发生了，用户进入购物车看到的是一个静态的页面;但是第三个问题，发生场景就在购物车中，正所谓是牵一发而动全身，试想一下，用户只是调整了一下购物车中商品所参加的活动，购物车排序大动，导致用户找不到刚调整过的商品，这种体验可想而知。
还需要说到另外一点是，这也是前文制定这样一个排序和分组规则的原因，当然也是为了解决问题3，提升用户体验。
假设商品C参加了活动A或B(一开始只是用户故意选择不参加任何活动)，那么当用户将商品C修改为参加活动A或B后，它的位置将如何变动?这里我就不再提供表格，大家去思考一下，实在不明白可以在文后提问我。
补充说明一点，为什么会有不参加活动的选项?
大家思考一下这个问题：假设平台满30包邮，不满则出6元邮费，现在商品E(单价=30元)参加了满30减5的活动，用户购买一件E，问，该用户应该参加活动么?为什么? (这个问题有一个前提是，平台计算是否满包邮的条件是以优惠后应付金额为准)
本文最重要的一部分算是讲完了，之后该讲一点其他细枝末节的东西了，关于购物车你还应该知道些什么?
4.关于购物车你至少应该知道些什么?
我觉得关于购物车你还应该知道的应该在下面这张脑图里了，第一是购物车中的商品从哪儿来到哪儿去，第二是购物车至少需要具备那几个功能点(我这里说的是骨架)，至于其他锦上添花的功能，读者可以留言分享给大家。
另外在设计购物车的时候，还有一个影响体验的细节——购物车合并问题，当一个用户在未登录状态加车，在他下次登陆账户时，应该将未登录状态已加车商品并入已登录账户购物车中。这里也有一个前提是：默认未登录状态也可以加购物车。
本篇到这里算是结束了，很多东西感觉没有说透，可能需要读者自己去深入研究，如果有什么心得体会，也欢迎大家一起交流。
作者：QJQ，微信公众号：倔牛的人生
本文由 @QJQ 原创发布。未经许可，禁止转载。
题图来自pixabay，基于CC0协议
