ReadAny 本地數據放在哪、怎麼帶走：一篇備份與遷移手冊

ReadAny 本地優先，不代表數據自動安全

ReadAny下載 是一款把 AI 對話和電子書閱讀器結合在一起的應用——用 Tauri + Rust 做跨平台殼，後端邏輯跑 Rust，UI 用 React，數據全存本地 SQLite。書籍導入時自動做語義分塊和向量嵌入，之後語義搜索和 RAG 對話（檢索增強生成）都能離線跑，AI 對話本身也能接本地 Ollama。這種「本地優先」架構的好處顯而易見：速度快、隱私不經過任何官方伺服器、斷網照樣能用。

但我前幾年用過另一款主打雲同步的閱讀器，服務關停那天，手機上的高亮和筆記全丟了——所以對「本地優先」這四個字一直保持戒心。本地優先的意思是數據不經過任何第三方，但也意味著你不主動備份，它就安靜躺在那塊硬碟上，硬碟壞了就沒了。這篇就按我踩過的坑整理：ReadAny 的數據到底存在哪、哪些要自己操心、換設備時哪些環節容易斷，以及哪天不想用了數據能不能帶走。

安裝

ReadAny官網 目前（v1.2.0）Android APK 大小 42.84M，包名 com.readany.app。首次啟動會跑設置嚮導，四步走完就能進主界面：選界面語言（簡中/英文等多語種）→ 可選配 AI 提供商（填 API 金鑰，或跳過之後在設置面板裡配）→ 選書庫存儲位置（預設用戶數據目錄，也能自訂到其他磁碟或分區）→ 選是否開啟同步（WebDAV / S3 / 局域網三種預設全關，按需開）。移動版（Android / iOS）不支援監控目錄自動掃描，但配好 WebDAV 後就能跨設備同步高亮和筆記。

數據都存在哪裡

ReadAny 的核心數據全部存在本地 SQLite 資料庫裡。從 ReadAny文檔 的技術架構文檔看，這一個 SQLite 同時扛著書籍元數據（書名、作者、封面）、高亮、筆記、閱讀進度，還有 RAG 管道生成的向量索引——後者是語義搜索和 AI 對話的基礎，向量索引在本地建完之後，離線也能正常跑。這點和很多雲端閱讀器不同：那些服務把高亮和筆記存在自家伺服器，你想帶走得找導出功能，ReadAny 則從設計上就是本地持有。

但有兩樣東西預設不同步，得你自己操心：

• 書籍文件本身（EPUB / PDF / MOBI 等，版權考量預設不跨設備搬）
• AI 對話歷史（隱私原因預設不同步到任何地方）

這兩樣一個要手動搬，一個文檔裡寫得不算清楚後面能不能導出——標未驗證，放在退路評估部分再說。

三條備份路徑怎麼選

ReadAny 給了三條同步路徑，從完全自建到最簡單都有覆蓋。三條都只同步元數據、高亮、筆記和閱讀進度——書籍文件本身仍需手動搬運，同步範圍是設計好的。

WebDAV 是最推薦的選擇。堅果雲（國內訪問速度快）、Nextcloud（自建）、OneDrive 等幾乎所有支持 WebDAV 的服務都能用。配置路徑很直觀：設置 → 同步 → 添加同步服務 → 選 WebDAV → 填 WebDAV 位址（通常是 https://你的伺服器/webdav）、帳號和密碼 → 勾選要同步的內容（書庫元數據 / 高亮 / 筆記 / 閱讀進度，四項可單獨開關）→ 測試連線 → 保存。通用性最強，自己掌控數據，國內用戶堅果雲速度最快。

S3 對象存儲適合已有雲端基礎設施的用戶。Cloudflare R2 等免費 S3 兼容存儲都能接，也能直接用 AWS S3。配置：設置 → 選 S3 → 填 Access Key、Secret Key、Bucket 名稱 → 選區域和 Endpoint（非 AWS 服務要自定 Endpoint）。如果你已經在 R2 或 S3 上存了不少資源，這條路徑成本低、和現有基礎設施打通自然。

