用 Navidrome 自建音乐库，手机也能听

音乐在自己的硬盘里，想换到手机或另一台电脑继续听，可以在 VPS 上装 Navidrome。它读取文件和标签，提供网页及兼容客户端播放。音乐、用户资料和播放记录都要分别保存。

先用两个专辑试运行，比一次上传整个库更容易发现标签、权限与播放问题。准备公开入口前，在 SSH 转发里完成首个管理员创建。

磁盘够放音乐，还要留给备份

部署需要 Linux、Docker Engine、Compose 插件和可登录的 SSH 账户。下面假定普通 Docker Engine，数据放在 /opt/navidrome。音乐必须是自己有权存储和使用的文件。

决定套餐之前，先统计音乐库实际体积、每月新增量和同时收听人数。原始播放主要涉及磁盘与网络，转码还会占用 CPU；几十 GB 的文件并不自动意味着需要高性能 CPU，多个客户端频繁转码也不能按空闲状态选内存。

例如 320 kbps 音频持续播放一小时，音频数据约为 144 MB，尚未计算协议开销。这只是用码率估算流量的方法，实际还受播放时长、缓存和转码设置影响。容量按当前库、增长和本地工作空间安排，另留独立备份，不能把唯一的音乐副本上传以后就删掉原件。

需要服务器保存较大的音乐库时，先比较存储 VPS 的磁盘、流量与备份条件。少量试用文件则可以先放到已有机器，验证手机连接路径后再决定是否增加容量。

少量原始音频播放可以从 2 GB 内存实例试运行，磁盘按现有音乐库和后续增长来选；多人转码另观察 CPU，不把原始播放的用量套过去。可查看雨云 RCS 的音乐库磁盘与网络，或比较 ECS 的实例与数据盘组合。下单前核对月流量、持续带宽和备份成本，先用自己的手机网络试完整播放，再上传整个库。

创建目录后，取得打算运行应用的数字 UID、GID，并把它们写入 .env。示例以当前账户运行；复制已有音乐进来以后，也应确认该账户能读取文件。

sudo mkdir -p /opt/navidrome/data /opt/navidrome/music
sudo chown "$(id -u):$(id -g)" /opt/navidrome/data /opt/navidrome/music
cd /opt/navidrome
printf 'APP_UID=%s\nAPP_GID=%s\n' "$(id -u)" "$(id -g)" > .env

把测试专辑复制到 music，创建 compose.yaml：

services:
  navidrome:
    image: deluan/navidrome:latest
    user: "${APP_UID:?set APP_UID}:${APP_GID:?set APP_GID}"
    restart: unless-stopped
    ports:
      - "127.0.0.1:4533:4533"
    environment:
      ND_MUSICFOLDER: /music
      ND_DATAFOLDER: /data
    volumes:
      - ./data:/data
      - ./music:/music:ro

/data 保存应用数据库、缓存等状态；/music 是音乐文件。这里只读挂载音乐，避免应用改动原文件。这个镜像使用 Compose 的 user 设置运行身份，不能靠添加其他镜像常见的 PUID、PGID 就认为权限已生效。

docker compose config --quiet
docker compose pull
docker compose up -d
docker compose logs --tail=100 navidrome

latest 是可变标签。正常运行以后记录摘要，固定已验证版本或摘要，并在升级前备份。遇到音乐扫描失败，检查容器日志、挂载路径和读权限；数据库写入失败则检查 data 权限与磁盘，不能通过删目录重启处理。

在自己的电脑转发端口：

ssh -N -L 127.0.0.1:14533:127.0.0.1:4533 user@YOUR_VPS_IP

访问 http://127.0.0.1:14533，按初始化界面创建管理员。之后若让手机通过公网使用，用自己的域名和 HTTPS 网关代理到服务器本机 4533；不要直接将首次初始化页面和明文登录入口开放出去。

试专辑标签、手机连接和完整播放

检查专辑名、专辑艺术家、曲目顺序和封面。合辑被拆散或同名专辑合并时，优先检查源文件标签，再重新扫描；只改文件夹名称未必能改变应用按标签组织的结果。

网页端播放一首歌，拖动进度、切换曲目，再在真正使用的手机客户端试一次。手机网络可能与电脑不同，网页正常也不能代替客户端连接验证。使用普通收听账户，确认它的访问范围；管理员账户用于维护，不必给每个客户端都配管理权限。

若手机端慢，先分开判断是否转码、请求是否到达应用、磁盘是否在繁忙扫描，以及这条网络是否绕路。开启转码后观察 CPU 与同时播放情况，再定输出码率，不要把转码失败直接归咎于 VPS 地区。

迁移时，音乐和数据库都要保存

Navidrome 内置备份导出的是数据库，包括用户、播放次数等资料，不会替你备份音乐或部署配置。迁移时至少要有音乐文件、应用数据、Compose 配置和镜像版本；“备份任务成功”不等于这几部分已经齐全。

小型实例可以停止应用后取得整个 data 的一致副本，同时保存音乐目录和配置，再启动服务。备份工具失败时也应恢复服务并排查，不要把残缺文件当成成功副本。音乐若另有完整保存位置，可按自己的增量策略处理，不需要每次重复打包整个库。

恢复演练在独立目录、不同回环端口使用相同版本启动。检查几个早期专辑、普通账户、播放列表和完整播放，再进行域名切换；若采用内置恢复命令，应用必须处于停止状态。用户记录恢复了而音乐挂载没恢复，界面可能仍有记录，播放却会失败。

磁盘够放音乐，还要留给备份

数据目录可写，音乐目录只读

试专辑标签、手机连接和完整播放

迁移时，音乐和数据库都要保存

接着读