用Python解析Spotify JSON数据：完整分析你的听歌历史

Spotify 的年度总结我连续看了好几年，但说实话，除了那张能发朋友圈的卡片，我几乎记不住自己过去一年到底在听什么。去年冬天我花了半小时把 Spotify 的 JSON 下载包翻出来，用 Python 从头到尾分析了一遍自己的听歌数据，这次体验比年度总结带来的冲击大得多。你会在那些 StreamingHistory 文件里看到真实但不怎么体面的事实：某首歌反复循环了四十遍，某位艺术家出现了 500 多次，某些深夜时段你连续切歌半小时。这些细节原本被埋在一个庞大的 JSON 文件里，但当你用 Python 把它解析成 DataFrame，一切都会变得非常具体。这篇文章我会带你走一遍完整流程，从向 Spotify 申请数据、清洗 JSON 文件，到算出你真正关心的指标，最后把结果画成图表。适合有一定 Python 基础但对文件处理不熟悉的读者，也适合只学过 pandas 基础、想找个真实项目练手的人。

1. 为什么值得自己下载数据，而不是只靠年度总结

很多人觉得 Spotify 年度总结已经够用了，但年度总结本质上是被加工的榜单，它只会告诉你最受欢迎的歌手、最常听的歌、总收听时长这类高光指标。它不会告诉你，你每天早上通勤时反复听的是同一张专辑但从来没把它听完，不会告诉你深夜 11 点到 1 点之间的切歌率有多高，也不会告诉你某个周末你突然从电子音乐跳到钢琴纯音乐。这些细节只有原始收听记录里才有。

自己下载数据分析还有一个直接的价值，就是你可以把数据变成自己的知识库，而不是等平台每年年底给你一个浓缩版本。数据在你手里，意味着你可以用任意维度去切。你想按小时看、按星期几看、按季节看，还是按“和谁一起听”看，都不依赖平台有没有这个功能。对学数据分析的人来说，这也是一个难得的、不算干净但非常真实的练手数据集。它包含时间字段、文本字段、数值字段，还有一些缺失值和脏数据情况，和网上那些整理好的 csv 完全不同，训练的是你面对真实数据时的判断力。

在线上的数据分析项目中，我们经常抱怨找不到感兴趣的数据集，Spotify 这个下载包却是少见的、高时效性的、跟个人兴趣高度相关的数据源。对于一个学 Python 的人来说，下载数据、读取 JSON、清洗、分组聚合、可视化这一整套流程，就是一个微小但完整的商业分析项目。它能让你反复练到 pandas 的日期处理和分组聚合，又不会像“泰坦尼克号生存预测”那样无聊。

2. 第一步不是写代码，而是去拿到那份 JSON 数据

2.1 申请导出：别以为点了按钮马上就能下载

进入 Spotify 的账户页面，找到“隐私设置”相关入口，里面通常有一个申请下载个人数据的选项。提交申请之后，平台不会立刻给你文件，一般要等几天，有时候甚至要一周。平台的界面和菜单文字在不同地区可能有变化，你找“Download your data”或者“Request data”这类关键词就行。

比较关键的一点是，申请下载时要看清楚页面上描述了数据范围。不同时候政策不一样，有人导出的包只包含一年的数据，有人能覆盖更长历史。我第一次申请时没有注意，后来打开文件夹才发现只是最近 12 个月的一部分，很多更早的记录并没有包含进去。所以你在做时间趋势分析前，最好先确认导出数据里最早的记录是哪一天，再判断自己能分析的时间范围，不然画出来的趋势图会让人误以为你只听了几个月歌。

收到邮件通知后，下载的文件一般是个 zip 压缩包，解压后会得到一个包含多个 JSON 子文件的文件夹。这个文件夹里不仅有收听历史，还有曲库、播放列表、偏好设置、账户信息等多类数据。我们要用的主要是 StreamingHistory 或 Streaming_History 相关的文件。

2.2 StreamingHistory 里每个字段的含义

用文本编辑器打开一个 StreamingHistory JSON 文件，你会看到类似这样的结构：

json复制[
  {
    "endTime": "2024-06-15 08:22",
    "artistName": "某歌手",
    "trackName": "某首歌",
    "msPlayed": 215000
  }
]

字段含义非常直白：

新版导出文件有时会包含 more 字段，例如 spotify_track_uri、episode_name、episode_uri 等，如果文件包含这类字段，说明它给每一首歌提供了 Spotify 的 URI。这个 URI 对后续对接 API 很重要，如果导出版本没有它，你后续想获取每首歌的音频特征时就会麻烦一些。

