排程中
閱讀時間 7 分鐘 作者 NT²
來自一萬筆項目 OPFS 保管箱的基準測試
技術文章
大型本機保管箱不是靠一句口號證明的。它靠的是量測人們實際使用的路徑—— 解鎖後的第一頁、防抖搜尋、FTS 與篩選查詢——並誠實說明這些數字不代表什麼。
標籤: sqlite
11 篇文章
排程中
閱讀時間 7 分鐘 作者 NT²
同一套保管箱 UI：瀏覽器、PWA 與桌面／行動殼層
技術文章
解鎖、列表、搜尋與設定不該裂成三個產品。NT² Vault 維持一套保管箱 UI， 讓每個殼層只負責平台必須擁有的事：耐用檔案如何落在該裝置上。
排程中
閱讀時間 7 分鐘 作者 NT²
保管箱設定檔是區段鍵值存放，不是一列巨無霸
技術文章
鹽值、保管箱金鑰 DID 公開材料、同步游標與引導偏好，不是同一列肥大的 SQL。它們以具名的 保管箱設定檔區段存在——讓備份、同步與解鎖各自只碰需要的部分。
排程中
閱讀時間 7 分鐘 作者 NT²
結構描述 v60 與漸進式遷移
技術文章
本機保管箱是裝置上的真正 SQLite 資料庫。當產品推出結構描述 v60 時，上線時期的保管箱必須就地升級——不能因為原始碼裡的 CREATE 語句變了，就強迫清除重建。
排程中
閱讀時間 7 分鐘 作者 NT²
SQLite 放在 Web Worker 裡，不是選配
技術文章
本機優先保管箱需要裝置上真正的關聯式引擎。若把引擎放在 UI 執行緒， 每一次分頁查詢都會與繪製、輸入搶資源。NT² Vault 在 Web Worker 中執行 SQLite，外層是型別化訊息與單一鎖鏈，讓列表在資料庫保持誠實的同時仍能回應。
排程中
閱讀時間 7 分鐘 作者 NT²
每個分頁一個已解鎖保管箱——刻意如此
技術文章
在兩個瀏覽器分頁開啟同一個保管箱很平常。讓兩個分頁同時寫入同一份本機 SQLite 檔案則否。NT² Vault 選出一個寫入者，並讓其他已解鎖分頁當跟隨者。
排程中
閱讀時間 6 分鐘 作者 NT²
中繼資料在 SQLite，密文在 BlobStore
技術文章
保管箱需要知道哪些檔案屬於哪些項目、它們有多大、以及如何解開金鑰。 它不需要把那些加密位元組塞進負責回答這些問題的關聯式資料庫裡。
排程中
閱讀時間 7 分鐘 作者 NT²
標題用 FTS5；篩選勝出時走表掃描
技術文章
本機搜尋不是單一查詢形狀。自由文字需要標題與搜尋文字的全文索引。 類別、垃圾桶、封存等篩選需要一般的表條件。產品會切換策略， 讓介面不必把整個保管箱塞進記憶體，也能感覺可搜尋。
排程中
閱讀時間 7 分鐘 作者 NT²
永遠不要把整個保管箱載入 Svelte state
技術文章
本機保管箱可以保存數千筆結構化項目，卻不必變成巨大的記憶體內陣列。 耐用的真實資料留在 SQLite。介面只持有一分頁的輕量列表列， 並透過虛擬列表渲染。
排程中
閱讀時間 8 分鐘 作者 NT²
為什麼我們將保管箱的 SQLite 資料庫放在 OPFS，而非 IndexedDB
技術文章
SQLite 需要的是檔案。隱私保管箱需要耐用的關聯式儲存，而且隨著項目、索引與加密附件增加， 效能仍須保持穩定。以 IndexedDB 承載 SQLite 虛擬檔案系統，確實能連接這兩個世界， 但這座橋也會介入每一次資料庫操作。對 NT² Vault 而言，瀏覽器中的保管箱檔案應該放在 Origin Private File System。
閱讀時間 5 分鐘 作者 NT²
為什麼選擇 PWA 本地優先、零伺服器的 Vault
技術文章
在雲端優先應用當道的時代，我們往往忽略了一個強大的替代方案：漸進式網頁應用（PWA）。當現代瀏覽器已經能在使用者裝置上完整執行高效、安全、高效能的應用時，為什麼還要維運一套沉重、昂貴且可能成為攻擊面的伺服器基礎設施？