QM-Music：把中文曲庫搜尋做扎實的 Subsonic 自架音樂伺服器

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

QM-Music 是一套以 Subsonic 協定為骨幹的開源私有雲音樂伺服器，用 Docker 一行指令就能跑起來，能直接銜接音流、feishin、Amperfy 這些你可能早就裝過的 Subsonic 客戶端。它真正值得多看一眼的地方，不在「輕量」這個宣傳詞（同類型的 Navidrome 也一樣輕），而在它把中文曲庫的繁簡互搜與排序當成一等功能來做。但也要先講清楚：它是 2025 年才開張的新專案，功能成熟度還追不上 Navidrome，而且它的 Apache-2.0 授權與「僅限學習研究」的免責聲明之間存在一段需要你自己拿捏的張力。

如果你只是想找一套穩定、生態成熟的自架音樂伺服器，業界標準答案一直是 Navidrome；QM-Music 的位置，是留給那些中文曲庫比例高、或想在寬鬆授權下做二次開發的人。下面把這兩個判斷分開講清楚。

Subsonic 當骨幹代表什麼：你裝過的客戶端都能直接接

QM-Music 不是又一套自己訂一套協定的封閉音樂盒，而是實作了 Subsonic 這套公開的串流 API。Subsonic 發展超過十年，圍繞它長出了一整圈第三方客戶端，所以「Subsonic 相容」在這裡不是一行行銷話，而是你部署完 QM-Music 之後，只要在客戶端填入伺服器地址、帳號、密碼就能連，不必為了它特地學一套新 app。README 列出實測過的客戶端包含音流（Stream Music）、feishin、Amperfy、substreamer、music-assistant，覆蓋了 iOS、Android 與桌面三大平台。

Pin

Subsonic 原本是某套同名商業音樂伺服器開放的 API，後來社群把它獨立成一套事實標準，任何伺服器只要照著這份 API 規格實作，就能被所有相容的播放器連線。這個生態的好處是「伺服器和客戶端可以自由組合」，你不會被綁在單一廠商的 app 上，換伺服器不用換播放器，換播放器不用換伺服器。QM-Music 選這條路，等於是把自己的伺服器接到一條已經成熟的水管，而不是從零造一條。

對讀者的實際影響是：你之前為 Navidrome 或任何 Subsonic 伺服器裝的播放器，換成連 QM-Music 不用重學。這也意味著 QM-Music 本身幾乎不需要自己做手機 app，它把「播放體驗」外包給整個成熟的 Subsonic 客戶端生態，自己只顧伺服器那一端。

真正的差異在中文曲庫，不在「輕量」兩個字

README 主打「約 150MB 記憶體占用」當輕量賣點，但這個數字是作者自行標註的，沒有第三方實測背書，而且 Navidrome 用 Go 寫成單一執行檔，資源占用同樣很低，所以「輕量」不足以當成選 QM-Music 的理由。QM-Music 比較實在的差異點，是它把中文曲庫的檢索體驗單獨拿出來做。

根據 README 的功能描述，QM-Music 支援繁簡字互搜，並針對中文排序與檢索做了優化。對一個中英文混藏的台灣音樂庫來說，這直接影響你搜尋歌手、專輯時會不會「明明有卻搜不到」。這一點是西方出身的 Subsonic 伺服器長期比較弱的地方。要強調的是，這段是作者宣稱的能力，本文沒有親自灌入大型中文曲庫實測它的搜尋準確度，但方向上它確實是把資源投在多數同類工具忽略的環節。

功能面它還涵蓋多使用者權限、自訂播放清單與收藏、本地與線上歌詞同步、依專輯／歌手／流派分類瀏覽、播放歷史與偏好記錄，以及定時掃描目錄自動更新曲庫。音訊格式支援 MP3、FLAC、AAC、WAV，若需要節省行動網路流量，可以打開 libmp3lame／acc 動態轉碼（預設是關閉的）。轉碼的取捨很直接：把高位元率的 FLAC 即時降轉成較小的串流，能省下行動網路流量，代價是伺服器要多吃一點 CPU；在家用 Wi-Fi 聽無損時通常不必開，通勤用手機網路時才值得打開，這也是它預設關閉的原因。

