电商购物车缓存设计

⑴ 初识购物车的产品架构

天下熙熙皆为利来，天下攘攘皆为利往。 ——源于《史记·货殖列传》

很高兴有一个愉快的周末，因为每次我都有时间去调整和回顾一下走过的一周，应该说这一周还是很有意思的！

1、高考6月789日，一个六年前我曾经为之紧张，如今却淡然处之。当然，并不是说不是当事人，站着说话不腰疼，心态真地发生了微妙的变化；

2、工作上针对用户体验和交互设计，提出了一套初期的小程序迭代产品方案以及后期的重大功能增量式迭代，并且完整交付了产品的解决方案；

3、预研电商C端产品的最为核心功能——购物车，很激动但也不免一丝的担忧，之前确实没有对这方面有过接触，如果偏要说也就是平时网上购物时的一点渊源；

最为繁重的工作就是购物车的调研，其实难度主要集中在两点：

1、熟悉： 电商的购物车像极了商超提供的实体购物车的概念，至少初衷都是一样的，方便用户购物、优化用户的体验，最大化商业价值才是最根本的；

2、陌生： 电商的购物车是虚拟的概念，与实体的可见可得的购物车存在差异，不受时间、空间的限制，随意性增大的同时带来了人、物关系的弱化；

面对熟悉与陌生这一组矛盾，产品经理的思维能力就显得格外重要， 模块化、过程化了整个购物车结构和流程：

1、传统购物车：购物车是指超市大型自选商场中，顾客用于暂时存放所选商品的一种手推车。通常是有几层，可以存放不同的物品，有些还可以载小孩。

2、网上购物车：买家可以像在超市里购物一样，随意添加、删除商品，选购完毕后，统一下单网上商店的购物车要能过跟踪顾客所选的的商品，记录下所选商品，还要能随时更新，可以支付购买。

——网络

第一要素：用户需求驱动

第二要素：业务发展驱动

以上两点背景我就不老生常谈了，网上有各种版本，比我写地好的多，可以去参阅。看了那多的背景分析，无非就是两个关键词：用户需求、业务需要。

试用体验了主流电商的，购物车的功能都非常强大。身为一个的初涉电商行业的产品，感觉理解起来是有点吃力的。而对于一个购物车而言，MVP具备的基本功能，最小化可行产品基础结构：

1、查看商品：购物车里面的商品清单，包含简单的商品信息；

2、管理商品：对已加入的商品进行简单的管理，包括：单选、多选，变更数量，删除，结算，批量操作的功能服务；

3、支持营销：活动信息的提示，订单金额信息的显示，需要显示单价、总价、优惠、运费，跨境电商的税费等在内的金额信息；

一个简单的用户购物车的流程：

1.1 加入购物车

-> 从商品页面加入，需要选择SKU

-> 从暂存架加入，已有SKU规格

-> 批量加入购物车，针对订单的重新购买或者重新加入购物车的功能需求

1.2 管理功能

-> 查看购物车，显示商品，支持分组

-> 修改数量，增减/输入

-> 移除商品

-> 移到暂存架，可选择是否从购物车移除

-> 清空购物车

-> 清空过期商品

1.3 结算

-> 关联促销活动，获得折后价

-> 对账功能支持，计算总价；支持整体结账、组结账或自由选择若干商品一起结账；

-> 对下达订单的支持，根据当次结算的所选的产品，更新购物车的数据；

2.1关联推荐

-> 在不同的视图中，根据上下文推荐商品；

-> 推荐类型，包括：

    ~~ 根据其他顾客购买的行为、浏览和收藏等推荐

      ~~ 根据商品的交叉销售推荐

-> 根据产品的向上/向下追加销售推荐

2.2 结账功能提前

-> 积分使用

-> 优惠券

-> 礼券使用

-> 运费估算，可以选择不同类型

2.3 策略功能

-> 库存提醒，剩余件数，预警提示

-> 促销活动到期，活动倒计时

-> 促销活动生效条件，查XX可享受【满XXX减少XXX】

3.1 购物车页面

3.2 迷你购物车，作为购物车的快捷入口

问题：如果一款产品满足多档促销活动，如何解决购物车产品逻辑设计以及设图设计？