2.3 如果你的文件命名我预想的不太一样

网络上的教程大多直接写 StreamingHistory0.json，但我发现实际下载的文件命名并非完全固定。老版本的导出可能是 StreamingHistory0.json、StreamingHistory1.json，新版本可能用 Streaming_History_Audio_2024_0.json 这种按年份分组命名。我在分析时看到的情况是，一种导出格式是按日期区间拆到多个文件，另一种是把音频历史和播客历史分开。

所以建议你不要把文件名写死在代码里。最稳妥的方式是先把解压后的文件夹结构弄清楚，再决定从哪里读文件。我的做法是先拿到整个 MyData 根目录下所有 JSON 文件列表，然后只筛选出文件名中带 “Streaming” 且内容是播放历史的文件。这样无论文件是叫 StreamingHistory0 还是 Streaming_History_Audio_2024_0，都能被统一捕捉到。后续的年份、批次拆分会由文件名反映出来，但解析逻辑不用变。

3. 把零散的 JSON 加载到 DataFrame

3.1 用 pathlib 读取多个文件，而不要只盯着一个文件

当你有多个 JSON 文件时，一次性把它们全部读进内存是最直观的。多数人的 Spotify 数据量并不大，一年撑死几万条记录，单文件几十 MB 对 pandas 来说非常轻松。

python复制import json
from pathlib import Path

data_dir = Path("MyData")
music_frames = []

for f in data_dir.rglob("Streaming*.json"):
    # 有的文件夹里可能也包含非流式历史文件，为稳妥起见只读后缀为 .json 的
    if not f.suffix.lower() == ".json":
        continue

    with open(f, "r", encoding="utf-8") as fp:
        rows = json.load(fp)

    if rows and "artistName" in rows[0]:
        music_frames.append(rows)

print(f"找到 {len(music_frames)} 个历史 JSON 文件")
all_rows = [item for part in music_frames for item in part]
print(f"总计 {len(all_rows)} 条记录")

rglob 做递归搜索，不止扫描当前目录，如果 Spotify 导出包里的子目录结构比较复杂，用它可以省去先看目录树、再一层层写死路径的麻烦。筛选条件 "artistName" in rows[0] 是为了防止把收藏曲库这类文件也混进来，因为有的 JSON 结构虽然也是数组，但字段完全不同。

3.2 时间字段是解析的关键，也是第一个坑

把数据变成 DataFrame 后，直接用 pd.to_datetime 解析 endTime 是最自然的一步。不过要注意导出数据的 endTime 是一个没有时区的字符串，格式通常是 “YYYY-MM-DD HH:MM”，偶见秒数和字母时区标识。这里有两个选择：

第一种是相信我所在的时区恰好在导出时被原生本地化，用 pd.to_datetime(endTime) 直接解析。第二种是把时间统一转换成 UTC 或我自己的时区，这需要自己额外指定时区逻辑。

我建议不要无条件相信平台给的 endTime。拿到数据后，可以挑一条你知道准确时间的播放记录和实际发生时间作对比，如果偏差了几个小时，就说明平台返回的时间和你本地时间不同，需要自己补上时区偏移。

解析逻辑：

python复制import pandas as pd

df = pd.DataFrame(all_rows)
# 先保留原始列
df["ts"] = pd.to_datetime(df["endTime"], format="%Y-%m-%d %H:%M", errors="coerce")
# 如果你确定时间需要转换到 UTC 或本地时间
df["ts"] = df["ts"].dt.tz_localize("UTC").dt.tz_convert("Asia/Shanghai")

errors="coerce" 是为了防止某个文件里混入格式异常的时间值导致整列解析失败。我实际碰过一次，某条记录里时间字段出现了空格或换行，如果不加 errors 参数，整段代码会直接崩给你看。加了之后，无法解析的值会变成 NaT，需要单独检查这一列里有多少空值，再决定是删除还是依据上下文补全。

3.3 清洗标准：哪些歌需要留下，哪些应该过滤

拿到完整 DataFrame 后，要先想清楚一个问题：你的收听历史里混杂着大量“没听几秒就切掉”的记录。这些记录要不要进入分析，取决于目的。

如果你想分析“我真正喜欢的音乐”，那么只播放 3 秒、5 秒的记录基本是探索或误触，统计它们会稀释真正的权重，不值得加入榜单。如果你想分析自己的“切歌行为”或者“注意力持续时间”，那么短播放记录恰恰是最珍贵的信号，过滤掉它们反而会丢失重点。

