前段时间我把自己的网站整理了一下，做了一个“番剧墙 / 影视墙”的页面。
每个作品有封面、标题、评分、简介，看起来很清爽，也算是给自己这些年的观看记录做一个归档。
一开始我也想过，这些信息要不要手动整理。
理论上当然可以，但当数量慢慢多起来之后，问题就变得很现实：
- 封面图从哪里来？
- 简介要不要自己维护？
- 某个平台没有这部作品怎么办？
后来我了解到了 TMDB。
它是一个由全球社区共同维护的影视数据库，电影和剧集信息都很完整，也有免费的开放 API。如果是动态网站，直接在前端或服务端请求接口就能拿到数据，非常方便。
但我的博客是静态博客。
这意味着每一次构建都不太适合去实时请求外部 API，也不太希望页面强依赖外部接口的可用性。
另外还有网络、图片外链、访问速度等问题。
并且这些数据并非是变动频繁的数据，更多情况下数据只要产生了就完全不会变更了。
所以我换了个思路。
既然 TMDB 本身支持创建片单，那我是不是只需要维护一个“片单”，然后把片单数据一次性抓下来，转成我自己的静态数据？
于是就有了这个项目：
GitHub：tmdb-list-exporter ↗
这个工具做了什么#
它是一个用 Go 写的命令行工具。
输入一个 TMDB 片单名称，它会自动抓取这个片单中的全部影视信息，包括：
- 标题
- 评分
- 简介
- 封面路径
- 背景图路径
- 类型
- 上映时间等
然后导出为本地 JSON 文件。
图片可以选择直接使用 TMDB 原图链接，也可以下载到本地，或者上传到自己的 OSS。
对我来说，它的作用其实很简单：
我只需要维护 TMDB 上的片单，其余的数据处理交给工具完成。
这样我的网站构建阶段只读取本地 JSON 文件，不再依赖外部 API。
如果以后需要迁移主题或者改展示方式，也只需要重新生成一次数据。
为什么会想自己写#
这其实不是一个复杂项目。
但它刚好卡在一个比较微妙的位置：
- 手动整理太麻烦
- 直接在线请求又不适合静态博客
- 已有工具要么偏重服务端，要么不太符合我的使用习惯
于是就干脆自己写一个。
这个项目的结构也比较简单，大概拆成几个模块：
- tmdb：负责接口请求
- image：处理图片下载
- storage：本地或 OSS 存储
- exporter：生成 JSON 文件
本质上它只是做了一次“数据搬运和整理”。
不过 CLI 项目本身对结构设计要求其实挺高的。
比如参数解析、错误处理、批量请求、不同平台打包，这些东西虽然不复杂，但做完整还是需要一点耐心。
我也顺便把它做成了多平台可执行文件，方便在不同环境下直接使用。
它解决的其实不是技术问题#
做完之后再回头看，我觉得它真正带来的变化不是“我可以抓取 TMDB 数据”——
而是我不需要再手动维护一堆展示数据。
我只维护一个片单。
内容管理变成了“增删作品”这件事情本身，而不是围绕展示结构去改 JSON。
对于一个静态博客来说，这种拆分其实挺舒服的。
网站只是负责展示，数据生成是另外一个步骤。
关于我的番剧墙#
这个工具目前主要服务于我自己的网站：查看我的番剧墙 ↗
我一直挺喜欢那种把观看记录长期整理下来的感觉。
像是一条时间轴，在不经意的时间打开一看就会感觉到一种类似于「自己居然已经经历过这么多了」的时间的流逝感。
对我来说，那更像是一份个人记录，而不是推荐列表。
这个小工具只是让这件事变得轻松了一点。
写在最后#
项目本身不大，但它刚好是从一个真实的小需求出发，慢慢成型的。
如果你也在做类似的影视墙、番剧墙，或者希望把 TMDB 的片单数据转成自己的静态资产，也许可以用得上。
对我来说，它更多是一次对自己网站体系的补充，也是一次挺完整的 Go CLI 实践。
以后可能还会继续围绕自己的内容系统做一些小工具。
慢慢来。