这篇是媒体链路的公开导览，目的是用最少的话说清楚一件事：家里云里的媒体服务不是拿家宽去扛视频流量，而是把浏览、鉴权和播放控制留在自建服务里，把真正的大流量尽量交给网盘和 CDN。

核心思路

如果把媒体系统拆开看，其实只有两类流量：控制流和视频流。控制流负责看列表、进页面、点播放、鉴权和跳转；视频流负责真正传输内容。两者混在一起，系统就容易变重，也更难维护。

现在的做法是：`Jellyfin`、`OpenList` 和 `go-emby2openlist` 负责前半段，实际视频流尽量走 `115 CDN`。这样一来，自建服务的角色更清楚，用户侧也更稳定。

对外怎么理解

• 媒体库入口负责浏览和播放控制。
• 网盘和 CDN 负责真正的视频传输。
• 页面看起来像一个播放器，底层其实是一个分层的直链方案。

为什么要这样做

• 减少自建机器承担大流量的压力。
• 降低故障恢复时的复杂度。
• 让目录、索引和播放入口可以继续自维护。
• 更容易把问题定位到“入口问题”还是“视频源问题”。

这篇文章不展开什么

• 不展开具体内网 IP。
• 不展开 token、密钥和 API 细节。
• 不展开完整反代拓扑。
• 不展开 115 账号侧的细节。

对应长文

如果要看更完整的实现细节，可以继续读《115 网盘 + Emby + STRM 直链播放：告别 FUSE 挂载的折腾之路》。这篇负责讲清楚原理，这篇负责讲清楚怎么跑。

后面如果还要补内容，优先补海报墙体验和公开说明，不优先重构播放器本身。