曲庫管理這一塊，README 描述它能定時監測音樂目錄的變動、自動重新整理元資料，並辨識 ID3 標籤與專輯資訊，把歌曲依專輯、藝人、流派結構化呈現，同時記錄播放歷史與個人偏好。這代表你把新檔案丟進掛載的音樂目錄後，不必手動觸發，伺服器會自己在下個排程把它編進曲庫。對收藏量大的人來說，這個自動化能省下不少整理功夫。

Pin

部署其實很短：Docker 一行起來，但預設密碼要馬上改

QM-Music 官方推薦用 Docker 部署。最基本的指令長這樣，把音樂目錄、資料庫、快取三個 volume 接出來，對外開 6688 連接埠：

docker run -d \
  --name qm-music \
  -p 6688:6688 \
  -v /your/music:/data/qm-music/music_dir \
  -v /your/db:/data/qm-music/db \
  -v /your/cache:/data/qm-music/cache \
  -e QM_FFMPEG_ENABLE=true \
  -e TZ=Asia/Taipei \
  --restart unless-stopped \
  qmmusic/qm-music:latest

啟動後用瀏覽器打開伺服器地址的 6688 埠，以預設帳號 admin、密碼 admin 登入，第一件事是立刻改掉這組預設密碼，再進到曲庫管理按下重新整理把元資料掃進來。接著到你想用的 Subsonic 客戶端裡，把伺服器地址指向這台機器、填入改過後的帳密，就完成連線了。三個掛載目錄各有用途：music_dir 放你的音樂檔，db 存資料庫與元資料（官方特別提醒別塞其他檔案進去），cache 放快取。把它們掛出來是為了容器重建或更新映像檔時，曲庫與設定不會跟著消失。

部署門檻確實低，但預設帳密是上線前一定要處理的安全風險。6688 埠不要直接裸露在公用網路上，比較穩的做法是放在區域網路內，或用反向代理加上 HTTPS 與存取控制再對外；畢竟這台伺服器連著你整個音樂收藏，一旦預設密碼沒改又被公開存取，等於把私人媒體庫大門敞開。除了 docker run，README 也提供 docker-compose 版本，方便你把設定寫進檔案版控。

環境變數裡幾個值得知道的：QM_FFMPEG_ENABLE 控制轉碼開關；TZ 請依所在地設定（台灣用 Asia/Taipei）；另外可選配 Spotify、Last.fm 的 API 金鑰來補強元資料，作者標示為非必要。如果你還在累積自己的音樂收藏，例如用 YouTube Music 下載工具 把合法取得的曲目收進本機，再交給 QM-Music 統一管理，是常見的自建曲庫流程；想找新歌時也能搭配 Samplette 這類音樂發掘工具 先擴充片單。

老實說它還做不到的事：CUE 分軌、同名專輯、基礎路線圖

把 QM-Music 當成熟產品來用之前，有幾個它目前還做不到、或做不好的地方要先知道，這些都來自它自己 issue tracker 上還開著的條目，不是猜測。首先是 CUE sheet 尚未支援：很多人收藏的無損專輯是一整個 FLAC 檔配一張 CUE 分軌，QM-Music 目前沒辦法依 CUE 把它拆成單曲瀏覽，這類收藏會匯入不全（補充：這不是 QM-Music 獨有的缺口，Navidrome 同樣不支援 CUE 分軌，所以大量依賴 CUE 的無損收藏，目前這類 Subsonic 伺服器都還幫不了你）。另一個是同名專輯的辨識邏輯還待調整，當不同歌手發行同名專輯（例如各家的精選輯）時，系統可能只依專輯名稱比對、把它們併成同一張，而不是依藝人加專輯的組合區分。

從路線圖看，外置資料庫、跨平台原生客戶端、Web 播放器強化、單元測試覆蓋率都還掛在待辦清單上，多數尚未打勾。對應到版本號，最新版是 2026 年 7 月發布的 v2.3.1，專案仍在更新，但整體還在補基礎建設的階段。講這些不是要否定它，重點是讓你掌握它目前的位置：方向正確、有持續維護，但還不是個功能齊全的成品。

