技術(shù)很簡單，業(yè)務(wù)很麻煩

在大公司，同一個域名下可能存在幾十上百條業(yè)務(wù)線，每條業(yè)務(wù)線都可能因為各種理由往 localStorage 里塞東西，跨頁面?zhèn)鲾?shù)據(jù)啦、緩存啦、離線化啦、性能優(yōu)化啦...，5M 看起來很多，其實很快就用完了。而開發(fā)時基本無感知，是因為大家都只訪問自己的業(yè)務(wù)，但用戶會訪問各種業(yè)務(wù)，時間一久，很容易就存滿了，凡是嚴(yán)重依賴 localStorage 的業(yè)務(wù)流程都存在風(fēng)險，寫可能出問題，讀自然也會出問題。

一種容易想到的方案是，當(dāng) localStorage 存滿后降級到 sessionStorage 里。看上去沒啥問題，但實際業(yè)務(wù)中 app 內(nèi) h5 頁面跳轉(zhuǎn)常常采用新打開 webview 的方式，這么做的好處是關(guān)閉一個 webview 可以直接回到上一個頁面，而不用重新加載頁面，對于訂單填寫這類帶有狀態(tài)的頁面就很需要這么做。新打開 webview 等于新打開一個會話，而 sessionStorage 只能存在于同一個會話中，因此 sessionStorage 無法跨頁面共享。

那降級到 cookie 里呢？cookie 一共才 50 個，總大小不超過 4k，作為 backup 過于脆弱，而且還會影響請求的效率。如果后端對請求頭大小做了限制，還可能產(chǎn)生 413 錯誤，導(dǎo)致請求被攔截。

那降級到 url 上呢？很麻煩。比如有一個交互流程是這樣的：頁面 A => 頁面 B => 頁面 C，如果頁面 A 的數(shù)據(jù)要傳到頁面 C，就得通過頁面 B 做一層中轉(zhuǎn)。而且 url 長度也是有限制的。

單頁應(yīng)用解決跨頁面?zhèn)鲾?shù)據(jù)就很簡單，改造成單頁應(yīng)用呢？這個就得估算成本，看老板們認(rèn)不認(rèn)可了，而且原有應(yīng)用積累了大量的業(yè)務(wù)邏輯，沒有注釋，沒有測試用例，需求文檔散落在不知名的角落，你真能保證重新做的和原來的功能一模一樣嗎。

我們還可以求助客戶端同學(xué)，通過 js bridge 提供一個仿 localStorage 的東西，不過要考慮版本的問題，新版 app 里使用了客戶端提供的 store，怎么兼顧老版 app，而且還要考慮兼容瀏覽器、微信。所以這種方案也只能解決一部分問題，當(dāng)然，如果 h5 的流量絕大多數(shù)都在 app 里，那么這種方案是可以解決一大部分問題的，不過客戶端提供的存儲可不見得比原生的存儲可靠，還是得加 backup。

我們還可以求助后端同學(xué)，多加幾個字段甚至多加幾個接口，不過這涉及到核心業(yè)務(wù)流程的改造，風(fēng)險不小，而且不見得能完全解決問題，也無法永久的解決問題。

我們還可以來一招互相傷害大法，那就是把別人存的東西都刪掉。。。

localStorage 是個好東西，不用，這是因噎廢食，用，又很難統(tǒng)一和約束各業(yè)務(wù)線的用法，一旦放開用，就總會面臨存滿的風(fēng)險。跟你在同一個域名下做開發(fā)的人可能跟你不在同一棟樓，甚至可能不在同一個城市，你有那個影響力去統(tǒng)一所有人的使用規(guī)范嗎。

還有一個很討厭的事情：safari 在隱私模式下不支持 localStorage 的存取（ios11 以下），這種情況比較罕見，但如果出了客訴，也是個大坑。

問題的本質(zhì)

localStorage 歸根結(jié)底就兩個作用：持久化存儲與跨頁面?zhèn)鲾?shù)據(jù)。持久化存儲不會出問題，存不進去就存不進去唄，取不出來就去其它地方取，或者不取。問題就出在跨頁面?zhèn)鲾?shù)據(jù)上，上一個頁面因為 localStorage 存滿導(dǎo)致數(shù)據(jù)沒有寫入，下一個頁面讀取數(shù)據(jù)為空，從而導(dǎo)致錯誤。

問題的根源

同一個域名共享同一個 localStorage，而同一個域名下存在過多獨立的業(yè)務(wù)線，業(yè)務(wù)線之間各自為政，毫無節(jié)制的攫取公共資源，這就是 localStorage 溢出問題的根源。

就我觀察的情況來看，很多公司都喜歡把 h5 頁面掛在 http://i.xxx.com 或 http://m.xxx.com 下，然后通過路徑劃分業(yè)務(wù)，比如 http://i.xxx.com/project-a, http://i.xxx.com/project-b...，隨著業(yè)務(wù)發(fā)展，越來越多的業(yè)務(wù)都加到 http://i.xxx.com 中，“公地悲劇”就無可奈何的產(chǎn)生了，而且積重難返。我以前在的團隊也是如此，用 h5、js、css 這樣的類型名稱來劃分目錄，初期東西少，自然沒問題，但后來所有應(yīng)用都把資源塞到 js 文件夾、css 文件夾下，一個文件夾包含了來自五湖四海的上百個文件，維護起來十分難受。

通過應(yīng)用類型劃分，而不是通過業(yè)務(wù)類型劃分，這是最初架構(gòu)策略的問題。如果 a 業(yè)務(wù)掛在 http://a.xxx.com 下，b 業(yè)務(wù)掛在 http://b.xxx.com 下，每個業(yè)務(wù)有獨立的團隊維護，localStorage 從公共資源變成團隊的私有財產(chǎn)，或許這樣才能從根源上解決 localStorage 無限膨脹的問題。有網(wǎng)友提出對 http://i.xxx.com 進一步劃分子域，其實也是這個思路。

理想的方案

假設(shè)我們回到起點，從零建設(shè)前端工程，我們怎么避免 localStorage 存滿的問題？

1、劃分域名。各域名下的存儲空間由各業(yè)務(wù)組統(tǒng)一規(guī)劃使用

2、跨頁面?zhèn)鲾?shù)據(jù)：考慮單頁應(yīng)用、優(yōu)先采用 url 傳數(shù)據(jù)

3、最后的兜底方案：清掉別人的存儲

總結(jié)

以上是生活随笔為你收集整理的app应用内嵌h5页面怎么直接打开safari_localstroage过多存储满的情况下应该怎么办？...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。