Emby、Jellyfin、Plex 怎么选

更新于 2026 年 8 月 31 日 · 三家均无官方鸿蒙客户端，接入方式见文末

三家的来历，以及它为什么还重要

这三家不是各自独立长出来的，它们的血缘关系直接解释了今天的产品性格。

Plex 最早是 2008 年前后从 XBMC（今天的 Kodi）的一个 Mac 移植版本演化出来的，很早就走上了商业化道路：自建服务端 + 自家的元数据服务 + 覆盖极广的官方客户端，整条链路都由一家公司掌控。所以它今天体验最完整、也最封闭。

Emby 起初是开源项目，2018 年服务端转为闭源，改为「核心免费 + 部分功能进付费档」的模式。它保留了大量面向折腾者的细粒度设置，界面和配置深度介于另外两家之间。

Jellyfin 就是那次闭源的直接结果：社区从 Emby 最后一个开源版本上分叉，做成完全开源、没有付费墙、没有中心化账号的延续。也正因如此，Jellyfin 与 Emby 在目录约定和库组织方式上仍有明显的同源痕迹——但两边的接口早已各走各的，不再通用，客户端里必须选对是哪一家。

这段历史的实际意义是：如果你担心「用着用着，某天核心功能被挪进订阅档」，那 Jellyfin 是唯一从制度上排除这种可能的一家。反过来，如果你觉得一家公司持续投入产品化是好事，那 Plex 的完整度也确实是社区项目短期内做不出来的。

定位对照

两点说明。第一，各家的功能划分会随版本调整，尤其是哪些能力属于付费档，以官方文档为准。第二，本文不写具体价格——汇率、促销、买断与订阅的差价都在变，值不值得请按你实际订阅的价格算：把年费除以 12，再问自己「为了省下自己配硬件转码和内网穿透的那几个晚上，这个数值不值」，比看任何评测都准。

逐家点评

Plex：省心买到底

优点是完整。装完基本不用做什么，元数据自动匹配，远程访问是官方支持的一等公民，官方客户端几乎覆盖了所有你能想到的屏幕——电视、机顶盒、游戏主机、浏览器。它还带自己的内容发现与免费点播频道，虽然那部分不属于「你的库」。给不折腾的家人用，Plex 的成功率最高。

代价是控制权。账号中心化意味着登录这件事发生在官方的账号服务上，而不是你那台机器上；服务器需要被账号认领。这也带来一个具体的技术后果：第三方客户端接入时用的是 X-Plex-Token 而不是账号密码。另外它是三家里最封闭的，很多能力是官方客户端与官方服务端配合出来的，换用第三方客户端会失去一部分——详见Plex 在鸿蒙上怎么看那篇里的得失清单。

适合谁：愿意花钱换省心、家里有非技术用户要一起用、需要在很多种设备上看的人。

Emby：折腾者的中间路线

优点是可调。它给出的设置粒度明显比 Plex 细，媒体库的组织、元数据的抓取顺序、用户权限的划分都能按自己的想法来，而又不像 Jellyfin 那样处处要自己搭。用户是建在服务器上的本地用户，不依赖外部账号服务，这一点比 Plex 更让自建党安心。

代价是它仍然是闭源商业产品，核心免费但一部分能力在付费档里，路线由公司决定。历史上那次闭源就是最好的提醒。

适合谁：已经用得顺手不想折腾迁移的人；想要细粒度设置、又不愿意在插件和驱动上花太多时间的人。

Jellyfin：控制权全在自己手里

优点是没有天花板也没有付费墙。完全开源，硬件转码不需要买断，没有中心化账号，服务器只对你负责。公司变了、服务停了，你的库不受任何影响——这是三家里唯一能给出这个承诺的。社区活跃、插件生态也在长。

代价是要自己动手。元数据数据源要自己配，硬件转码的驱动要自己搞定，远程访问完全自理，偶尔升级会遇到需要读改动说明的情况。官方客户端以社区维护为主，各平台的成熟度不一样——所以「有没有一个像样的原生客户端」对 Jellyfin 用户格外重要，鸿蒙上的现状见Jellyfin 鸿蒙客户端现状与替代方案。

