GoMusic 歌單搬家：把網易雲與 QQ 音樂歌單變成可搬移清單

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

先說結論：它只解決搬歌單的前半段，而且這半段親測可用

把網易雲音樂或 QQ 音樂的歌單搬到 Spotify、Apple Music 或 KKBOX，卡住你的從來不是「搬不動」，而是一百多首歌要一首一首搜尋、一首一首加入。GoMusic 這個開源小工具做的正是這件事的前半段：你貼上歌單連結，它回給你一份「歌名 – 歌手」的文字清單，你再把這份清單拿到搬遷服務去比對匯入。

我前後對它的線上服務發了十來個請求：網易雲官方熱歌榜（200 首）第一次花了 31.5 秒、第二次 1.5 秒；QQ 音樂一份 42 首的公開歌單花了 31.6 秒；README 示範用的短連結 113 首只花 2.4 秒；餵它亂打的字串，它直接拒絕處理。功能是真的、免帳號、免安裝。但「免費搬到國際服務」這句話要拆開看：GoMusic 免費給你的只有那份清單，真正把歌塞進 Spotify 的下一站（TuneMyMusic）免費額度是 500 首，超過要付費。

這個專案 2023 年 10 月開在 GitHub 上，MIT 授權，到 2026 年 10 月約 2,500 顆星，162 個提交裡 157 個出自同一位深圳開發者之手，維護方式很個人化：沒有商業公司、沒有付費牆，README 放的是微信打賞碼和一張贊助榜。對使用者的意義是，它的存續跟作者一個人的意願綁在一起，這點後面限制段會再回到。

接下來把該知道的事攤開：這半步工具的實測表現、免費界線實際畫在哪裡、程式碼和線上服務之間有哪幾處對不起來，最後是誰該用誰該繞路。

實測：兩條來源路都活著，速度差一個量級

GoMusic 的官網就一個輸入框：貼連結、按下紅色的取得歌單按鈕、等結果。沒有註冊、沒有登入、沒有驗證碼，介面有中英文切換。我把測試過程整理成下表。

Pin

結果輸出成文字前有三個格式選項：「歌名 – 歌手」（預設）、「歌手 – 歌名」、「只保留歌名」，加上正序倒序切換。另外有個「使用未經處理的原始歌曲名」的勾選，勾了會跳過站方快取、直接向網易雲即時要資料，官方提示寫明不勾的版本在目的地平台比對成功率較高。我拿同一份歌單兩種都跑過，差異比選項名字暗示的細微：逐字對照才會看到括號標記清理這類小出入，演唱者名單也曾出現不一致（我這次對照中，快取版列出完整合作藝人，即時版少列一位）。搬遷用途用預設就好。

Pin

有個小地方值得知道：如果你貼的網易雲連結少了歌單 id（例如只貼了 music.163.com/playlist），它不會報錯，只會回你一個「成功」加空清單，歌曲數顯示 0。工具不會咬你，但你得自己看出連結貼錯了。拿一個不相干的網址給它，它也會明確拒絕，錯誤處理算是乾淨；照原始碼的路由規則，不在支援清單裡的連結（例如 YouTube）都會被擋下。

輸出的文字長什麼樣？以熱歌榜為例，就是一行一首的 我不难过 - 孙燕姿、罗生门 (Follow) - 梨冻紧 / Wiz_H张子豪 這種純文字（歌名照原樣輸出，來源是簡體字就維持簡體），按「複製結果」整份進剪貼簿，拿去哪裡貼都行。這也帶出它的第二個用途：就算你根本不打算搬家，一份純文字的歌單本身就是最耐放的備份，放在筆記或文字檔裡，十年後照樣讀得動，比鎖在任何一個平台裡都保險。

順帶一提，官網首頁掛的 GitHub 星數徽章在這次測試時顯示不出來，一直是一個 invalid 字樣。不影響功能，但對一個以星數當門面的專案來說，這個細節頗有寓意。

免費的界線不在這個網站，在下一站

