告别4个服务只留1个，Jellyfin 12凭一个插件让我的小主机负载直降四成

我这台迷你小主机里，四年间始终跑着四个独立服务：一个管电影电视剧，一个管电子书，一个管漫画，还有一个专门管有声书。每个服务都有自己的端口、账户和元数据抓取逻辑。同一批磁盘上的文件，被四个进程各扫一遍，同一台瘦小的 Debian 虚拟机硬是被拆成了四家“专营店”。

我嘴上说“术业有专攻”，可每次想从一章有声书切到同名漫画，都得关掉一个网页、打开另一个网页、重新登录、等封面刷出来——这套操作在手机浏览器上是灾难级别的体验。

直到 Jellyfin 12 预览版放出，我才找到理由把其中三个服务彻底停掉。不是这个流媒体平台突然变万能了，而是它的 Bookshelf 插件重构后给了我一个理由：用同一个登录态、同一套文件夹结构，把视频、电子书、漫画、有声书装进同一个图书馆。在此之前，我对它的书籍支持是彻底放弃的——好几年了，它在我眼里就是个纯视频服务器。

过去那种“四个 App 管四种介质”的痛，不是来自任何一个软件做得不好。正相反，电子书管理器 Calibre-web 的网页阅读器对 epub 渲染快速且干净，漫画工具 Komga 翻页进度从不丢失，有声书管家 Audiobookshelf 能按章节快进、记住每本书的播放位置，这些都远远超过 Jellyfin 原生的书籍扫描能力。我从来没有把这些库映射进去，不是不想，而是它对书籍的元数据抓取实在太像半成品——作者页面是空的，封面时有时无，扫描一个两万册的 epub 文件夹常常能卡住整个库刷新。我宁愿让四个服务保持“老死不相往来”，至少它们各自稳定。

Jellyfin 12 这次最打动我的改动，恰恰就是元数据。Bookshelf 插件被重新打了地基，虽然它依旧需要手动去插件目录添加，但一旦启用，整个电子书、漫画、有声书的处理逻辑就肉眼可见地上了一个台阶。文件识别不再乱匹配：以前同名不同格式的电子书，比如《三体》同时有 epub 和 azw3，会被当成两本书分别生成条目；现在它们归到同一作品下，再按格式列出可读版本。这对同时收藏 mobi、pdf 和 epub 的人来说，省掉的整理工作就不是一个下午能衡量的。

另一个提升是元数据抽取的密度和来源。过去的 Bookshelf 插件扫描后，作者页经常只有名字，如今它会从书籍文件的嵌入信息里拽出作者简介，再从已有媒体库交叉引用同一作者的作品，形成一个能点进去看的作者主页。虽然这还比不上 Calibre-web 那种可自定义数据源的灵活度，但对于只想“能看就好”的用户，已经不构成迁移障碍了。

有声书元数据的支持，成为我立刻拆掉 Audiobookshelf 的另一个原因。以前该平台连有声书的章节都分不出来，文件被当作一首首零散的 MP3，甚至连“记住上次听到哪里”都做不到。这次 Bookshelf 插件直接利用音频文件的内嵌章节标记，在网页播放器里生成了可点击的章节导航，播放进度也不再全局丢失，而是按书本记录。我当然清楚这依然依赖社区插件的迭代，并非官方原生功能，但既然它就在同一个界面上、使用同一套文件夹和文件名规则，为什么还要单独开一个服务去维护？

整个迁移过程比我预想的安静得多。所谓“迁移”，其实没有做任何文件拷贝或格式转换。四个服务的根目录本就在同一个 ZFS 数据集下，只是原先分别指向各自的专用扫描文件夹。我把插件安装好，在书籍库里添加上电子书、漫画、有声书这三个文件夹，然后触发一次全量扫描。仅此而已。没有重新整理作者名，没有补全封面，甚至连音频文件的书名标签都没改动。扫描跑完，大部分条目已经可以点开直接看。

Komga 读进度那块，我是比较过才决定关掉的。Bookshelf 插件现在支持在阅读页面记录章节级和页级进度，漫画的缩放和左右翻页也可以跟随浏览器宽度调整。虽然它还无法像 Komga 那样自动识别多个漫画合集之间的故事线跳转，但我并不需要那种程度的整理，能在手机上用同一个入口续看昨天的漫画就已经足够了。那些必须跨多部单行本才能看完的系列，我仍旧按文件夹排列，反正登录后一眼能扫到。

四个服务变成两个的最大回报，最先体现在小主机的日常负载上。Proxmox 里的 Debian 虚拟机原本常年内存占用在 6GB 以上，Jellyfin 的转码、Audiobookshelf 的音频流、Komga 的漫画图片实时缩放各占一块，再加上 Calibre-web 的 epub 渲染进程，系统几乎喘不过气。如今只留下它和 Calibre-web，日常内存占用跌到了 3.5GB 左右，CPU 平均使用率也降了四成。这台曾被我视为“四驾马车”的小主机，终于不必再左右横跳了。