飞牛NAS部署docker专属私人音乐库，安装插件拓展更多功能
摘要
Songloft 是一款专注于管理本地合法音乐的自托管工具，其核心优势在于开放的插件生态，能灵活应对音源变化。文章详细介绍了在飞牛 NAS 上通过 Docker Compose 部署 Songloft 的方法，强调了数据挂载的重要性。文中推荐了智能音箱联动、标签刮削及 Subsonic 协议等实用插件。总体而言，Songloft 功能完整但有一定折腾门槛，适合追求深度定制的用户，建议先试用官方音乐再决定是否迁移。
前言
Songloft 是一款面向个人用户的自托管音乐工具，核心定位是帮你管理自己合法拥有的音乐文件，而不是去"破解"或聚合盗版资源。它支持本地音乐管理、跨平台客户端、网络歌曲与电台、歌单批量转存到本地等功能，并依托一套 JS 插件体系自由扩展音源、元数据刮削、设备控制等能力。
可能有人会问：这和之前介绍过的 MiMusic 是什么关系？其实 Songloft 就是 MiMusic 的"改名续作"。作者因为各种原因把项目改名为 Songloft，但核心功能不变，并且开放了插件生态，让第三方开发者可以更方便地贡献能力。对老用户来说，迁移成本很低，功能上也没有缩水，反而未来可扩展性更强。作者主页：https://songloft.hanxi.cc
为什么"插件体系"这件事值得单独说
原话是"开放了插件生态"，听起来像个普通的功能更新，但它其实决定了一个自建音乐项目能活多久。
先看自建音乐软件通常要干的三件事：
要干的事 | 具体是什么 | 变化快慢 |
|---|---|---|
管本地曲库 | 扫描、刮削、分类、播放 | 很稳定 |
接音源 / 元数据源 | 拉元数据、找在线资源 | 变化极快（接口随时关停） |
控制播放设备 | 音箱联动、投屏、协议对接 | 中等 |
问题就出在第二行。音源和元数据接口是最不稳定的一环——它们往往依赖第三方服务，接口改了、关了、限流了，整个软件的核心功能就瘸了。如果这些逻辑写死在主程序里，那就只能等作者发新版本；作者一忙，项目就"看起来没人维护"了。
插件化的意义在于把"会变的部分"拆出去独立演进：
接口挂了 → 换一个插件，主程序不用动
有人想加个新音箱品牌 → 自己写个插件，不用等作者
版权上有顾虑 → 主程序只做"本地曲库管理"这件干净的事，具体音源交给插件，责任边界清楚
所以官方说的"核心定位是管理自己合法拥有的音乐文件"，配合插件体系，是一套很清醒的工程选择：主程序保守、生态开放。这也是我看好这类项目的原因——能在接口不断变化的现实里活下来的，往往不是功能最多的那个，而是架构上最"经得起改"的那个。
部署
这次我通过 docker compose 的方式把 Songloft 部署到了飞牛 NAS 上，步骤非常简单。
这里有几个部署要点需要特别提醒：
音乐目录挂载：
/vol3/1000/Music要改成你 NAS 上真实存放音乐文件的目录。建议把音乐统一放在一个独立目录里，方便日后管理，也方便后续的"本地扫描"。数据目录独立：
/app/data存的是配置、歌单、刮削缓存等数据，务必挂载到持久化目录，否则容器重建后所有设置都会丢失。端口映射：默认 58091 是官方端口，如果你的 NAS 上该端口已被占用，记得改成别的并同步修改
LISTEN_PORT环境变量，两者必须一致。默认密码必改：
ADMIN_PASSWORD=123456只是示例，上线前务必改成强密码，因为服务如果做了端口映射暴露到公网，弱密码等于把音乐库敞开给别人。
第 2 点值得展开讲，因为它是 Docker 新手最容易吃亏的地方。
容器在直觉上像一台"电脑"，很多人以为装进去的东西会一直在。但服务器上容器的真实语义是：镜像只读，容器可随时删除重建。你更新镜像、改了配置文件、甚至只是手滑删了容器，容器内部的文件就一起没了。
所以判断一个 Docker 应用"会不会丢数据"，就看它有没有把关键目录挂载出来（volumes）。这份 compose 里挂了两处，含义不同：
挂载
存什么
丢了会怎样
/app/music你的音乐文件
歌全没了（这是你的原始数据，必须挂）
/app/data配置、歌单、刮削缓存
设置和歌单全丢，要重新配一遍
判断标准很简单：凡是"我辛苦攒的东西"，都要确保它在挂载目录里，而不是容器内部。
使用
浏览器打开
http://NAS的IP:58091，用户名密码填写之前设置的。
SongLoft 的主界面如下图所示，整体布局清爽，左侧是媒体库和设置入口。
进入设置页面点击
扫描本地文件，将 NAS 本地的音乐添加进来。扫描是全量扫描，会把挂载目录里所有支持的音频文件索引进媒体库，之后按专辑、歌手、流派自动归类。
在扩展项目里点击
插件商店，可以安装官方维护的插件，装完即可在首页启用。
如果你会写 JS 或拿到第三方插件包，也可以手动上传自己的插件，上传后在插件列表里开启需要的功能即可。
⚠️ 插件是"能执行代码的程序"，不是"配置文件"——尤其是手动上传的第三方插件，它运行在你的 NAS 上，理论上能访问容器内的一切。所以：插件商店里的官方插件可以放心装；来路不明的第三方插件包，装之前最好看一眼代码（大多就几百行 JS，重点看它有没有把数据往外发、有没有执行可疑命令）。这个习惯不只适用于音乐插件，对所有的自托管插件生态都成立。
返回首页就可以看到并正常使用已启用的插件了。
常用插件
智能音箱（米家）联动：在米家 APP 里扫描即可发现并控制自己的小米音箱，把 Songloft 作为播源，实现"NAS 私人曲库 + 全屋音箱播放"。
服务器配置这里要重新填写并保存一下，确认地址和端口无误。
配置完成后就可以正常播放了。
这里填的地址要用"音箱能访问到的地址"。如果你的音箱和 NAS 不在同一个网段、或者你在配置时习惯性填了
localhost，会发现"能连上但播不出声"。正确做法是填 NAS 在内网的实际 IP + 端口（比如http://192.168.1.x:58091）。这是个很常见的小坑，但它消耗的时间往往比部署本身还多。
标签刮削：在歌单里全选歌曲，插件会自动联网补全专辑封面、艺人、曲目信息等元数据，让原本文件名杂乱的本地音乐库变得整洁美观。
Subsonic 协议支持：这个插件让 Songloft 兼容 Subsonic API，可以把其它支持 Subsonic 协议的外部音乐服务器（如 Navidrome、Airsonic）无缝接入到 Songloft 播放器里统一听。这样即使你之前用别的音乐服务，也能平滑迁移过来，客户端选择也更自由。
Subsonic 协议的支持，其实是三个插件里"含金量"最高的一个，值得单独说清楚。
在自建音乐这个圈子里，Subsonic API 事实上是一个通用语言。Navidrome、Airsonic、gonic 等一批服务端都实现了它，于是产生了一个很实用的局面：大量手机端/桌面端播放器只要支持 Subsonic，就同时支持所有这些服务端。
这意味着两件事：
你不用被单一客户端绑死——服务端是 Songloft 还是 Navidrome，客户端都能用同一个 App 连
迁移成本极低——换服务端只改一下连接地址，客户端的歌单和习惯都不用重建
所以选自建音乐方案时，"是否支持 Subsonic"是我会优先看的指标，它比"自带客户端好不好用"更影响你未来几年的使用体验。
结尾
手机客户端大家找自己设备的版本安装即可，和 Web 端体验基本相同，支持后台播放、歌单同步。
整体使用下来，Songloft 和 MiMusic 没有太大区别，属于"换名不换心"。作者已经完全剥离了原先的一些依赖，独立成项目。它现在更适合把本地正版音乐管好、通过插件接各种合法音源和设备的玩法。几个老问题依然存在，比如对 FLAC 这类无损格式的支持还不是特别完善、某些操作偶尔会卡顿——但这些都靠作者持续迭代和插件生态逐步完善，期待未来更好用。
它和飞牛官方音乐、和其他方案怎么选
现在 NAS 听歌的选择其实不少，按"省事程度"排下来是这样：
方案 | 上手成本 | 功能完整度 | 适合谁 |
|---|---|---|---|
最低，装完勾权限就能用 | 基础（无声歌词管理、暂无手机端） | 想省事、曲库不大 | |
Songloft（本文） | 中等，需要写一份 compose | 完整，靠插件扩展 | 想要完整功能、愿意折腾一次 |
中等 | 侧重多端与音箱联动 | 重视全屋播放体验 |
我的建议顺序是：先用官方音乐跑起来，确认自己真的会长期用 NAS 听歌；等到开始嫌它功能不够（尤其是想要手机端、想要音箱联动）时，再迁到 Songloft 这类自建方案。因为曲库文件在哪都一样，迁服务端只是换个入口，不会白折腾。
常见问题
Q：扫描后曲库是空的 / 少了很多歌？
先确认挂载路径对不对——这是最高频的原因：compose 里写的 /vol3/1000/Music 如果实际不存在或者写错了，容器里那就是个空目录，扫不出任何东西。排查方法是在 NAS 的终端里 ls 一下这个路径，看有没有文件。其次看音频格式是否在支持范围内。
Q：无损格式（FLAC）支持不好怎么办？
这是它的已知短板。折中做法是：核心播放库用 FLAC 保证音质，同时准备一份 mp3 版本给兼容性差的场景用。另外可以留意作者后续版本——这类问题通常会在迭代中解决。
Q：暴露到公网安全吗？
两个动作必做：改掉默认密码（compose 里的 123456 是示例值），以及不要直接把端口映射到公网——推荐用反代加一层访问控制（或者只在内网/组网环境访问）。音乐服务本身不涉及支付等高敏感数据，但一个开放的管理后台就等于 NAS 的一个入口，不该裸奔。
Q：以后想换到 Navidrome 之类的服务，歌单会丢吗？
因为曲库文件是你自己的、且大家都遵循同样的标签规范，曲库本身不受影响。歌单这类"服务端数据"通常能通过导出/导入或 Subsonic 协议的收藏同步来迁移，具体看两边支持程度。这也再次说明：真正值钱的是你本地那份整理好的曲库和标签，服务端只是"读它的工具"，工具可以随时换。
相关文章
暂无相关文章