一萬個標題,搜尋仍然不拖
排程中閱讀時間 2 分鐘 作者 NT²
你存到第兩千筆。列表還能捲——但搜尋不該每次打字都把整份財務人生載入記憶體。
第二千筆的感覺不一樣
保管箱的第一版很寬容。五十組憑證、幾筆銀行紀錄、護照掃描——你還記得東西在哪。
幾年過去。副業、報稅資料夾、硬體錢包、保險續約、早就忘了還在的客戶 API 金鑰。問題不再是「我貼在哪?」而是 「壓力下找一個欄位時,app 還能即時嗎?」
若答案是否定的,人們會回到截圖、桌面檔案與聊天串。效能不是跑分炫耀——而是較安全的習慣能否撐過成長。
我們在 一萬個項目,仍然是保管箱 先點出產品邊界。本文再深一層:NT² 如何設計列表與搜尋,讓保管箱在裝置上 scale 時仍可用。
載入一頁,不是整個閣樓
筆記 app 或試算表常把「打開保管箱」當成「渲染全部」。NT² 把保管箱當 本機資料庫 的結構化列:
| 習慣 | 「全部載入」路徑 | 分頁保管箱路徑 |
|---|---|---|
| 打開列表 | 記憶體隨每筆資料成長 | 分頁列表 — 一次一屏列 |
| 搜尋 | 用 JavaScript 掃每個標題 | SQLite 全文搜尋 標題——不必載入完整 payload |
| 打開項目 | 點擊才解密 | 需要時才解密 一筆 |
| 敏感 payload | 與列表 UI 混在一起 | 加密 blob 與列表中繼資料分離 |
| 離線 | 依賴同步完成 | 本機優先 — 索引在 OPFS 儲存的本機資料庫 |
你不是要求 UI 在 RAM 裡握著一萬筆解密秘密,只為了找一組 IBAN。
結構為何幫助搜尋
類別不是裝飾。Credential 列與 Document 列搜尋方式不同,因為欄位有語意:
- Bank 項目暴露機構與帳號標籤——不是長備忘錄第三段。
- Document 項目在可預期位置放發證機關與效期。
- Crypto 項目在複製前保持助記詞遮罩。
這種形狀餵給搜尋與篩選。「Stripe production key」是標題與範本——不是長文裡的針。
NT² 也把附件當加密 blob,中繼資料在 SQLite。列表與搜尋關於 你要找什麼;開項目時才載入較重的 ciphertext。
上線前的誠實說明
NT² Vault 仍在積極開發,尚未對公眾開放。數量與上限可能在 launch 前調整;本文描述的是 設計意圖——本機索引、分頁讀取、搜尋不必載入整個保管箱——不是基準測試表。
若你在評估結構化保管箱能否取代「數位閣樓」,值得問的問題很簡單:找一筆紀錄是否仍然從容? 這是我們在優化的方向。
進一步了解
- 成長故事(首篇): 一萬個項目,仍然是保管箱
- 類別教育: 不是另一個密碼管理員登入
- 產品支柱: nt2.me/zh-TW/about
- 訂閱部落格: RSS 摘要
當 NT² 在 se.nt2.me 上線,保管箱第十年仍應從搜尋開始——而不是捲到拇指投降。
最後更新 2026-11-13
相關故事
- 一萬個項目,仍然是保管箱
閱讀時間 1 分鐘
- 換了 Ledger,還是寫進 Apple 備忘錄
閱讀時間 2 分鐘
- 領事館沒訊號,護照資料在哪
閱讀時間 2 分鐘