思路： 由于涉及到到多个重叠交集的问题，那么直接使用【韦恩图】的集合解决方案，将i上的问题要素模型化，通过几个模型分析：

至于上述问题如何解读，我只给出了思路并没有给出详细的解释，大家可以自由发挥哦！

如果需要帮忙，可以给我留言...

后面我将会对购物车进行详细的研究，也会不定时的与大家一起分享交流！

我是王伟

很开心和大家分享，而我想把开心一直继续！希望对大家有点帮助！

⑵ 浅谈移动端电商产品的购物车设计逻辑

先来说说购物车的起源，起初的购物车存在于线下商超的购物场景中，其主要解决的问题是提高用户购物过程的便利性和客单价，达到优化用户体验和促销的目的。而在之前电商行业是没有购物车这个概念的，主要原因有：

1、电商发展初期，SKU数量较少，而用户需求一般来讲是一个恒定量，这种情况下，较少的SKU无法起到很好地满足用户需求和带动用户需求提升的作用。

2、电商发展初期，由于对新生事物信任感的缺失，网购人数及频率较少，客单量也较少，用户倾向于立即购买。

3、电商初期无法解决合并支付带来的拆单后货款的分配问题等（主要表现在平台型电商）

随着互联网电子商务行业的发展，目前，各大电商平台都已经引入了购物车这个概念。

我们首先看下移动端电商产品中购物车的作用。

·收藏

对于用户来讲，购物车首先发挥的是收藏的作用，相对于[收藏夹]来说，购物车在收藏属性上应该是一个“弱收藏强购买属性”（购物过程中有比较强烈的购买倾向），而收藏夹则是一个“强收藏弱购买属性”（比如我看重一款鞋子，但这款鞋子没有适合我的尺码，所以我不能加入购物车（加入购物车需要填写尺码）只有收藏下来等到有合适尺码再来买）。因此，购物车展示的商品以SKU形式显示，而收藏夹以SPU显示。

·筛选

由收藏带来的筛选，对于用户来讲，在面对海量的商品资源的情况下，对意向的商品加入购物车，利于快捷的对不同商品的横向对比，提高用户购物决策的效率。

·凑单

凑单下包含两种情况，一是用户本身需求较多，需要一次性支付，提高购物效率；另一方面是一个随机性的购物需求的增加（冲动消费），这个主要是基于商品优惠活动的影响（主要指范围促销，比如满减，满赠，满返等）。

对于产品方来讲，促销是购物车的主要目的，而促销一般包括两种类型：单品促销和范围促销。

单品促销是指对单个商品的优惠促销活动，比如打折，赠品等；这种促销一般在单个商品详情页用户即可得知最终的优惠情况，购物车只是作为一个补充说明。

范围促销是指多多个商品的优惠促销活动，比如满减、满赠、满返；而这种促销一般由于门槛较高（比如满100减10，满500返100等），一方面商品单价往往不能cover所有的优惠另一方面单个商品详情页只指出优惠规则，因此在单个商品详情页用户并不能明确最终的优惠情况，需要购物车做一个合并最终得出优惠情况。

而以上两种促销的目的都是为了提高客单价，以提升销售额。

前面讲到，购物车对于用户来讲最重要的是收藏作用，因此用户放在购物车的商品就可以作为用户的“个性化数据之一”，产品可以根据该数据对用户做个性化推荐。因此，一般在购物车的下方，都会有“看了又看”“大家都在看”这样的推荐。而在此值得说的是，前者是基于用户的个性化数据做的推荐（也就是用户有收藏、加入购物车等行为）；而后者是在未掌握用户个性化数据下做的推荐，这种推荐一般来源于商品的热度（大家都在看，都收藏或加入购物车）；运营需求（商品上新；库存紧张等）。

从用户在电商平台的使用流程来看：打开App——选择意向商品——加入购物车——下单——支付——完成。那么在这一过程中，下单环节是一定需要获取用户的详细数据（姓名、收货地等），产品需要明白是哪一个用户下的单，以匹配唯一的订单。而在这前一步，也就是加入购物车环节，是否需要用户登陆后才可使用尼？