下面的清洗流程是我常用的：

python复制# 单位换算，加一个方便的分钟列
df["play_minutes"] = df["msPlayed"] / 60000

# 把一个可能会参与后续统计的短播放标记出来
df["is_short_play"] = df["msPlayed"] < 10000

# 计算播放占比时需要知道歌曲总时长，但 StreamingHistory 不一定有
# 所以我们先做一个保守判断：小于 10 秒视为极可能跳过
df_for_ranking = df[df["msPlayed"] > 30000].copy()

这里的阈值 30 秒是我自己的经验设置，并不是绝对标准。如果你听的是 3 分钟以上的歌，30 秒代表你至少听了一段；但如果你听的是几分钟的播客或片段，30 秒可能毫无意义。你可以先把 msPlayed 分布跑出来，看整体的分位数，例如 df["msPlayed"].describe()，然后根据结果决定阈值。我通常会观察 25 分位数附近是否有显著断层，如果大部分记录低于 10 秒，那说明我有一个高频“探索型”收听习惯。

4. 指标计算：从“我都听了啥”过渡到“我什么时候听”

4.1 分钟数 vs 播放次数，两种口径带来的差异

最常见的统计结果是按播放次数计算“最常播放的歌手”：

python复制top_artists = (
    df.groupby("artistName", dropna=False)
      .agg(play_count=("msPlayed", "count"),
           total_minutes=("msPlayed", lambda x: x.sum() / 60000))
      .sort_values("total_minutes", ascending=False)
      .head(20)
)

但真实分析里你会发现“播放次数最多”和“收听时长最高”往往是两张不同的榜单。比如有一个歌手每次都被你随机播放，其中重复了半首歌就被切掉，播放次数很高，但总收听时长很低。反过来，一个你睡前循环的安静歌单，播放次数不多，但有些歌每次播放都到完整结束，累计时长可能排第一。

所以排序时我推荐优先按 total_minutes 来排，因为它贴近大众对“我最常听谁”的真实理解。如果你要观察重复播放，可以额外加一列 play_count，这样输出的表格里同时能看到“他出现频繁”和“他真正被长时间收听”的差异。简洁起见，下面的例子用了两次 groupby：

python复制# 先算播放次数
artist_count = df.groupby("artistName").size().reset_index(name="play_count")
# 再算总时长
artist_time = (
    df.groupby("artistName")["msPlayed"]
      .sum()
      .div(60000)
      .round(1)
      .reset_index(name="total_minutes")
)

artist_stats = artist_count.merge(artist_time, on="artistName")
artist_stats = artist_stats.sort_values("total_minutes", ascending=False)

4.2 从“结束时间”倒推收听时刻

这里真正值得用心的地方，是将 endTime 作为“结束时间”这件事拆解出来。因为流媒体日志记录的是某次播放结束时的时间，而不是开始时间。大多数情况下，歌曲会被完整或基本完整地听完，所以 endTime 往前推移歌曲时长才接近你开始听的那刻。但当我们想按小时分析收听行为时，直接用 endTime 的小时字段会有小偏差。

如果你的歌平均时长越来越长，或你经常在午夜前后播放长专辑，那么跨小时的偏移会被放大。比如说你在 23:58 开始听一首 6 分钟的纯音乐，真正的收听高峰位于 23:58 到 0:04，如果只用 endTime，这首歌会被整体记到 0 点这个小时里，导致 23 点的高峰被低估，0 点的高峰被夸高。

如果你只是想看个大概趋势，直接用结束时间也可以，这个偏差通常不大。但如果要做更细的时间分布，不妨增加一列 estimated_start_time：

python复制# 估算实际开始时间：假设歌曲从 msPlayed 对应的时长之前开始
df["estimated_start_ts"] = df["ts"] - pd.to_timedelta(df["msPlayed"], unit="ms")
df["listen_hour"] = df["estimated_start_ts"].dt.hour

这种情况下，对于那些“听了几秒就被切掉”的记录，估算开始时间和结束时间重叠，不会产生明显扭曲。对于那些完整听完的歌，按开始时分摊收听行为更合理。

4.3 星期几、一天内各时段的热度

有了时间列，比较自然的第二步是统计一周中每天、每天不同时段的分布。pandas 的 crosstab 做这类透视很方便：

python复制df["weekday"] = df["ts"].dt.dayofweek   # 0=周一，6=周日
df["hour"] = df["ts"].dt.hour

