这几天配置 RSS 花了我很多的精力，大作业都没心思做了，感觉可以说的地方还蛮多的，这么好的机会，还不拿来水一篇？

先直接看下最终的成果图：

还是很爽的

什么是 RSS

RSS 是一个基于 XML 的格式规范，它可以将来自各平台的信息用统一的格式表示，借助专用阅读器就可以达到一站式获取信息的效果

不知道大家有没有过这样的经历：尽管关注的博主事实上一直在活跃，平台却不会显示他们的消息。现在我们可以直接通过 RSS 订阅这个博主的动态，就不会被平台的逆天机制恶心到了

除此之外，以往获取信息需要前往不同的平台，跳转到各种页面本身就是一个很繁琐的流程，而且很容易出现遗漏。RSS 通过将信息聚合起来，可以优雅地解决这个问题

选一款 RSS 阅读器

经过一番了解，我得知阅读器大体包括本地阅读器和在线阅读器。在线阅读器的优势在于可以实时更新，本地阅读器打开后需要加载一下才行。如果某个源的更新数超过了预先设定的 rss 文章数量，还可能出现遗漏的问题，不过这种情况比较罕见。

网上能找到的在线阅读器基本上都需要付费才能享受全部功能，我最终选择的是本地阅读器，所以不会过多介绍。除此之外还有自己部署阅读器的做法，不过花钱用 VPS 部署一个阅读器感觉多少有些没必要，所以把他排除掉了。

Feedly

推荐的唯一一个在线阅读器，界面非常的美观，是我阅读器里面用下来体验最舒适的一个。它还支持自动生成 RSS，如果一些网站没有提供 RSS 订阅，这个功能可以帮你爬取并处理信息，还提供了一个可视化的界面让你手动调整，十分高效，当然这个功能是付费计划专属的。缺点就是免费计划功能阉割，且只支持 100 个订阅源和 3 个文件夹，要想用的舒服还是得付费，如果你可以承受一个月 50 上下的花销，可以选择这一个阅读器

Folo

与 RSSHub 出自同一制作组，拥有用户间互相分享的数量庞大的 RSS 源，界面也比较漂亮，通过分享自己的 RSS 源还有机会拿到赏金，属于是非常全面的一款产品

至于为什么没有选择它，主要是因为它太占内存了，一开始安装好大概有 700MB，用了没一会就接近一个 G 了，虽然它提供了很多的功能，但是跟阅读体验没有太大关系，于是我也忍痛把它卸载，选择了接下来这款更加轻量化的阅读器

Fluent Reader

我现在正在用的一款，也是在文章开始展示的阅读器，个人认为是本地阅读器 UI 巅峰，阅读体验没的说。然而缺点也比较突出，就是功能比较简陋。上面提到的消息推送、分享订阅源、自动生成 RSS 一概没有，甚至没有最小化托盘和开机自启。属于是阅读器丁真，除了颜值啥也没有。好在从爬取订阅源到阅读的这一整套流程做的还是很完善的，一句话来说就是，够用！

正如前文所言，它占用内存相对较小，大概 200MB 多一点，比其他阅读器小很多，也是我选择这款阅读器的重要原因

这些阅读器怎么都是 F 字辈的

部署 RSSHub

选好心仪的阅读器后，接下来就要去寻找 RSS 源了。一般来讲个人博客站点或者开源项目博客都会提供 RSS 订阅的服务，但是油管这样的商业平台不会直接提供，需要自己制作 RSS。这时就要用到上文提到的 RSSHub 了，开发者会将制作好的 RSS 生成代码放在这里，借助服务器路由就能够订阅各大平台的 RSS。如果没有找到想订阅的网站，也可以通过封装好的函数自己制作

官方提供了一个实例供我们使用，我们可以直接用它来订阅 RSS，然而它并不能完全满足我们的要求。因为官方的服务器位于美国，访问人数多，速度会很慢甚至不响应。还有就是无法自主配置环境变量，有些需要 token 的路由无法使用。为了更好的满足自己的需求，我决定自己部署一个 RSSHub