在这方面的处理上，不同产品的方法是不一样的：目前主流的电商产品中，除了天猫、淘宝将“登陆”前置的购物车之前，其他的比如京东、苏宁、亚马逊、国美等都将“登陆”后置的用户下单之前，加入购物车之后。那么很显然，后者的用户体验会更佳，因为这时候用户已经有明确且强购物意愿了（可能阿里财大气粗，非要将此环节前置到加入购物车之前）。

那么在这一环节设计上，因为购物车要匹配用户的信息实现购物车的唯一性，因此需要明白的有两点。

第一、用户在无登录状态下加入的购物车和用户登陆后的购物车是两个概念：前者是离线购物车，其匹配的用户信息是设备ID信息，设备ID信息的唯一性带来购物车的唯一性；而后者的购物车属于在线购物车，匹配的是用户的注册登录信息，注册登录信息的唯一性带来在线购物车的唯一性，因此需要用户进行登录。而考虑到用户设备的作弊、更换与丢失等风险，因此，在下单环节需要将离线购物车切换到在线购物车，以获取安全、真实的用户注册登录信息来匹配唯一的订单。（插个话，在这种情况下，如果用户使用设备ID来直接下单购买，是不是具有可行性？恳求指导..）

第二、也就是用户进入下单环节前，需要从离线购物车切换到在线购物车，这时候要同步的有两个：

1）离线购物车的商品同步到在线购物车（否则用户很懵逼）。

2）PC端在线购物车的商品同步到移动端在线购物购物车。

基于用户和产品的需求，在购物车页面的设计上，主要包括两大部分：购物车商品信息流和个性化推荐商品信息流。

由于购物车的商品以SKU形式展示，这就带来的因库存变化、价格调整及促销信息调整等带来的SKU的变化，从而会对用户购买意愿产生影响，那么这方面是怎么解决的尼？

在电商产品中，库存和购物车分别是两个单独的系统存在的。

一方面不同的SKU分布在不同的仓库（天猫或淘宝中的店铺）中，因此购物车需要从库存系统调取SKU所属的仓库信息（天猫或淘宝中的店铺）已备后续的拆单支付。

另一方面购物车中SKU的变化受到库存的影响，因此购物车中SKU需要关联到库存系统。这样以来，在电商前端有三种情况：

1）当可售库存>某个阈值X，前端显示库存充足或者不进行显示。

2）当0<可售库存<某个阈值X，前端显示库存紧张，提高用户的紧迫感和危机感，利于促进转化率的提升。

3）当可售库存=0，前端将所属商品灰置，并提示用户商品已下架。

当然以上是理想化状态，库存的变化是比较复杂的，涉及到何时锁库存以及库存类型（逻辑库存、实时库存、调配库存等）。

同样在电商产品中，促销系统和购物车分别是两个单独的系统存在的，购物车系统可以调用促销系统数据。当用户增删商品数量，商品类型，促销系统会经过计算将其满足的最大优惠反馈到前端，带来最终价格的变化；此外，对于单个商品而言，当出现价格下降时，会在前端显示“已下降XX”，进而促进用户的购买欲望，提高转化率。

⑶ 浅谈电商购物车设计

最近在做电商H5的设计，在研究购物车的时候有过那么一些思考，周末终于有时间把最近的一些看法整理一下，文中所选的竞品包括：淘宝（C2C）、京东(B2C)、网易考拉(跨境电商)和苏宁易购（B2C）、阿里巴巴（B2B），基本涵盖了目前主流的电商模式，同时这几个平台用户数量很广，能在一定程度上反应用户的使用习惯。

1、符合用户购物习惯 ，相比较一些线下的小商品，任何一个电商平台都算得上是一家“超市”了，所以用户很可能在同一个电商平台购买多个商品，如果用户每购买一个商品就支付一次，不符合用户购物习惯，对用户体验来说是一个巨大的灾难。 因此从购物的流程来说，我们需要立即购买来快速购买，减少流程（当然任性的jd一直没有），也需要加入购物车，多个商品合并支付。

2、体现订单信息，即多个商品相互影响或者单个商品数量对订单的影响。 电商平台最主要的此类信息就是 优惠信息 ，目前优惠主要有两种，一种是单品的优惠，即单个商品的降价。另一种是多品优惠，比如满减、满送、搭配优惠等。如何体现后面这些优惠类型，就需要购物车的帮助。比如网易考拉左上角的满减优惠：

