“YuE”这个词第一次出现在我手机备忘录里的时候，其实就俩字母——Y和E。当时我正坐在客厅沙发上，电视遥控器在茶几上排成一排，手机里装了四五个视频App，想找一部电影却翻来覆去搜不到；NAS硬盘灯在角落一闪一闪，里面躺着几百部电影、几千首无损音乐和我爸妈扫描出来的老照片，却几乎没有被打开过。那一刻我突然意识到，问题不在内容，而在入口太乱。
YuE（Your Entertainment）就是从这个念头里长出来的：把散落在NAS里的电影、剧集、音乐、电子书、照片，全部汇到一个统一入口，电视、手机、平板、电脑随时能看能听。这个项目不追求复杂的自动化，也不做所谓的内容平台，它只做一件事——把你已经拥有的资源，用最舒服的方式组织起来，全家人都愿意打开。适合谁参考呢？家里有NAS但长期吃灰的，觉得各家流媒体订阅费越来越肉疼的，还有想给孩子和老人准备一块干净可控内容区的，都可以看看我这一路的方案取舍和踩坑记录。
1. 项目背景与设计思路拆解
1.1 痛点很清晰，但解法不是再多买一个会员
过去两三年，各家视频平台把版权切割得非常碎，想看的电影分散在不同App里，每个App的播放器体验、画质策略、搜索逻辑又各不相同。我实测过，如果想在同一台电视上看完自己常追的片单，至少要装四五个App，每年订阅费加起来超过千元。而另一边，我手里其实已经积累了大量本地媒体文件——蓝光原盘、无损音乐、Kindle书库、家人扫出来的老照片，这些东西的价值完全没有被释放出来。
YuE的第一条设计原则，就是“本地优先”。所有内容存在本地，播放走局域网，既不受外网带宽影响，也不存在“这个资源在A平台、那个资源在B平台”的割裂感。你要做的不是再买一个平台的会员，而是把内容入口统一起来。当时我也考虑过直接买一台成品NAS、用厂商自带的全家桶，但看了看那些软件在中文媒体刮削、多端播放上的表现，还是决定自己组一套。
1.2 整体拆解：YuE要解决的五件事
动手之前我列了一张需求清单，最后收敛成五个模块：
- 影视库：电影、剧集的分类展示，海报墙，自动刮削元数据，多端播放
- 音乐库：无损音乐的整理、封面匹配、手机端和客厅端播放
- 阅读库：电子书的格式转换和在线阅读、漫画的翻页体验
- 相册库：老照片、手机照片的备份与时间轴展示
- 访问入口：电视、手机、平板、PC四端的统一接法，以及出门在外时的安全访问
这五个模块各自独立，但共享同一个存储池和同一套权限体系。架构上我用Docker Compose把它们编排在一起，每个服务跑一个容器，互不污染配置和依赖，后续升级某个模块不影响其他服务。这个决定在后面维护时省了大量心思。
1.3 为什么叫YuE：名字背后是产品思维
项目名“YuE”最初只是“Your Entertainment”的缩写，后来我越用越觉得它更像一个动词——“娱乐一下”。打开电视说一声“YuE一下”，其实就是打开全家的娱乐中心。名字这个东西确实不重要，但它时刻提醒我：这个项目的目的不是折腾技术，而是让家里人每周愿意打开它、使用它。任何会影响这个目标的复杂度，都应该被砍掉。
所以在后面选型时我有一个原则：能少配置一个组件就少配置一个组件，能少暴露一个端口就少暴露一个端口。YuE的核心价值是稳定和易用，不是功能堆叠。
2. 硬件选型与系统规划
2.1 三套方案，我为什么选了N100迷你主机
先交代一下我考察过的三类承载方案。
第一类是成品NAS，群晖DS423+、威联通TS-464这类。优点非常明显：开箱即用，系统稳定，套件丰富，国内外社区资料多。缺点是价格偏高，同等配置下比DIY方案贵出一大截，而且自带的Video Station对中文刮削支持并不算好，很多玩法还是要靠第三方Docker套件来补，那不如一开始就上通用系统。
第二类是旧电脑或旧笔记本改造。性能足、零成本（前提是手头有闲置机器），但整机功耗通常30W起步，风扇噪音放在客厅里比较明显，24小时开机的话电费也不容小觑。如果家里客厅不是单独设备间，这款体验一般。
第三类就是我最终选的方案：迷你主机加硬盘柜。我用的是N100型号的迷你主机，8GB内存起步，后面升到了16GB，配一个四盘位硬盘柜，通过USB接口连接。N100自带Intel UHD Graphics核显，支持Quick Sync Video硬解，实测下来可以同时处理多路1080P转码任务。整机功耗在8W左右，几乎没有噪音，放在电视柜侧面完全不觉突兀。总预算也控制在四千元以内，包含主机、硬盘柜和四块4T硬盘。
最终选它的核心原因有三个：功耗低，适合7×24小时运行；体积小，能塞进客厅；预算可控，后期硬盘不足还能换大容量盘。当然，如果你更追求省心、不想折腾系统，成品NAS依然合理——YuE这套软件栈完全可以用Docker跑在群晖和威联通上，下面的配置思路是通用的。
2.2 硬盘、网络与供电：这三件事决定“稳不稳”
先说硬盘。我选的是NAS专用盘（酷狼4T×4），组RAID 5阵列，可用容量约10.9TB。RAID 5允许坏一块盘不丢数据，同时比RAID 1节省空间，适合媒体库这种大文件连续读写的场景。如果你预算高一些，也可以考虑酷狼Pro、红盘Plus，主要差别在质保年限和转速，使用层面区别不大。
再说网络。千兆有线是底线：电视、迷你主机、主路由之间一定尽量走网线，Wi-Fi留给手机和平板。如果家里预埋了六类网线，直接组千兆内网就行；没有预埋的话，用Mesh路由器做有线回程也比电视直接连Wi-Fi稳定。我在实际使用中感受到，Jellyfin加载大体积原盘文件时，有线网络基本能做到秒拖进度条，Wi-Fi偶发卡顿，体验差距在客厅场景下体现得非常明显。
最后说供电。UPS不间断电源是我强烈建议加的一项，一百多块的入门型号就能起到保护作用。媒体服务器最怕的不是断电本身，而是断电瞬间硬盘正在写入，导致文件系统损坏或者出现坏道。给迷你主机和硬盘柜配上UPS，断电后自动安全关机，这个投入比多买一块硬盘还值。我自己用的APC BK系列，设置好自动关机脚本后，家里停电几次都没出过问题。
2.3 为什么用Debian加Docker，而不是装个图形化系统
很多新手会直接给迷你主机装Windows，然后开共享文件夹、用播放器直接拉文件，一开始我差点也这么干。但仔细想了一下，Windows有三四个问题绕不开：自动更新会半夜重启导致服务中断，系统本身占用内存高，远程管理不方便，权限体系也比较松散。所以我最终装了Debian 12的无桌面版本，再用Docker Compose管理所有服务。
Docker在这里最大的价值，是把每个服务的依赖隔离干净。Jellyfin需要ffmpeg做转码，Navidrome又要自己的音频解析组件，Calibre-Web还要依赖Calibre的数据库，这些依赖如果直接装在同一个系统里，版本冲突只是时间问题。用Compose文件一次性定义好所有服务，一条 docker compose up -d 就能把整个YuE拉起来，升级某个容器也不会影响其他服务。
3. 核心搭建实操与节点实现
3.1 磁盘初始化与共享目录规划
先说磁盘初始化的思路。我用Linux下的mdadm工具把四块4TB硬盘组成了RAID 5阵列，格式化为ext4，挂载到 /data 目录。操作过程大致是：安装mdadm、创建RAID设备、格式化和挂载、最后写入fstab让系统开机自动挂载。这一步如果用群晖或威联通的图形界面，直接在存储管理器里划存储池和共享文件夹就行，思路一样，只是命令换成鼠标操作。
目录规划是很多人容易忽略的细节。我建议用“媒体类型/内容类型/具体文件”三层结构：
/data/media/movies /data/media/tv /data/media/music /data/media/books /data/media/photos /data/downloads为什么要单独留一个 /data/downloads？因为下载和整理是两个阶段，下载目录保持“原始状态”，整理完成后再移动到媒体目录。这样即使自动整理脚本抽风，也不会把原始文件搞乱，最多是在待整理目录里多留几份文件。
3.2 影视库：Jellyfin的部署与调优
影视库是YuE里最核心的模块，我用的方案是Jellyfin。在Plex、Emby和Jellyfin三个选项里，Jellyfin完全开源免费，没有会员限制，硬件解码、多用户、家长控制这些功能全部开放，而且中文社区案例非常多，遇到问题几乎都能搜到解决方案。
部署方式用Docker Compose，核心片段大致这样：
jellyfin: image: jellyfin/jellyfin container_name: jellyfin volumes: - ./jellyfin/config:/config - /data/media:/data/media devices: - /dev/dri/renderD128:/dev/dri/renderD128 ports: - "8096:8096" environment: - TZ=Asia/Shanghai这里最关键的配置是把核显设备 /dev/dri/renderD128 映射进容器，这样Jellyfin才能调用Intel核显硬解做转码。如果漏掉这一行，转码就会走CPU软解，N100这种低功耗处理器立刻露出原形，并发一多就卡。
第一次启动后进入初始化向导，我建议把电影和剧集分开添加媒体库，刮削语言选简体中文，元数据提供方选TMDB。这一步最影响刮削成功率的是文件命名，最规范的格式是“电影名 (年份).mkv”，比如“流浪地球2 (2023).mkv”；剧集则是“剧名/Season 01/剧名 S01E01.mkv”。命名规范之后，海报墙基本一遍就能刮出来，后面再微调个别条目就行。
3.3 音乐库：Navidrome与移动端搭配
音乐模块我用了Navidrome，一个轻量的开源音乐流媒体服务器。它界面风格偏向老牌的Subsonic，但后端是Go写的，容器启动很快，内存占用也就一两百兆，几乎没有存在感。它支持直接输出无损音频，FLAC、APE、WAV这些格式都能直接播放，不需要转码。
音乐目录的整理是重点。Navidrome和大多数音乐服务器都按“艺术家/专辑/曲目”三级目录识别：
/data/media/music/李健/拾光/01. 贝加尔湖畔.flac目录规范之后，Navidrome会自动读取音频文件内嵌的ID3标签，自动匹配封面。如果音乐文件本身内嵌了封面，基本不会出现“封面找不到”的问题；如果没内嵌封面，把 cover.jpg 放在专辑目录里也能识别。整理老唱片时如果标签缺失或者混乱，我推荐先用MusicBrainz Picard批量补TAG，再丢进音乐库，效率会高很多。
手机端我用的播放器是substreamer和play:Sub，iOS和Android都有，打开后填入Navidrome的地址、用户名和密码，就能同步整个曲库。在客厅里还可以通过浏览器的Web界面直接播放，或者用支持DLNA的设备连接Navidrome，场景覆盖比较完整。
3.4 阅读库：Calibre-Web与Komga各管一摊
书籍和漫画的体验需求完全不同，我把它拆成两个服务。电子书用Calibre-Web，它后端复用Calibre的数据库能力，支持epub、mobi、azw3和PDF等格式，在线能读，也能做格式转换和元数据编辑，适合构建私人书库。漫画我用的是Komga，专门处理CBZ、CBR这类压缩包格式，支持连续滚动阅读，手机上比直接用PDF阅读器舒服很多。
这两个服务流量不大，内存占用也小，各分配100MB左右就够用了。唯一要注意的是，不要让它们直接读取原始下载目录。Calibre书库有个特点，它会按作者和书名重新组织文件，如果你往书库里直接丢文件，很容易把目录结构搞乱。正确做法是：先用Calibre桌面版把书导入书库，让服务端做格式转换和元数据整理，然后让Calibre-Web只读这个书库目录。
4. 访问入口与自动化流程
4.1 局域网里四个终端的接法
核心服务搭起来之后，关键是让家里每个屏幕都能用起来。先聊电视端。如果电视是Android系统，直接装Jellyfin官方TV客户端，打开后它会自动扫描局域网里的服务器，输一次账号密码就行。如果是老款电视或者电视盒子，可以用浏览器打开Jellyfin的Web界面，遥控器操作稍微麻烦点，但也能看。手机和平板直接用各平台的Jellyfin App，PC端我倾向于直接用浏览器，Web播放器已经足够好用了，不需要额外装客户端。
音乐和阅读的终端逻辑也一样。Navidrome的Web界面可以在浏览器里直接放歌，漫画我主要在平板上用浏览器或者Komga的App看。这里我一度有个误区，觉得所有内容应该合到一个App里。实际用下来发现分开反而更合理：影音归影音、音乐归音乐、书归书，每个工具只服务一个场景，界面更干净，家里人学起来也快。
4.2 出门在外想访问家里：三条路线对比
余下这个问题很多人迟早都会遇到——出门在外，怎么安全地访问家里的媒体服务。我的建议是先分清自己的网络环境：有没有公网IP，路由器支不支持端口转发，运营商有没有屏蔽常见端口。不同环境适合的方案不一样。
我实际测试过三条路线：
- 动态域名解析加路由器端口映射：适合有公网IP的用户。优点是延迟低，不依赖第三方中转；缺点是配置相对复杂，要面对运营商端口封禁的问题。如果家里上行带宽够大，播放原盘也没压力。
- 开源内网穿透工具（frp这类）：需要一台有公网IP的中转服务器，家里客户端主动连出，不在家庭网络开放任何入站端口，安全性更好。缺点是带宽受限于中转服务器的上行，自建中转的话还要额外维护一台服务器。
- 异地组网产品（Tailscale等）：把手机、电脑、平板都放到同一个虚拟局域网里，在公共场所也能像在家一样访问NAS。优点是完全不需要公网IP，配置简单，流量自动加密；缺点是部分网络环境下需要额外处理。
我目前的方案是“DDNS加端口映射”和“异地组网”双保险：在家里走局域网，出门默认走异地组网，特殊情况下走DDNS。这三条路线解决的都是远程访问需求，而且都是在合规的远程访问范畴里做的，没有额外引入任何不安全手段。关键原则是：能不开端口就不开端口，能用加密组网就不用裸暴露。
4.3 文件不用手动收拾：自动化整理脚本
媒体文件多了以后，最累人的不是看片，而是整理文件。我写了一个小脚本，用inotifywait监听 /data/downloads 目录，一旦发现新文件落盘，就根据扩展名和文件名规则自动分类：电影文件移动到 movies，剧集文件移动到 tv，音乐文件移动到 music，电子书移动到 books。移动完成后，通过Webhook通知Jellyfin、Navidrome、Calibre-Web分别刷新对应媒体库。
脚本的核心逻辑很简单，就是一个文件监控循环，配合几条分类规则。需要注意的点是：文件名必须规范，脚本只处理命名规律的文件，遇到不认识的命名就丢进“待整理”目录，人工确认后再入库。这个设计避免了脚本误判导致的错误归类。
除了自动分类，我还给文件做了命名规范化处理：检测文件名里的“S01E01”这类剧集标记，或者“xxxx.2023.xxx”这种年份模式，把来源比较乱的文件名统一成“剧名 S01E01 集标题”或“电影名 (年份)”的格式。这一步是刮削成功率的根本保障，后面的海报墙再智能，也要先有规范的文件名才能识别。
5. 体验调优与内容编排
5.1 海报墙刮削的调优经验
Jellyfin的海报墙是YuE的门面，刮削效果直接决定了家里人愿不愿意天天打开它。这块我踩了不少坑，总结了三条实践经验。
第一，命名永远是最重要的。文件名“蜘蛛侠：纵横宇宙 (2023).mkv”比“Spider-Man - Across the Spider-Verse 2023 2160p.mkv”更容易被刮削正确，因为中文名和年份在文件名里位置固定，刮削器解析成功率更高。当然英文原盘资源保持英文名也完全可以，关键是年份一定要写清楚。
第二，优先启用TMDB刮削器，并把刮削语言设为简体中文。如果某些老电影在国内资料站找不到中文条目，可以把语言顺序调整为“中文、英文”，用英文条目做兜底，这样即使海报和简介是英文的，也不至于整条记录丢失。
第三，剧集目录一定按“季”分开。Jellyfin识别多季剧集依赖“Season 01”“Season 02”这样的目录结构，如果全季文件堆在一个平铺目录里，识别结果会把所有集混在同一列表里，整理起来非常痛苦。
5.2 多用户权限与家长控制
家用环境下，权限设计也要认真对待。我建了四个账号：管理员（我自己）、大人账号、儿童账号和访客账号。Jellyfin的原生多用户系统支持给不同用户分配不同的媒体库，儿童账号只开放动画标签和G、PG级别的内容，访客账号只能读电影库，不能看家庭照片库。这个配置不光保护了孩子的观看内容，也避免了访客误改媒体库里的配置。
音乐和阅读服务我就没有做这么细的账号隔离了，Navidrome和Calibre-Web各自建一个共享账号，开放给局域网和可信设备就够了。它们没有公网端口暴露，只在内网范围使用，安全风险可控。
5.3 转码与播放兼容性调优
播放卡顿的原因里，有八成是转码策略没调对。Jellyfin默认情况下，如果检测到播放器不支持某种编码格式，就会自动转码。要是核显没正确映射进容器，转码就会落到CPU软解，N100这个级别的处理器立刻捉襟见肘。
我实测下来的结论是：N100核显可以同时硬解三路1080P H.264，或者一路4K HEVC转1080P。再往上就不是硬解能力问题了，而是内存和磁盘IO会成瓶颈。所以日常使用建议开“原画直出”，只在字幕烧录或格式不兼容时才触发转码。
还有两个细节值得注意。一是把Jellyfin的转码临时目录放到空间充足的磁盘上，否则转码大文件后磁盘空间会被临时文件占满；二是字幕文件命名，把 .srt 和视频放在同目录且同名，Jellyfin会自动加载，比在播放器里手动挂载方便很多。
6. 常见问题与排查技巧实录
6.1 我实际踩过的几个坑
第一个坑是硬解不生效。Jellyfin界面一直显示“检测不到可用硬件”，排查了很久才发现是容器启动时漏传了 /dev/dri/renderD128 设备。加上之后，转码速度从0.3倍速提升到10倍以上，肉眼可见的差距。如果你也遇到类似情况，先确认容器里能不能看到这个设备文件。
第二个坑是中文文件名乱码。自动化整理脚本用Python写的，脚本文件本身没有声明UTF-8编码，导致移动中文文件时名称全部乱掉。后来在脚本头部显式加上环境编码声明，问题才解决。这个坑在中文场景下非常经典，任何处理中文文件的Python脚本都值得留意。
第三个坑是刮削器匹配到了错误条目。典型场景就是两部同名电影，刮削器总是识别成旧版。解决办法是在Jellyfin里对条目手动“识别”，输入正确的TMDB ID或IMDb ID，刷新后即可纠正。
第四个坑是外网访问速度奇慢。排查来排查去，最后发现是局域网内用了Wi-Fi中继，电视和主机本身又都在无线网络中。换上网线之后，速度问题直接消失。家庭内网的基础布线，永远是媒体体验的地基。
第五个坑是Docker容器日志涨到好几个G。Jellyfin长时间运行后，日志文件不断膨胀，最后居然把磁盘占满了。解决方法是在Docker的daemon.json里配置日志轮转，限制单个日志文件大小和保留份数，之后再也没复发过。
6.2 故障排查速查表
我把这些经验整理成了一张速查表，遇到问题直接对照排查：
| 症状 | 可能原因 | 排查与解决 |
|---|---|---|
| 硬解转码不生效 | 未传递核显设备 | 确认 /dev/dri/renderD128 已映射进容器 |
| 海报墙大量缺失 | 文件命名不规范 | 检查“电影名 (年份)”格式，手动刷新元数据 |
| 局域网外访问失败 | 没有公网IP或端口未映射 | 改用异地组网或内网穿透方案 |
| 音乐封面不显示 | 标签和封面未内嵌 | 用MusicBrainz Picard批量补TAG |
| 播放频繁缓冲 | 转码路径空间不足 | 加大缓存目录空间，改用原画直出 |
| 中文剧集不识别 | 目录结构不合规 | 使用“剧名/Season 01/剧名 S01E01.mkv”结构 |
| 容器日志占满磁盘 | 日志轮转未配置 | 设置Docker日志轮转，保留最近3个文件 |
6.3 数据备份与灾难恢复方案
YuE里的媒体文件大多是可以用时间重新获取的，但照片、家庭录像和书库整理记录是真正不可再生的数据。我的备份策略分三层：照片和文档每天用rsync同步到另一块独立硬盘；Jellyfin的配置目录，包含所有用户的播放记录和媒体库设置，每周打包备份到网盘；四块硬盘组成的RAID 5阵列为整库提供硬件冗余。
另外，我坚持每个季度做一次真实的恢复演练。拔掉一块硬盘，确认阵列降级后数据依然能正常读取，然后再插回去做重建。这个测试虽然听起来有点多此一举，但真等到硬盘报警再去摸索恢复流程，心态完全是两回事。做完一次演练，你对这套系统的信任度会高很多。
最后说一点个人体会。YuE这个项目的价值不在于技术堆得多高，而在于它让全家人在同一个地方找到想看的内容。搭建过程里最花时间的不是装软件，而是整理目录、规范文件命名、调试刮削器。把这些“脏活”做完，之后的使用体验会非常顺畅。如果你想做类似的东西，不用一步到位，先跑起影视库，再慢慢加音乐和阅读，让家人先看到成果，再逐步完善。每当我看到客厅电视上整整齐齐的海报墙，就知道这些折腾是值的。
