本文主要分為四個部分：簡單說一下購物車、購物車與后臺的密切關系、購物車中商品的分組和排序、關于購物車你至少應該知道些什么。

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.關于購物車你至少應該知道些什么？

我覺得關于購物車你還應該知道的應該在下面這張腦圖里了，第一是購物車中的商品從哪兒來到哪兒去，第二是購物車至少需要具備那幾個功能點（我這里說的是骨架），至于其他錦上添花的功能，讀者可以留言分享給大家。

另外在設計購物車的時候，還有一個影響體驗的細節——購物車合并問題，當一個用戶在未登錄狀態加車，在他下次登陸賬戶時，應該將未登錄狀態已加車商品并入已登錄賬戶購物車中。這里也有一個前提是：默認未登錄狀態也可以加購物車。

本篇到這里算是結束了，很多東西感覺沒有說透，可能需要讀者自己去深入研究，如果有什么心得體會，也歡迎大家一起交流。

相關閱讀

電商入門（1）：先從線下到線上說起

電商入門 （3）：電商CMS，一勞永逸的建站方案

作者：QJQ，微信公眾號：倔牛的人生

本文由 @QJQ 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自pixabay，基于CC0協議