GoMusic 的 README 使用指南就四步：貼連結、複製結果、打開 TuneMyMusic 或 Spotlistr、選「任意文字」當來源貼進去，再選 Apple Music、YouTube Music 或 Spotify 當目的地。實際走一次會發現「任意文字」這個來源選項是整條路的接合處：TuneMyMusic 不認得網易雲或 QQ 音樂，但它認得一份歌名清單，GoMusic 負責把前者變成後者。整個過程 GoMusic 從頭到尾沒有碰你的音樂帳號，它不做匯入、不代管密碼，只做「清單抽取」這一個動作。這個設計讓它避開了最麻煩的授權問題：它不繞過任何 DRM，也不搬音樂檔本身，搬的只是中繼資料。

收費的關卡在下一站。TuneMyMusic 官網方案文字寫的是「免費傳輸最多 500 首歌曲」，升級付費方案才有無限傳輸、自動同步和備份。以我測的熱歌榜 200 首來說免費額度夠用，但網易雲重度用戶動輒上千首的收藏，要嘛付一筆小錢、要嘛把歌單拆成多次搬。KKBOX 也列在 TuneMyMusic 的支援平台清單裡，台灣讀者有這條路可走（實際匯入結果我沒有親測）；Spotlistr 是 README 點名的另一個選擇，它的額度與限制我沒有逐一核對，下手前值得兩邊都比一下。

如果想搬回中國服務，方向要反過來走：QQ 音樂自己有文字匯入功能，把清單貼進去即可。但專案 issue 裡的用戶回報，QQ 音樂單次匯入有約 1000 字元的上限，大歌單要分批貼，貼完還要手動合併，來回幾次相當折騰。這條路沒有自動化，只能靠耐心。

QQ 那條路為什麼慢：一頁 30 首的重試迴圈

31.6 秒只搬 42 首歌，這個數字背後是一個正在退化的依賴。我讀了 GoMusic 的原始碼：它對 QQ 音樂走的是帶簽名的公開介面，每個請求要先對參數做 MD5 雜湊、按特定規則取字元、再組出一個簽名值附在網址上，而且同一頁資料要按七種平台身分（android、iphone、h5、windows 等）依序嘗試，哪個身分回的內容有效就用哪個，全部失敗才算這一頁掛了。更要命的是分頁上限：2026 年 1 月 13 日的一次修復，把 QQ 音樂每頁抓取量從 1000 首砍到 30 首，因為 QQ 的介面不再接受大頁請求。一千首歌的 QQ 歌單，現在理論上要連續打 34 頁、每頁最多七次嘗試，上限則是 10,000 首。

GitHub 的 issue 紀錄把這條退化曲線畫得很清楚：2025 年 12 月底有用戶回報 QQ 音樂歌單只解析出首頁 30 首；進到 2026 年 1 月，又有人回報「歌曲獲取的結果少了非常非常多」，還有用戶留言說 183 首只解析出 30 首、已經打賞求作者出山處理。修復在 2026 年 3 月 4 日合併，就是那次砍分頁的提交。但 2026 年 3 月之後 main 分支就沒有再動過，到 2026 年 10 月已七個多月，倉庫也從未發布過任何正式版本。依賴 QQ 介面的功能，等於踩在一條會繼續收緊的地基上。

網易雲那條路健康得多。它走網易雲的公開介面，一次能批量查 400 首歌的資料，伺服器端還有兩層快取：Redis 存 30 秒的原始結果，MySQL 長期存「歌曲 id 對歌名」的對照表，第二次查同一個歌單命中快取就快了。汽水音樂是第三條路，做法又不同：不走介面，直接抓分享頁面的 HTML，再用 CSS 選擇器從頁面結構裡挖出歌名與歌手。這種寫法最依賴對方頁面長什麼樣，對方一改版就失效，三次來源裡工程上最脆弱，後面限制段會回到它的現況。

還有個工程細節值得一提：官網域名其實不處理資料請求。直接對 music.unmeta.cn 的後端路徑發請求，會被轉回首頁；前端網頁的程式碼裡寫死了另一個子網域當真正的介面位址。對一般使用者無感，但這解釋了為什麼有些人照著教學文章直接呼叫 API 會失敗。