weekly_hour = pd.crosstab(df["weekday"], df["hour"], values=df["msPlayed"], aggfunc="sum")
weekly_hour = weekly_hour.fillna(0).div(3600000)   # 转换为小时

这样生成的行代表 7 天，列代表 24 个小时，值代表当天那个小时累计播放了多久。这个矩阵可以直接交给 seaborn 画热力图。你甚至可以按工作日和周末分组聚合，比较两种生活节奏下收听习惯差异。比如我自己的数据里，周一到周五 8 点到 9 点有一个明显的收听高峰，而周末下午 2 点到 4 点反而很平，显示我确实只有在通勤路上才集中听歌。

4.4 用分组看“一个月的你”而不是“一年份的你”

除了日维度，月份粒度也很有价值。由于 Spotify 导出的范围可能不完整，按自然年份直接看连续趋势很危险，可以用月度相对值来看：

python复制monthly = (
    df.groupby(df["ts"].dt.to_period("M"))
      .agg(play_count=("msPlayed", "count"),
           total_hours=("msPlayed", lambda x: (x.sum() / 60000) / 60))
      .reset_index()
)
monthly["month"] = monthly["ts"].astype(str)

这里我特意用 dt.to_period("M") 而不是 dt.month，是因为 to_period 能保留年份信息，避免把 2023 年 1 月和 2024 年 1 月合并在一起。如果你的数据跨了多个年份，只取 dt.month，那么两年同月的数据会被加总，长时间趋势就丢失了。

4.5 艺人重名和同一首歌的合并问题

artistName 和 trackName 都是纯文本，这意味着同一个概念会出现不同拼法。比如某些西方歌手在不同平台专辑里的 artistName 可能带大小写或特殊标点，还有的曲目里会出现 Feat. 几位其他歌手，造成同一首歌里的 feature 歌手会进入统计过程。如果你介意，可以按文本规范化后再分析，比如把字母全部转小写、去除多余空格、把括号里的内容移除。但音乐是重名极多的领域，最好保留 artistName 和 trackName 的组合列来分析，不要只看其中一个字段。

我做分析时最实际的做法是新增一列：

python复制df["artist_track"] = df["artistName"] + " - " + df["trackName"]

这样统计同一首歌是否被反复播放就不会因名字近似而被漏掉，也比单纯列 trackName 精确一些。

5. 画图：让分析结果从表格变成让人眼前一亮的图

分析做到这一步，直接打出一张 top_artists.head(20) 表格，能说明问题但不够直观，也缺少继续探索趣味。我更喜欢用图表去呈现几点信息：时间热力图、月度趋势柱状图、歌曲榜单横向条形图。

安装依赖：

bash复制pip install pandas matplotlib seaborn

我最常用的出场配置是 matplotlib + seaborn，因为 seaborn 热力图开箱即用、配色好看，而 matplotlib 提供底层控制。见下：

python复制import matplotlib.pyplot as plt
import seaborn as sns

plt.rcParams["figure.figsize"] = (12, 5)
plt.rcParams["font.sans-serif"] = ["Arial Unicode MS", "Microsoft YaHei", "SimHei"]

如果你的系统缺少中文字体，绘图中的中文会变成乱码。这里可以通过安装中文字体或在最终标签里用英文避免字体问题。由于海外平台的默认字体往往不包含汉字，我在做个人分析时会把中文字体设置为 Microsoft YaHei 或 Noto Sans CJK。如果是服务器环境，手动注册字体则会麻烦不少。

先看“一天中的哪个小时你在听歌”：

python复制hour_by_hour = (
    df.groupby(df["ts"].dt.hour)["msPlayed"]
      .sum()
      .div(60000)
)
hour_by_hour.plot(kind="bar", color="#1DB954", width=0.8)
plt.title("过去一年每个小时的累计收听时长")
plt.xlabel("小时")
plt.ylabel("分钟数")
plt.show()

结果大概率会呈现两个峰：早高峰和晚间高峰。如果看到晚上的峰值出现在凌晨，那就说明你的数据很可能受到了时区偏斜影响，回头去检查第 3 节讲的时间转换。

看一周规律时，用热力图：

python复制pivot_table = pd.crosstab(
    df["ts"].dt.dayofweek,
    df["ts"].dt.hour,
    values=df["msPlayed"],
    aggfunc="sum"
).div(3600000).fillna(0)

