Exportify：把 Spotify 播放清單匯出成救得回來的 CSV 備份

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Spotify 的客戶端到今天都沒有「匯出播放清單」這個按鈕。歌單刪了可以透過官方的帳號頁救回來，但要是帳號出狀況、地區搬家，或者純粹想把十幾年攢下來的清單留一份在自己手裡，官方介面給不了你任何檔案。Exportify 補的就是這個洞：授權一次，幾分鐘後你拿到一份 UTF-8 編碼的 CSV，每一首歌一列，連同它在全球資料庫裡的身分證號一起帶走。

這個工具比多數人以為的老得多。watsonbox 這個 GitHub 專案建立於 2015 年 5 月，到本次查核有 4,182 顆星、529 個 fork，MIT 授權，主分支最新的提交落在 2026 年 4 月，十一年後仍然有人在修它。下面把它的機制、匯出內容、還原方式與幾個先講清楚比較好的限制，一次攤開。

一支 2015 年申請的金鑰，開著 2026 年還能用的門

先看整個工具最值得知道的一件事。我把 src/auth.ts 逐行讀過，程式裡寫死了一組 Spotify 應用程式的 Client ID，所有人預設共用同一支 2015 年申請的老金鑰。這件事平常無感，放在 Spotify 近兩年的政策脈絡裡就很有戲：2024 年 11 月 27 日起，Spotify 官方公告新申請的應用程式不再能呼叫音檔特徵、音檔分析、相關歌手這類端點，連多筆回應裡的 30 秒試聽連結也一併收回；只有在那之前就通過配額延展審核的舊應用程式可以照舊使用。開發者社群裡大量 2024 年之後才申請金鑰的人，拿到的是 403 拒絕。

Exportify 的音檔特徵欄位到現在還能匯出，對應的正是這條祖產線。repo 的 issue #223 裡就有第三方開發者直接問維護者：你們是不是有特殊權限？這個問題到本文查核時沒有得到回答。官方沒有公開豁免名單，所以嚴格說這是時間點加第三方回報推出來的結論：工具的金鑰比政策早了九年，而新金鑰的使用者確實拿不到同樣的資料。對一般使用者的實際意義有兩層。用預設金鑰匯出的檔案，欄位比 2024 年之後任何新工具能拿到的都完整；而 README 建議重度使用者自建 Spotify 應用程式、在網址加上自己的 Client ID 來換取更寬鬆的額度，這條路在 2026 年有個新代價：自架的新金鑰，試聽連結會變成空白，音檔特徵大概率被 API 直接拒絕，該次匯出可能因此失敗。

金鑰怎麼授權也值得看一眼。2025 年 11 月的一次提交裡，整個登入流程從 Implicit Grant 遷移到 Authorization Code with PKCE，簡單說就是瀏覽器端的標準做法，token 換取過程多了一組動態 challenge，防的是授權碼被攔截。授權範圍是三個純讀取的 scope：讀私密清單、讀共同編輯清單、讀個人音樂庫。沒有任何寫入權限，這支工具從權限設計上就動不了你帳號裡的東西。

CSV 裡到底有什麼：19 欄基本欄位，URI 是還原鑰匙

匯出的主體是每張清單一份 CSV。基本欄位有 19 欄，包含歌曲與歌手的 URI、專輯資訊、發行日期、封面圖連結、音軌編號、長度、是否含限制級內容、熱門度，以及兩個比較少見的欄位：ISRC 國際標準錄音碼，和這首歌被誰、在什麼時候加進清單。ISRC 是唱片業辨認「同一個錄音版本」的全球編號，比歌名字串可靠得多；將來要拿這份 CSV 去別的服務對帳、去重，靠的就是它。

點右上角的齒輪可以再加掛三包資料。選歌手資料，補上每首歌歌手群的流派分類，多歌手合作曲會把所有歌手的流派合併在同一格；選音檔特徵，補上 12 個量化指標，從舞曲性、能量、節奏到情緒價值都有，等於 Spotify 替每首歌貼好的聲學標籤；選專輯資料，補上專輯流派、發行廠牌與版權聲明。原始碼裡對拿不到音檔特徵的項目，例如 Podcast 單集，會直接補空欄位而不是中斷整份匯出。代價也寫得明白：欄位開越多，匯出越慢，因為每一包資料都是額外一輪 API 呼叫。

