第 125 期自托管音乐GPL-3.0Go
你花钱买的会员，买的其实不是音乐，是一份随时可以作废的租约：歌单变灰、专辑下架、换区就听不了、一年涨两次价。更麻烦的是，你花几年攒的收藏和播放记录，全都躺在别人的数据库里，迁不走也导不全。Navidrome 想解决的正是这件事——把音乐文件留在你自己的硬盘上，再给它套一层能随时随地点开的播放界面。
一、它到底是做什么的
Navidrome 是一个用 Go 写的音乐服务器兼流媒体服务端。你把一个装满了音乐文件的目录挂给它，它会扫描、读取文件里已有的标签信息，整理成专辑、艺术家、歌曲的库，然后提供一个网页界面让你在浏览器里听，同时对外暴露一套 Subsonic / OpenSubsonic 兼容 API。
这套 API 是它的关键设计。因为 Subsonic 协议是早年开源音乐服务器领域的事实标准，市面上已经存在一大批现成的客户端应用，iOS、Android、桌面、Android TV、CarPlay 都有覆盖。Navidrome 自己不造播放器，只把服务端做好，等于把移动端这条最烧钱的腿外包给了整个生态。
功能上它给得挺足：多用户（每个人有自己的播放次数、歌单、收藏）、多音乐库并给不同用户分配访问权限、按用户或按播放器单独配置实时转码（支持 Opus）、自动监听目录变化并增量导入、智能动态歌单、.m3u 歌单导入与同步、把播放记录同步到 Last.fm / ListenBrainz / Maloja、生成专辑或歌单的公开分享链接、以及让服务器直接出声的 Jukebox 模式。
二、怎么用：两条命令，加一个权限坑
官方推荐 Docker 部署。下面是官方文档里的 compose 写法，改掉两个路径就能用：
services:
navidrome:
image: deluan/navidrome:latest
user: 1000:1000 # must own the data folder and be able to read music folder(s)
ports:
- "4533:4533"
restart: unless-stopped
environment:
# Optional: put your config options customization here. Examples:
# ND_LOGLEVEL: debug
volumes:
- "/path/to/data:/data"
- "/path/to/your/music/folder:/music:ro"或者直接用命令行：
$ docker run -d \ --name navidrome \ --restart=unless-stopped \ --user $(id -u):$(id -g) \ -v /path/to/music:/music \ -v /path/to/data:/data \ -p 4533:4533 \ -e ND_LOGLEVEL=info \ deluan/navidrome:latest
容器起来后访问 4533 端口，第一个注册的账号就是管理员。之后在手机上装任意一款 Subsonic 客户端，填服务器地址、账号密码即可开始听。
三、优点：轻、全、不绑架
- 资源占用极低。官方文档明确说在树莓派 Zero 和老旧硬件上都能跑得动，拿一台吃灰的小主机或 NAS 常驻完全没压力，不像 Plex、Jellyfin 那样动辄吃掉一大块内存。
- 协议开放，不被单一客户端锁死。服务端与播放器解耦，换客户端不用重建曲库，哪天某个 App 停更了换一个就是。
- 大曲库友好。官方主打的特性之一就是能吃下很大的音乐收藏，且支持增量扫描，往目录里丢新专辑不用手动触发全量重建。
- 元数据归你。所有播放次数、收藏、歌单都存在你自己的 /data 目录里，导出来就是你的，不看任何平台的脸色。
- 转码可按人配置。在外面用流量听就压成低码率，在家听无损就直出，同一台服务器能给不同用户不同策略。
四、缺点和坑：先看清再上车
下面这些不是挑刺，都是从仓库的开放问题里捞出来的真实反馈。
- 没有官方客户端。网页端做得不错，但手机端必须自己挑第三方 App，体验参差不齐，有的免费有的收费，还得碰运气看它对新协议的支持度。
- 它不支持按文件夹浏览。官方文档直接写明：Navidrome 不按目录结构组织音乐，而是用标签模拟出 /AlbumArtist/Album/01-Song.ext 这样的路径。也就是说，你的音乐必须有规整的标签；文件分目录分得再漂亮也没用。社区里已有用户反馈这个模拟路径让第三方客户端的文件夹浏览直接失效。
- 标签烂，曲库就烂。上一条的直接后果：如果收藏里混着大量没打标签或标签中文乱码的文件，你会得到一堆「Unknown Artist」和一拆多份的同名专辑，事前的标签整理工作省不掉。
- 账号体系偏弱。想要 LDAP 的需求从 2020 年挂到现在仍未实现，改进单点登录的诉求也一直开着。如果是小团队共用，权限这块要自己想办法绕。
- 周边功能偶发小毛病。近期仍有用户报告外挂 .lrc 歌词文件不显示、某版本之后封面图全丢、ListenBrainz 同步超时、蓝牙耳机断连后自动续播等问题。都不致命，但说明它仍是个在快速迭代中的项目。
- 许可证是 GPL-3.0。强 copyleft：个人自用完全没问题，但如果你打算拿它改一改做成对外提供的服务，分发义务要先算清楚。
五、最终能达到什么效果
装好之后，你得到的是一台只属于你的私人音乐服务器：曲库在硬盘上，界面在浏览器里，手机上随便挑一个顺手的客户端连回去，通勤时能听、在家能听、换设备播放进度能接着走。它不会给你推荐算法，也不会帮你发现新歌，但它保证一件事——你收藏的东西不会某天早上突然变灰。
适合谁：手里有一批自己攒下来的正版或自录音乐文件、愿意花半小时整理标签、家里有台常年开机的 NAS 或小主机、受够了会员涨价和下架的人。
不适合谁：音乐全靠平台曲库、没有本地文件的人；完全不接受折腾、希望装完就有官方手机 App 的人；指望它顺带管理影视、播客的人——官方明确说播客的接口支持至今还是个开放需求。
三个坑再记一遍：一是 user 指令别省、PUID/PGID 无效、别跑 root；二是 /data 要读写、/music 只读，曲库空了先看权限而不是看路径；三是它按标签而不是按文件夹组织，上车前先把标签理干净。
下期预告：自建影音的另外两块拼图——同样思路下的影视与照片管理方案横向对比，讲清楚它们各自的资源占用、客户端生态和许可证差异。