plt.figure(figsize=(14, 6))
sns.heatmap(
    pivot_table,
    cmap="crest",
    cbar_kws={"label": "收听时长（小时）"},
    xticklabels=range(24),
    yticklabels=["周一", "周二", "周三", "周四", "周五", "周六", "周日"],
)
plt.xlabel("小时")
plt.title("一周中每天每个小时的热度")
plt.show()

这里值的单位是小时而不是毫秒，不然热力图色条数字会很大。颜色越深的地方代表你的收听活动越密集。我通常会结合它来判断自己是不是在工作和休闲之间形成了某种固定循环：如果你周一到周五的形状非常不同、周末又完全是另一番面貌，它能让这些模式变成肉眼可见的证据。

最后看看总排行榜：

python复制top = artist_stats.head(15).sort_values("total_minutes")

plt.figure(figsize=(8, 8))
plt.barh(top["artistName"], top["total_minutes"], color="#1DB954")
plt.xlabel("总收听分钟数")
plt.title("收听时长最长的 15 位艺人")
plt.tight_layout()
plt.show()

由于每个平台的默认主题和字体差异，你在运行时多半要调一两处细节。这没什么好抱怨的，数据处理的核心环节并不在于追求一次成图成功，而是让表格和图保持一致。

6. 我实际踩过的几个坑，希望你不必重走

6.1 endTime 写成“结束时间”，我却在凌晨分析时理解反了

我第一次分析时直接把 endTime 当成歌曲开始时间，用 dt.hour 分组，得到的结果是夜晚 0 点前后突然出现一个巨大高峰。这让我很困惑，因为我极少在那个时间登录。后来查看原 JSON 中一条“我知道自己 22:50 开始听”的记录，发现它的 endTime 为 0:10 左右，才知道平台记录的是播放结束时间。

因此，你的数据如果包含大量“整首完整播放”的内容，想还原收听开始时间时，用结束时间减去 msPlayed 会准确得多。短播放差距不大，长曲目完整听完的话，误差可以到几分钟甚至十几分钟，足以影响跨小时统计你的时段分布。

6.2 “单曲循环”产生大量记录，远看像收听了很多遍不同歌

流媒体历史中，如果同一首歌连续出现在多行记录里，其实反映的是单曲循环播放行为。Spotify 在连续循环时会为每轮播放生成一条新记录。这种数据很真实，不需要清洗，但某些分组统计会受影响。比如我的数据里有一首歌连续被完整播放了 6 次，只因为那晚我睡着了没关音乐。我没有特地把重复行去掉，因为数据本来记录的就是播放行为，但分析时心里要有数，不要对这些排行赋予过度解读。如果分析师想计算“不重复音乐作品数”，这会成为一个明显需要处理的逻辑问题。

6.3 “短播放”不一定是跳歌，也可能是缓存中断

对流媒体平台来说，msPlayed 很容易受到网络状况影响。偶尔网络卡顿后记录会被截断，让本来完整的播放变成很短的一截。所以看到 15 秒的播放就断定你一定不喜欢这首歌，并不安全。更合理的做法是把短播放视为“该歌曲的吸引力不够强”或“遇到了一次不稳定的播放事件”，然后结合后续播放次数来判断。它更像是一个信号，而不是结论。

6.4 数据范围不完整导致趋势图被切断

这是最容易骗到自己的坑：导出包虽然收集了过去一年的数据，但如果导出日期距离你听歌的高峰期已经好几个月，那么最终只有截止到申请日之前的一段窗口。如果某个群组在此之前没有记录，折线图会从一个很低的起点突然上升，让人误以为你忽然开始大量听歌。建议在拿到数据后，先看一眼 df["ts"].min() 和 df["ts"].max()，并在图上把范围写成 min ~ max，不要在标题里写“过去一年”，除非二者差距确实约等于一年。

6.5 中文字体导致的绘图报警

如果你在 macOS 或 Windows 本机绘图，系统一般已有中文字体，但你仍然需要把它设进 matplotlib 配置。如果什么都不做，中文标签可能显示成方框。我通常直接设置：

python复制import matplotlib
import matplotlib.font_manager as fm

# 检查可用的中文字体
font_names = {f.name for f in fm.fontManager.ttflist}
print([name for name in font_names if "Hei" in name or "CJK" in name or "YaHei" in name])

找到可用字体后，再设置到 rcParams 里，这个方法比硬编码系统路径灵活得多。

7. 想把分析推到更高层，你需要把曲目 ID 和音频特征接进来

