从番剧墙到一个 Go CLI 工具

前段时间我把自己的网站整理了一下，做了一个“番剧墙 / 影视墙”的页面。

每个作品有封面、标题、评分、简介，看起来很清爽，也算是给自己这些年的观看记录做一个归档。

一开始我也想过，这些信息要不要手动整理。

理论上当然可以，但当数量慢慢多起来之后，问题就变得很现实：

• 封面图从哪里来？
• 简介要不要自己维护？
• 某个平台没有这部作品怎么办？

后来我了解到了 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 实践。

以后可能还会继续围绕自己的内容系统做一些小工具。

慢慢来。