事情经过：
有个喜欢的歌手的网站没有 rss ，rsshub 也没有相应的源，于是看了下 rsshub 的开发文档开始写源，想着写好了我也能提个 pr
结果写到后来直接把我写得绷不住了，最大的问题：rsshub 作为专门将网页解析成 rss 的项目，实际上本质就是个大型的爬虫。而作为一个爬虫，请求各种网站的时候你肯定需要有一点反爬对策的。比如我期待就是 RSSHub 会提供一些网络请求的接口如 .get() .post() 来给我们调用，底层一些简单的杂活累活就由 RSSHub 来负责，我只需要提供相应请求信息之类的，然后对结果进行解析 or 处理更复杂的页面逻辑 or 反爬逻辑
结果在请求网页的时候，RSSHub 几乎没有提供任何工具。它让开发者直接用 ofetch 这个包跳过 RSSHub 直接去请求网页。网络请求的所有细节和繁杂工作全都要每个源作者自己去处理。
最让我难受非 cookie 莫属。所有涉及到 cookie 的操作全都需要第三方源作者自己来处理。而很多网站反爬又很依赖 cookie 。ofetch 作为一个网络请求包并不具备任何 cookie 相关功能，一切都要你手动处理。你需要提取出返回头里的 Set-Cookie 信息，然后解析出来，然后手动放到下一次请求头里，下次如果返回值 Set-Cookie 你又要手动更新处理等等。关键是 js 里 cookie 解析，CookieJar 之类包又极其难用。体验极其坐牢
你也许会说，处理这么麻烦你不会写点 helper 函数？是的，其他源作者也是这么想的，所以导致现在 RSSHub 项目数不清的源里，非常多作者都各自独立造了 cookie 轮子或者单独用自己的方式在用 cookie
除此之外网络请求没有比较统一的资源池，要爬取一个列表中所有文章信息，官方文档直接让你 Promise.all([get(), get(), get()]) 暴力请求，也没有任何针对网站请求速率进行控制的相关工具。所有东西全要自己实现。我越是写到后来越觉得奇怪，我感觉 RSSHub 怎么看着就是个非常简陋的前端展示框架啊。整个系统中最麻烦复杂的网络请求部分全都一股脑地扔给了源开发者，RSSHub 本身地工作实际上就是调用源然后渲染成 rss 这么简单
那么这就有个问题了，RSSHub 写源花费的这功夫和我直接新建个项目起个简单服务器然后直接调用 http clinet 然后整形成 rss 好像没区别啊？那我干嘛不去选其他在网络请求方面更适合人类的语言和工具
