开源媒体服务器 Jellyfin 发布 12.0 稳定版。这个版本原定叫 10.12.0，项目组这次直接把版本号开头的"10."去掉，跳成 12。10.11.x 是旧命名体系里最后一个版本分支。
数字变了不是重点。真正的动作是把 10.11 那次重建数据库的工程，变成用户能感觉到的浏览提速，代价是一次必须停服、必须备份、不能回退的数据迁移。
自建服务器的管理员，插件装得多的重度用户，升级前的准备工作比新功能本身更值得看清楚。
数据库重构，这次开始兑现
10.11.0 当时把版本号写成小版本升级的样子，实际却重写了整个媒体库数据库结构。不少人以为只是小补丁直接升级，结果被这次重构打乱了使用节奏。这也是官方这次修改版本号的直接原因——以后版本号第一位真的变了，才代表这是大版本。
12.0 接着把 10.11 打好的地基用起来。最大的改动是播放列表和合辑的存储方式。以前整份列表塞进一个大字段，数据库看不进去，哪怕只想知道看了几集、翻到第几页，都得把整份数据读出来解包。现在每条目单独成行，数据库能直接数行数、翻页、增删单条。官方说"继续观看""接下来""按文件夹统计观看数"这类页面应该会更顺。
但要说清楚：这轮优化冲的是读库和浏览，不是媒体库扫描器本身。官方原文写得直白——扫描速度可能因为路径优化顺带快一点，但这不是本轮目标。真正该留意的反而是升级后的首次扫描，会因为清理历史脏数据明显变慢，不是变快。
升级不是点一下按钮：不可逆迁移才是最大门槛
12.0 首次启动时会主动改写数据库结构。官方把这句话写得很重——备份是回到旧版本的唯一办法。
想升级，服务器版本必须落在 10.10.7 或任意 10.11.x。更早的版本得先补一次 10.10.7 的中间步骤。升级前要完全停服，做一次覆盖数据和配置目录的手动全量备份。官方没有给出预计停机时长，库越大、插件越多，备份和首次扫描占用的时间大概率越长。
升级后必须跑一次全库扫描，首次扫描会明显变慢，个别电影甚至短暂显示成"新增"。这是清理历史脏数据的正常现象，不是故障，中途不能停服务器。
除了扫描变慢，两类东西会直接失效。一是给10.11写的第三方插件，12.0不认，得等作者出兼容版本，官方插件已经跟上。二是常年没更新、还在走旧版 /emby/、/mediabrowser/ 地址或旧登录方式的客户端，这条兼容路径在 12.0 里被移除。
不同用户该怎么动手，取决于自己踩了哪几条：
| 用户类型 | 现状 | 该怎么做 |
|---|---|---|
| 只用官方 Web/App、插件很少的家庭用户 | 兼容风险最低 | 备份后可以升级 |
| 装了多个第三方插件的自建党 | 插件可能在12.0下失效 | 先确认插件是否已适配，没适配就先观望 |
用老客户端（多年未更新，走 /emby/ 或 /mediabrowser/ 旧接口）的用户 | 旧接口被移除，登录方式会失效 | 先换成新版客户端，再考虑升级服务器 |
| 库里存了大量书籍漫画、依赖Bookshelf插件的用户 | Bookshelf被标记弃用 | 升级后检查官方原生功能能否覆盖原有阅读体验 |
从视频库走向综合媒体库：书漫原生化能走多远
12.0 另一条主线是书籍和漫画第一次被当成一等公民。以前这块功能靠第三方 Bookshelf 插件补，这次官方把大部分能力搬进了服务端：直接读取 OPF、ComicInfo、ComicBookInfo 里的元数据，自动给 EPUB 和漫画压缩包生成封面，从文件名识别系列、卷号、章节。Bookshelf 插件被标记弃用，功能拆成 GoogleBooks、ComicVine 两个官方 provider，外加一个新的 OpenLibrary 插件。
界面上，过去标着"实验性"的 Modern 布局这次直接变成桌面端和移动端的默认样式。老界面改名 Legacy 继续保留，电视端不受影响，仍走独立的 TV 布局。
重度堆漫画和有声书的用户等到了原生支持，不用再等插件作者维护，可用周期更有保障。不过功能刚落地，元数据识别准确度、边缘格式兼容性目前还看不清，大概还得再等几个版本才能验证扎实。
版本号从10.12跳到12，只是记法上的一次简化。真正决定这次升级顺不顺利的，是备份有没有做全，插件和客户端有没有提前排查——这两步跳过了，才是出问题的地方。