整份資料的粒度，拿來做使用情境分析是夠用的。想看自己十年來聽歌的節奏分布、想統計某張清單裡有多少獨立廠牌發行，CSV 丟進試算表或 Python 都能直接算。TechMoon 之前介紹過的 Samplette YouTube Music 隨機抽歌工具走的是發現新路線，Exportify 則是把舊路上的東西打包帶走，兩件事剛好互補。

資料流向：瀏覽器直連，但錯誤回報有但書

首頁最顯眼的一句話是 No data will be saved，整個應用程式在瀏覽器裡跑。對照原始碼，這句話成立：授權流程直連 Spotify 的帳號伺服器，API 呼叫直連 Spotify 的資料端點，repo 裡沒有任何後端，你也不用在第三方網站輸入 Spotify 密碼。存取權杖放在瀏覽器的 localStorage，過期就自動清掉重來。

Pin

但書在錯誤監控。程式內嵌了 Bugsnag，請求失敗重試時會把錯誤連同請求與回應的詮釋資料送出去。這不涉及你的歌單內容被整批上傳，但「完全沒有任何東西離開瀏覽器」這句話嚴格說並不精確，追求最小足跡的人可以自己 clone 專案、用 Docker 跑在本機，README 有現成的指令。授權一次拿到的只是讀取權，這在權限段已經提過，這裡再提醒一次：移除授權隨時可以在 Spotify 帳號頁的應用程式清單裡自己操作。

備份救得回來嗎：URI 能貼回去，資料夾和排序不在保單裡

備份工具的終極問題是還原。README 的官方路徑是：把 CSV 裡的 spotify:track: 開頭 URI 整欄複製起來，在 Spotify 桌面版開一張新清單，貼上，歌曲就回來了。作者註明這條路只在桌面版測過。所以那份 CSV 裡真正值錢的是 URI 欄，歌名會改、串流平台會下架又上架，URI 是 Spotify 生態裡辨認「就是這首歌」的穩定指紋。

三個還原的邊界要先講。播放清單資料夾救不回來，Spotify 的 Web API 根本不回傳資料夾結構，README 直接引用官方文件說明這是 API 的限制，所以匯出檔裡沒有任何資料夾資訊，幾十張清單分層收納的人要有心理準備。排序要看運氣，貼回去的順序通常跟著 URI 在剪貼簿裡的順序走，但這是桌面版客戶端的行為，不是工具的保證。跨平台搬家不在保單裡，Exportify 只負責把資料交到你手上，CSV 變成 Apple Music 或 YouTube Music 的清單需要另外的轉換服務或腳本，ISRC 欄位在那個階段才會派上用場。

如果你對「音樂資料握在自己手裡」的想法更進一步，TechMoon 介紹過的 QM Music Server 自架音樂伺服器是另一個量級的方案；單純想把手機裡的聊天紀錄也留檔的，可以看 iMessage Exporter 訊息匯出工具，同一種「資料出口」的思路。

官方其實有匯出，只是要等最多 30 天

誠實起見，Spotify 並非完全沒有官方出口。帳號頁的 Download your data 功能，產出的封裝裡確實包含你自己建立的播放清單，官方說明文件寫明會給清單名稱與所含歌曲，第三方拆包分析也確認有個 Playlist 開頭的 JSON 檔完整列出清單內容。兩條路線的差別在形狀：官方路線的準備時間最長可以到 30 天，格式是 JSON，拿到手還要自己轉檔；Exportify 是幾分鐘的事，格式直接是能開、能貼、能分析的 CSV，還多了流派、音檔特徵、ISRC 這些官方封裝不一定有的欄位。平常的頻繁備份用 Exportify，帳號要永久註銷前的那次終極封存，兩個都跑，互為保險。

清單一多就撞牆：限流排隊、卡死個案與一場已落幕的斷線

這個工具的另一面是規模。批次匯出的請求在程式裡是排隊序列執行的，同時只有一條連線；撞到 429 限流時，程式會照伺服器回報的 retry-after 秒數等待後重試，最多重試兩次，遇 502 這類暫時性錯誤也有一套加長緩衝的重試邏輯。這套機制 2020 年就上了，但 API 有額度就是有額度，幾百張清單的 Export All 本來就會花上一段時間，這是排隊，不算故障。

