我原本真的只想导出一个歌单

最开始只是我自己要用#

当时我想把歌单转去 Apple Music，找了一圈国外的歌单迁移服务，发现它们基本都不认识国内的 QQ 音乐，没法直接丢个链接过去自动迁移。

我当时能想到的办法，就是先把 QQ 音乐里的歌名、歌手全部导成纯文本，再交给迁移工具去 Apple Music 里一首首匹配。需求非常简单，我就想要几百行这样的文本：

1
歌名 - 歌手
2
歌名 - 歌手

结果在网上找了一圈，居然没找到什么顺手的工具。各家音乐平台都把“收藏、建歌单”做得非常方便，但等你哪天真想换平台、想把自己的歌单带走时，就会发现处处都是麻烦。

既然找不到现成的，那就自己写一个吧。

于是我用 Python 随便写了个小脚本，把歌单数据抓下来。后来想想，反正数据都抓到了，只输出 TXT 好像有点浪费，就顺手把 Excel、CSV、JSON 也加了进去。那时候整个项目也就这么点东西：输入歌单链接或 ID，选个格式，导出，结束。

因为本来就是写给自己用的，写完我就顺便扔到 GitHub 上开源了，也没觉得真会有多少人用。

这东西怎么自己开始涨 Star 了？#

把项目放到 GitHub 以后，我有很长一段时间压根没管过它。毕竟在我眼里，这就是个连界面都没有的 Python 小脚本，用之前还得自己装 Python 和依赖，门槛真不算低。

结果过了一段时间，我偶然点进仓库一看：怎么有人开始给它点 Star 了？🤔

而且不是我发给朋友让他们帮忙点的，是真的有陌生人自己搜到了这个仓库，Star 数量在一点点往上涨。我当时还挺奇怪的，就这么个简陋脚本，居然真的有人需要？

后来想了一下也挺合理。既然我自己会遇到“想换平台但歌单带不走”的问题，那肯定不只有我一个人。看着慢慢涨起来的 Star，我就开始想，既然真的有人需要，要不干脆认真搞一下？

然后这个项目就开始一路膨胀了。

平台越加越多，用户的链接也越来越离谱#

最先想到的自然是多加几个平台。既然做歌单导出，总不能只能导 QQ 音乐。于是很快加上了网易云，接着又是酷狗、酷我、汽水音乐和咪咕，后面连“酷狗概念版”这种特殊情况也单独做了兼容，一点点扩成了现在的六大平台。

但平台多了以后我才发现，这事根本不是“多写几个接口”这么简单。

你别看用户粘进来的都叫“歌单链接”，实际上什么五花八门的东西都有 🤦‍♂️。网页版复制出来一种，手机 App 分享出来一种，微信里转发出来又是一种，微博、抖音转一圈回来还带着一大串分享文案。有长链接、有短链接、有纯 ID，有些链接还要在后台跳转好几次，甚至平台自己过段时间还会换一套分享格式。

用户当然不会管这些。他只知道：“我都把链接粘给你了，怎么不能用？”

想想也没毛病。为了处理这些输入，我只能一个平台一个平台地去测、去适配。后来网页版真正有人用以后，我还专门做了一键反馈功能：解析失败时，用户不用专门跑去 GitHub 提 Issue，直接在页面上点反馈就行。后台会把当时的输入和报错记录下来，我打开管理后台就能直接拿来复现和修 Bug。

毕竟做这个工具真正麻烦的，从来都不是标准的 https://xxx.com/playlist?id=123，而是现实世界里用户到底能复制出什么奇奇怪怪的文本。

从网页版到 CLI：总是忍不住“顺手加一下”#

平台多了之后，工具的形态也跟着改了好几轮。基本上每次都是觉得“这个功能顺手加一下吧”，结果过几天再回头看，莫名其妙又多了一堆东西。

首先是做了网页版。毕竟你总不能让一个只是想导歌单的普通用户，先去学怎么装 Python、怎么 pip install，然后再开终端跑脚本。原本我以为网页版很简单，不就是一个输入框、粘贴链接、解析下载吗？结果做着做着，自动识别平台、批量导出、酷狗登录、多语言、移动端适配全给加进去了。

