很多 Navidrome 教程的结尾，都是"部署完成，打开网页，你自己的 Spotify 诞生了"。可真把几千首歌丢进去之后，你会发现现实不太一样：封面缺一半、歌词没几首、有的歌搜不到，出门一听还放不出来。B站一条搭建教程视频下的高赞评论说得很直白：最难的不是搭建平台而是找到音源。哔哩哔哩搭建只是入场券，真正的修行从音乐入库才开始。
自建音乐库的真实状态其实挺典型的：知乎上有人在小主机里用 docker 跑 navidrome，配上免费隧道和一个便宜域名听歌。知乎门槛确实不高，但水下的坑，教程里很少写。今天就聊聊这 4 个教程不教的事：刮削、格式、资源和异地播放。
它不是全能点唱机：只读标签，不做刮削
想避坑，先搞清楚它的工作逻辑。Navidrome 是一个开源、自托管的音乐流媒体服务器，兼容 Subsonic/Airsonic 客户端协议，在圈子里以资源占用低出名，几万首歌也就吃几十 MB 内存。但关键点在于：它自己不刮削。它只读取你音频文件里已经写好的标签——标题、歌手、专辑、内嵌封面——然后整理成曲库。
换句话说，你的文件标签有多乱，搭出来的库就有多"面目模糊"：封面缺失、歌手错乱、专辑分裂。曲库质量的上限，在你把文件丢进去之前就定好了，Navidrome 只是如实展示。
坑一：刮削失败才是常态
既然 Navidrome 不刮削，社区早就形成了一套标准三件套：Navidrome + music-tag-web + 音流客户端。三个容器用 Portainer 这类 Docker 管理工具在 NAS 上一起部署，music-tag-web 负责补封面和歌词。
music-tag-web 的刮削数据源主要是 QQ音乐、网易云音乐。知乎专栏这就决定了它的长板和短板：中文主流曲目匹配率不错，但冷门专辑、欧美独立音乐、古典乐的不同版本，就容易对不上。别以为英文歌就稳，有跟着教程实操的用户发现：全选之后点了自动刮削，但还是很多没有出来，而且还是英文歌。哔哩哔哩
同一评论区里还有一串别的问题：music-tag-web 在 ARM 设备上创建任务失败、报 redis Error 111，网页端只显示 100 首歌，有的机器上卡得动不了。所以刮削结果不理想时先别慌，这不是你姿势不对，是这套工具目前的真实状态。
对策有两条。一是刮削完手动复查一遍，把重点专辑修好，死活匹配不上的用 Mp3tag 这类工具手动补标签。二是干脆走"入库前把封面歌词写进文件"的路线，比如社区里最近在聊的 Ro，能把歌词和封面直接嵌入 FLAC、MP3 文件，丢进 Navidrome 就是完整档案。知乎不过要提醒一句：这类工具本身不提供音源，需要自己备好音乐，而且务必在法律允许的范围内使用。
坑二：CUE 和 DSF，两种踩上就后悔的格式
第二个坑藏在文件格式里，教程几乎从不提。
如果你的存货里有不少 CD 抓轨时代的全专辑 cue——一张专辑一个大文件加一个 .cue 索引——那 Navidrome 大概率会让你失望。有用户直接吐槽：navidrome 看着好像很高级，但是不支持 cue。几百首歌的 cue 一首首去转，确实考验耐心。现实的做法是：入库之前，先用支持 cue 分割的工具把整轨拆成单曲，顺手把每首的标签写好，长痛不如短痛。
另一个隐形坑是 DSF，也就是 DSD 格式。有人搭完才发现：navidrome 音流网页播放，竟然不支持 dsf 格式的音频。小红书这是因为浏览器本身不解码 DSD。手里 dsf 多的话，要么换支持本地解码的客户端，要么提前转成 FLAC，没有第三条路。
所以动手之前先盘点一下自己的存货：有多少 cue、多少 dsf、主流 FLAC 和 MP3 的标签状况如何。这一步，其实比挑客户端更影响你后续的体验。
坑三：大曲库费机器，异地播放要绕路
曲库质量搞定后，还有两个日常用起来才显现的问题。
先是扫描资源。Navidrome 会定期扫描曲库来维持索引，曲库大、文件放在机械硬盘上时，扫描的开销就很明显。有用户因此换了方案：Navidrome 刷新曲库的参数无法更改，对 NAS 的资源占用一直偏高。知乎专栏如果你的曲库是几万首级别，建议把曲库目录尽量放 SSD，首次全量扫描安排在半夜，再观察扫描期间的 CPU 和磁盘占用，决定要不要调低扫描频率。
然后是异地播放，这是劝退最多人的一个坑。部署视频的评论区里，隔三差五就有人问"能出一期音流用外网播放的教程吗"，也有人直言：远程访问需要自行做反向代理，麻烦。哔哩哔哩典型症状是：家里 WiFi 下正常，一切到移动网络，列表能刷出来，歌就是放不了。对此有位专门踩坑后复盘的用户给了答案：常用的 DDNS-GO 方案在移动网络下问题很多，从 DDNS-GO 更换成虚拟局域网之后，播放竟然意外流畅。知乎专栏所谓虚拟局域网，简单说就是用 zerotier、节点小宝这类工具，把手机和家里 NAS 组成一个虚拟内网，流量走组网通道而不是公网直连，不需要公网 IP，配置门槛也不高。卡在异地播放的，不妨先试这条路。
还值得折腾吗？看你属于哪一类
说完坑，回到最现实的问题：Navidrome 还值不值得搭？看你属于哪种情况。
曲库不大、以中文主流歌曲为主、标签不算太乱的，Navidrome + music-tag-web 这套组合就够用，刮削一遍能解决大部分问题，折腾成本花得值。
欧美乐迷、古典党，存货里 cue 整轨和 dsf 较多的，建议先转格式、拆轨、补标签，再入库。否则搭完发现一半放不了、一半搜不到，弃坑的念头会比任何时候都强烈。
进阶玩家可以多看看它的协议生态：Navidrome 走 Subsonic 协议，除了音流，Amperfy 这类第三方客户端也能接，评论区已经有人用反代加 Amperfy 的组合在车上 CarPlay 听歌了。曲库不被锁在某一个网页里，这种可扩展性，才是自建真正的护城河。
最后提两个醒。第一，刮削和下载工具都只是帮你整理已经合法获得的音乐，音源版权这条线别碰。第二，这套生态还在快速进化，今天吐槽的坑，可能下个版本就有人填上，值得多留意社区动态再动手。
你搭自建音乐库的时候踩过什么坑？评论区聊聊，让我看看谁的更离谱。
