一、初接触
产品新人在初次接触电商时，会接触到一些抽象的概念，比如一级频道、二级频道、活动专题页、列表页、搜索页、详情页……
遇到这些抽象概念，有一部分人选择强行记住它们，因为电商发展已经够成熟了，学习过程中只需要按图索骥就行，其实我不建议新人回避更深入的理解电商。
二、学会找本源
产品一定需要这样一个习惯，一旦遇到不懂的问题就主动去分析它，从本源出发一步一步推导，直到找到问题答案，如果找不到本源无法逐步推导，就选择合适的案例，通过类比的方式理解问题。
究其（电商）本源，自然就找到了线下商场，初期电商的基础架构完完全全来自于线下。注意是初期电商，因为随着电商的逐步发展，出现了很多变化，比如现在电商（淘宝、京东）首页呈现的内容基本上都是推荐数据，再也不需要人工维护了，这在电商发展初期是不敢想象的。
正是因为有这些变化，我们在类比线上电商和线下商场时，某些时候可能会与现实情况不尽相同。不过，你可以尝试整理一份电商初期逐步发展到现在所经历的各个阶段的文档，从中你会发现推动电商发展的本质因素是什么？结论我可以先告诉你，一定是业务变化推动技术变革，产品（产品经理和产品本身）一定是由业务驱动的！
三、电商终究是从线下来
一个线下商场不能完完全全对应上一个电商网站，这是必然的！但我们能看到两者之间相互继承和学习的影子。电商继承于线下商场这不用多解释，线下商场学习电商的例子：目前很多线下商场也增加了换购、加价购、售后等服务台、电子屏展示广告等等一系列从线上搬到线下的东西，其中最为突出的是新零售商店。
那么，作为产品新人，该怎么类比电商和线下商场呢？
接下来的内容将从这几个方面着手，逐一展开。
- 线下商场的基础架构是怎样的？
- 电商初期基础架构是怎样的？
- 两者对比后，如何借助前者更深刻的理解后者？
四、线下商场基础构架
在说线下商场前，先从‘宏观’到‘微观’描述在商场买一只榴莲的流程：
- ①进入商场；
- ②找一辆购物车（因为买的是榴莲呐~）；
- ③找到水果专区（商场还有零食、蔬菜……专区）；
- ④找到榴莲货架；
- ⑤挑选一只榴莲；
- ⑥放入购物车；
- ⑦称量计价；
- ⑧去收银台结账（会员积分、优惠）；
- ⑨出商场。回到家如果打开榴莲发现不臭，你认为自己买到了假榴莲，于是提着榴莲又回到商场，于是有了：
- ⑩退（换）货。
从上一个例子可以看出，一个商场从商品展示的角度出发，层级关系大致是这样：商场 >> 某类商品专区 >> 某件商品货架 >> 某件商品。
其实，某件商品也有可能在某个特价专区被找到，这里涉及到优惠和活动的内容。无论在线上还是线下，优惠和活动都是不可忽视的重要营销手段，但本次不做更多描述。
然后再简单抽象一下商场购物的流程：找商品 >> 放入购物车 >> 去收银台 >> 掏钱 （>> 退换货）
有前面几个铺垫，商场的基础架构大概就出来了，如下图所示：
在上方脑图中，解释两点：
- 第一，找商品下的“逛”，指的是通过逛商场而记住了商场布局，在下次购物时，能准确快速找到自己想要的商品，先解释这个概念是为了方便之后与电商的列表页（检索）对应起来。（说明：商场布局基本上不会有大变动，主要是为了降低用户重新熟悉商场的成本）；
- 第二，拆开收银台和支付确实有必要，收银台虽然名为收银，但更多的是承担商品信息数据录入工作，进而打印出结算清单，才有之后的支付。这里，建议读者把这两个流程分开来看。
五、电商初期基础构架
在说线上电商前，同样的先从‘宏观’到‘微观’描述电商网站上买一只榴莲的流程（默认用户已登录）：
- ①打开电商网站；
- ②直接搜索或按商品分类逐步缩小范围；
- ③挑选一只榴莲；
- ④打开这只榴莲的商品详情页；
- ⑤放入购物车；
- ⑥去结算购物车中的榴莲；
- ⑦确认结算清单（确认购买的是你想要的那只榴莲）；
- ⑧支付；
- ⑨追踪物流信息；
- ⑩收货；如果打开榴莲发现不臭，你认为自己买到了假榴莲，于是去网站要求：
- ⑪退（换）货（假设榴莲也能退/换货哈~）。
从购物流程来看，线上和线下基本相似。这里必须要说一句：外表的东西看似简单，但是内在的东西确是超级复杂。比如商场库存管理（主要指盘点和上架）、商场布局、货架布局（下回去商场时，思考两个问题：你能一眼看到的商品都有哪些特征？不能一眼看到的呢？）；
再说线上，好似一个用户敲几下键盘和鼠标几秒钟就能完成一次购物，但是牵扯到复杂的后台逻辑（多库房派单拆单逻辑就能够人吃一壶），涉及到纷繁的后台系统（主要指商品、库存、结算、营销、订单、物流……），这些东西你不深入去了解，是绝对想不到它有多复杂的。
接下来直接放电商初期基础架构的脑图，这里边可能会有一些相对专业的名词出现，我不打算解释它们的定义，因为在下一部分线上线下对比时，你就能不用我说，也真正看得明白了。
在电商发展初期，上方脑图中的这些功能基本上不能再精简了，如果要按照现在电商发展的情况去绘制详细的脑图，估计14寸屏幕的电脑都不够展示。本文最终目的是建立线上线下对应关系，有这个精简的脑图已经足够。
六、线上与线下对应
先看一张图（水平对应着看，没有完全对齐请见谅。）：
线上线下对比图
关于线上线下商品展示，举个图书电商的例子助你理解：这个电商网站有一个首页（一级频道），从首页你能直接或间接到达某一具体的图书详情页，也就是说首页囊括了这个平台的所有图书，如同线下“商场”的概念一样（商场包含了该商场所有商品）；在首页一级频道下有一个专卖教材教辅类图书的二级频道，在这个频道中，汇集了该平台所有教材教辅类书籍，这就类似于商场的“某类商品专区”的概念；在二级频道教材教辅下，运营人员发现中学教材卖得最火爆，于是专门做了一个中学教材的三级频道，它包含了这个平台所有中学教材的书籍，类似于商场“某件商品货架”的概念。
接下来就不一一列举了，相信大家能通过自己的分析和思考得到相应结论。
后话：其实在对比电商和线下商场过程中，笔者漏掉了一些东西，你该怎么办呢？也许文章只是给你提供一点思路，如果想要了解更多，你至少需要亲自去研究几个电商网站和几个线下商场。
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.关于购物车你至少应该知道些什么？
我觉得关于购物车你还应该知道的应该在下面这张脑图里了，第一是购物车中的商品从哪儿来到哪儿去，第二是购物车至少需要具备那几个功能点（我这里说的是骨架），至于其他锦上添花的功能，读者可以留言分享给大家。
另外在设计购物车的时候，还有一个影响体验的细节——购物车合并问题，当一个用户在未登录状态加车，在他下次登陆账户时，应该将未登录状态已加车商品并入已登录账户购物车中。这里也有一个前提是：默认未登录状态也可以加购物车。
CMS（Content Management System），顾名思义，即内容管理系统。各大新闻网站、电商平台、个人博客等等都可以采用CMS进行建站，但是今天仅说CMS在电商领域中的应用，CMS在电商领域主要是解决一次开发，灵活运营的问题（动态配置C端页面）。
1、CMS之关于“千人千面”的猜想
京东、淘宝C端绝大部分页面也可以看成是由一个大型的CMS配置生成。在我看来CMS的核心只有两点：内容创建和内容发布，简单来说就是按照一定规则创建一条内容，然后发布到指定位置的过程。
在电商发展初期，没有用户数据积累，用户标签体系（用户画像）没有建立起来的时候，CMS相对简单，内容创建靠运营手工填入、手动发布；而在当下，像京东、淘宝这种大型电商平台，我估计CMS应该对接了素材中心（后台商品中心、营销中心、广告中心等）、大数据分析中心（用户标签体系、用户行为数据等 [会员中心]），通过CMS与素材、数据中心连接就能实现自动生成前台频道等页面，做到千人千面，让不同类型的用户看到不同内容的首页。
我从产品的角度画了一个“千人千面”大致实现流程，如果有纰漏，请读者们指正。
上文说CMS最核心的两部分是内容创建和内容发布。如上图，在这个猜想中，当决定用机器取代人工时，就必须要解决自动创建内容的问题，也即解决这两个问题：①内容选取标准是什么？（大数据分析中心）②内容从哪儿来？（素材中心）
以上仅是我的一个猜想，希望大家辩证的去看这个问题。另外，想补充一点是在绝大部分应用场景下，CMS经过二次开发之后已经不是传统意义上的CMS了（经典的CMS比如WordPress、帝国等等），大家只要记住上文说的这句话：CMS最核心的两部分是内容创建和内容发布。
下面开始进入正题，会有这么几个方面的内容：
- 从业务流程角度，看电商CMS如何动态化配置前台页面；
- 抽象出电商CMS的页面动态化配置逻辑；
- 电商网站有哪些元素可动态化配置。
补充说明下，本文不会在按钮功能操作这种颗粒度上进行分析，我想一个产品最重要的是思路和业务流程分析，功能操作只是帮助业务流程顺利流转。举个例子：在售后系统中，用户退货时，仓库管理员必须有一个‘验货’的按钮操作，当仓库管理员确定验货通过后，才会有之后的退款步骤。
2、CMS如何动态化配置前台页面
写这一部分之前，先给大家看一看电商CMS究竟在解决一个什么样的问题，看下图：
这张图看起来很抽象，但是不妨碍理解，建议去看一些电商网站帮助脑补一下。这张图里其实涵盖了很多内容，比如说楼层模板（或者叫组件，想想拼图，一个完整的图由很多组件组成，一个网站也是由很多组件拼凑而成的，CMS其实就是一个拼合组件并发布出去的工厂）。需要提醒的是大家不要被这一个案例图给局限了思维，CMS可动态化配置的内容远远不止于此，第5部分将有相关介绍。
那么，回到问题本身，利用CMS，运营想要在楼层A之前增加一个楼层C，这里面涉及到几个问题呢？
- 运营想强推的商品是什么？（不同的商品，需要突出的重点信息不一样，选择的模板也不一样）
- 运营选择什么样的模板？（有多样的模板供选择，这里自然牵扯出了CMS中有一个模板库的概念，模板越多运营起来越灵活）
- 运营如何把数据录入模板当中？
- 运营如何将创建好的内容发布到前台网站？（中间一般还需要分多重角色，运营专员负责数据录入，审核专员负责审核发布，这里会牵扯到数据权限的一些概念，不多说了，电商后台数据操作权限界定，是非常重要的一个点，三言两语说不清楚，大家感兴趣可以自行去了解一下）。
从这四个问题中可以抽象出这么一个工作流程：选择模板》数据录入（》内容审核）》内容发布
关于内容发布先多说一点，内容发布有一个点是将内容发布到哪儿？可以是同一个端（PC、APP、H5端等）的不同页面（涉及到模板复用的概念，这可以帮助运营减轻很多工作量）；也可以是不同端，比如我在APP上用了一个模板，能不能直接复用到H5上去呢？在初创公司里，更多的应该去考虑这些问题，因为初创公司就没有太多的运营团队，不同端分开运营成本太高了。这种方案默认一个楼层只有一个模板，因此而忽略了位置这个概念（因为在这里位置 = 楼层）。当然，还需要设置模板的顺序（一般用阿拉伯数字大小排序），这个顺序决定了它在前台展示在第几个楼层。
淘宝店铺装修（它是一个典型的电商CMS）就强调了位置这个概念，可以看看下图红框强调的部分：
看得出有这几个概念：页面总宽度、容器宽度（位置）、页面总宽度 = 容器宽度1 + 容器宽度2 + ……
之后的内容就统一按照方案1的模式，默认一个楼层一个模板描述。另外，大家感兴趣可以注册一个淘宝店铺，如果你是初创电商公司，在淘宝店铺CMS的基础上做减法就够了（模块拖拽的方式也可以暂时绕过）。
3、电商CMS页面的动态化配置逻辑
第3部分实际上已经抽象出了电商CMS的业务流程：选择模板》数据录入（》内容审核）》内容发布
用电商首页来举例，一个电商首页的构成大致如下图所示：
整站分类列表在我看来是一个挂件，它一般悬浮在轮播图上方（页面左侧）。我们绕过这些写死的页头、页尾以及挂件一般的分类列表，现在只说楼层这一部分。接下来，假设把首页简化成是由多个楼层构成，首页动态化配置逻辑大致如下所示：
需要多说一点的是，由首页配置的模式可以推及更多页面的配置模式，套路都是一样的。从上图也可以看出来，关于CMS，一直没有脱离上文说的：CMS最核心的两部分是内容创建和内容发布。
在第1部分，也提到CMS在电商领域主要是解决一次开发，灵活运营的问题，到这里相信大家也可以看出来了，利用CMS搭建一个电商网站的好处是运营不需要因为想新发布一个营销页面来争取开发资源，而开发只需要不断的造模板去满足运营需求，至于产品呢？产品就需要考虑电商网站的灵活性问题，怎么最大化让所有位置都成为可配置？这可能是产品经理需要考虑的产品迭代方向。（当然，创新营销玩法也是电商产品需要不断思考的问题。）
那么，怎么最大化让所有位置（场景）都成为动态化配置的呢？
4、CMS可配置的电商网站元素
第4部分最后一个问题，其实应该改成如果CMS是一个C端页面展现的最终输出口，那么应该控制哪些元素的输出？举个例子，商品详情页有一个商品参数，先看看下图（其实用3C举例更好些哈，大家研究的时候，去研究3C吧~）：
鞋这个分类的商品可能有多个商品参数（导致需要折叠），那么优先展示哪些参数呢？另外，后台对于鞋的描述可能字段（参数）更多，那么哪些字段（参数）可以输出呢？不同分类的商品展示字段也不一样，是不是需要分类进行配置展示呢？
以上的例子，也归属于CMS动态化配置的范畴，这和用户体验相关啊，试想产品设计时，把这个商品有关的全部字段都吐出来，用户不会懵圈么？
举这个例子只是为了说明一下，CMS的动态化配置不仅仅只是局限于频道页（特别是首页）以及活动专题页这些。
本来想在这一部分画一个脑图，苦思之后发现还是脱离不了第4部分，首页构成那种形式，所以也就不画了得了，第5部分也就写到这里。
如果，大家还有什么疑问或者想要我系统补充的，欢迎大家留言我，也欢迎大家和我一起交流。
电商靠运营，运营靠多样化的模板库，CMS看来是电商平台不可或缺的系统了。
之前抽出时间体验了一下搜狗云表情APP，这是一款工具型APP。先说说为什么会把它列入到电商入门的系列里面呢？因为之前有说过，如果有机会，我要说一说电商里面的另一个灵魂——搜索，现在积蓄还不够，所以会抽出时间去研究一下其他具备搜索功能的APP，希望能逐步提炼出一些自己的东西，以后才有可能写出电商领域的搜索。（ps：如果把云表情的单个表情比作电商的一个sku，你可能会对我的意图理解得更深刻些~）
通过体验云表情APP的搜索功能，我希望从APP端展现出来的规律和现象，猜测目前云表情搜索功能的后台逻辑，进而假设如果是自己负责云表情搜索功能，会怎样去优化搜索。
所以本文的大概框架和思路是：现象 → 猜测 → 优化，一共写了4个case：分类及元素归属、关键词匹配效率、语义分析以及标签体系。
注：下文元素指一个表情（jpg、gif、……）
Case1：分类及元素归属
现象：
- 输入任意不同关键词，转搜索结果页，可见结果列表分暴漫、视频截屏、卡通形象、纯文字4类聚合展示全部匹配元素；
- 切换分类，比如从暴漫切换到视频截屏，各类中所包含的元素不重复。
猜测如下：
- 没有前、后台分类的区分，前台分类即为后台分类，也就是说云表情后台只有：暴漫、视频截屏、卡通形象、纯文字4个分类；
- 每一个元素只能归属于一个后台分类，进而导致每一个元素只能归属于一个前台分类。
优化：
后台分类是用来管理素材的，一般枝叶较密；前台分类是方便用户筛选的，一般枝叶稀疏，两者用途不一样。从可扩展性角度出发（素材增多），前、后台分类一致不利于日后类目扩展以及应对素材急剧增加带来的问题。
- 建立前台分类和后台分类；
- 一个前台分类可对应多个后台分类；
- 每一个元素仅可挂在一个后台分类上，但在前台展示时，可能出现在多个前台分类中。
Case2：关键词匹配效率
现象：
分别输入“快乐”、“快乐宝”、“快乐拉”和“宝拉”4个关键词（由表情包“快乐宝拉”拆分得来）：
- “快乐”和“快乐宝”可搜索得到“快乐宝拉”表情包，“快乐拉”和“宝拉”无表情包展示，但在结果列表中有“快乐宝拉”相关元素展示；
- 搜索“快乐拉”关键词，在结果列表中包含“快乐”、“快乐宝拉”和“拉”3者元素之并集。
猜测如下：
- 依据关键词优先查询表情包库，若无匹配表情包（名称），则仅在结果列表中展示全部与（已拆分）关键词匹配的元素；
- 表情包搜索不支持表情包（名称）中间空缺（如快乐*拉这样），但支持尾部空缺（如快乐宝*这样）[注：但某些关键词，如“快乐”，却能匹配出“我超快乐”表情包]；
- 按关键词搜索元素时，结果列表包含该关键词所有被拆分的有效（包括模糊匹配）关键词包含元素之并集。
优化：
- 优化搜索关键词与表情包（名称）匹配效率，如“宝拉”和“快乐*拉”能匹配出“快乐宝拉”表情包；
- 优化结果列表（即有效（包括模糊匹配）关键词包含元素之并集）排序，如优化搜索“快乐拉”关键词的结果展示列表。
Case3：语义分析
现象：
- 分别输入“开心”、“快乐”和“高兴”3个同义词，转搜索结果页：
- 关键词“开心”对应结果页，匹配出了“不开心”表情包；
- 各关键词对应结果列表页中元素有交集（比例很高）。
猜测如下：
- 尚未做语义分析功能；
- 假设第一条成立，那么同义词搜索对应结果呈现出高相似度的现象，可以说明一个元素可能对应多个标签，比如结果中相同元素均具备“开心”、“快乐”和“高兴”三个标签，所以不论搜索“开心”、“快乐”还是“高兴”，它们都能出现在结果列表中。
优化：
优化语义分析功能，至少在搜索结果中不能出现自相矛盾的元素，比如搜索“开心”，结果中出现“不开心”元素。
Case4：标签体系
现象：
- 输入关键词“开心”，转搜索结果页：
- 开心❤表情包中部分表情，并未展现在下方结果列表中。
猜测如下：
- 每一个元素都存在一个或多个关键词（标签），同一个表情包可以收录具备不同标签的元素（通过其他案例发现同一个元素可以被不同表情包收录）；
- 补充：通过以上case2其实还可以猜测：后台可能没有从表情包的维度去维护标签（对表情包来说，可能仅仅只维护了一个表情包名称）。
优化：
- 一个表情包代表同类型元素的合集，它们一般具有相似的属性（标签），后台可以在表情包的维度维护标签，表情包下所有元素继承表情包的标签，这样可以解决当搜索“开心”时，“开心❤”表情包中所有元素也会陈列在下方结果列表中。
- 后台建立完善的表情包体系，因为在元素日益增多时，元素分门别类以表情包这个维度聚合必然是未来的发展方向。
权限系统其实不只是应用于电商领域，各个领域都有可能用到。一旦公司系统做大，系统使用者的类型越来越丰富，权限系统就必不可少了。也就是说，小公司可能会没有权限系统，一般用一个admin账号供所有成员使用。这里需要注意，我说的使用者类型越来越丰富，导致权限系统必可不少。很简单，假设一个系统只有一类使用者，这一类人必然有相同的使用权限，那就无所谓有没有权限系统了。
如果抽象一下，你可以看到：使用者 – 某一类使用者– 权限，如果某一类使用者唯一，我可以直接抽象为：使用者– 权限。这算是提前剧透，权限系统的经典模型：RBAC模型，即用户– 角色– 权限。上文就是将用户这个维度向上抽象出角色，某一类使用者对应一种角色。
看权限两个字，可以通俗的理解为权力限制，即不同的人由于拥有不同权力，他所看到的、能使用的可能不一样。对应到一个应用系统，其实就是一个用户可能拥有不同的数据权限（看到的）和操作权限（使用的）。或者大家可以把权限看成资源获取权，B/S结构里，你通过浏览器有没有向服务器请求某项资源的权力。
很多公司喜欢做用户白名单这种事，其实道理和权限系统一致，给白名单用户开方便之门，让他们访问非白名单用户访问不到的资源。总结来说就是，我需要通过权限决定谁可以访问我的资源。
另外，现在大部分文章没有把数据权限和操作权限说明白，我会试图在本文中讲明白这个问题。
更多的铺垫就不说了，全文将会以这个节奏进行：
- 权限系统的背景，从这一部分你会知道为什么需要诞生权限系统。
- 权限系统经典模型，这一部分我会简单介绍一下RBAC模型。
- 操作和数据权限，在这一部分，我会把大部分文章没有讲清楚的数据权限和操作权限讲明白。
- 权限系统实操，在这一部分我会简单说下做一个权限系统的底层逻辑，让你很快能”复制”一个权限系统。
二、权限系统的背景
为什么会有权限系统？或者换个说法，为什么需要权限系统？
正如前文说的，某些小公司不需要权限系统，原因也提到了使用者类型唯一，那么，是不是说当我使用者类型丰富的时候，我就需要考虑权限问题了呢？答案是肯定的！
权限系统起源是提供企业级应用软件解决方案的公司，如SAP、PeopleSoft等，也是这类公司最早开始探索高内聚低耦合系统。
举个可能不恰当的例子：当客户只想要WMS的时候，你说OMS和WMS不可分割，想买WMS就必须买OMS，显然是不合理的。
这和权限系统有什么关系呢？
OMS和WMS，一个是订单管理系统，一个是仓库管理系统。假设OMS的使用者是公司客服，WMS的使用者是公司仓库管理员。这里出现了两个系统，两类使用者，客服应该看到并使用WMS么？
最早的一批提供企业级应用软件服务的公司，也面临着同样的问题，随着客户公司的业务拓展，首先是客户公司对各子系统的需求量增大，可能不仅仅只需要一个HRMS，其次是对系统的使用安全、保密性，系统操作人员的权责关系界定上越来越严格，最后是B/S结构出现后带来的便捷性（需要注意的是这一点并不是初期探索权限系统的原因）。
关于这一点简单画了一个图来说明，如下：
从图中可以看出来，所有资源都统一存放在一处，当用户需要请求资源的时候，先经过资源表判断该用户是否有对应权限，如果有则返回结果。
没有B/S结构，一个软件服务公司可能需要为客户组装各种本地化的系统（如sys1和sys2打一个包，sys1单独打一个包，……），这就是B/S结构带来的便捷性，而权限系统在这中间起了至关重要的作用。
三、权限系统经典模型
需要先说明一点，在权限系统文章里强调RBAC模型，只是为了让大家对这个经典模型重视起来，再强调一下RBAC模型的基本结构：用户- 角色- 权限，却不仅限于此，更多细节需要大家亲自去摸索。
RBAC模型可以分为：RBAC 0、RBAC 1、RBAC 2、RBAC 3 四个阶段，一般公司使用RBAC0的模型就可以。另外，RBAC 0相当于底层逻辑，后三者都是在RBAC 0模型上的拔高。
我先简单介绍下这四个RBAC模型：
RBAC 0模型：用户和角色、角色和权限多对多关系。
简单来说就是一个用户拥有多个角色，一个角色可以被多个用户拥有，这是用户和角色的多对多关系；同样的，角色和权限也是如此。
RBAC 0模型如下图：没有画太多线，但是已经能够看出多对多关系。
RBAC 1模型：相对于RBAC 0模型，增加了角色分级的逻辑，类似于树形结构，下一节点继承上一节点的所有权限，如role1根节点下有role1.1和role1.2两个子节点。
角色分级的逻辑可以有效的规范角色创建（主要得益于权限继承逻辑），我之前做过BD工具（类CRM），BD之间就有分级（经理、主管、专员），如果采用RBAC 0模型做权限系统，我可能需要为经理、主管、专员分别创建一个角色（角色之间权限无继承性），极有可能出现一个问题，由于权限配置错误，主管拥有经理都没有权限。
而RBAC 1模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持针对性删减主管权限。
RBAC 1模型如下图：多对多关系仍旧没有改变，只增加角色分级逻辑。
RBAC 2模型：基于RBAC 0模型，对角色增加了更多约束条件。
如角色互斥，比较经典的案例是财务系统中出纳不得兼管稽核，那么在赋予财务系统操作人员角色时，同一个操作员不能同时拥有出纳和稽核两个角色。
如角色数量限制，例如：一个角色专门为公司CEO创建的，最后发现公司有10个人拥有CEO角色，一个公司有10个CEO？
这就是对角色数量的限制，它指的是有多少用户能拥有这个角色。
RBAC 2 模型主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。
RBAC 3模型：同样是基于RBAC0模型，但是综合了RBAC 1和RBAC 2的所有特点。这里就不在多描述，读者返回去看RBAC 1和RBAC 2模型的描述即可。
四、操作和数据权限
写在之前，这一部分，我主要是讲自己的理解，读者们需要辩证的去看这一部分。
用户在使用操作系统时能进行的增删改查我都归为操作权限，有很多人将增删改归为数据权限，因为这是在更改数据库某张表里的记录，必然是数据权限，真的是这样么？例如：商品中心里新增加一个商品，这到底是操作权限还是数据权限？
在我看来，凡是在操作系统中的任何动作、交互以及结果都是操作权限。那么，我说的数据权限是什么呢？
上文提到过我做的BD工具，再用这个例子：
先简单介绍我们的业务模式：BD专员负责拓展客户，BD主管直接管理推动专员作业，主管上级是经理，经理负责组织管理主管作业，这条业务线基本上如下图：
从上图很容易能看出来我说的数据权限是什么了，如果以客户作为最小数据单元往上看，你会发现：客户2.1.1和客户2.1.2只属于专员2.1，只属于主管2，再往上就是经理。
这个属于关系换另外一句话就是：我的客户只有我和我的直属上级以及直属上级的领导能看到，这也就是我说的数据权限。为什么这么说呢？
我们在作业过程中，销售数据是客户这个最小单元产生的，没有客户就没有销售数据，那么我的客户产生的销售数据谁可见呢？
这就是我说的数据权限。
简单说下，在实现数据权限时至少有两种方式：
- 一种上文提到了，利用RBAC 1模型，角色分级来实现，我们需要的就是角色分级带来的角色树，利用树形结构去控制数据输出。
- 另外一种方式，也就是我的实现方式，雷同于RBAC 1模型的角色树，我利用HRMS中的人事组织架构来实现数据输出，也即是打通HRMS系统和对应需要数据权限控制的系统，当涉及到数据输出时，会调用HRMS系统中的组织结构树，从而确定数据输出范围。当然我们在开发过程中，也可以直接把组织结构树置于权限系统之中，这种方式适用于组织架构相对固化的组织（如国企），但一般不建议这样做，系统的灵活配置、高可拓展性是开发想要的，也是产品需要考虑的。
这就是我理解的操作权限和数据权限，再次希望大家辩证的去看，自己多思考。
五、权限系统实操
到这一部分，我相信绝大部分产品同学已经有自己对权限系统的认知了，特别是看到RBAC模型后，做一个简单的权限系统应该没任何问题。
我说的实操的底层逻辑其实也是基于RBAC模型，再次强调下RBAC模型：用户– 角色– 权限。
那么，一个简单的权限系统应该具备哪几块呢？
首先考虑一个问题，用户从哪儿来？
很多权限系统直接在权限系统内创建一个用户，也可以打通HRMS系统，员工即用户，省去专门创建用户的一步。我想说的是后者，即打通HRMS系统。多说一句，这种设计一般需要在员工入职的时候为其选择相应角色。
用户已经有了，在这个前提下，就可以考虑其他问题了。
在RBAC模型下，给这样一个场景，创建一个角色，并为这个角色赋予相应权限，最后将角色赋予用户。那么，这个用户就拥有了该角色所拥有的权限。
抽象一下这个问题：开始》创建角色》为角色赋予权限》添加用户（调用HRMS）》将角色赋予用户》结束。
底层逻辑已经抽象出来了，那么该如何设计呢？
- 第一步，需要角色管理列表，在角色管理列表能快速创建一个角色；
- 第二步，角色管列表中能跳转至为角色配置权限的页面，也就是说有一个权限配置页；
- 第三步，需要有用户管理列表，在用户管理列表能快速添加一个用户，添加用户的这一页至少有让用户关联角色的功能。
简单来说权限系统设计至少有这三步，这样就完成了之前场景预定的全部内容，即：创建一个角色，并为这个角色赋予相应权限，最后将角色赋予用户。