后来我又觉得，网页版方便归方便，但有些人还是习惯在本地跑，或者想拿脚本批量处理。于是我干脆把原来那个 Python 脚本也彻底重构了，做成了现在的 Playlist Out CLI。

我专门给它打包了 Windows、macOS 和 Linux 的可执行版本，直接去 GitHub Releases 下载就能用，不需要再自己装 Python。平时双击打开，它就是个完整的交互式 CLI，一步步引导你粘贴链接、选导出格式；如果你本来就是开发者，想写批处理或者自动化任务，它也保留了传统的命令行参数模式：

1
PlaylistOut "歌单链接" -f xlsx,json

到这里，普通用户有网页，喜欢本地运行的人有交互式 CLI，写脚本的人也有命令行参数，我能想到的使用方式差不多都塞进去了。

统一 JSON、开放 API，以及和开源播放器抱团#

再往后，我开始觉得单纯“能导出数据”还不够，还得考虑导出来的数据怎么给别的程序用。

因为各个平台原始的字段命名全都不一样，比如同一个“歌手”，这家叫 artist，那家搞成 artists 数组。如果直接原样导出 JSON，别的软件想对接还是非常麻烦。

那干脆自己定一套统一格式算了。所以后来我专门做了一套 Canonical JSON 数据规范（顺便把 Excel、CSV、TXT、M3U8 的导出规范也一起整理了）。不管原始歌单来自哪个平台，最后都整理成同一套结构。

规范定好之后，我又顺手把解析能力做成了 Public API。如果其他开发者也在写播放器或者歌单小工具，完全不用再把六个平台的接口重新研究一遍，直接发个请求就能拿到洗好的标准数据：

1
curl "https://playlistout-api.lengxiqwq.com/api/v1/resolve?q=歌单链接"

顺着这个思路，我后面又想到：大多数人导歌单，说到底还是为了继续听。既然商业音乐平台之间互相封锁，那我们开源项目之间不如互相抱团？Playlist Out 负责把各家乱七八糟的歌单解析成标准数据，开源播放器负责把数据接进去播放。

于是我给 MusicFree 做了专门的 Playlist Out 插件，可以直接在播放器里粘歌单链接或者导入 JSON 文件。后面我又跑去给 BBPlayer 写歌单导入适配，认认真真写了好几天代码提了 PR，结果现在呢？还躺在人家的 PR 列表里，一直没合 😅。

看到这情况我也只能说：行吧。现在我对这部分已经比较随缘了，有合适的、维护还活跃的播放器，我就顺手适配几个；真让我见一个开源播放器就跑去写插件、提 PR，那 Playlist Out 自己也不用维护了。开源抱团这想法确实不错，但也不能先把自己累死。

现在已经不太敢随便想新功能了#

前阵子看了一下统计数据，折腾了这么多功能，实际用得最多的依然是 QQ 音乐、网易云和酷狗，兜ConformanceMode，最基础的需求依然是最多人用的。

我现在已经不太敢随便想新功能了，因为这项目实在太容易膨胀。每次觉得“这个功能好像挺有用”，过两秒就会反应过来：“等一下，这东西做下去不会又冒出来二十个新需求吧？” 😂

所以现在反而开始收着点了。平台差不多够用了，就先把现有的几个维护稳当，不再轻易开新坑。

说到底，Playlist Out 一开始也没准备做成什么大项目。它只是因为有一天，我想把自己的一个 QQ 音乐歌单带走，结果发现这件事比想象中麻烦得多。于是我自己写了一个脚本，然后发现原来还有不少人有同样的问题，接着事情就一路变成了现在这样。

现在再回头看 2025 年那个只有一个 Python 脚本、只支持 QQ 音乐的小仓库，我是真没想到：你小子以后事情还挺多 🫡。

如果你也刚好想把手里的歌单带出来，不妨去 网页版 试一试，或者去 GitHub 仓库 翻翻源码、提个 Issue。说不定哪天我又忍不住“顺手加了点什么”呢 😂。