自己动手搭过 Navidrome 的人，大概率都经历过同一幕：音乐库明明按文件夹分门别类整理了好几年，打开 Navidrome 一看，全被「拍扁」了——眼前只有专辑、歌手、标签组成的列表，自己那套目录结构像从来没存在过。
这不是你一个人的困惑。在 B 站一条 Navidrome 教程视频下面，有用户直接发问：自己的音乐都按类型用文件夹分门别类了，有什么办法能在 Navidrome 里直接查看某个文件夹的歌曲，最好还能汇总显示。哔哩哔哩也有人手握几千首歌，试图把同一文件夹里的专辑和专辑艺术家都改成相同名称来「骗」过系统，结果显示照样一团乱。
一、为什么不支持文件夹：这不是 bug
先说结论：Navidrome 不认文件夹，是设计取舍，不是等着被修复的功能。它的组织逻辑完全围绕元数据（歌曲标签）展开，教程 UP 主在评论区回复提问时说得直白：Navidrome 的逻辑里压根没有按文件夹整理的概念，它是基于元数据进行管理和展示的。哔哩哔哩
开发者的态度也很明确。一位从 foobar2000 迁移过来的用户研究了两天，确认没有按文件夹分类的路子：开发者标榜的就是按标签分类，并且 3 年前就说过绝不会增加这个功能。哔哩哔哩所以「等官方加文件夹视图」这条路可以直接划掉，别把时间耗在等更新上。正确的思路，是把「文件夹需求」翻译成 Navidrome 听得懂的方案。下面 4 条出路，一条条拆清楚怎么选、坑在哪。
二、先回答一个问题：你的文件夹在分什么？
选哪条出路，先看你现在的文件夹到底在分什么：
按歌手、专辑分——这类需求标签本身就能完全覆盖，文件夹只是外壳。最省事的做法是补齐标签，别折腾目录。
按场景、主题分（健身、车载、儿歌、白噪音）——这类分类和歌曲本身属性无关，天生就该用歌单承载。
按盘符、来源分（无损盘一个、下载的 MP3 一个、抓轨的一个）——这是存储问题，不是分类问题，靠多目录挂载解决。
对号入座之后，再看下面 4 条出路。
路线一：物理合并——最笨，但最稳
把散在各处的音乐归拢到同一个父目录的子文件夹里，让 Navidrome 唯一的音乐目录（ND_MUSIC_FOLDER）直接指过去。做法原始，但最不容易出错：不依赖任何环境、没有兼容性问题、版本升级也不会失效。不少老用户的思路正是如此：容器内挂载参数全默认，容器外所有音乐放进一个篮子，再建若干子目录。哔哩哔哩子目录叫什么 Navidrome 并不关心，但你自己加歌、备份时结构清楚。适合曲库不大、硬盘允许归拢、不想维护复杂配置的人。
路线二：Docker 多挂载——多盘用户的正解
音乐真的散落在多块盘、又没法物理归拢时，用 Docker 部署可以把多个宿主机目录挂进容器的 /music 子路径：
```yaml
volumes:
/volume1/music/flac:/music/flac
/volume2/downloads/mp3:/music/mp3
./data:/data
```
在 Navidrome 看来，这依然是「一个音乐目录」，但实际数据分布在多块盘上。以后加盘只是多加一行挂载配置，不用搬家式挪文件。如果你用的是带图形化 Docker 管理的 NAS，入口就在 Navidrome 容器的编辑页面，找到「文件夹路径」一栏，把多个目录逐条映射到 /music 下的不同子路径即可。
适合多盘、多来源曲库的 Docker 部署用户。注意挂载路径写错时容器会直接扫不到歌，改完配置记得重建容器再看扫描日志。
路线三：软链接——能用，但要绕开这 4 个坑
思路很简单：在音乐目录里建软链接，指向散落各处的音乐，Navidrome 顺着链接扫进去。理论上成立，但社区的实测翻车案例集中在 4 个地方。
坑一，飞牛 fnOS 的「快捷方式」不是软链接。有人嫌飞牛挂载的 SMB 路径太长，想用软连接缩短路径，结果发现打不开，还以为自己没整对，其实是飞牛不支持。哔哩哔哩系统界面上的快捷方式和 ln -s 是两回事，必须用真正的软链接。
坑二，CasaOS 里可见不等于可识别。有人在 CasaOS 里用 ln -s 把 U 盘的音乐链进 Music 目录，文件浏览器里能看到、打开也正常，但 Navidrome 里还是认不到。哔哩哔哩
坑三，群晖的局域网映射权限严格。有用户把 Navidrome 路径映射到局域网里的群晖，没有成功。哔哩哔哩这类情况建议先映射到本地路径排除权限问题，群晖的共享权限要单独放行。
坑四，容器内的软链接指向挂载目标之外的路径必然失效。软链接指向的目录如果没挂载进容器，容器里根本看不到——先挂载、再谈链接，顺序不能反。
适合不想挪动数据、又能记住这几个坑的人；新手不建议把软链接当第一选择。
路线四：用播放列表模拟文件夹——最 Navidrome 的答案
这是社区认可度最高的方案，也最贴合 Navidrome 的设计：既然它只认播放列表，那就把「文件夹」变成播放列表。关键事实是，Navidrome 本身可以自动导入、同步音乐文件夹下的 m3u、m3u8、nsp 等播放列表。哔哩哔哩问题就变成：如何让播放列表跟着文件夹内容走。
懒人做法是 .nsp 智能歌单。写好一段规则，保存为「歌单名.nsp」丢进音乐文件夹就行，它会自动更新整个文件夹的歌曲，按加入日期排序，自动更新增减。哔哩哔哩比如建一个「车载」歌单，规则写「歌名包含 车载」或按评分筛选，之后新入库的歌自动进来，完全不用手动维护。
勤快做法是脚本批量生成 .m3u。如果你的文件夹已经很规整，只想 1:1 映射成歌单，社区里有现成的 Shell 脚本：作者折腾这个脚本，就是为了依据文件夹自动生成歌单，从而以文件夹的形式便捷地管理音乐。今日头条脚本会遍历子目录，给每个含音频的目录生成同名 m3u 文件，用相对路径，方便整个音乐库搬家；支持多级子目录，自动跳过空目录。注意两点：它只收录当前目录的音频、不含子目录；新增音乐后要重跑脚本，歌单才会更新。
最后提醒一句：歌单文件就放在音乐目录里，备份曲库时请带上它们。曲库丢了可以重扫，歌单规则丢了只能一条条重建。适合按场景/主题分文件夹、或想保留现有文件夹成果又不动存储结构的用户。
决策速查表
你的情况 | 推荐路线 |
|---|---|
按歌手/专辑分，标签基本齐全 | 不动目录，把标签补齐 |
按场景/主题分（健身、车载、儿歌） | 播放列表模拟（.nsp 或脚本） |
音乐散落多盘、无法归拢 | Docker 多挂载 |
完全不想动数据、只求汇总 | 软链接（绕开 4 个坑） |
曲库不大、不想维护复杂配置 | 物理合并 |
最后说两句
如果你是从 foobar2000 这类播放器迁移过来的，习惯把音乐当成「文件夹里的文件」，我的建议是别和 Navidrome 的逻辑较劲。文件夹是存储视角，Navidrome 提供的是收听视角，两者不必一一对应。该补的标签补上，该模拟的场景用歌单模拟，存储层面用挂载解决——过了这道坎，你会得到一个能搜索、能筛选、不随目录变动的曲库。
你踩过哪个坑，或者有更好的整理思路，评论区聊聊。
