1. 移動電商APP，購物車和立即購買，到底應該重點突出哪個
立即購買:減少操作步驟，選擇商品立即跳轉到訂單頁面完成購買。購買一些一次性購買的即時產品，如機票、住宿、電影票非常合適。
購物車:一次購買多個商品。選擇一個項目後，您可以繼續購買其他項目。但是當用戶明顯需要購買產品時，增加了用戶的操作步驟。與此同時，更容易開展諸如滿減、滿送、免運費等營銷活動。
結論
根據情況，如果電商app沒有幾個SKU(如微商)，你當然只選立即購買，根本不用考慮購物車；但是，像淘寶天貓這樣的電子商務網站的購物車的點擊率要比立即購買高得多，所以此電商平台的購物車的優先順序必須高於直接購買。
2. 為什麼說用session對象來表示電子商務中的購物車
一般來說購物車信息是存放在Session中的, 因為Session 便於管理. Session 不是在用戶的電腦里的, 它是一次會話, 所以是暫存在伺服器上的.(是否是在JVM中我不敢肯定, 好像實例化出來的對象和數據都是存放在JVM, 僅供參考)
Session 的性能不用擔心, 因為是伺服器和一個客戶端之間的會話, 而且購物車中的內容不會太多, 所以不會影響到伺服器的性能.
用Session做購物車有一點不好, 除非你Session有效期設置的很長, 否則的話, 用戶在操作過程中, 一旦Session 超時, 購物車中的東西就會全部丟失.
提供者：高山流水
網路空間：http://hi..com/ww715519816/home
如有其它問題可以到空間留言咨詢，或者網路知道直接提問。
3. 完成電子商務網站後台資料庫的建立，和相關表格，查詢，存儲過程等的建立.
我覺得你這個不應該放在上面~~~放在豬八戒上面比較合適
4. 淺談移動端電商產品的購物車設計邏輯
先來說說購物車的起源，起初的購物車存在於線下商超的購物場景中，其主要解決的問題是提高用戶購物過程的便利性和客單價，達到優化用戶體驗和促銷的目的。而在之前電商行業是沒有購物車這個概念的，主要原因有：
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」，進而促進用戶的購買慾望，提高轉化率。
5. 電商網站應該如何建設，不知道怎麼做
網站的總體分析與設計(重點分析電子商務)
首先分析購物系統的組成結構，前提是該購物車系統基於ASP+MYSQL(或者PHP+SOLSEVER 或者ASP。NET等)結構，也就是說，使用MYSOL資料庫存儲有關數據，使用ASP訪問資料庫(可以訪問本地，也可以遠程訪問)，進行產品列表顯示增加刪除修改等操作。
設計的功能模塊的流程是：客戶端瀏覽器送出HTTP訪問請求，WWW伺服器收到請求後，判斷是否需要向資料庫查詢，如果需要，生成SQL查詢指令，並送到資料庫伺服器中。
這部分功能主要由ASP程序實現，資料庫伺服器收到相應埠送來的查詢請求以後，進行資料庫表的操作，以表單形式向查詢者返回查詢結果。
最後，WWW伺服器收到查詢結果，使用其中的數據生成標準的HTML頁面，並將HTML代碼返回給原訪問者，這部分功能同樣由ASP編程實現。
通過上面電子購物系統功能的分析，網站主要由如下功能模塊組成：
1、前台網上銷售模塊。所謂前台銷售模塊，就是指客戶在瀏覽器中所看到的直接與客戶面對面的銷售程序，包括瀏覽商品、在線注冊、訂購商品、查詢訂購、購物車等功能。也就是說客戶面對瀏覽器時所看到的網頁的基本內容使客戶更加直接、快捷的瀏覽網頁以節省客戶的時間並且能全面的了解所需要的商品，使其能得到詳細的信息。
2、用戶注冊功能與用戶登錄功能。當用戶進入我們的電子商務網站時不一定立即就要購買我們的產品，但是可以先注冊，任何時候都可以來買我們的產品。用戶先注冊的好處在於用戶購買完我們的產品後無需要再輸入一大堆個人信息，只須將帳號和密碼輸入登錄就可以了。
3、後台數據錄入模塊。是在前台銷售商品所有數據，(就是我們所看見的產品的詳細信息例如：價格、名稱、葯效等信息)，其來源都是後台所錄入的數據。(存放在資料庫中)
4、後台數據處理功能模塊。所謂後台數據處理，是相對於前台網上銷售模塊而言，網上銷售的數據，都放在銷售資料庫中，對於這部分的數據進行處理，是後台數據處理模塊的功能。(就是說把客戶填寫的所有數據、購買的產品數量等都存放在資料庫中進行處理)
5、訂單號模塊。所謂訂單號模塊，就是客戶購買完商品後，系統自動分配一個購物號碼給客戶，可以方便客戶隨時查詢帳單處理情況，了解現在貨物的狀態，真正做到處處為顧客著想
二、詳細設計
電子商務網站基本是由動態網頁構成的，則動態網頁就是一個可以訪問資料庫的網頁。在建立資料庫網頁前，要建立一個資料庫。在建立資料庫時，還要根據項目的具體要求設計資料庫的結構。
也就是說動態網頁是一種互動式網頁，所有的互動式網頁都來自靜態網頁，也就是我們在瀏覽器中所看到是靜態的網頁，這個靜態網頁包括網站Logo標志 Banner廣告條、友情連接links、版權(right)靜態文字、圖片、FLASH動畫、超級連接、按鈕以及表單等。
在靜態網頁中加入ASP、JSP、PHP 等代碼或通過使用其它動態網頁技術訪問資料庫，將資料庫中的數據顯示在網頁中，或將網頁中的數據記錄到資料庫中。
對於網上購物系統的資料庫是比較龐大的，在設計的時候需要要從使用的功能模塊入手，可以分別創建不同的數據表，命名的時候也要與使用的功能相配合，方便後面相關頁面製作時的調用。
1、建立的資料庫
1)商品表，存儲商品的相關信息
2)商品類別表，是把商品進行分類後的一級列表，這個可以給據咱們公司的實際情況來展示的商品種類，在數據表中加入商品的類別。例如：流感錄入資料庫類別表
3)商品的子類類別表，是把商品進行分類後的二級類別例如：流感的症狀有傷風、頭疼錄入資料庫子類表。
4)訂單表是存儲網上用戶訂購商品的相關信息表，例如，用戶名、訂單日期、聯系電話、電子郵件等錄入訂單表。
5)訂單商品表是記錄用戶在網上訂購的商品信息表，用於用戶在線查詢訂單。主要設計"訂單商品號"、"訂單號"、"商品號"、"訂購數量"
6)用戶表是存儲注冊用戶的數據表，設計了用戶編號、用戶名、密碼、電話、住址等欄位名稱。
對於網上購物系統的資料庫設計並不是一成不變的，是可根據公司的具體要求來增加或者減少數據表。
2、購物系統
1)購物車系統
電子商務網站的關鍵技術之一就是購物車系統的設計與實現，購物車系統還有一些其它稱呼如：網上購物系統、網路購物系統、網上開店系統等，實質上都是一樣，就是程序結合資料庫開發的網站系統;
購物車系統的使用者是做網上銷售的商家，不需要懂任何網路知識，只要使用了購物車系統可以輕松建立一個功能強大的網上商城，實現用戶注冊、產品展示、在線定購、在線支付等電子商務功能計;一般的購物車系統集成了產品發布與查詢、會員注冊登錄、購物車、在線訂單、在線支付、在線交流等完善的網上銷售功能，最主要的是管理員只需要登錄網站後台管理就可以在線發布商品、處理訂單等。
商務網站的購物車系統功能之中，應首先包含用戶登陸界面，用戶進行登錄後，可以完成查看產品類型，查看購物車內容、訂購產品、顯示訂購單及刪除指定定單等相應功能，若成功訂購，還可以按照網頁指示用銀行劃撥或信用卡方式進行支付。
首先用戶在登陸頁面中登陸網站，進入顯示產品信息的網頁，在該網頁中，設有"產品類型"、"查看購物車"、"顯示訂購單"等超級鏈接。此時若要購物，便可在相關產品後面的表單中輸入購買數量，將其放入購物車。
若用戶點擊"查看購物車"的超級鏈接。下方框架將會顯示購物車內的產品情況，此時還可進行產品刪除的操作。
若用戶點擊"顯示訂購單"超級鏈接，下方框架將會顯示訂購單網頁，用戶在對訂單細目核對後，便可進行訂購了。
2)注冊系統
當用戶進入瀏覽頁面時，點擊有超級鏈接的"注冊"按鈕，進入注冊系統的主頁面。這個頁面需要用戶填寫用戶名、密碼、確認密碼、電子郵件等個人信息，這些都需要網站設計者根據實際情況編寫。當用戶填寫准確無誤時，然後"單擊"提交按鈕，就可以將用戶輸入的注冊資料提交到伺服器之前，就會對這些資料進行驗證，檢驗瀏覽者在輸入的內容是否滿足資料庫表中的欄位要求，如果符合，就被錄入資料庫中，建立起用戶檔案。如果不符合，讓用戶從新填寫用戶填寫或用戶自身填寫不正確需要從新填寫時，單擊"重置"按鈕。
為了方便瀏覽者知道自己是否注冊成功，如果注冊成功，會跳轉出注冊成功的頁面。如果用戶注冊信息不正確或用戶名已經存在，則會跳轉處注冊失敗的頁面，並設置"單擊這里重新注冊"的超級鏈接。
3)登錄系統包括登錄、新用戶注冊、忘記密碼
一般來對於登錄系統來說，是在用戶已經注冊完以後，用戶再次瀏覽咱們網站，或者購買咱們商品等情況。
在用戶登錄系統時，登錄成功時，會進入登入成功頁面來提示用戶。用戶登錄後可能修改個人的注冊信息，單擊"修改資料"進入修改頁面。
當用戶登錄失敗時，用戶可能記錯密碼或忘記密碼，用戶可以單擊"忘記密碼"讓系統幫助用戶尋找密碼。
(在用戶注冊時要求用戶提供的電子郵箱，然後利用電子郵箱來幫助用戶找回遺失的密碼。這時也會進入幫助用戶找回密碼的網頁。如，lostpassword。asp頁面中輸入用戶名，並單擊"提交"按鈕後，會根據用戶名從資料庫中找到對應的記錄，然後反饋給用戶。)
4)商品搜索
在首頁中有一個商品搜索功能，輸入要搜索的商品，單擊"搜索"按鈕後打開的頁面就是這個商品搜索結果頁面。該頁面的功能是由搜索頁傳過來的欄位搜索資料庫中的數據並顯示該商品。為了方便購物，在找到的顯示商品中還設置商品的名稱、報價、在架狀態，同時可以加入購物車功能，使客戶能更加的了解我們的產品，做到一目瞭然的效果。
5)商品結算功能頁面的基本設計
購物車最實用的就是如何進行上商品的結算，通過這個功能用戶在選擇了自己喜歡的商品後可以通過網路確認所需要的商品，輸入聯系方式，提交後寫入資料庫，方便企業進行售後的服務，即送貨收錢等工作。當用戶瀏覽商品，看見比較滿意的商品時，會單擊【放入購物車】按鈕後，購物車頁面會顯示用戶購買的數量。同時也設置了【清空】按鈕，是通過這個命令清空購物車中的數據統計。當用戶單擊【結算】按鈕，打開訂單用戶信息確認頁面，該頁面主要顯示選擇的購物商品數量、訂購的商品、單價、總價等還要填寫送貨信息，例如真實姓名、住址、電話、電子郵件等詳細的送貨信息。填寫完收貨人後，單擊【確認收貨人信息】，彈出剛收貨人填寫的信息，選擇的送貨方式單擊【確認送貨方式】，選擇付款方式例如，網上支付、網上銀行、支付寶、貨到付款等付款方式。單擊【確認付款】，跳轉到用戶填寫所有信息的頁面，用戶瀏覽後，確認無誤後，單擊【確認訂單】按鈕，結束購物。結算完成，顧客可以【繼續購物】或者【退出登錄】。
6)用戶訂單查詢
用戶在購物時還想知道自己最近一段時間一共購買了多少產品，單擊導航上的【訂單查詢】命令，打開查詢頁面在查詢文本域中輸入客戶的訂單編號或者商品名稱，方便與企業的溝通。單擊【查詢】按鈕彈出的查詢結果頁面。
7)後台系統
商務實用型網站擁有者需要登錄後台進行網上購物系統管理，由於涉及很多商業機密，所以設計登錄用戶頁面，通過用戶名與密碼登錄後進行管理後台系統。
後台管理系統是內容管理系統Content Manage System(簡稱CMS)的一個子集。WMS是Web Management System 的簡寫，簡單的說：WMS是一個網站管理系統。一個網站管理系統是把一個網站的內容(文字，圖片，等等)與網站的組件分離開來，可以將各個頁面連接到一起，可以控制頁面的顯示。通過這個系統，可以方便的管理，發布，維護網站的內容，而不再需要硬性的寫HTML代碼或手工建立每一個頁面。
後台管理系統的大致(類似)功能：
1、系統管理：管理員管理，可以新增管理員及修改管理員密碼;資料庫備份，為保證您的數據安全本系統採用了資料庫備份功能;上傳文件管理，管理你增加產品時上傳的圖片及其他文件。
2、企業信息：可設置修改企業的各類信息及介紹。
3、產品管理：產品類別新增修改管理，產品添加修改以及產品的審核。
4、下載中心：可分類增加各種文件，如驅動和技術文檔等文件的下載。
5、訂單管理：查看訂單的詳細信息及訂單處理。
6、會員管理：查看修改刪除會員資料，及鎖定解鎖功能可在線給會員發信。
7、新聞管理：能分大類和小類新聞，不再受新聞欄目的限制。
8、留言管理：管理信息反饋及注冊會員的留言，注冊會員的留言可在線回復，未注冊會員可使用在線發信功能給於答復。
9、榮譽管理：新增修改企業榮譽欄目的信息新增修改企業形象欄目的信息。
10、人才管理：發布修改招聘信息，人才策略欄目管理，應聘管理。
11、營銷網路：修改營銷網路欄目的信息。
12、調查管理：發布修改新調查。
13、友情鏈接：新增修改友情鏈接。
14、全新模版功能，在線編輯修改模版。
15、全新掛接資料庫，在線表編輯，添加數據表，編輯資料庫，加添編輯文件掛接網站等等。
16、系統日誌功能，每一步操作都有記錄，系統更安全。
17、中英文切換，簡體繁體切換。
6. 網站購物車是怎麼個原理。對資料庫表配哪些欄位想不明白。請假大俠們。
第一：做購物車，一般來說是不存入資料庫這樣數據量比較大並且查詢效率慢，所以一般購物車都用Session,或Cookie來實現，建一個購物車實體類，大概有這些欄位，商品ID，用戶ID，數量...等這可以根據自己需要來設置，然後比如購買一件商品添加到購物車就創建一個hashtable來保存購物車里的信息，然後把hashtable保存到Session或Cookie，大致就這樣。
第二：訂單，你說的那個訂單一般都有一個訂單表的。首先要弄清楚流程，肯定是用戶先將產品加入購物車，然後再提交訂單的。為什麼會訂單下了以後還關購物車的事呢？購物車只是臨時保存用戶購買產品的地方。就像超市裡去賣東西首先推一個車，然後去選購你要的產品，最後付款。對應這車只是你保存東西的一個工具，當你購買完畢後就不會和他有什麼聯系了。如果你後面需要退貨你也只管那張單據（對應產品訂單）而不會和你購物車車上聯系。
不知道我這樣講你是否明白！
7. 大家在做商城網站系統的購物車時是否將購物車數據放入資料庫呀
一般來說，我們都是把數據放到資料庫中，狀態為購物車，資料庫存為0，可以這樣做，這樣我們方便可以看到客戶准備購哪些東西
也有一種方法，用SESSION來存的，但是這種不方便我們了解客戶的心思。
8. 電商剖析：解密購物車邏輯
在電商的核心交易流程中，購物車是一其中非常重要的一環，也是其中最復雜的一個環節。在做電商流程中，可以簡單的把業務領域劃分成兩部分，一部分是底層支撐業務模塊，一部分是上層流程串流程的模塊。
底層支撐的模塊，比如，庫存系統、會員系統。這些模塊的特點是，所處理的業務流程相對單一、閉環，不需要太多依賴外部系統既可以完成領域內的邏輯。
如會員系統最重要的流程就是注冊、登錄、校驗登錄態。這幾個流程基本只依賴會員系統自身，沒有對外部系統產生強依賴，強耦合。
比較復雜的是串業務流程的系統，這部分系統業務邏輯會相對更復雜些，比如商詳或者購物車。因為商祥或者購物車所展示給用戶看到的東西需要串聯非常多的業務模塊，將其中的信息進行封裝組合展示給用戶，這里的業務邏輯非常復雜，系統內部的交互非常多。
我們以京東的購物車為例，簡單的剖析一下京東的購物車大體背後的業務邏輯，實現方式。
購物車中所展示的東西，無非就是加入購物車中的商品以及一些促銷信息。那麼第一個問題是，這些購物車中的商品、促銷信息是靜態的還是動態獲取的？
所謂靜態就是指用戶在將商品加入購物車的時候，在購物車中存儲加入購物車的商品所需要展示的各種信息。例如上面展示的商品的主圖文描，促銷等等。
動態獲取就是在查看購車的時候，再去實時調用相應的系統獲取最新的信息。
答案是，購物車的數據只會存儲必要的商品信息，其他的信息完全是動態獲取的。
因為在加入購物車的時候如果是靜態存儲的，那麼在下一次查看購物車的時候，所展示的信息可能就不是最准確的。這中間可能商品信息會發生變化，比如商品被下架了、商品的主圖被調整了、或者主題被修改了、商品的促銷信息也可能會發生變化，在加入購物車的時候可能會命中一個促銷，但是過了一段時間之後，這個促銷可能結束了。所以比較精準的做法是在展示購物車的時候，再去實時拉取一次商品的詳細信息以及當前的最新促銷信息。
但是購物車中還是會存儲一部分數據，主要存儲哪些數據呢？主要如下圖所示。
那麼下面我們來看一下，查看購物車背後到底有哪些邏輯？
第一步首先是校驗會員的登錄態。上面購物車存儲的結構中，我們看到購物車的存儲是以用戶維度進行數據存儲的，所以要展示購物車的時候，首先要拿到用戶的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元。
通過上面幾個過程，系統就可以幫你算出來每一個商品在當前情況下的一個預估到手的價格。
總結下，購物車是整個電商交易流程中比較復雜的一個環節，需要串聯會員、商品、庫存、促銷、優惠券等大部分邏輯進行最終的購物車的呈現。為了保證購物車展示給用戶信息的准確性，購物車只存了最基本的一些信息，絕大部分的信息都是在用戶查看購物車那一剎那實時計算出來的。
9. 淘寶購物車的資料庫怎麼設計
無非兩種：
一種就是把購物車里的商品存在資料庫里
另一種就是用session或者cookie這種方式存儲在客戶端。
如果你是使用.net開發，那麼可以直接把添加購物車信息的函數放到「加入購物車」按鈕的事件里，如果是asp這種的，你可以做一個加入購入車動作的頁面，用來處理商品加入購物車的動作。
這個頁面接受商品信息和來自頁面的url,處理完畢直接response回去就可以了！
10. 誰能給我個簡單的網上購物網站，其中要包括，注冊，登錄，購物車等全套功能，我做電子商務的畢業設計
www.dnagdang.com (當當網）
www.taobao.com. (淘寶網)
都很不錯。 到當當網去看看，你就知道了。那也瞞不錯。