Calibre-Web 适合阅读和轻管理，前提是书库来源合法、metadata.db 受保护、导入流程保持单一。

\n
我把 Calibre-Web 定位成合法自有或授权电子书库的 Web 阅读入口，而不是书库生产工具。原始书籍、封面和元数据先在固定流程里整理好，Calibre-Web 负责浏览、搜索、阅读和少量用户管理。它越轻，越不应该让它和多个写入工具一起抢同一个书库。

电子书库最值钱的不只是文件本身，还有 metadata.db。作者、标题、系列、标签、封面、格式信息都在那里。这个数据库一乱，页面还能打开，但书库体验会明显变差。

先确认书库来源和边界

我的书库只放自有、公开授权或已经获得合法授权的电子书。这个边界要写在目录说明里，也要影响导入流程。来源不清的文件不进入主库，临时整理目录和正式书库目录分开。这样后续备份、迁移和分享阅读入口时，才不会把不该混入的内容带进去。

Calibre-Web 不适合承担“什么文件都先扔进去再说”的角色。它面对的是已经整理过的书库，而不是杂乱的收件箱。

metadata.db 是核心资产

Calibre 书库通常包含 metadata.db，这是书库索引和元数据的核心。只备份 .epub、.pdf 这类文件还不够，恢复后作者、系列、标签、封面和排序都可能丢失或错乱。我会把整套书库目录作为备份对象，而不是只挑书籍文件。

备份时要避开写入窗口。桌面 Calibre 正在导入，Calibre-Web 正在修改元数据，或者脚本正在整理目录时，都不适合做关键备份。最稳的方式是固定导入窗口，导入完成后再做一次完整备份和校验。

Web 侧尽量只读挂载

如果 Calibre-Web 只是阅读和搜索入口，我倾向把书库用只读方式挂载进去，例如 /srv/books:/books:ro。这样即使 Web 侧配置出错，也不容易误改原始书库。用户、权限、界面设置等应用状态放在单独配置目录里，和书库目录分开备份。

只读挂载不是绝对要求，但它能减少很多意外。尤其是家里还有桌面 Calibre 负责整理时，多个工具同时写 metadata.db 是最该避免的事情。一个主写入者，其他入口只读，是我认为最省心的结构。

导入流程必须单一

新增书籍最好只有一个入口。比如先进入临时整理目录，在桌面 Calibre 里检查标题、作者、封面和格式，再进入正式书库。不要今天用 Web 导入，明天用桌面端导入，后天又用脚本改目录。工具越多，元数据越容易出现细小但难查的差异。

如果确实需要批量导入，我会先复制一份测试书库，确认格式、命名和元数据没有问题，再对主库操作。导入完成后，打开 Calibre-Web 检查搜索、分类和封面显示，而不是只看文件夹里多了文件。

搜索异常不要先重建容器

Calibre-Web 页面能打开但搜索不准，通常不该第一时间重建容器。先看书库路径是否正确，metadata.db 是否存在，容器是否有读取权限，应用配置里指向的是不是同一个书库。路径映射如果有多个别名，很容易让 Web 侧读到旧目录。

docker compose config
docker inspect calibre-web --format '{{json .Mounts}}'
find /srv/books -maxdepth 2 -name metadata.db -ls
ls -ldn /srv/books
docker compose logs --tail=120 calibre-web

这些检查能先判断问题在书库、路径、权限还是应用配置。只有确认数据层没问题，再考虑应用索引或容器本身。

备份要覆盖书库和配置

我会备份两类东西：正式书库目录和 Calibre-Web 配置目录。书库目录里有书籍文件、封面和 metadata.db；配置目录里有用户、权限和应用设置。两者缺一块都不能算完整恢复。

升级前我也会先打开书库做一次抽查：随机找几本书，看封面、作者、标签、格式和阅读入口是否正常。升级后重复同样的抽查，比只看容器状态更能发现元数据或路径问题。如果书库是只读挂载，升级风险会小很多，因为 Web 侧不容易误改核心文件。

Calibre-Web 的价值在于让家里的电子书库更方便访问，而不是让维护链路更复杂。合法来源、只读挂载、单一导入流程、完整备份，这四点做好以后，它就是一个很安静的阅读入口。否则书库越大，元数据问题越难收拾。