官方文档中给了很多平台的部署方法，我最后选择了 Zeabur。它每个月会给五美元的免费额度，如果正常使用的话，每天的费用会在 0.1 美元左右浮动，足够挺过一个月了。文档作者也很贴心，提供了一键部署的按钮，我只需要配置一下域名就行，整个过程十分愉快。

部署成功后，就可以在阅读器中用上自己的 RSS 链接了。

遇到的一些问题

油管推送内容重复

我在用 RSSHub 订阅油管频道的时候，发现相同的内容，每次刷新后返回的 RSS 发布时间不一样，导致一个信息会在阅读器中多次出现。我百思不得其解，于是去 Github 上提了 issue。根据回复，原因是我没在环境变量中配置 token，而第三方的爬取工具只能返回“xxx 小时前”格式的内容，就会出现我这样的情况

我一听感觉很有道理，给环境变量加上 token 后果然不重复了。文档中有提到这个配置项，但标的是 optional，我当时想着多一事不如少一事就没有搞。果然以后还是不能偷懒啊

Taptap 部分游戏订阅失败

既然要整理信息，那肯定少不了游戏资讯，有的 b 站官号动态除了更新情报外可能还会推送其他内容，不是我想看的东西，我还需要一个更加干净纯粹的情报站。很快我就把眼光放在了 Taptap 上面，如果有官方入驻的话，这里的信息还是比较及时的

然而我在订阅 Phigros 的官方动态时，发生了这样的报错：

TypeError: Cannot read properties of undefined (reading 'id_str')

通过格式来看，这个报错很明显是 JS 返回的。也就是说，是代码发生了问题。我于是查找了这部分处理函数的源码，大体的逻辑是，获取路由中传入的参数，然后发往 Taptap 的 API 接口，获取到 json 后，对帖子进行逐个处理，最终返回 RSS。

逻辑看上去很正常，没什么问题。我的 Milthm 订阅也是用的这个路由，没有出现问题，所以我推断可能发生了某个特殊情况，导致 json 结构不一致，引发了报错。为此我手搓 url 拿到了响应信息，然后发现果然有一个帖子不符合规范。这个帖子因为转发了其他的帖子，结构相比普通帖子产生了变化，代码中没有考虑到这个情况，导致了空指针。

既然发现了问题，改起来就容易了。我先是去提了一个 issue，探讨接下来的解决方案。然后我从凌晨一点开始写代码，到了四点完成编写并通过测试，提交 PR，很快啊就被合并了，歪果仁大半夜回复效率就是高。这是我第一次参与开源，躺在床上兴奋的睡不着，很难忘的回忆。

修改后的代码其实还是有缺陷的。因为缺乏实例，没有涵盖到转发视频的情况，届时可能不会显示视频，甚至还是会报错，那时就需要进一步修改了

b 站订阅视频的风控问题

其实订阅 b 站视频的步骤非常简单，只要在环境变量中添加 token，然后在阅读器中订阅相应的路由就可以了。然而问题就出在更新 token 这个步骤上，b 站的 token 更新频率很频繁，更新之后原来的 token 就失效了，无法用来获取信息，如果一两天手动更换一次 token 的话会很麻烦。于是我找到了这个 issue，有人提到用无痕模式拿到 token 之后能保持较长时间的有效期，我在别的地方还看到借助 CookieCloud 编写脚本实时更新的，但是我嫌太麻烦懒得搞了，就订阅了一个视频源不想大动干戈，所以最后还是选择手动更新

虽然有一点小小的缺憾，综合来看使用体验已经非常令我满意了

尾声

把这些能想到的东西都安顿好后，我也算是从火星搬回地球了，终于不会再错过游戏更新的信息。找资料的过程也额外发现了不少优质的博客，顺手都添加了订阅。不得不感慨这些技术真的大大方便了人们的生活，希望以后能多多学习吧