局域網同步零成本零隱私顧慮。兩台設備在同一 WiFi 下直接走區網，數據不出家門。一台設備做「服務端」（通常選桌面端）開啟局域網同步，另一台在同一網絡下自動發現並連接，第一次配對要輸入配對碼。適合家庭場景、設備基本固定在同一網絡的用戶。

同步時如果同一本書在兩台設備上都有修改，ReadAny 採用智能合併策略：新增的高亮和筆記兩邊都保留；修改過的筆記保留最新時間戳版本；刪除操作以「最後一次操作」為準；極端衝突（兩邊都改了同一段且內容差異大）則保留兩份並加上後綴區分，讓你手動選擇留哪份。

預設 5–15 分鐘後台同步一次（可配置間隔），也能手動點「立即同步」按鈕觸發。移動版可以設「僅 WiFi 下自動同步」避免消耗移動數據。

換設備遷移的斷點與繞路

換手機或換電腦時，ReadAny 的遷移大方向清晰，但有幾個容易斷的環節值得提前知道。

書籍文件要自己搬。同步機制預設不同步 EPUB / PDF 文件，所以遷移第一步是用 USB 連線或雲盤把你書庫裡的書籍文件搬過去，然後在新設備上打開 ReadAny 重新導入。導入過程不是簡單複製：ReadAny 會重新解析格式、提取封面、生成向量嵌入（如果你配置了嵌入模型）——向量化這步對長書可能要幾十秒，走雲端 API 會消耗對應的配額，用本地 Ollama 就純吃 CPU。

iOS 和 Android 的導入路徑不一樣。iOS 要先把書籍存到「文件」App 的 ReadAny 目錄裡，或在其他閱讀器 App 裡選「用 ReadAny 打開」；Android 則直接從系統文件管理器選文件就行。移動版都不支援監控目錄自動掃描，書籍搬過去後得手動觸發導入。

向量索引要重建。新設備上書籍文件重新導入後，ReadAny 會自動重新做語義分塊和向量嵌入。這點文檔沒寫，但從架構上推斷：向量索引是跟著書籍文件在本地生成的，不會跟著同步機制一起跨設備搬——否則就是 ReadAny 把你整個向量索引傳到雲端了，和本地優先的設計相悖。

AI 對話歷史不跟著同步。這項文檔明確說了不同步，所以遷移後對話記錄會斷。如果你在意對話記錄的價值，得看 ReadAny 有沒有對話歷史的導出功能——目前文檔沒提到任何導出入口，標未驗證，建議裝完先測一次。

哪天不用了，數據能不能帶走

這是我最在意的部分——很多應用的導出功能藏得很深，或乾脆沒有。ReadAny 的文檔在這點上寫得不算完整，幾條能確定：

SQLite 資料庫是標準格式，可以直接導出整個資料庫文件。裡面有高亮、筆記、閱讀進度和向量索引。具體路徑隨平台不同而異：桌面端在 Tauri 應用的數據目錄下（macOS 在 ~/Library/Application Support/com.readany.app/ 一類的路徑，Windows 在 %APPDATA%\com.readany.app\），Android 在應用私有目錄裡（需透過 adb 備份或 root 後從 /data/data/com.readany.app/ 拉出）。

同步到 WebDAV / S3 的數據可以直接從對應服務端拉出，完全不需要經過 ReadAny 本身。這條路徑是用戶掌控數據最實在的兜底——你只要記得 WebDAV 服務端自己的帳密就行。

AI 對話歷史文檔說不同步，那本地有沒有完整存儲、能不能導出——標未驗證。建議如果對話歷史對你有價值，先在一台設備上產生幾條對話，然後用文件管理器翻進應用目錄看一下有沒有對話記錄文件。

結論

ReadAny 的本地優先架構在性能和隱私上給了很大的空間，但代價是數據自主度完全取決於你有沒有提前建備份習慣。WebDAV 是目前最穩妥的選擇，書籍文件和對話歷史這兩塊預設不跟著同步的要自己操心——特別是 AI 對話歷史的導出路徑目前文檔沒說清楚，建議裝完先測一次再深度用。

本文为个人基于网络公开资料整理编写，非官方内容，仅供学习交流参考；软件版权归原作者所有，请支持正版；使用过程中遇到问题请查阅官方渠道，本文不承担任何责任。