開源碼和線上服務，不是同一份東西

幾個對不起來的地方，用之前應該知道。

最顯眼的是廣告。2026 年 3 月 4 日合併的前端重構，把 Google AdSense 從開源版裡移除了；但線上版 music.unmeta.cn 的頁面原始碼到今天仍帶著 AdSense 的載入腳本與發布商號碼，是伺服器端注入的。也就是說，你讀的原始碼沒有廣告，你用的網站有。規模大概只是一條橫幅，對免費服務也不苛刻，但「讀到的碼」和「用到的站」有落差這件事本身，值得放在心裡。

更要緊的是資料流向。這個站沒有任何條款頁或隱私權頁，整個服務就是一個單頁應用加一支後端介面。你提交的歌單連結會進它的請求日誌，歌曲清單會流過它的 Redis 與 MySQL 快取，預設模式的歌名對照還會長期存在資料庫裡。域名查起來是阿里雲註冊的個人域名，解析出來的兩個子網域都指向中國阿里雲機房的同一台伺服器。歌單不算敏感個資，但「我正在搬家、我聽什麼歌」這件事被誰看到，你應該有知情權，而這裡沒有任何人給你交代。

自架的人則要注意預設值。GoMusic 可以自己架一套：官方部署文件給了完整的 docker-compose，但裡面把 MySQL root 密碼（12345678）和 Redis 密碼寫死在文件裡，而且把 3306 和 16379 兩個埠直接發布到主機上。文件有提醒改密碼要同步改哪兩個程式檔，這點值得肯定，但照抄部署的人若沒讀到那段，就是在網路上開了一台弱密碼的資料庫。另外專案沒有發布過任何打包版本或映像檔，自架就是從原始碼自己編。

服務本身的歷史也提示了它有多「個人」。2025 年 10 月曾有用戶開 issue 反映網站打不開，五天後修復關閉；QQ 解析壞掉的那波，從用戶回報到修復合併隔了約兩個多月。作者不是棄坑型的人，贊助榜上也看得出有人用行動支持，但一台伺服器加一個人的作息，就是這個服務的全部冗餘。

五百首內的公開歌單直接用，汽水用戶先試十首

適合用的情境很明確：你有一份網易雲或 QQ 音樂的公開歌單，目的地是 Spotify、Apple Music、YouTube Music 或 KKBOX，歌單在 500 首以內，不想裝任何東西。貼連結、複製、到 TuneMyMusic 貼上，幾個動作就能把清單送進搬遷流程，這個價值是真的。人在台灣而一直在網易雲聽華語歌的用戶，大概就是最典型的受眾。

幾種情況要先想一下。歌單超過 500 首，先算一下 TuneMyMusic 的付費方案值不值得，或把最重要的幾張先搬；把歌單拆批能不能閃過額度，官方文案沒有講清楚，我不會建議靠這招。用的是汽水音樂，README 雖然列了支援，但 issue 裡有一條 2025 年 7 月開立的汽水相關故障回報至今未解，建議先拿十首歌試水溫再全搬。非常在意資料流向，或本來就有 Docker 環境，自架一個實例是乾淨的替代路，記得先改掉資料庫密碼與對外埠。私人歌單我這次沒有測，工具對「開放存取」狀態的歌單最順，不確定就先把歌單設成公開再搬。

最後一個預期管理：這類搬遷搬的是「歌單」不是「歌」，音樂檔不會跟著走，也不會碰任何版權保護。目的地平台靠清單文字去比對自家曲庫，比對不到的（地區限定、下架、翻唱與現場版差異）最後仍要你手動補。把 GoMusic 當成「省掉逐首搜尋的那一步」來用，它稱職；期待一鍵全自動、什麼都不用補，會失望。

手邊有網易雲歌單的讀者，可以順著看我們介紹過的網易雲歌詞下載工具；搬完之後的聆聽端，開源播放器 SimpMusic 和終端機 Spotify 播放器各有玩法，最近寫的AI 音樂播放器 Melodisco 則是另一種聽歌的思路。