把书存在浏览器里靠谱吗：IndexedDB 的配额、驱逐，和为什么必须导出备份

Q: 浏览器到底给一个网站多少存储空间？

按剩余磁盘空间的比例给，不是一个固定数字。大致规律：主流浏览器会把整机可用空间的相当一部分作为所有站点共享的池子，再给单个站点一个上限，实际能用到的空间通常是几百 MB 到几个 GB，磁盘快满时会显著缩水。怎么查自己的：控制台执行 await navigator.storage.estimate()，返回 quota（配额）和 usage（已用），单位是字节。对电子书的意义：一本中文长篇 TXT 通常 5 – 15 MB，带插图的 EPUB 二三十兆，所以几十本书一般不成问题；真正的风险不是装不下，是被清掉。还有一点：配额是按「站点」算的，同一个域名下所有页面共用。

Q: navigator.storage.persist() 有用吗？

有用，但它是「请求」不是「设置」。两种模式：(1) best-effort（默认） —— 浏览器在磁盘压力下可以自行回收这个站点的数据；(2) persistent —— 除非用户主动清除，否则不会被自动驱逐。怎么申请：await navigator.storage.persist() 返回布尔值，表示有没有拿到。批准与否不由你决定：浏览器会看这个站点的「参与度」——有没有被安装成 PWA、是否被加为书签、用户访问得频不频繁。冷不丁弹一次请求，多半会被拒。要点：(1) 用 navigator.storage.persisted() 查当前状态；(2) 拿到持久化也不等于永不丢失 —— 用户清理浏览器数据、卸载浏览器、换设备，数据照样没；(3) 它不能替代备份，只是把「可能被自动回收」这一条风险去掉。

Q: 哪些操作会让存在浏览器里的书消失？

五种，其中两种用户自己完全察觉不到。主动的三种：(1) 清除浏览记录时勾选了「Cookie 及其他网站数据」或「缓存的图片和文件」；(2) 在站点设置里点「清除数据」；(3) 用无痕/隐私窗口——那里的数据在窗口关闭时就没了。被动的两种：(4) 磁盘空间不足时的自动驱逐 —— 浏览器按最近最少使用的顺序回收 best-effort 站点的数据；(5) Safari 的七天规则 —— 对脚本可写的存储（IndexedDB、localStorage 等），七天内没有再访问这个网站就会被清除，这一条在 iPhone、iPad 上最容易中招，而且没有任何提示。结论：把浏览器存储当缓存看，不要当归档看。

Q: 换设备怎么把书带过去？

只能靠导出文件，没有别的路。原因：IndexedDB 是按「浏览器 + 设备」隔离的，Chrome 和 Edge 算两个、无痕窗口又算一个，彼此看不到对方的数据，也没有任何自动同步。做法：在书架上用「导出全部」打包下来，导出的是标准 EPUB，然后在新设备上重新导入。进度不会跟着走 —— 阅读位置存在原设备的浏览器里，新设备要从头找。这是纯本地方案的代价，换来的是书和阅读记录完全不上传。建议的节奏：(1) 导入一批新书之后立刻导一次；(2) 每隔一两个月导一次；(3) 导出的 EPUB 丢进网盘或移动硬盘——那才是归档，浏览器里那份只是随手在读的副本。

EPUB/TXT 阅读器没有账号、没有服务器，书从选中的那一刻起就只在你的浏览器里。这是它隐私上最大的优点——也意味着数据的安全完全由浏览器的存储规则决定。

这些规则比多数人以为的宽松，也比多数人以为的脆弱。

数据存在哪

网页能用的持久化存储有几种，容量差着数量级：

机制	容量	适合
Cookie	4 KB	什么都装不下
localStorage	约 5 – 10 MB	设置项、草稿
IndexedDB	按配额，通常几百 MB 到几 GB	文件、大对象

所以电子书这类东西只能放 IndexedDB。它是结构化的、异步的、能存二进制大对象（Blob），一本带插图的 EPUB 直接整个塞进去没问题。

查自己当前的额度，控制台一行：

const { quota, usage } = await navigator.storage.estimate();
console.log((usage / 1048576).toFixed(1) + ' MB / ' + (quota / 1048576).toFixed(0) + ' MB');

配额不是一个固定数字，按剩余磁盘空间的比例给，磁盘快满时会显著缩水。而且它是按「站点」算的，同一个域名下所有页面共用。

对电子书来说，装不下几乎不是问题——一本中文长篇 TXT 通常 5 – 15 MB，带插图的 EPUB 二三十兆。真正的风险是被清掉。

两种存储模式

await navigator.storage.persisted();   // 查当前状态
await navigator.storage.persist();     // 申请持久化，返回是否拿到

模式	含义
best-effort（默认）	浏览器在磁盘压力下可以自行回收
persistent	除非用户主动清除，否则不会被自动驱逐

persist() 是请求，不是设置。批不批由浏览器按站点「参与度」判断——有没有被安装成 PWA、是否被加为书签、用户访问得频不频繁。冷不丁弹一次请求，多半会被拒。

而且要说清楚：拿到持久化也不等于永不丢失。用户清理浏览器数据、卸载浏览器、换设备，数据照样没。它只是去掉了「可能被自动回收」这一条风险。

五种会让数据消失的情况

用户主动的三种（至少还知道自己做了什么）：

清除浏览记录时勾选了「Cookie 及其他网站数据」「缓存的图片和文件」
在站点设置里点「清除数据」
用无痕 / 隐私窗口 —— 那里的数据在窗口关闭时就没了

用户完全察觉不到的两种：

磁盘空间不足时的自动驱逐 —— 浏览器按最近最少使用的顺序回收 best-effort 站点的数据。不常见，但确实会发生
Safari 的七天规则 —— 对脚本可写的存储（IndexedDB、localStorage 等），七天内没有再访问这个网站就会被清除

第 5 条最值得单独强调：它在 iPhone 和 iPad 上最容易中招，没有任何提示，而且「我只是两周没看书」正好符合触发条件。

所以一句话：把浏览器存储当缓存看，不要当归档看。

换设备：只能靠文件

IndexedDB 是按「浏览器 + 设备」隔离的：

Chrome 和 Edge 算两个独立的存储空间
无痕窗口又算一个
没有任何自动同步

所以换设备只有一条路：在书架上用「导出全部」打包下来，导出的是标准 EPUB，在新设备上重新导入。

阅读进度不会跟着走——它存在原设备的浏览器里。这是纯本地方案换隐私的代价，值得提前知道，免得以为是功能缺失。

（进度本身记的不是页码而是 EPUB CFI，一个指向「第几章第几段第几个字」的位置串，所以在同一台设备上改字号、换行距、横竖屏切换，回到的都是原来那句话。跨设备是另一回事。）

一个能落地的备份节奏

导入一批新书之后立刻导一次 —— 这时候你正好在这个页面上
每隔一两个月导一次
导出的 EPUB 丢进网盘或移动硬盘 —— 那才是归档，浏览器里那份只是随手在读的副本
Safari 用户额外注意：长期不打开会被清，重要的书别只放在那儿

补一句：导出的是标准 EPUB，任何阅读器都能打开，不存在被这个工具锁住的问题。这也是它把 TXT 也在本地合成 EPUB 再存的一个副作用——备份出来的永远是通用格式。