诸如此类的优惠还很多，对用户来说这主要是给用户一个再思考的机会，对平台来说是关联销售。其他比如邮费等的信息也需要在购物车中体现。 当然还有很多其他非优惠的订单信息需要在购物车内就对用户进行提示，比如跨境电商的2000元限额等。这些信息是能影响购物决策的，因此不能放在订单确认页，购物车就是提示的最好地方 。

据说很多女性用户都是把购物车当做收藏功能用的，把想要的商品加入购物车，之后再在购物车里选择合适的商品组合进行结算，在这种用户场景里，购物车也是必不可少的。

对一个购物车来说，他需要实现的 基本功能 ，即一个购物车的下限应该有：

1、浏览商品信息 ，即大概的看一下我的购物车里有哪些商品，同时这一定得是去到商品详情的入口，用户点击购物车里的商品后能够重新回到商品详情，再一次决策是否结算该商品，商品信息可以比较简略，只包含关键的品名、价格和数量，当然配图的话比较直观，因为有些品名实在太长，只看品名用户还真不知道到底是什么。

2、对商品的操作 ，对商品的操作包含了：多选，变更数量，删除和结算，多选是为后面几个功能服务。

3、包括优惠在内的订单金额信息的显示 ，这主要是配合商品的操作，因为数量上的变更可能会引起优惠、价格上的变动。所以购物车需要显示包括单价、总价、优惠、运费，跨境电商的税费等在内的金额信息，方便用户进行购物决策。

上述的三个功能基本也是一个用户使用购物车的流程

作者研究了5个竞品的PC端和移动APP或H5，发现购物车的设计基本PC端和移动端差别不大，显示的信息基本相同，所做的一般就是把信息重新排布，按钮移到操作热区等一系列适应移动端特点的的变化。但也有一些不同。

淘宝和网易考拉购物车无法直接编辑数量 。京东、苏宁易购和阿里巴巴可以。淘宝和考拉都是需要点击右上标签栏中的编辑才能跳出数量的加减。

淘宝的设计比较好理解， 其商品下包含了较多的子选项 ，即一个大的商品下根据大小、颜色等的不同，可能有十多二十个具体商品，单纯在购物车内数量加减容易出错，其PC端可以进行加减操作是因为加减操作页面同时能够进行具体商品的选择， 两个选择能在一个页面的弹窗内实现 。

但对于手机淘宝来说，因为移动端屏幕大小的限制，不能把规格选择和数量选择做到同一个界面里，为了降低出错几率，手机淘宝把数量和规格都放到了“编辑”这个页面里

至于考拉为什么不能在购物车里变更数量，并没有想到很好的原因，希望能想到的人告知。

⑷ 2002-04-02是什么类型的数据,电

Copyright © 1999-2020, CSDN.NET, All Rights Reserved

打开APP

上水若善
关注
2022/08/04、05 day01-2/02：Redis数据类型 原创
2022-08-05 20:40:19

上水若善

码龄2年

关注
文章目录
今日内容
数据存储类型介绍
string
**Redis数据存储格式**
**string类型**
**string类型数据的基本操作**
**string类型数据的扩展操作**
**string类型数据操作的注意事项**
**string类型应用场景**
**key的设置约定**
hash
list
今日内容
常用的数据类型一共有一下5种：

string
hash
list
set
sorted_set
数据类型实践案例
数据存储类型介绍
业务数据的特殊性

作为缓冲使用
原始业务功能设计
秒杀
京东618活动
天猫双11活动
火车排队购票
运营平台监控到的突发高频访问数据
突发时政要闻，被强势关注围观
高频、复杂的统计数据
在线人数
投票排行榜
附加功能
系统功能优化或升级
单服务器升级集群
Session管理
Token管理
Redis数据类型（5种常用）