7.1 从 Stream 历史生成可对接 API 的曲目 ID

如前所述，有些导出文件里会有 spotify_track_uri，格式通常是 spotify:track:<id>，这个 ID 是对接 Spotify 开发者 API 的关键。没有它，就只能靠 artistName + trackName 文本匹配，这是一个不那么干净的方案，因为名字可能有多个版本或大小写差异。如果当前文件确实缺 ID，也可以从之前旧的 API 拉取结果匹配回来，但过程繁琐。

对接 Spotify API 最常用的 Python 库是 Spotipy。有了 API，你能为每个 track ID 拉取官方元数据，比如曲目时长、专辑、发行日期、流行度和音频特征（acousticness、danceability、energy 等）。这样就能从“我听了什么”升级到“我听的东西在声音上有什么共性”。

7.2 做一个“音频特征分析”：我到底在高潮时听什么

把每个 track ID 关联到音频特征后，可以轻松跑均值比较。比如分别计算早上 8 点到 10 点和晚间 22 点到 24 点的平均 danciability 或 energy。经常出现的结果是，早间音频的 energy 更高，而晚间更安静。这类分析已经接近推荐系统的思路，你开始观察自己的收听偏好在情绪、活跃度上是如何变化的。

用 Spotipy 获取音频特征的基本流程如下：

python复制import spotipy
from spotipy.oauth2 import SpotifyOAuth

scope = "user-library-read"
sp = spotipy.Spotify(auth_manager=SpotifyOAuth(scope=scope))

# 一次最多获取 100 个音轨的特征
def get_audio_features_for_ids(track_ids):
    features = []
    for i in range(0, len(track_ids), 100):
        batch = track_ids[i:i+100]
        features.extend(sp.audio_features(batch))
    return features

音频特征 API 返回的内容包括 energy、danceability、valence 等，它们本身不是玄学，而是 Spotify 对声音的算法化描述。拿你的播放历史做均值时，要注意缺失值，因为部分用户上传音频或某些本地文件并不在 Spotify 曲库中，API 可能查不到。

7.3 定期把数据沉淀下来，给自己做一个小型仓库

手工下载数据是一次性行为，但如果想长期追踪自己收听习惯的变化，就需要“定期抽取 + 存表”的习惯。你可以把相同脚本做成每月运行一次的任务，导出包下载后自动解析、清洗、存入数据库。这里我会选 SQLite 作为首选，因为单纯 CSV 很难做多表关联，而 SQLite 对个人项目足够轻量：

python复制import sqlite3

conn = sqlite3.connect("my_spotify_analysis.db")
df.to_sql("streaming_history", conn, if_exists="replace", index=False)
)

# 以后查询时可以用 SQL 做更精细的筛选
artist_monthly = pd.read_sql_query("""
    SELECT artistName,
           strftime('%Y-%m', ts) as year_month,
           SUM(msPlayed) as total_ms
    FROM streaming_history
    GROUP BY artistName, year_month
""", conn)

这个做法的好处是，你可以积累一个不断增加的数据集，观察自己从乐队 A 转移到音乐人 B 的时间点，分析哪些事件让你连续多天听了某个流派。它会变成一个完全属于你个人的收听日志，比刷新平台界面更可靠。

8. 回到数据本身：分析结束后我通常还留下什么

通过上面这一路流程，你能自己看到的不只是榜单，而是行为轨迹。你可能会发现：周三晚间的收听时间远超其他工作日晚间，或者在某个特定月份你的音乐偏好几乎完全改变。这些分析不需要特别高级的算法，Python 的基础技巧已经够用，难的是带着正确的问题去读数据。

我在处理自己的 Spotify 数据时，最大的体会不是“排行榜和我原来的预期差多少”，而是意识到数据分析项目里的时间字段远比教科书例子要脏，真实世界的时间可能没有时区声明，字段名可能前后变动，数据范围可能本身就截断。这些问题不靠某个库解决，而靠你在每一步反问“这个字段到底是什么时点的事件”来解决。

如果你打算借鉴这个项目练手，我的建议是先别急着把所有代码一次性写完，先用小样本文件跑通，再把全量数据放进去，最后把可视化做完整。这样做能让你对输出结果有掌控感，而不是在长满维度的结果表中迷失。希望这套从数据下载、字段拆解、清洗聚合到绘图和 API 扩展的思路，能让你在分析自己的 Spotify 听歌数据时少踩几个坑，也让你更了解自己到底是如何通过音乐度过那些日子的。