localstorage使用。
為什麼要使用 localstorage？
因為在之前的討論過程中，問題：每次新增一件商品和去掉乙個商品都需要傳送乙個http請求來更新購物車，目的是為了在使用者下次登入的時候可以記得購物車裡的內容，這樣， 如果使用者選了之後即使沒有付款，但是下次登入的時候仍然一開啟頁面我們就可以把localstorage中的內容顯示出來，這樣，使用者體驗會更好一些，比如餓了麼在小程式上的做法就是這樣，但是美團不是，美團並沒有儲存購物車中的內容， 而餓了麼儲存了，之所以可以判斷使用的時localstorage，是因為我們在斷網的情況下他也可以記錄。
之所以可用，是因為在相容性上也不存在問題，支援ie8，android2.1（幾乎是所有的了）、以及ios3，所以相容想上可以做。
另外，localstorage可以儲存json字串，所以說資料也沒有問題，並且本地的儲存量在5m，足以滿足我們的需求。
同樣的，localstorage也存在跨域的問題，只能在乙個**下面使用，廢話不多說，開始吧。
具體思路：
當使用者新增一件商品的時候，我們就把相應的商品的sbgaid值儲存到localstorage中，並且因為使用localstorage也只需要購物車部分，我們現在有兩種選擇：
一種是新增乙個商品儲存到乙個鍵值對中； 刪除一件商品，就刪除乙個鍵值對。
優點： 比較簡單，新增setitem， 刪除removeitem。 缺點： 可能會比較亂， 全是一堆鍵值對。
還有一種做法是先新建乙個物件，然後新增乙個商品，就把鍵值對新增到這個物件上，然後在json.stringify，然後再儲存到locolstorage中。
優點: 可能看上去可以整潔一些。 缺點： 需要不斷的更新這個物件，然後就是轉換和替換josn字串，結果就是消耗效能。
師兄的意思是從商品中尋找localstorage，我們可以來使用localstorage的遍歷方法判斷是否相等來做。。
需要知道的時，我們需要儲存的是什麼？ 乙個是sbgaid，這個是每乙個商品都不同的，所以可以作為鍵，那麼值是什麼呢? 當然就是使用者需要買的數量了！ 儲存的過程中，如果add，就amount為1， 如果remove，那麼就直接刪除這個鍵值對即可。所以還是使用前者好一些。
綜合考慮兩種，其實使用者的購物車往往很少，所以即使是散的鍵值對，也不會很亂，影響不大，所以我決定最終採用第一種做法。
2023年6月19日更新
目前專案的需求是做成微商廈的形式，所以說我們需要改變localstorage的儲存形式，對應於不同的店鋪都要有不同的k-v，大致如下所示：
var sbid1 =,整體思路:sbgaid2: ,
sbgaid3: ,
//總價，在訂單頁重新整理的時候是需要的。
totalprice: 115
};
var sbid2 =,
sbgaid2: ,
sbgaid3: ,
totalprice:
45};
//儲存方式二
localstorage.setitem('
sbid1
', json.stringify(sbid1));
localstorage.setitem(
'sbid2
', json.stringify(sbid2));
一、首先解決新增商品和減去商品的問題，在新增商品的時候，首先檢測當前的sbid是否存在，如果不存在就建立乙個值為相應sbid的localstorage鍵值對，值為乙個物件，然後物件中檢視是否有相應的商品，如果有相應的商品，我們就直接給number++,如果沒有相應的商品，我們就建立乙個該商品的物件，並儲存相應的資訊。然後再儲存。 如果是減去乙個商品，就要直接減1，如果結果為0，那麼刪去物件的這個鍵就可以了。
補充：
之前試了一下採用localstorage做購物車的頁面，但是有乙個問題很明顯的出現了。
還是要先說一說餓了麼為什麼要用localstorage，這是因為餓了麼希望當使用者某次選中某些產品之後，然後退出，在下次進來的時候可以顯示出這些之前點選過的商品。
這一點很重要，我之前嘗試的方法是採用元件懶載入的方式，也就是說，比如乙個店家中五個分類，每個分類下大概有30件產品，當我進入主頁時，我會自動把第乙個分類下的產品顯示出來10條（注意：不是顯示完全）。 如下所示：
然後獲取到這些資料之後，就把資料存放到vue的store中，這樣，下次使用者再載入時，就可以使用使用store中的了。
如果我希望看到該分類下的更多，那麼我一定會向下拉，這裡我使用了懶載入，當使用者拉到底部時，開始載入更多的資料，這樣就避免了不必要的資料浪費。
當看其他分類下的產品時，比如我點選一下哈哈，這時又會傳送乙個ajax請求， 請求到這個頁面下的前10條資料。 當我希望看更多時，拉到底部開始載入更多資料。
而這就有乙個問題！ ---那就是如果暫時性的網路差，那麼我可能已經點選了哈哈，但是介面還停留在蔬菜的內容上，這是因為vue的view是由資料驅動的，我這樣的做法如果沒有獲取到資料， 那麼介面就不會發生變化，這樣的使用者體驗是非常的不好的。 所以這種方法不可取。
進入首頁，先定位（這個無論是美團還是餓了麼都是這麼做的，優點是可以根據你的位置來提供附近的店家，但是缺點也是存在的，它占用頻寬比較多，4g的網路還要載入一會，如果網路再差一點，那麼幾乎要卡死。）， 定位成功之後就是推薦商家的介面，每乙個店家是乙個item，並且我們可以無限向下拉，這個介面採用了懶載入的方式，使用者體驗還是很不錯的（除了之前說到的位置定位以外）。 對於這些店家的介紹無非是店名、評分、位置、月訂單數、配送費、起送**、 一些優惠政策等等。
進入其中的乙個店家之後， 其上半部分是店家的介紹，下面是商品的羅列和可以左右切換的評分。 對於商品而言， 同樣，左邊是分類，右邊是商品。主要說一說它的實現方式：進入店家之後，先顯示分類，然後顯示出所有分類下的所有商品！！！！ 而不是點選乙個分類之後再傳送ajax。 並且只有第乙個分類的是事先載入好的。其他分類只是載入了基本的資料，而沒有載入，我們通過斷網就可以發現。並且無論乙個分類下有幾十件商品，他都是一次性載入完的，那麼這樣做的好處是什麼呢？ 我個人認為好處有以下幾點：
總而言之，可以採取這種思路！ 使用者體驗必然得到大幅度的提高！！！！
但是使用這種方式，存在哪些亟待解決的問題呢？
回答問題：
在嘗試這個方法的過程中，我還是不可避免的遇到了問題。 其實也不是問題，只是我之前的想法可能出現了偏差。 比如說，對於用這個方式我們來分析一下是怎麼載入的。 即一進入之後首先載入了必須要載入的東西。
並且可以看到載入其他種類的商品資料只發了3個http請求，並且請求到的資料量是很小的，所以這種思路是絕對划得來的。
對於餓了麼，我們還可以發現它做的乙個比較好的地方，那就是在進入乙個店鋪之後，使用者體驗做的是真的很棒，比如我先進入這個店，它此時並沒有獲取，而是等到獲取了所有的分類之後才開始獲取。如果不是這樣做，那麼我們很有可能在得到其他分類的時間會非常長。
即進入店鋪，優先獲取所有分類下的所有商品的資料，這是第一步，第二步才是獲取第乙個分類下的。
餓了麼註冊餓了團 餓了麼拼團商標
程式設計yi vgdbz客棧 www.cppcns.com 6月16日 訊息 企查查app顯示，餓了麼運營主體公司拉扎斯網路科技 上海 有程式設計客棧限公司於6月8日申請註冊餓了團商標。餓了麼申請的餓了團商程式設計客棧標國際分類包含35類 www.cppcns.com廣告銷售 43類 餐飲住宿等，目...
餓了麼 餓百 美團 外賣訂單API
美團 查詢訂單列表 美團拉取訂單列表 function sign data secret url,else urls url ltrim s secret 簽名 sig md5 urls temp url ltrim s sig sig return temp url data timestamp ...
美團王興要向口碑餓了麼學啥？
5月24日，美團創始人王興在財報 會議上的一番言論引起人們關注。王興稱 那些居住在低線城市，對 比較敏感的使用者會花更多時間在家做飯，他們的生活方式與北京上海這些城市的居民不同。對此，餓了麼口碑公關負責人進行了回應。餓了麼負責人稱 王興真的慌了吧？當然這也正常，三四線城市的 糧倉 著火了嘛 雙方的隔...