QM-Music 與 Navidrome：你該拿哪一個

多數人會拿 QM-Music 跟 Navidrome 比，因為兩者都是 Subsonic 相容的自架音樂伺服器。這裡把兩者在文件可核對的維度上攤開來看，幫你判斷自己落在哪一邊。需要先說明的是，這張表比的是規格與客觀條件，不比實際跑起來的手感或音質，那些本文沒有實測。

從這張表可以看出一個清楚的分流。如果你重視的是穩定度、社群資源與成熟的客戶端相容性，Navidrome 目前還是比較安全的預設值，它在 OpenSubsonic 協定的推動裡就是參考實作，生態位牢固。OpenSubsonic 是社群為了延續原 Subsonic API 而共同維護的開放規格，Navidrome 是其中領頭的實作，這意味著未來客戶端相容性它會走在前面。反過來說，如果你的曲庫以中文為主、你確實在別套 Subsonic 伺服器上遇過中文搜尋排序不對勁的困擾，而且你想做的事情可能涉及商業運用或不想被 GPL 綁住，那 QM-Music 的 Apache-2.0 授權加上中文優化方向，會是值得追蹤的理由。同樣是「自架自己的媒體庫」這個大方向，把影片收藏自建一套 的讀者，也常會在同一台機器上順手架一套音樂伺服器。

授權很寬鬆，但作者的免責聲明又寫了限學習研究

QM-Music 以 Apache License 2.0 開源，這是一份寬鬆授權，允許商業使用、修改與散布，條件是保留原始版權聲明、並對你的修改做明確標示。對想把音樂伺服器嵌進自家產品的開發者來說，這點比 GPL-3.0 的 Navidrome 友善很多。但 README 同時附了一段免責聲明，寫明「僅供學習研究、不得用於商業活動」，這兩段文字其實是有張力的。

從授權法的角度，Apache-2.0 一旦授出就不可撤銷，它授予的商業使用權利不會因為 README 的一句免責聲明就消失；但作者確實表態了非商業的立場，這會反映在他後續維護意願、是否接受商業導向的功能建議上。本文不替你下法律結論，只把事實攤開：實際要用在商業場景之前，請自行看過 LICENSE 條款、衡量作者立場帶來的長期風險，必要時找專業意見。這種「條款本身允許、但作者表態反對」的灰色地帶，在開源專案裡不算少見，誠實說出來比假裝它不存在有用。

所以，誰該花時間裝 QM-Music

把你情境對號入座的話：你的音樂檔以中文歌手為主、你曾在別套 Subsonic 伺服器上被中文搜尋排序卡過、你的收藏裡沒有大量 CUE 分軌的無損專輯，而且你有能力接受一套還在補功能的新專案，那 QM-Music 值得你架來用看看，尤其當你打算做點二次開發、想避開 GPL 的時候。相對地，你要的是一套裝了就穩、出問題找得到答案的成熟方案，那 Navidrome 仍然是該優先裝的那一個。

不管選哪一邊，自架音樂伺服器的核心價值都在於把資料留在自己機器上、不被任何串流平台綁住。QM-Music 把賭注押在中文曲庫與寬鬆授權這個 niche 上，方向清楚，只是需要再多一點時間把成品補齊。若處理音訊檔案時需要轉換格式，也能搭配 瀏覽器端的音訊轉檔工具 先把收藏整理成伺服器吃得進的樣子。

想實際動手的話，順序大概是這樣：先確認你的曲庫格式是不是 QM-Music 吃得下的 MP3／FLAC／AAC／WAV，有 CUE 分軌的無損收藏先留意，目前 QM-Music 與 Navidrome 都還會匯不全；接著準備一台常開的機器，用 Docker 把它跑起來、掛好三個目錄、改掉預設密碼；最後挑一個你順手的 Subsonic 客戶端連線試播幾首，看看中文搜尋排序符不符合你的預期。這一圈走完，你自然會知道它適不適合你的收藏，不必只靠規格表判斷。