string
hash
list
set
sorted_set
string
Redis数据存储格式
Redis自身是一个Map，其中所有的数据都是采用key:value的形式存储
数据类型指的是存储的数据的类型，也就是value部分的类型，key部分永远都是字符串
string类型
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2NBOyzvI-1659702772759)(en-resource://database/4938:1)]

存储的数据：单个数据，最简单的数据存储类型，也是最常用的数据存储类型
存储数据的格式：一个存储空间保存一个数据
存储内容：通常使用字符串，如果字符串以整数的形式展示，可以作为数字操作使用，但其本质还是字符串
string类型数据的基本操作
添加/修改数据：set key value
添加/修改多个数据：mset key1 value1 key2 value2…
追加信息到原始信息后部（如果原始信息存在就追加，否则新建）：append key value
获取数据：get key
获取多个数据：mget key1 key2…
获取数据字符个数（字符串长度）：strlen key
删除数据：del key
(integer) 0 代表失败
(integer) 1 代表成功
string类型数据的扩展操作
业务场景
大型企业级应用中，分表操作是基本操作，使用多张表存储同类型数据，但是对应的主键id必须保证统一性，不能重复。Oracle数据库具有sequence设定，可以解决该问题，但是MySQL数据库并不具有类似的机制，那么该如何解决呢？

解决方案：

设置数值数据增加指定范围的值
incr key 如果是数值，则给value做增操作，每次增加1个单位
incrby key increment 增加指定的整数的值（可以为负数）
incrbyfloat key increment 增加指定的小数的值
设置数值数据减少指定范围的值
decr key 如果是数值，则给value做减操作，每次减少1个单位
decrby key increment 减少指定的整数的值（可以为负数）
string作为数值操作

string在redis内部存储默认就是一个字符串，当遇到增减类操作incr，decr时会转成数值型进行计算。
redis所有的操作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发带来的数据影响。
注意：按数值进行操作的数据，如果原始数据不能转成数值，或超越了redis 数值上限范围，将报错。
9223372036854775807（java中long型数据最大值，Long.MAX_VALUE）
Tips 1：

redis用于控制数据库表主键id，为数据库表主键提供生成策略，保障数据库表的主键唯一性
此方案适用于所有数据库，且支持数据库集群
业务场景

“最强女生”启动海选投票，只能通过微信投票，每个微信号每 4 小时只能投1票。
电商商家开启热门商品推荐，热门商品不能一直处于热门期，每种商品热门期维持3天，3天后自动取消热门。
新闻网站会出现热点新闻，热点新闻最大的特征是时效性，如何自动控制热点新闻的时效性。
解决方案

设置数据具有指定的生命周期
setx key seconds value 秒
例如：setex tel 10 1 当10s到达后，tel就失效为空了（没有了）
例如：set tel 2 此命令已经更新，上面的语句已经没有用了
psetex key milliseconds value 毫秒
例如：psetex tel 9999 1
Tips 2：
redis 控制数据的生命周期，通过数据是否失效控制业务行为，适用于所有具有时效性限定控制的操作

string类型数据操作的注意事项
数据操作不成功的反馈与数据正常操作之间的差异
表示运行结果是否成功
(integer) 0 -> false 失败
(integer) 1 -> true 成功
表示运行结果值
(integer) 3 -> 3 3个
(integer) 1 -> 1 1个
数据为获取到
(nil) 等同于null 不存在
数据最大存储量
512MB
数值计算最大范围（java中的long的最大值）
±9223372036854775807
string类型应用场景
业务场景

主页高频访问信息显示控制。
例如新浪微博大V主页显示粉丝数与微博数量
解决方案

在Redis中为大V用户设定用户信息，以用户主键和属性值作为key，后台设定定时刷新策略即可。
eg: user🆔3506728370:fans → 12210947
eg: user🆔3506728370:blogs → 6164
eg: user🆔3506728370:focuss → 83
例子：set user🆔00789:blogs 789
例子：set user:id00789:fans 123456789
在Redis中以json格式存储大V用户信息，定时刷新（也可以使用hash类型）
eg: user🆔3506728370 →
{“id”:3506728370,“name”:“春晚”,“fans”:12210862,“blogs”:6164, “focus”:83}
例子：set user🆔00789 {id:00789,blogs:789,fans:999}
使用这种方式： incr user🆔00789:blogs --> (integer) 790
Tips 3：
redis应用于各种结构型和非结构型高热度数据访问加速

key的设置约定
数据库中的热点数据key命名规范
* [
hash
存储的困惑

hash类型

新的存储需求：对一系列存储的数据进行编组，方便管理，典型应用存储对象信息
需要的存储结构：一个存储空间保存多个键值对数据
hash类型：底层使用哈希表结果实现数据存储
hash类型数据的基本操作

添加/修改数据
hset key field value
例子：hset user name zhangsan
例子：hset user age 38
例子：hser user weight 80
获取数据
hget key field
单查询：hget user name
hgetall key
全查询：hgetall user
删除数据
hdel key field1 [field2]
删除weight：hdel user weight
添加/修改多个数据
hmset key field1 value1 field2 value2…
例子：hmset user name zhangsanfeng weight 68 已经有的就改了，没有的就加上去了。
获取多个数据
hmget key field1 field2…
例子：hmget user name age -->纯值
获取哈希表中字段的数量
hlen key
例子：hlen user 看的是field的字段
获取哈希表中是否存在指定的字段
hexists key field
例子：hexists user age – (integer) 1 true
例子：hexists user hight – (integer) 0 false
hash类型数据扩展操作

获取哈希表中所有字段名或字段值
hkeys key
例子：hkeys user 打印field
hvals key
例子：hvals user 打印value
设置指定字段的数值数据增加指定范围的值
hincrby key field increment
例子： hincrby user age 2 value字段增加整数范围内的值
hincrbyfloat key field increment
例子：hincrbyfloat user age 1.1 value字段增加小数范围内的值
hash类型数据操作的注意事项

hash类型下的value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到对应的值为(nil)
每个hash键值对式有上限的，可以存储2^32 -1个键值对
hash类型十分贴近对象的数据存储形式，并且可以灵活添加删除对象属性，但hash设计初衷不是为了存储大量对象设计的，切记不可滥用，更不可以将hash作为对象列表使用（随着对象存储的增多，会很麻烦，效率会很低）
hgetall操作可以获取全部属性，如果内部field过多，遍历整体数据效率就会很低，有可能成为数据访问瓶颈
hash类型应用场景
业务场景
电商网站购物车设计与实现

业务分析

仅分析购物车的Redis存储模型
添加、浏览、更改数量、删除、清空
购物车于数据库间持久化同步（不讨论）
购物车于订单间的关系（不讨论）
提交购物车：读取数据生成订单
商家临时价格调整：隶属于订单级别
未登录用户购物车信息存储（不讨论）
cookie存储
解决方案

以客户id作为key,每位客户创建一个hash存储结构存储对应的购物车信息
将商品编号作为field，购买数量作为value进行存储
添加商品：最佳全新的field与value
浏览：遍历hash
更改数量：自增/自减，设置value的值
删除商品：删除field
清空：删除key
购物车实现

用户001 商品g01 g02
hmset 001 g01 100 g02 200
用户002 商品g02 g04 g05
hmset 002 g02 1 g04 7 g05 100
给001用户添加一个商品 g03 添加field
hset 001 g03 5
查看用户001的所有商品
hgetall 001
用户001 的g01商品不要了 删除field
hdel 001 g01
用户001 的 g03商品 在加10个 添加field对应的值
hincrby 001 g03 10
提问：我们当前的设计是否加速了购物车的呈现？
当前仅仅是将数据存储到了Redis中，并没有起到加速的作用，商品信息还需要二次查询数据库

⑸ 电商的购物车确认删除按钮设计的为什么不跟软件卸载的

因为功能诉求根本不一样好不啦？
软件卸载界面把确认按钮弱化，是利用了人类的“3分钟热度“现象，用户需要卸载一个软件，往往是卸载想法→卸载操作→最终卸载，如果充分的拖延操作的过程，分散用户注意力，用户有一定几率失去卸载的热度，忘却卸载的初衷，最终导致继续使用该软件（如360/金山等最初占领广大电脑小白的桌面，就是利用了电脑小白不想麻烦的心理。）
对于软件卸载而言，大部分用户的态度是模棱两可，对于这部分用户，卸载界面的弱化是一种重要的防止用户流失的做法。

⑹ 购物网站如何设计漂亮且实用的购物车

相应的，大量的购物网站也随之出现。如何设计兼顾美观与可用性的网站购物车，是一门非常有研究价值的问题。本文为读者介绍了10个优秀购物车的设计技巧，并为读者推荐了一些国外的优秀购物车设计欣赏。1. 整版车和迷你车购物车通常有两种形式，整版页面的购物车和作为网页组件的迷你购物车。建议两种形式同时包括。迷你购物车不影响购物车以外的布局，只显示购物的列表及简要信息，并且有一个醒目的链接指向整版购物车页面，下面是一个很好的例子：相反的，整版购物车页面可以提供更详细的信息，例如产品详情、删除/添加、税收和发货选项等。以下显示了一个整版购物车页面，它的右上角同时也包含了一个迷你购物车： 2. 结账：逐步引导或一页式用逐步引导的方法使用户更容易上手。看看Apple.com结帐页面，结帐程序包含四个步骤：登录，结算及托运，付款方式和最后确认/修改。 除了循序渐进的引导，另一种方式是把所有的付费、运输和结算操作放在一个页面上。 如果设计得合理，这也是一种很好的方式。下面的网站使用了良好的单页结帐过程： 3. 使用图标链接到详细页面迷你购物车上应该有链接到详细页面的醒目图标，以引导用户进入详细页面。下面这个网页虽然是日语的，但它的图标可以清晰的显示这是购物车链接。4. 使用明显的结账/添加按钮设计电子商务购物车，重要的是要包含明确的信息 ，并引导客户进入结账程序。最好使用明显的按钮，并包含清楚易懂的文字，如“添加到购物车”或“结账”。 5. 使用清晰整洁的列表设计购物车最好使用列表结构，清晰的现实信息，使用标准字体 ， 并尽量避免使用复杂的背景 。6. “继续选购”链接“继续购物”链接的作用是引导用户回到商品列表继续选购，这当然是所有网站都想要的。 7. 避免填写过多的条目尽量让用户填写最少的表格，用最快的速度完成网上购物过程。 8. 提供充分的帮助信息快速提示和通用提示是网站必不可少的组成部分，尤其是购物网站，你要让你的客户没有任何疑问和疑虑的完成购物过程。关于电子商务网站的提示技巧，请参阅： 正确使用提示文字提升用户体验9. 使用视觉辅助使用图标、箭头、文字等醒目的视觉辅助元素，引导用户的视觉流向。以下图片显示的一个极方便的单击并拖动车 。.形象的购物车图标告诉顾客，他们可以拖动物品到购物车。 10. 包含确认步骤用户必须有一个步骤来确认是不是买到了正确的货物，并且有办法及时取消选择，然后进入付款结算程序。

⑺ 现存在购物车的不足

购物车的不足有：
1、市场上的购物车缺少一个相对较小的密闭的空间去让顾客存放一些比较贵重的物品。2、购物车缺少分隔设计，因为当物品较多时，一些易碎的物品的完整性往往得不到保证。3、购物车的灵活性仍然有待改变，物品重量达到一定程度时，购物车往往就变得难以操控。4、对于残障人士这类弱势群体，购物车如何设计的方便供他们使用等。
超市购物车泛指我们在超市购物使用的购物设备的一种，是我们生活中不可或缺的工具，在进行超市购物时使用购物车，一方面可以提高买家更多的需求，另一方面更加提高了卖家的成交量，可谓一举两得的双赢结果。

⑻ 淘宝购物车的数据库怎么设计

无非两种：
一种就是把购物车里的商品存在数据库里
另一种就是用session或者cookie这种方式存储在客户端。
如果你是使用.net开发，那么可以直接把添加购物车信息的函数放到“加入购物车”按钮的事件里，如果是asp这种的，你可以做一个加入购入车动作的页面，用来处理商品加入购物车的动作。
这个页面接受商品信息和来自页面的url,处理完毕直接response回去就可以了！

⑼ 电商剖析：解密购物车逻辑

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

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

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

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

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

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

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

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

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

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

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

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

第一步首先是校验会员的登录态。上面购物车存储的结构中，我们看到购物车的存储是以用户维度进行数据存储的，所以要展示购物车的时候，首先要拿到用户的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元。

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

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