grimmory
grimmory-tools/grimmory加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
你是否有过这样的经历：买了几百本电子书，却散落在硬盘的各个角落，找起来费时费力；或者是订阅了多个平台，却发现某本书在一个平台下架，从此再也找不到。随着数字阅读的普及，如何有序管理自己的藏书，同时不被平台绑架，成了许多阅读爱好者共同的痛点。
Grimmory 正是为解决这些问题而生。它是一个完全开源、可自托管的数字图书馆平台，支持电子书、PDF、漫画、有声书等多种格式，内置浏览器阅读器，支持 Kobo 阅读器同步、OPDS 标准协议，以及多用户协作管理。你可以把它理解为一个「Personal Netflix」，只不过里面放的不是电影，而是你真正拥有的书籍。
Grimmory 的故事要从 Booklore 说起。Booklore 是一款曾在树莓派社区和自托管爱好者中颇受欢迎的电子书管理工具，但由于原始维护者长期缺乏更新，社区积累了大量功能需求和改进意见始终没有得到响应。
2024 年，一批深度用户决定不再等待 fork 了 Booklore，成立了 grimmory-tools 社区，正式启动了 Grimmory 项目。作为一个独立社区维护的分支，Grimmory 从一开始就将「长期可持续发展」和「社区治理透明化」作为核心原则——项目导入了 AGENTS.md、GOVERNANCE.md、SECURITY.md 等治理文档，建立了 Discord 社区和明确的贡献者协议，确保项目不会因为单一维护者的离开而陷入无人维护的困境。
这种社区驱动的模式让 Grimmory 在短短一年内就积累了超过 3000 颗 GitHub Stars，Docker Hub 拉取量持续增长，并获得了 Railway、Coolify 等主流部署平台的一键部署模板支持。
Grimmory 采用典型的 前后端分离架构，技术选型在数字图书馆工具中相当硬核：
后端：基于 Spring Boot 3（Gradle 构建，Java 25）构建，这一选择在同类项目中颇为大胆——主流电子书管理工具多选用 Python 或 Node.js，而 Grimmory 选择 Java 主要看中其企业级的稳定性和 MariaDB 数据库连接池的高性能。JVM 调优参数也相当专业：使用了 Shenandoah GC 算法（延迟敏感型工作负载的理想选择）、MaxRAMPercentage=60% 的容器感知配置，以及 -XX:+ExitOnOutOfMemoryError 的防雪崩设计。后端服务暴露在 6060 端口，提供 RESTful API 和 OpenAPI 文档（需手动开启）。
前端：采用 Angular 18+ 构建，配合 PWA（Service Worker）支持离线缓存和推送通知能力。这是一个重量级选择——相比 React/Vue，Angular 的优势在于强类型约束和大型项目的可维护性，但也意味着开发门槛更高。
数据库：使用 MariaDB 作为主存储，通过 JDBC 连接。README 提供了完整的数据库迁移说明，支持从旧版 Booklore 无缝升级。
容器化：提供完整的多阶段 Dockerfile，架构如下：前端 Node 24 构建（Angular 生产构建）→ Gradle 后端编译（含前端产物嵌入 JAR）→ 最终镜像基于 eclipse-temurin JRE 25 Alpine，集成了 ffmpeg（用于音视频元数据提取）和 kepubify（Kobo 专用格式转换）工具。最终镜像支持 AMD64 和 ARM64 双架构，可在树莓派、NAS、Mac 等多种硬件上运行。
图1：Grimmory 社区维护团队
Grimmory 的功能设计围绕三个核心场景展开：整理、阅读、同步。
传统图书馆软件的书架是静态的，你必须手动将每本书拖进去。Grimmory 的「魔法书架」（Magic Shelves）支持基于规则的动态过滤：你可以定义「所有未读的科幻电子书」「过去一年添加的 PDF」「评分 4 星以上的漫画」等规则，书架内容自动随藏书库变化而更新。这对于藏书量超过 500 本的用户来说，节省了大量手动维护成本。
Grimmory 支持从 Google Books、Open Library 和 Amazon 三大数据源自动拉取书籍封面、简介、评分和评论。用户上传一本 EPUB 后，系统会自动联网查询并填充元数据，全程无需手动输入。当然，Grimmory 也允许用户手动编辑所有元数据，确保个人信息不被覆盖。
这是 Grimmory 最吸引人的功能之一。你不需要额外安装 Calibre 或第三方阅读器，直接在浏览器里打开即可阅读 EPUB、PDF 和漫画（CBZ/CBR）。阅读器支持：
对于漫画阅读，Grimmory 还支持左右滑动或连续滚动模式，适配不同阅读习惯。
Grimmory 不是一个孤立的 Web 应用，它设计了一个完整的设备同步生态：
| 同步方式 | 说明 |
|---|---|
| Kobo 同步 | 原生支持 Kobo 设备，阅读进度和笔记双向同步 |
| KOReader 同步 | 支持 KOReader 第三方固件的进度同步 |
| OPDS 协议 | 任何 OPDS 兼容的阅读 App（如 Moon+ Reader、MapMap）均可访问 Grimmory 的藏书目录 |
| Kindle 推送 | 一键将书籍推送到绑定的 Kindle 邮箱 |
| 邮件分享 | 任意邮箱地址均可接收书籍分享 |
这是最能体现 Grimmory 设计哲学的功能。用户只需配置一个「监视文件夹」，将电子书文件拖入其中，Grimmory 会自动检测文件格式、联网查询元数据、分类入库，并等待你确认后完成导入。整个流程零手动操作，对于习惯用 Calibre 管理藏书但想要更好 Web 体验的用户来说，堪称完美升级路径。
Grimmory 的部署友好度在同类开源图书馆工具中属于顶级水准。
生产部署只需要三步：创建 .env 配置文件 → 复制 docker-compose.yml → docker compose up -d。项目提供了生产级 docker-compose.yml，内置 MariaDB 服务、健康检查、资源限制和重启策略。对于已有 Booklore 部署的用户，Grimmory 提供了完整的迁移路径——只需替换 Docker 镜像名称，现有数据、配置和服务名均可无缝保留。
进阶部署方面，Railway 和 Coolify 提供了一键部署模板，Helm Chart 支持 Kubernetes 集群部署，Unraid 用户还有专用的 XML 模板，照顾到了几乎所有主流的自托管场景。
开发调试方面，dev.docker-compose.yml 提供了带热重载的开发环境：前端 Angular Dev Server（端口 4200）和后端 Spring Boot（端口 6060）独立运行，远程调试端口 5005 对外开放，数据库使用 Docker Compose 自带的 MariaDB。对于 Java 开发者来说，.sdkmanrc 文件锁定了 SDK 版本（Java 25），确保团队成员使用一致的构建环境。
没有项目是完美的，Grimmory 也有一些值得关注的局限：
1. 资源占用相对较高。相比 Calibre-web 等轻量级方案，Grimmory 需要同时运行 Java 后端、Angular 前端构建产物和 MariaDB 三件套，最低 2GB RAM 推荐。树莓派 3 等低性能设备上运行可能会感到吃力，建议使用树莓派 4（4GB+）或 NAS 设备。
2. Android 原生阅读体验有限。虽然 Grimmory 支持 OPDS 协议访问任何第三方阅读 App，但内置的浏览器阅读器在手机上体验不如专业阅读 App。如果你的主力阅读设备是手机而非 Kobo 或电脑，可能需要搭配 Moon+ Reader 等专业 App 使用 OPDS 访问。
3. 社区仍在成长中。相比 Calibre 十余年的积累和丰富的插件生态，Grimmory 目前插件机制尚不完善，扩展能力有限。对于需要高度自定义工作流的用户，可能还需要等待生态成熟。
4. Java 25 的激进版本策略。项目使用 Java 25（尚未正式发布，目前为 Early Access 版本），虽然这是 JVM 爱好者眼中的优势，但也意味着在某些 LTS 优先的生产环境中可能引发兼容性和维护担忧。
Grimmory 的出现代表了一个重要趋势：数字阅读领域的「自托管运动」正在加速。
长期以来，电子书用户面临两难选择：要么依赖亚马逊、豆瓣阅读等商业平台（面临内容下架、服务关闭风险），要么使用 Calibre 等桌面工具（功能强大但缺乏跨设备同步能力）。Grimmory 试图在两者之间找到平衡点——提供接近商业平台的多设备同步体验，同时保持完全的开源透明和数据自主。
其社区驱动的治理模式也值得关注。与许多个人开发者维护的开源项目不同，Grimmory 从一开始就建立了正式的社区治理结构，包括贡献者协议、安全响应政策和公开的决策记录。这种结构虽然增加了运营成本，但为项目的长期可持续性提供了制度保障。
如果你对 Grimmory 感兴趣，建议按以下路径体验：
docker compose（需要 Docker 环境），约 5 分钟即可看到完整的 Web 界面dev.docker-compose.yml 启动开发环境，Angular 前端 + Spring Boot 后端的组合对全栈开发者是很好的学习素材