深入 PouchDB 源碼瀏覽器存儲 API 兼容性戰(zhàn)役中的十個血淚教訓(xùn)【免費(fèi)下載鏈接】pouchdb:kangaroo: - PouchDB is a pocket-sized database.項目地址: https://gitcode.com/gh_mirrors/po/pouchdb在 CouchDB 兼容的客戶端數(shù)據(jù)庫中PouchDB 的價值不僅在于在瀏覽器里跑 CouchDB更在于它必須在 Web SQL、IndexedDB、LocalStorage 乃至 Node.js 的 LevelDB 之間反復(fù)橫跳把五花八門的瀏覽器差異一一抹平。本文源自 PouchDB 核心維護(hù)者 Nolan Lawson 的實戰(zhàn)筆記《10 things I learned from reading (and writing) the PouchDB source》我們將以這篇文檔為主線結(jié)合當(dāng)前倉庫中packages/node_modules下的適配器源碼逐條剖析 Web SQL 與 IndexedDB 的十個坑并展示 PouchDB 是如何用 user-agent 嗅探、特性檢測、字符串拼接鍵、非遞歸 JSON 序列化等土辦法化解它們的。讀完本文你將理解瀏覽器存儲 API 的底層行為差異也能掌握跨端存儲兼容性工程的具體套路。背景作者于 2013 年底加入 PouchDB 項目時PouchDB 已相當(dāng)成熟首個提交距今已四年。他的目標(biāo)集中在提升性能與瀏覽器兼容性——而瀏覽器兼容性正是 Web 世界里那個 Android 生態(tài)聞之色變的碎片化難題。下文涉及 LocalStorage、Web SQL、IndexedDB 三種存儲 API若讀者不熟悉可先閱讀 瀏覽器存儲概覽 了解 PouchDB 視角下的存儲適配器分層。1. 沒有人說得清 Web SQL 的 estimated size 到底是什么意思打開 Web SQL 數(shù)據(jù)庫時需要使用openDatabase()最后一個參數(shù)是所謂的estimated size預(yù)估大小var db openDatabase(documents, 1.0, some description, 5000000);當(dāng)年 PouchDB 是這樣設(shè)置它的文檔原文function getSize(opts) { /* ... */ var isAndroid /Android/.test(window.navigator.userAgent); return isAndroid ? 5000000 : 1; }User-agent 嗅探?jīng)]錯這確實不夠優(yōu)雅。但理由很現(xiàn)實在現(xiàn)代 Chrome 與 Android 4.4上這個 size 會被直接忽略瀏覽器自行根據(jù)磁盤剩余空間設(shè)定上限在Android 4.4上它是一個硬性上限傳 5000000 就永遠(yuǎn)只有 5 MB在Safari/iOS上則更微妙傳大于 5000000 的值應(yīng)用首次加載就會彈出煩人的容量確認(rèn)框見下圖極易嚇跑用戶傳小于 5000000 的值數(shù)據(jù)庫漲到 5 MB 時會再次彈框而 iOS 7.1 還有一個 bug——彈框次數(shù)耗盡后不再出現(xiàn)于是容量被永久釘死在 10 MB想存更多就必須在一開始就要得更多傳 0 到 5000000 之間的值Safari/iOS 會把它當(dāng)作何時彈框的提示PouchDB 的自動化測試跑在 Selenium 下無法點(diǎn)擊OK按鈕所以理想值是 0但PhantomJS 和舊版 WebKitSafari ~5遇到 0 會直接崩潰。這就是 PouchDB 嗅探 Android 才把 size 提到 5000000、其余情況一律設(shè)為 1 的原因。作者還吐槽 W3C 官方示例用5*1024*1024誤導(dǎo)了所有人實際規(guī)避彈框的臨界值是 50000005 MB即 5 兆字節(jié)而非5*1024*10245 MiB5 兆二進(jìn)制字節(jié)但網(wǎng)上博客與 Stack Overflow 到處流傳著錯誤的1024*1024寫法。今天倉庫里的源碼印證了這段歷史packages/node_modules/pouchdb-adapter-websql-core/src/utils.js中的getSize()utils.js#L164-L179保留了幾乎相同的邏輯并補(bǔ)充了關(guān)鍵注釋function getSize(opts) { if (size in opts) { // triggers immediate popup in iOS, fixes #2347 // e.g. 5000001 asks for 5 MB, 10000001 asks for 10 MB, return opts.size * 1000000; } // In iOS, doesnt matter as long as its 5000000. // Except that if you request too much, our tests fail // because of the native do you accept? popup. // In Android 4.3, this value is actually used as an // honest-to-god ceiling for data, so we need to // set it to a decently high number. var isAndroid typeof navigator ! undefined /Android/.test(navigator.userAgent); return isAndroid ? 5000000 : 1; // in PhantomJS, if you use 0 it will crash }可見后來的代碼還增加了對opts.size顯式配置的支持單位按 1e6 換算而5000000 : 1的兜底策略與當(dāng)年的實現(xiàn)一脈相承。該值最終被傳入openDatabase見 pouchdb-adapter-websql-core/src/index.js#L126-L146。2. IE 的 IndexedDB 存在競態(tài)條件微軟的 IndexedDB 實現(xiàn)速度很快——比 Chrome 慢一點(diǎn)但遠(yuǎn)快于 Firefox。然而為了這個速度他們顯然走了捷徑IE10 與 IE11 存在多個令人頭疼的競態(tài)條件。因此 PouchDB 源碼中常見這類防御性代碼文檔原文//Close open request for name database to fix ie delay. if (IdbPouch.openReqList[name] IdbPouch.openReqList[name].result) { IdbPouch.openReqList[name].result.close(); }以及把所有 open 和 destroy 操作串行化的任務(wù)隊列taskQueue.queue.push({ action: function (thisCallback) { destroy(name, opts, thisCallback); }, callback: callback });還有按名稱緩存所有數(shù)據(jù)庫的cachedDBs——因為 IE 不允許同時打開兩個同名的數(shù)據(jù)庫var cached cachedDBs[name]; if (cached) { idb cached.idb; /* ... */ }這些經(jīng)驗在今天倉庫的pouchdb-adapter-idb中依舊可見openReqList被實現(xiàn)為一個Mapindex.js#L54在打開請求完成后從列表中移除index.js#L629-L659串行化打開/銷毀的機(jī)制則被提煉為獨(dú)立的 taskQueue.js 模塊通過enqueueTask對外暴露index.js#L48。作者對 IE 團(tuán)隊的態(tài)度是功過相抵——他們響應(yīng) bug 報告相當(dāng)迅速。3. Web SQL 中的二進(jìn)制數(shù)據(jù)一團(tuán)糟Web SQL 規(guī)范制定時Blob 和 ArrayBuffer 都還沒有標(biāo)準(zhǔn)化。SQLite 本身支持二進(jìn)制 BLOB 類型但要往 Web SQL 里存二進(jìn)制只能用老辦法傳 JavaScript 二進(jìn)制字符串。這帶來兩個棘手問題\u0000被當(dāng)作字符串終止符WebKit 與 Chromium 都存在這個 bug——插入和排序沒問題但讀出來時數(shù)據(jù)會被截斷。由于 BLOB 必須以二進(jìn)制字符串插入任何含 0 字節(jié)的二進(jìn)制數(shù)據(jù)都會被截斷。唯一的繞法是SELECT HEX(columnName)用十六進(jìn)制字符串取回完整數(shù)據(jù)HEX() 也有問題Safari 7.1 與 iOS 8 把所有字符串強(qiáng)制轉(zhuǎn)成 UTF-16導(dǎo)致同樣的十六進(jìn)制串在 UTF-8 瀏覽器Chrome/Opera/Android 及新版 Safari/iOS與 UTF-16 瀏覽器早期 Safari/iOS里必須用不同方式解析。于是有了文檔中這段好玩的代碼function parseHexString(str, encoding) { var result ; var charWidth encoding UTF-8 ? 2 : 4; for (var i 0, len str.length; i len; i charWidth) { var substring str.substring(i, i charWidth); if (charWidth 4) { // UTF-16, twiddle the bits substring substring.substring(2, 4) substring.substring(0, 2); } result String.fromCharCode(parseInt(substring, 16)); } result encoding UTF-8 ? decodeUtf8(result) : result; return result; }作者自嘲 twiddle the bits 注釋不準(zhǔn)確正確的術(shù)語是 nibble-swizzling即高低字節(jié)交換。判斷數(shù)據(jù)庫是 UTF-8 還是 UTF-16 則靠特性檢測——直接查詢dbid及其十六進(jìn)制形式比較長度function checkDbEncoding(tx) { // check db encoding - utf-8 (chrome, opera) or utf-16 (safari)? tx.executeSql(SELECT dbid, hex(dbid) AS hexId FROM META_STORE, [], function (tx, result) { var id result.rows.item(0).dbid; var hexId result.rows.item(0).hexId; encoding (hexId.length id.length * 2) ? UTF-8 : UTF-16; } ); }由于是特性檢測Safari 7.1 與 iOS 8 上可以自動正常工作。作者還預(yù)告PouchDB 3.1.0 起對大二進(jìn)制附件不再 hex 化性能太差改為剔除\u0000字符并在取回時還原。這段歷史在今天被整理成了一個獨(dú)立模塊parseHex.js頭部注釋直接引用了當(dāng)年的兩個 bug 鏈接Chromium 422690 與 WebKit 137637并把 UTF-8/UTF-16 拆成兩個函數(shù)以換取微小的性能提升// Example: // pragma encodingutf16; // select hex(A); // returns 4100 // notice that the 00 comes after the 41 (i.e. its swizzled) function parseHexUtf16(str, start, end) { var result ; while (start end) { // UTF-16, so swizzle the bytes result String.fromCharCode( (hexToInt(str.charCodeAt(start 2)) 12) | (hexToInt(str.charCodeAt(start 3)) 8) | (hexToInt(str.charCodeAt(start)) 4) | hexToInt(str.charCodeAt(start 1))); start 4; } return result; }源碼注釋里那句 Parsing hex strings. Yeah. 隔著十年依然能讀出當(dāng)年的無奈。4. IndexedDB 里的二進(jìn)制數(shù)據(jù)同樣一團(tuán)糟作為 Web SQL 的時髦弟弟IndexedDB 理應(yīng)原生支持 Blob。但現(xiàn)實是Chrome 直到 v37 才支持 Blob而蘋果在修復(fù) IndexedDB 更基礎(chǔ)的問題之前也明確不打算支持。這些情況下PouchDB 退而求其次把 Blob 存成 base64 字符串并用特性檢測來判定try { var blob utils.createBlob([], {type: image/png}); txn.objectStore(DETECT_BLOB_SUPPORT_STORE).put(blob, key); txn.oncomplete function () { /* ... */ blobSupport true; /* ... */ }; } catch (err) { blobSupport false; /* ... */ }然而事情沒這么簡單Chrome v37 雖然實現(xiàn)了 Blob卻實現(xiàn)錯了——取回時返回錯誤的 MIME 類型。所以 v37 需要單獨(dú)檢測這種壞支持v38 起才能與其他瀏覽器一視同仁var storedBlob e.target.result; var url URL.createObjectURL(storedBlob); utils.ajax({ url: url, cache: true, binary: true }, function (err, res) { if (err err.status 405) { // firefox wont let us do that. but firefox doesnt // have the blob type bug that Chrome does, so thats ok blobSupport true; } else { blobSupport !!(res res.type image/png); } });Firefox 在這里也有個小 bug好在 nightly 版已修復(fù)。于是出現(xiàn)了荒誕的一幕PouchDB 需要為 Chrome v36、v37、v38 各準(zhǔn)備一種策略而 Android 上凍結(jié)的各代 Chromium 內(nèi)核意味著這三種變體還將在野外長期共存。今天的pouchdb-adapter-idb仍保留了完整的檢測管線checkBlobSupport(txn, DETECT_BLOB_SUPPORT_STORE, key)index.js#L784-L790并把結(jié)果記錄在元信息里后續(xù)寫入時據(jù)此決定附件格式是blob還是base64var blobType api._meta.blobSupport ? blob : base64;見 bulkDocs.js#L63——存儲層對應(yīng)用透明但底下是兩套完全不同的編碼路徑。5. IE 不支持 complex keysCouchDB 是 NoSQL 的元老順理成章地影響了 IndexedDB 的設(shè)計。CouchDB 一個強(qiáng)大而微妙的功能是complex keys視圖的 key 可以是任意 JSON 值而不只是字符串。經(jīng)典用例是把博文及其評論放進(jìn)同一個視圖function(doc) { if (doc.type post) { map([doc._id, 0], doc); } else if (doc.type comment) { map([doc.post, 1], doc); } }key 是一個字符串 整數(shù)的數(shù)組排序時先按字符串、再按整數(shù)。這個特性確實寫進(jìn)了 IndexedDB 規(guī)范對要在 IndexedDB 上重寫 CouchDB的 PouchDB 而言簡直完美。然而 IE 不支持 complex keys所以源碼里出現(xiàn)的是這種偽復(fù)合鍵docInfo.data._doc_id_rev docInfo.data._id :: docInfo.data._rev; var seqStore txn.objectStore(BY_SEQ_STORE); var index seqStore.index(_doc_id_rev);查詢時則用邊界范圍var start docId ::; var end docId ::~; var index seqStore.index(_doc_id_rev); var range global.IDBKeyRange.bound(start, end, false, false); var seqCursor index.openCursor(range);把_id與_rev用::拼成一個字符串——故意選~ASCII 0x7E作為結(jié)束邊界因為任何合法字符都排在它之前。這是有意為之不是失誤。這條設(shè)計還深刻影響了持久化 map/reduce既然不能指望底層數(shù)據(jù)庫按多字段排序PouchDB 干脆發(fā)明了toIndexableString()——把任意 JSON 對象編碼成一條按 CouchDB collation 順序排列的大字符串。這段設(shè)計今天完整地活在pouchdb-collate包中toIndexableString先把 key 規(guī)范化index.js#L116-L120// convert the given key to a string that would be appropriate // for lexical sorting, e.g. within a database, where the // sorting is the same given by the collate() function. function toIndexableString(key) { var zero \u0000; key normalizeKey(key); return collationIndex(key) SEP indexify(key) zero; }其中normalizeKey把undefined/NaN/Infinity歸一為null、Date 轉(zhuǎn)字符串、對象鍵排序index.js#L36-L69indexify對字符串做 0/1/2 控制字符的順序保持替換\u0000→\u0001\u0001等確保詞法排序等價于 CouchDB collationindex.js#L71-L89。數(shù)字則被編碼為帶 3 位量級前綴的字符串-Number.MIN_VALUE到Number.MAX_VALUE都能保序index.js#L1-L5。同樣的字符串拼接技巧在今天的pouchdb-adapter-idb里依然到處可見寫入時doc._doc_id_rev metadata.id :: metadata.revbulkDocs.js#L256讀出時再用lastIndexOf(:)拆回_id/_revutils.js#L57-L65并且在docIdRevIndex上建立了unique: true的唯一索引index.js#L89。allDocs、changes 等模塊均復(fù)用了這個索引做范圍游標(biāo)allDocs.js#L106、changes.js#L206。6. 反向迭代時 start end 會拋錯其實是個誤會文檔中附帶了一段更新說明作者后來承認(rèn)自己誤解了 IndexedDB 規(guī)范——其實把IDBKeyRange的 start 和 end 對調(diào)就能在所有瀏覽器里反向迭代PouchDB 據(jù)此修復(fù)見 issue 3488。但在當(dāng)時這個符合規(guī)范的 bug在 Firefox、IE、Chrome 三大瀏覽器中忠實復(fù)現(xiàn)try { if (start end) { keyRange global.IDBKeyRange.bound(start, end, false, !inclusiveEnd); } else if (start) { /* ... */ } } catch (e) { if (e.name DataError e.code 0) { // data error, start is less than end return callback(null, { total_rows : totalRows, offset : opts.skip, rows : [] }); } else { return callback(errors.error(errors.IDB_ERROR, e.name, e.message)); } }IndexedDB 對任何 start 大于 end 的IDBKeyRange都會拋錯即使你正在反向迭代。當(dāng)時的繞法是手動檢查結(jié)束鍵if (manualDescEnd) { if (inclusiveEnd doc.key manualDescEnd) { return; } else if (!inclusiveEnd doc.key manualDescEnd) { return; } }代價很小只是多取一個多余的鍵而已。這個案例也提醒我們面對瀏覽器都這樣的行為先懷疑自己對規(guī)范的理解再懷疑瀏覽器。7. IndexedDB 與 Web SQL 對回調(diào)嚴(yán)防死守在 IndexedDB 和 Web SQL 中想在事務(wù)里用 Promise 甚至再調(diào)用一個回調(diào)都是奢望一旦控制權(quán)交還事件循環(huán)事務(wù)就自動關(guān)閉。所以用戶側(cè)的 PouchDB API 可以優(yōu)雅地 Promise 化得益于 Calvin Metcalf 的 lie 庫但 PouchDB 內(nèi)部代碼是徹底的回調(diào)地獄。文檔展示了當(dāng)時 IndexedDB 適配器約 400 行與 Web SQL 適配器約 400 行的縮影verifyAttachments(function (err) { if (err) { return callback(err); } /* ... */ });以及這種山寨版Promise.all()function checkDoneWritingDocs() { if (numDocsWritten docInfos.length) { complete(); } }如果需要調(diào)用 FileReader 這類外部回調(diào) API還必須小心翼翼地挪到事務(wù)之外于是出現(xiàn)preprocessAttachments()這類前置處理函數(shù)preprocessAttachments(function () { db.transaction(function (txn) { /* ... */ }); });作者的結(jié)論很實在如果我們沒有大量的集成測試我們幾乎不敢相信這些代碼能跑。 這正是 tests/integration 下數(shù)百個測試文件存在的意義——從 test.basics.js 到 test.attachments.js每一個行為都被瀏覽器矩陣反復(fù)驗證。8. 遞歸是把雙刃劍先看文檔引用的這段代碼// Unfortunately, the metadata has to be stringified // when it is put into the database, because otherwise // IndexedDB can throw errors for deeply-nested objects. // Originally we just used JSON.parse/JSON.stringify; now // we use this custom vuvuzela library that avoids recursion. // If we could do it all over again, wed probably use a // format for the revision trees other than JSON. function encodeMetadata(metadata, winningRev, deleted) { var storedObject {data: vuvuzela.stringify(metadata)}; storedObject.winningRev winningRev; storedObject.deletedOrLocal deleted ? 1 : 0; storedObject.id metadata.id; return storedObject; }這是一個影響所有瀏覽器甚至 Node.js 的刁鉆 bugissue 2543任何接受對象作為輸入的原生函數(shù)如JSON.stringify()或 IndexedDB 的put()對傳入對象的嵌套深度都有硬性上限var object { enhance: { enhance: { enhance: { /* and so on */ } } } };上限值隨可用內(nèi)存浮動一旦觸頂就會拋 too much recursion 或 maximum call stack 錯誤用戶得到的是一個崩潰的 PouchDB。深層嵌套的來源正是文檔的 revision tree——每次文檔更新都在樹上疊一個節(jié)點(diǎn)深度會無限增長。解法是作者與 Calvin 合寫的一個名字滑稽的非遞歸 JSON 庫 vuvuzela。它比原生方法慢但在絕不能崩潰的場景里是救命稻草。今天這個策略被保留在pouchdb-json包里優(yōu)先用原生JSON.stringify捕獲異常后才回退到 vuvuzelasafeJsonStringify.js#L1-L10import vuvuzela from vuvuzela; function safeJsonStringify(json) { try { return JSON.stringify(json); } catch (e) { /* istanbul ignore next */ return vuvuzela.stringify(json); } }對稱的 safeJsonParse.js 處理解析方向。這也是性能與健壯性二選一的典型工程決策先快崩了再慢而穩(wěn)地兜底。9. IndexedDB 中 unique index 拋約束錯誤keyPath 卻不拋這是又一個反直覺的設(shè)計讓作者大為意外。SQLite/Web SQL 中主鍵與唯一索引基本等價——重復(fù)插入都會報約束錯誤CREATE TABLE employees (id PRIMARY KEY UNIQUE, name); CREATE TABLE employees (id, name); CREATE UNIQUE INDEX id_index ON employees (id);但 IndexedDB 中帶主鍵keyPath的 object store 插入重復(fù)鍵不會報錯而是靜默覆蓋原記錄——put()本質(zhì)是 upsert。唯一索引則截然不同重復(fù)插入確實會拋錯。也就是說以下兩種寫法并不等價db.createObjectStore(employees, {keyPath : id}); db.createObjectStore(employees).createIndex(id, id, {unique: true});文末作者補(bǔ)充若想用 keyPath 也拿到約束錯誤可以用add()代替put()。這對數(shù)據(jù)庫設(shè)計的影響是結(jié)構(gòu)性的選用哪種模式直接決定了重復(fù)寫入是覆蓋還是報錯。PouchDB 之所以堅持用唯一索引而非裸 keyPath 來約束_doc_id_rev見第 5 節(jié)的createIndex(_doc_id_rev, _doc_id_rev, {unique: true})正是為了在寫入重復(fù)的 doc_id/rev 時能可靠地檢測沖突從而支撐 CouchDB 的 MVCC 修訂模型。讀者在實現(xiàn)自己的 IndexedDB 層時務(wù)必先想清楚自己要的是 upsert 語義還是沖突檢測語義。10. CouchDB 影響了 IndexedDBIndexedDB 影響了 LevelDB然后呢數(shù)據(jù)庫設(shè)計從來不是在真空中進(jìn)行的。文檔梳理了這條血脈Web SQL最初受Google Gears啟發(fā)——后者在 2008 年一度有望成為移動 Web 存儲標(biāo)準(zhǔn)兩者都離不開SQLite而 SQLite 創(chuàng)始人 Richard Hipp 坦言 SQLite 深受PostgreSQL影響盡管Web SQL 規(guī)范最終被廢棄它深刻影響了后輩 IndexedDB兩者共享異步結(jié)構(gòu)、自動關(guān)閉的事務(wù)和幾乎逐字復(fù)制的安全模型Mozilla 與 Apple 還各自獨(dú)立地把 IndexedDB 實現(xiàn)建在 SQLite 之上更妙的是IndexedDB 早期討論中就能看到CouchDB 的影子——complex keys、start/end key 迭代、類文檔數(shù)據(jù)模型皆源于此。IndexedDB 設(shè)計者 Nikunj Mehta 早在 2009 年就說有些人覺得 [IndexedDB] 很適合做一個 JavaScript 版 CouchDB。 某種意義上這就是 PouchDB 最早的理念宣言Google 又用 LevelDB 實現(xiàn)了 IndexedDB 規(guī)范LevelDB 借由 LevelUP 項目在 Node.js 生態(tài)中聲名鵲起。PouchDB 也順勢搭上了 LevelUP 的船在 Node.js 端用 LevelDB 實現(xiàn)了近乎完整的 CouchDB HTTP API即 PouchDB Server。這條鏈條在今天的倉庫中依然清晰可辨packages/node_modules下pouchdb-adapter-leveldb、pouchdb-adapter-memory、pouchdb-adapter-websql-core、pouchdb-adapter-idb等適配器并存見 packages/node_modules 目錄上層共享同一套 pouchdb-core 核心通過pouchdb-collate統(tǒng)一排序語義。從 IndexedDB 的早期討論經(jīng) LevelDB 與 LevelUP 生態(tài)最終匯成 PouchDB——當(dāng)我看 PouchDB 源碼時這個巨大的成就仍讓我起雞皮疙瘩。它足以讓你原諒所有古怪的 hack、workaround 和不優(yōu)雅。PouchDB 居然能跑起來這本身就是一個小小的奇跡。結(jié)語兼容性工程的通用方法論回顧這十個案例可以提煉出幾條放之四海皆準(zhǔn)的工程原則把嗅探降到最低把特性檢測用到極致getSize()的 UA 嗅探是少數(shù)不得不為之的特例而 Blob 支持、數(shù)據(jù)庫編碼等判斷全部靠運(yùn)行時特性檢測完成為已知 bug 寫注釋、留鏈接parseHex.js頭部保留的 Chromium/WebKit bug 編號讓十年后的維護(hù)者依然知道為什么會有這段看起來多余的代碼用平凡的編碼技巧替代缺失的平臺能力_doc_id_rev字符串拼接、toIndexableString的保序編碼都是底層做不到就自己造輪子的典范性能與健壯性分層兜底safeJsonStringify先快后慢的降級策略是深度嵌套問題的標(biāo)準(zhǔn)解法懷疑規(guī)范、懷疑自己、懷疑瀏覽器最后相信測試第 6 條的反轉(zhuǎn)說明連核心維護(hù)者都會誤讀規(guī)范而 tests/integration 的龐大測試矩陣才是 PouchDB 能在如此多的瀏覽器上存活下來的真正底牌。對于今天仍在瀏覽器存儲領(lǐng)域耕耘的開發(fā)者這些來自 2014 年的教訓(xùn)并未過時——IndexedDB 的怪癖依然存在新的存儲 API如 OPFS、Storage Buckets也正在孕育自己的 quirks。讀懂 PouchDB 當(dāng)年如何馴服這些怪癖就是為下一場兼容性戰(zhàn)役做的最好準(zhǔn)備。【免費(fèi)下載鏈接】pouchdb:kangaroo: - PouchDB is a pocket-sized database.項目地址: https://gitcode.com/gh_mirrors/po/pouchdb創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考