因為網站系統的日益龐大，不同域名業務，甚至不同合作方網站的cookie可能或多或少需要進行共享使用，遇到這個情況的時候，大家一般想到的是使用登錄中心分發cookie狀態再進行同步進行解決，成本較高而且實施起來比較複雜和麻煩。
因為cookie在跨網域的情況下，瀏覽器根本不允許互相存取的限制，為了突破這個限制，所以有了以下這個實作方案，使用postmessage和localstorage進行資料跨域共用。
原理比較簡單，但是遇到的坑也不少，這裡梳理一下，做個備份。
二，API設計背景中說我們使用localstorage來代替cookie，本身localstorage和cookie就有一些使用上的區別，例如localstorage的容量更大，但是不存在過期時間，雖然容量大，但在不同的瀏覽器上也都有空間上限，操作不好很容易崩潰，還有就是postmessage雖然支援跨域，安全問題和api的非同步化也給使用帶來了一些麻煩，我們如何把這個模組設計的更易用呢？
先看下我設計的API：
import { crosData } from 'base-tools-crossDomainData';var store = new crosData({ iframeUrl:somefile.html, //共用iframe位址，iframe有特殊需求，詳見範本檔案expire:'d,h,s' //單位天，小時，秒預設過期時間，也可以種的時候覆蓋});store.set('key','val',{ expire:'d,h,s' //option 可帶過期時間，覆蓋expire}).then((data)=>{ //非同步方法，如果種失敗，會進入catch事件//data {val:' val',key:'key',domain:'domain'};}).catch((err)=>{ console.log(err);}); store.get('key',{ domain:'(.*).sina.cn' //可以指定域名，也可以使用(.*)來匹配正規字串，返回的val資訊會帶著domain資訊,不填寫則返回本域的}) .then((vals)=>{ console.log(val) //非同步取得儲存資料,可能多個，是陣列[{},{}]}).catch((err)=>{});store.clear('key').then().catch() ; //只清楚目前網域下的key,不允許清除其他網域下的key，只能讀一個模組上手快不快主要看api，所以對於一個數據共享模組，我認為支持set，get，clear這3個方法就ok了，因為postmessage本身是個一來一回的異步的行為，包裝成promise的肯定更為合適、易用。因為localstorage不支援過期時間，所以需要一個全域的過期時間配置，當然也可以在set的時候進行單獨配置，而get的時候我們可以指定獲取某個域下的資料或多個域下的數據，因為key名可能重複，但是網域只有一個。這裡就牽扯到了數據的管理，後邊單獨來說，最後clear和set的api只能種本域的數據，不可以操作其他域下的數據，get被允許。
下面我們來看看，client端的設定和API：
<!DOCTYPE html><html> <head> <meta charset=utf-8> <title>crosData</title> </head> <body> <script> window.CROS = { domain:/(.*). sina.cn/, //或你允許的網域,支援正規和*通配符lz:false //是否開啟lz壓縮val字元}; </script> <script src=http://cdn/sdk.js></script> </body></html>你可以靈活在任何一個網域下的一個html文件中，引入client的js sdk，然後透過全域屬性的方式來設定一個你允許被種到這個文件所在網域下的domain白名單，支援正則，然後lz是是否啟動lz-string壓縮，至於什麼是lz壓縮後邊我再介紹。
到這裡，一個比較通用的API設計就完成了，下面我們來看看實現原理和具體的一些問題。
三，實現原理說起來好想蠻簡單的，但寫起來其實並不是，我們首先需要知道postMessage怎麼用，這個屬於很常見的一個API了，他有一個要點這裡告訴大家，就是postMessage只能在iframe中或者使用window .open這種開啟新頁面的方式進行互相通訊，當然這裡我們首先就要創建一個隱藏的iframe，進行跨域。
懶得拿工具畫圖了，因為流程比較清晰，這裡拿文字複述一下整個通訊流程，首先父頁面創建一個隱藏的iframe，然後當執行set，get，clear等command的時候，透過postMessage來進行訊息廣播，子頁面接收到訊息後，解析指令，資料和回呼id（postMessage無法傳遞函數和引用，相容問題導致，最好只傳string類型，所以還需要對data做stringify）。然後當子頁面處理完localstorage的操作後，再透過postMessage把對應的cbid和data回傳給父頁面，父頁面監聽message事件，處理結果。
四，編碼嗯，所以說沒幾行，我們下面開始進行編碼了：
首先介紹一下我們用到的第三方包都有什麼，為什麼要用：
1，url-parse 對url進行parse解析，主要用他裡面的origin屬性，因為postMessage本身對origin就有嚴格的驗證，我們要支援白名單和網域管理也需要。
2，ms 對時間簡寫做毫秒轉換的工具庫。
3， lz-string 對字串做壓縮用的工具包，這裡給大家科普一下LZ壓縮演算法，首先了解LZ需要先了解RLZ，Run Length Encoding ，是一個針對無損壓縮的非常簡單的演算法。它用重複位元組和重複的次數來簡單描述來取代重複的位元組。 LZ 壓縮演算法的背後是使用RLE 演算法用先前出現的相同位元組序列的引用來替代。簡單的講， LZ 演算法被認為是字串匹配的演算法。例如：在一段文字中某字串經常出現，並且可以透過前面文字中出現的字串指標來表示。
lz-string本身有優勢就是可以大大的減小你的儲存量，本身5MB的localstorage如果用來支援多網域的資料保存，很快就會被壓縮用完，但是lz-string本身比較慢，消耗比較大，大家平常在工作中如果對傳輸資料量有大小要求的話可以嘗試使用這個壓縮演算法來優化字串長度，預設是不開啟的。
4，store2 本身localstorage的api比較簡陋，為了減少程式碼邏輯複雜度，這裡選了一個比較受歡迎的localstorage的實作函式庫來進行store的操作。
說完了第三方包我們下面看一下父頁面的js怎麼寫：
class crosData { constructor(options) { supportCheck(); this.options = Object.assign({ iframeUrl: '', expire: '30d' }, options); this.cid = 0; this.cbs = {}; this .iframeBeforeFuns = []; this.parent = window; this.origin = new url(this.options.iframeUrl).origin; this.createIframe(this.options.iframeUrl); addEvent(this.parent, 'message', (evt) => { var data = JSON.parse(evt.data); var origin = evt.origin || evt.originalEvent.origin; //我只接收我打開的這個iframe的message，其他的都是不合法的，直接報錯if (origin !== this.origin) { reject('illegal origin!'); return; } if (data. err) { this.cbs[data.cbid].reject(data.err); } else { this.cbs[data.cbid].resolve(data.ret); } delete this.cbs[data.cbid]; }); } createIframe(url) { addEvent(document, 'domready', () => { var frame = document.createElement('iframe'); frame.style.cssText = document.createElement('iframe'); frame.style.cssText = 'width:1px;height:1px;border:0;position:absolute;left:-999px;top:-9999px;'; frame.setAttribute('src', url); frame.onload = () => { this .child = frame.contentWindow; this.iframeBeforeFuns.forEach(item => item()); } document.body.appendChild(frame); }); } postHandle(type, args) { return new Promise((resolve, reject) => { var cbid = this.cid; var message = { cbid : cbid, origin: new url(location.href).origin, action: type, args: args } this.child.postMessage(JSON.stringify(message), this.origin); this.cbs[cbid] = { resolve, reject } this.cid++; }); } send(type, args) { return new Promise (resolve => { if (this.child) { return this.postHandle(type, args).then(resolve); } else { var self = this; this.iframeBeforeFuns.push(function() { self.postHandle(type, args).then(resolve); }); } }) } set(key), args).then(resolve); }); } }) } set(key , val, options) { options = Object.assign({ expire: ms(this.options.expire) }, options); return this.send('set', [key, val, options]); } get(key, options) { options = Object.assign({ domain: new url (location.href).origin }, options); return this.send('get', [key, options]); } clear(key) { return this.send('clear', [key]); }}大概方法就這麼幾個，這裡有幾個關鍵點，我說一下。
1，get，set，clear方法都是統一的呼叫的send方法，只不過對options部分做了補齊。
2，send方法返回一個promise對象，如果iframe已經onload成功，則直接調用postHandle方法進行postMessage操作，如果iframe還在加載中，則把當前的操作推到iframeBeforeFuns數組中，用函數包裹，等待iframe onload結束後統一調用，函數包裹的也是postHandle方法。
3，postHandle方法，在發送請求前包裝data，生成cbid，origin，action和args，cbs物件保存了每個cbid下的resolve和reject，等待子頁面的postMessage返回後處理。因為postMessage不能保留引用，不能傳函數，所以這裡選擇這個方法來進行關聯。
4，constructor比較好理解，當這個類別被初始化的時候，我們定義了我們需要的一些options的屬性，創建iframe，然後監聽message事件，處理子頁面返回的訊息。
5，在父親頁面的message事件中，我們要校驗，給我發訊息的必須是我打開的這個視窗iframe，否則報錯，然後根據data中的err標識來讓cbs中的resolve和reject進行執行。
6，createIframe方法中，iframe onload中的回呼處理創建前緩存的呼叫方法，這裡注意使用了domready，因為可能body還沒解析就會進行sdk的執行。
下面是child部分的程式碼：
class iframe { set(key, val, options, origin) { //檢查val大小，不能超過20k. val = val.toString(); val = this.lz ? lzstring.compressToUTF16(val) : val; var valsize = lzstring.compressToUTF16(val) : val; var valsize = sizeof(val, 'utf16'); //localStorage 儲存使用utf16編碼計算位元組if (valsize > this.maxsize) { return { err: 'your store value : ' + valstr + ' size is ' + valsize + 'b, maxsize :' + this.maxsize + 'b , use utf16' } } key = ` ${this.prefix}_${key},${new url(origin).origin}`; var data = { val: val, lasttime: Date.now(), expire: Date.now() + options.expire }; store.set(key, data); //大於最大儲存個數，刪除最後一次更新的if (store.size() > this.storemax) { var keys = store.keys(); keys = keys.sort((a, b) => { var item1 = store.get(a), item2 = store.get(b); return item2.lasttime - item1.lasttime; }); var removesize = Math.abs(this.storemax - store.size()); while (removesize) { store.remove(keys.pop()); removesize--; } } return { ret: data } } get(key, options) { var message = {}; var keys = store.keys(); var regexp = new RegExp('^' + this.prefix + '_' + key + ',' + options.domain + '$') ; message.ret = keys.filter((key) => { return regexp.test(key); }).map((storeKey) => { var data = store.get(storeKey); data.key = key; data.domain = storeKey.split(',')[1]; if (data.expire < Date.now()) { store.remove(storeKey ); return undefined; } else { //更新lasttime; store.set(storeKey, { val: data.val, lasttime: Date.now(), expire: data.expire }); } data.val = this.lz ? lzstring.decompressFromUTF16(data.val) : data.val; return data; }).filter(item => { return !!item; //過濾undefined }); return message; } clear(key, origin) { store.remove(`${this.prefix}_${key},${origin}`); return {}; } clearOtherKey() { //刪除不合法的key var keys = store.keys(); var keyReg = new RegExp('^' + this.prefix); keys.forEach(key => { if (!keyReg.test(key)) { store.remove(key); } }); } constructor(safeDomain, lz) { supportCheck(); this.safeDomain = safeDomain || /.*/; this.prefix = '_cros'; this.clearOtherKey(); if (Object.prototype.toString.call(this.safeDomain) !== '[object RegExp]') { throw new Error('safeDomain must be regexp'); } this.lz = lz; this.storemax = 100; this.maxsize = 20 * 1024; //位元組addEvent(window, 'message', (evt) => { var data = JSON.parse(evt.data); var originHostName = new url(evt.origin).hostname; var origin = evt.origin, action = data.action, cbid = data.cbid, args = data.args; //合法的廣播if (evt.origin === data.origin && this.safeDomain.test(originHostName)) { args.push(origin); var whiteAction = ['set', 'get', 'clear']; if (whiteAction.indexOf(action) > -1) { var message = this[action].apply(this, args); message.cbid = cbid; window.top.postMessage(JSON .stringify(message), origin); } } else { window.top.postMessage(JSON.stringify({ cbid: cbid, err: 'Illegal domain' }), origin); } }); }}程式碼也不多，這裡簡單說一下各個方法的用處和組織關係：
1，constructor部分，上面的類別裡也進行瀏覽器特性支援檢查，然後定義了store的prefix值，最大個數和每一個key的maxsize等屬性。然後我們創建message通道，等待父頁面呼叫。
2，在message中，我們對發送廣播的origin進行檢查，然後對調用的方法進行檢查，調用對應的set，get，clear方法，然後把執行的結果拿到，綁定cbid，最後再postMessage發送回父頁面。
3，clearOtherKey 刪除不合法的一些store數據，只保留符合格式的資料。
4，set方法中對每一條的資料做size校驗，lz壓縮，保存的data中包含了val，key，過期時間以及更新時間（用於LRU計算）。
5，set方法中，如果儲存的ls個數超過了最大限制，這個時候需要進行刪除操作， LRU是Least Recently Used的縮寫，即最近最少使用。我們透過遍歷所有的key值，對key值做一個排序，通過lasttime，然後進行keys數組的pop操作，拿到堆疊尾部的需要被清除的key，然後逐個刪除。
6，get方法中，我們透過遍歷所有的key值，匹配到我們需要拿到的domain的域的key，然後把返回值中的key進行拆解（我們儲存時是key,domain的格式），因為api要求回傳多個符合的值，我們對過期的資料最後再做一個filter，然後用lz解壓縮val值，保證用戶拿到的是正確結果。
以上就是我們的一個整體實現編碼過程和review，下面說一說遇到的坑。
五，一些遇到的坑因為上面只給了主程式碼，並不是完整程式碼，因為本身邏輯比較清晰，花一點時間都可以寫出來的。下面說說有什麼坑的地方。
1，計算localstorage的儲存值。
因為我們都知道有5MB的限制，所以每個資料最大要求不能超過20*1024 字節，對於字節的計算，localstorage要使用utf16的編碼進行轉換，參考這篇文章： JS計算字串所佔字節數
2，相容性
ie8下postMessage最好都傳字串，事件需要抹平處理，JSON需要抹平處理。
3，創建iframe時的非同步處理
這裡之前做了個一個setTimeout的遞迴等待，後來更改成了上面的實作方法，透過onload後統一處理promise的reslove，確保promise api的統一。
4，資料保存時，空間複雜度vs 時間複雜度。
第一個版本並不是上面的實現，我實作了3個版本：
第一個版本是保存了一個LRU的數組，為了減少時間複雜度，但浪費了空間複雜度，而且經過測試，store的get方法耗時比較大，主要是parse的耗時。
第二個版本，為了能讓lz-string壓縮率最大化，我把所有的資料包括LRU數組保存到了一個key值上，導致資料多的時候lz-string和getItem，parse時間消耗非常大，雖然計算的時間複雜度是最低。
最後一個版本，就是上面的，我犧牲了一些時間複雜度和空間複雜度，但是因為瓶頸在於set和get的讀寫速度，單個的保存讀寫速度極快，獲取keys的方法因為底層是用的for in localstorage實現的，效能還是很不錯的，20kb存滿100條，讀寫也在1s左右，效能非常不錯。
六，總結和對比模組寫完了，我才知道原來還有這麼一個函式庫： zendesk/cross-storage
但是我查看了他的api和原始碼，比較了一下實作方法，我覺得還是我這個版本考慮的比較多。
1，我的版本對網域和資料的管理有控制。
2，我的版本promise api更簡化，比它少一個onConnect，可以參考他的實現，比我寫的多多了，也沒解決這個iframe等待異步的問題。
3，不支援lz壓縮資料。
4，不支援LRU的儲存池管理，所以可能存多了造成寫不進的問題。
5，他看似每次互動都搞一個iframe，太浪費dom操作和廣播了，我覺得一直開著並沒有什麼問題，當然他可能有需求連接多個client才這麼處理的。
總結以上所述是小編給大家介紹的使用localstorage代替cookie實現跨域共享數據問題，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回覆大家的。在此也非常感謝大家對VeVb武林網站的支持！