这篇记录的是我把媒体库从「网盘 FUSE 挂载直读」改成「STRM 文件 + 播放时重定向」的过程。结论先说：媒体库负责展示和管理，真正的视频流量尽量交给网盘侧直链/CDN，不让家宽或中转机长期扛视频流。

为什么要改

最早的做法是把 115 网盘挂成一个本地目录，再让 Emby 直接扫描。短期好用，长期问题明显：

• 扫描不稳定，FUSE 偶发卡住或断开。
• 播放路径不理想，容易把流量压到自建机器上。
• 目录改名、移动和元数据刷新容易留下脏状态。

所以这次不是继续补 FUSE，而是把 FUSE 从播放链路里拿掉。

现在的链路

这套方案可以理解成两段：前半段负责“看起来像一个正常媒体库”，后半段负责“把播放尽量导向网盘直链”。

用户端
  -> 媒体入口
  -> go-emby2openlist
  -> Emby 媒体库与播放控制
  -> STRM 文件
  -> OpenList / 115 API 获取真实地址
  -> 客户端跳转到网盘直链播放

最关键的点是：Emby 还是负责海报墙、观看记录和客户端体验；go-emby2openlist 负责把 STRM 里的路径解析成真实播放地址；真正的视频流量尽量不要走反代服务器。

组件分工

组件	职责	注意点
OpenList	管理网盘目录，提供文件列表和下载地址能力	API 调用要控制频率，避免触发限速
STRM 文件	给 Emby 提供可扫描的媒体入口	路径映射必须稳定，不要频繁改根目录
go-emby2openlist	解析 STRM，协助重定向播放请求	入口应该先进它，而不是直接打到 Emby
Emby	媒体库、海报墙、观看记录和客户端体验	Web 播放器兼容性不如外部播放器稳定

实施重点

STRM 要放在持久化目录里

OpenList 生成的 STRM 必须落在 Docker volume 里。否则容器重建后文件丢失，Emby 的媒体库也会跟着失效。

路径映射按 Emby 视角写

go-emby2openlist 的路径映射不要按宿主机绝对路径写，而要按 Emby 容器里看到的路径写。最容易错的地方就是把宿主机路径直接塞进去。

入口先到中间层

如果入口直接反代到 Emby，播放请求就绕过了解析和重定向逻辑。正确做法是先到 go-emby2openlist，再由它和 Emby 协作处理页面和播放请求。

踩过的坑

• Emby 首次识别 STRM 时，部分内容可能会被误判成普通目录。
• Web 播放器经常会先发 HEAD 请求，实际体验不一定最好。
• 批量生成 STRM 和刷新媒体库都要限速，别硬怼并发。
• 目录改名后要清理旧 STRM，不然容易出现重复条目和失效条目。

现在的取舍

这套方案不是最省事的，但比 FUSE 直读稳定。它把媒体服务拆成两层：Emby 负责“像一个正常媒体库”，OpenList / go-emby2openlist 负责“让播放尽量走网盘直链”。

后面更值得优化的是海报墙和元数据，而不是继续让自建服务器承担视频流量。只要播放链路能稳定跳到直链，这套架构就算达成目标。