整理上万首音乐后的完整工作流：下载、刮削、播放与避坑指南
上篇文章讲了 Music Tag Web V2 的单机部署和基础使用，属于"能把东西跑起来"的阶段。今天这篇聊点更实际的：当你曲库规模从几百首膨胀到上万首，怎么让整个流程自动化，以及这一年多我踩过的坑。
这套工作流的核心思路很简单------让文件自己流进来，自动变整齐，打开就能听 。中间尽量少人工干预。
一、下载自动化：让音乐自己进库
手动下载再传到服务器上，几十首还行，上千首绝对是体力活。我的方案是用 go-music-dl 挂在服务器上自动下载。
go-music-dl 是一个命令行下载工具，支持网易云、QQ 音乐、酷狗等十几个平台。同样用 Docker 部署：
bash
docker run -d \
--name go-music-dl \
-v /你的下载目录:/app/download \
--restart=always \
xhongc/go-music-dl:latest注意这里的 /你的下载目录，要和 Music Tag Web V2 的 /app/download 指向宿主机上的同一个路径。我是直接在宿主机上建了一个 /docker/music/download 目录，两个容器都挂载它。
这样一来，go-music-dl 下载完的文件，Music Tag Web V2 立刻就能在下载目录里看到。你甚至可以在 Music Tag Web 的设置里配置"监控下载目录自动导入"，文件落地后自动出现在待整理列表里。
go-music-dl 的使用很简单，进入容器命令行：
bash
docker exec -it go-music-dl sh然后输入类似这样的命令：
bash
# 下载单曲
go-music-dl -u "https://music.163.com/song?id=xxx"
# 下载整张专辑
go-music-dl -u "https://music.163.com/album?id=xxx"下载的格式默认是 MP3，如果你对音质有要求可以在命令里加参数指定 FLAC。
二、衔接步骤：从下载到刮削的自动流转
文件下载到 /app/download 后，接下来就是让 Music Tag Web V2 接管。我摸索出来的最佳实践是这样的：
第一步：设置自动导入
在 Music Tag Web V2 的设置页面里，把下载目录设为 /app/download，然后开启"自动导入到媒体库"。这样每次有新文件落地，它会自动出现在待处理列表里。你不需要手动去移动文件。
第二步：设置文件命名规则（这步最关键）
go-music-dl 下载的文件名通常带有平台前缀或者编号，比如 "123456 - 周杰伦 - 晴天.mp3"。这会影响后续刮削的匹配准确率。
我的做法是：先在 Music Tag Web 里全选新导入的文件，用"从文件名解析"功能把艺术家和标题写进标签------分隔符选" - "，然后勾选"解析后重命名文件为 艺术家 - 歌曲名.扩展名"。这样一轮操作下来，文件名干净了，标签也有了基础信息。
第三步：批量刮削
基础标签就位后，全选文件点"批量刮削"，程序自动从网络数据库拉取专辑名、封面、发行年份、歌词等信息。实测下来，只要艺术家和标题是对的，刮削命中率在九成以上。
第四步：移动到正式目录
刮削完成后，把这些文件从 /app/download 移动到 /app/media 对应的子目录里。Music Tag Web 内置了文件移动功能，直接在界面里操作就行，不需要去宿主机敲命令。
三、播放端搭配：不同场景的最佳选择
上篇已经列出了各平台客户端，这篇重点说说实际使用中的搭配逻辑。
日常主力：Symfonium（Android）
市集评分最高不是没道理的。我选择它的几个理由：离线缓存稳定，通勤路上没信号也能听；智能推荐算法不错，会根据你最近听的内容推荐类似的歌；界面响应快，上万首曲库滑动不卡顿。
连接方式：添加服务器 → 选择 Subsonic → 地址填 http://你的IP:8002 → 输入用户名密码。注意地址后面不要加 /rest 之类的路径，Symfonium 会自动处理。
桌面沉浸式听歌：Feishin
Feishin 的专辑展示界面非常有质感，适合在电脑前认真听一张专辑的场景。而且它支持快捷键操作，切歌调音量不用离开键盘。
特殊情况：Tempo 做歌词联动
Tempo 是另一个 Android 客户端，特色是支持逐行歌词拖动。如果你收藏的歌里有不少歌词是错的或者时间轴对不上，可以在 Music Tag Web V2 里编辑内置的 LRC 歌词，然后在 Tempo 里查看效果。改完立刻同步，不用等缓存刷新。
临时听一下：Web 端就够了
V2 自带的 Web 播放器虽然简陋，但胜在零配置。有时候在朋友家想展示一下曲库，浏览器打开就能放，不用装任何 App。
四、踩坑记录：这些都是真金白银换来的经验
用了一年多，以下每个坑都搭进去过不少时间。
坑一：文件权限紊乱
Docker 容器默认以 root 运行，它创建或修改的文件权限可能变成 root:root。如果宿主机上还有其他服务需要读这些文件，就会报权限错误。
解决方法：在宿主机上定时执行 chown -R 你的用户名:你的用户组 /你的音乐目录，或者写个 cron 定时任务。我现在每天凌晨自动跑一次，再也没出过问题。
坑二：刮削数据源偶尔抽风
批量刮削依赖网络数据库，但有些数据源在国内访问不稳定，偶尔会出现连接超时。现象是刮削进度条卡住不动，或者返回结果全是空的。
解决方法：换个时间段重试。我一般晚上十点以后操作，成功率比白天高很多。如果一直不行，检查一下 Docker 容器的 DNS 设置，有时候改成 8.8.8.8 会有奇效。
坑三：/app/data 目录没有备份就升级
有一次手贱升级镜像没备份 data 目录，结果新版本数据库结构变了，回退后发现之前的刮削记录全丢了，几百首歌的封面又要重新刮一遍。那次之后我学乖了。
现在的做法：每次升级前先把 /app/data 整个目录打个 tar 包，确认新版本跑稳了再删旧备份。这个习惯救过我至少两次。
坑四：多用户环境标签冲突
如果你家里多人共用一台服务器，各人有各人的音乐目录，做好目录隔离。Music Tag Web V2 支持多用户，每个人设置自己的媒体路径就行。不要多人共用同一个 media 根目录，否则 A 改了标签 B 那边也会变，容易引起家庭矛盾。
坑五：strm 文件的直链失效
上篇讲了 strm 文件很香，但有个前提------直链必须稳定。我最初用某个网盘的直链，结果那个链接每隔几天就会过期。后来换成阿里云盘配合 alist 生成相对稳定的直链，情况好很多。另外建议定期检查 strm 文件的可用性，Music Tag Web V2 目前还没有自动检测 strm 有效性的功能，需要自己想办法。
坑六：客户端缓存不更新
偶尔遇到在 Web 端改了标签，客户端那边显示还是旧的。这不是 Music Tag Web V2 的问题，是客户端的缓存机制导致的。解决方法：在客户端设置里找到"清除缓存"或"刷新数据库"，一般都能解决。Symfonium 的话直接下拉刷新就行，响应很快。
五、正则表达式：进阶用户的效率利器
如果你文件名格式特别复杂，普通的"从文件名解析"可能不够用。Music Tag Web V2 支持正则表达式解析，这里给两个我实际在用的表达式，供参考。
场景：文件名是"音轨号. 歌曲名"
比如 "01. 晴天.mp3"、"02. 稻香.mp3" 这种。
正则表达式：^(\d+)\.\s*(.+)$
- 捕获组 1 映射为音轨号
- 捕获组 2 映射为标题
场景：文件名是"艺术家 - 专辑名 - 音轨号 - 歌曲名"
这种四段式命名在一些老资源里很常见。
正则表达式：^(.+?)\s*-\s*(.+?)\s*-\s*(\d+)\s*-\s*(.+)$
- 捕获组 1 → 艺术家
- 捕获组 2 → 专辑名
- 捕获组 3 → 音轨号
- 捕获组 4 → 标题
用好正则能省下大量手动编辑的时间，建议花点时间学一下基础语法，回报率很高。
到这里，从下载到刮削到播放的完整工作流就搭好了。自动化程度足够高的话，日常维护几乎不怎么花时间，偶尔上去看看有没有刮削失败的漏网之鱼就行。曲库越大，这套流程的价值越明显。