真正的故障長什麼樣，2026 年 7 月有一場現場。7 月 22 日起陸續有三位使用者回報頁面卡在載入、匯出到一半出現 Failed to fetch，維護者隔天回覆並追查，最後確認問題出在 Spotify 端，服務隨後自行恢復，三個人都回來確認正常。這場斷線約兩天，是 Spotify 那側的事，但它示範了這類工具的結構性風險：工具再老牌，地基是別人家的 API。另外還有一個未結案的個案，有使用者回報約兩千張清單的帳號匯出到六成左右頁面會自動重新載入，這個 issue 從 4 月開到現在沒有回覆。帳號規模在那個量級的人，比較穩的做法是分批：用內建搜尋先篩一部分清單，匯出搜尋結果，分幾輪把整庫搬完。

Pin

同名不同人：.app 與 .net 是兩個專案

搜尋 Exportify 會撞到兩個長得很像的網站，先分清楚。exportify.app 是本文介紹的這個，watsonbox 的 2015 年專案，現在的前端是 React 打包的新介面；exportify.net 也活著，但它背後是另一位開發者的同名專案 pavelkomarov/exportify，2019 年建立，700 顆星上下，技術組合停在較舊的 Bootstrap 3 搭 React 16，匯出欄位與附帶的 Jupyter 分析流程也是自己另一套。我把兩邊的首頁原始碼比對過，.net 頁面上的 GitHub 連結全部指向 pavelkomarov 的 repo，與 watsonbox 沒有從屬關係。7 月那場斷線的錯誤回報裡，就有使用者的錯誤堆疊指向 exportify.net，證明真的有人會從同名網站進來，然後把兩個工具的狀況混在一起回報。要用的話認明 .app。

介面語言目前沒有中文。README 列了十種語言，2026 年 4 月又合併了希臘語，而正體中文的翻譯還躺在 open 狀態的 PR 裡等著被審。不影響使用，授權按鈕與匯出流程就那幾個字，看著圖示也能走完。

誰該現在備份，怎麼開始

把上面的線索收攏。適合現在就動手的：清單累積了幾十張以上、其中有花過心思整理的人，備份成本低到沒有理由拖延；想對自己的聽歌習性做資料分析的人，音檔特徵那 12 個欄位是 Spotify 不會主動給你的視野。觀望就好的人：清單只有個位數張、而且都在追蹤別人公開清單的，追蹤關係本來就不會因為你沒備份而消失。

流程本身四個動作：打開 exportify.app，按 Get Started，在 Spotify 頁面確認授權，回來按單張清單的 Export 或整包的 Export All。清單很多時，Export All 會把每張清單各存成一份 CSV 再打包成 ZIP，下載完記得把 ZIP 多留一份在雲端硬碟或外接碟。匯出檔沒有保存期限，但 Spotify 的 URI 會因為下架而失效一部分，所以「重要清單每年補一次匯出」比「一次匯出永久安心」務實。

還原演練也建議做一次。挑一張十首歌的小清單匯出，照著官方路徑把 URI 貼回桌面版重建一次，確認自己真的會走完這條路。備份的價值要到還原那一刻才兌現，這個流程親手跑過一次，那天真的需要時才不會手忙腳亂。

授權與專案狀態

watsonbox/exportify 採 MIT 授權，商業與修改重用都沒有額外條件，重散布時保留原授權聲明即可。專案建立於 2015 年 5 月，2020 年與 2024 年各有一次大改版，前者加入搜尋、歌手與音檔特徵資料、喜歡的歌曲匯出與新的限流系統，後者加入深色模式、多語介面與搜尋強化。最近一年的維護節奏穩定：2025 年 11 月完成 PKCE 授權遷移，2026 年 4 月合併希臘語翻譯，7 月斷線事件期間維護者一天內回應。專案與 Spotify 沒有任何從屬關係，README 裡作者自己也承認這名字取得有點俏皮。本文事實取自 repo 原始碼、GitHub API、Spotify 開發者官方公告與支援文件，於 2026 年 8 月 16 日查核；匯出速度與大規模帳號的實際表現不在本次驗證範圍，相關段落均標明是使用者回報或官方說法。