适合谁：愿意花时间换控制权的人；反感订阅、反感账号绑定的人；已经在用 Docker 管一堆自建服务、多这一个不算负担的人。

在鸿蒙上，三家的差别只剩认证方式

先说清楚一件事：Emby、Jellyfin、Plex 都没有官方鸿蒙客户端。安卓版可以借助卓易通这类第三方兼容层运行，但功能受限、流畅度不如原生，而播放器又恰好是对系统解码能力依赖最深的品类。所以日常主力建议用支持这三家接口的鸿蒙原生播放器。

接进来之后，三家在客户端这一侧的差异其实很小：Emby 与 Jellyfin 填用户名密码，端口通常是 8096；Plex 填 X-Plex-Token，没有用户名栏，端口是 32400。三家都不需要填起始目录——服务端已经分好库了。完整的字段对照、Plex 的取 token 步骤和排查清单在鸿蒙有 Emby 客户端吗那篇里。

还有一条对三家一致的重要行为：媒体服务器类的源用的是服务端已经刮好的元数据，海报、简介、演员表、分集与外挂字幕流都来自你的服务器，客户端不再自己去查一遍。所以你不必在客户端配任何元数据 API Key；你在服务端手工纠正过的匹配，这边就是纠正后的样子；「重新刮削媒体库」也会有意跳过这三类源，不会把服务端的结果覆盖掉。选哪一家服务端，不影响这一点。

以及第四个选项：也许你不需要服务器

写到这里该把这个问题摆出来：你确定你需要的是一台服务器吗？

把服务端做的事拆开看，其实是五件：刮削出海报墙、记住看到第几集、多用户与权限、转码、远程访问。而多数人架服务端，真实动机只有前两件——想要个海报墙，想让它记得追到哪一集了。这两件事不需要服务端，客户端直连 SMB 加客户端侧刮削都能办到，还省掉一个要维护、要吃 CPU、升级时会出事的进程。后三件才是服务端不可替代的部分。

所以如果你还没开始架，先问自己用不用得上后三件。如果答案是「就我自己看」，那可以先走直连路线试试，不合适再架也来得及——完整的算账、做法和一张诚实的对比表（包括四种仍然该架服务器的情况）在不架服务器的海报墙。

反过来，已经架好并且跑得稳的，不要为了这一节去拆。服务端方案在「换新设备后登录即恢复」「多端元数据完全一致」这两点上有实打实的优势，而且两种源可以同时存在于一个媒体库里，不冲突。

常见问题

三家能同时用吗？

能。三个源可以并存，条目汇总在同一个媒体库里。同一部片在多处都有的话，展示层会折叠成一条主版本（取体积最大的那份），其余进详情页的版本菜单，已看状态会落到全部版本上。

从一家换到另一家，麻烦吗？

重新扫描片库通常很快，真正麻烦的是观看记录——三家之间没有官方的互相导入通路，换家基本意味着这部分要重来。所以如果你已经积累了几年的观看历史，这本身就是留在原地的理由。

哪一家最省 NAS 的 CPU？

不转码时三家差别都不大，真正吃 CPU 的是转码。而客户端本身解码覆盖面够宽的话（硬解走 H.264、HEVC 8/10bit，冷门格式落到软解引擎），就用不上服务端转码，服务器只需把文件读出来发过去。这也是「NAS 配置低要不要架服务端」的答案：转码需求才是分水岭。

国内网络下刮削会有问题吗？

三家的刮削都要访问各自的元数据服务，国内网络下可能需要额外处理，具体做法看各家文档。这一层与客户端无关——媒体服务器类的源，客户端复用服务端的结果，不重新去查。

如果我最后决定不架服务器，刮削靠什么？

客户端侧刮削，在「设置 → 元数据与刮削」里配 TMDB 或 OMDb 的 API Key（两家都配则互为兜底），然后把目录纳入媒体库即可。识别原理和命名规范见电影刮削完全指南。