关于未来展示的建议

看样子现在是全量获取单个友链的feed全部数据，那么也就会导致后续如果该插件升级能够前端展示订阅的话，岂不是如果某个站点通过采集等手段在同一时间写了成千上百的文章（迁站），前端就展示了他一个人的站点？

### 我认为可以像我一样前端展示

既展示了友链可访问性、访问速度、feed排序，无法访问无feed默认降序，点击友情链接直接展示feed，无feed则立即跳转。

### 默认按照feed更新评率展示友链，没有必要单独的在造个“朋友圈”。
默认依照网站feed更新时间排序结合是否能够访问也是排序规则。通常情况下，无法获取浏览器请求的反馈信息及相关内容则直接排序在结尾，也就是先前用户也提到既然有了友链可访问性检测、反链检测，那么前端就应该这样智能化的展示分组。这没有提供feed的就让他在一个分组、这没有反链的给它一个分组、不能访问的给它一个分组。至少我目前的老站点就是这么去做的。同样既然是根据feed更新频率来展示友链，那么每个友链自身点击打开那就必然是feed。

先前也说过，如果一个友链给了feed，全量的去抓它，一个服务器是否吃得消，第二个，抓了之后呢？缓存么？倘若这个站点比较动荡、喜欢折腾二十四小时同一篇文章可能不同URL呢？所以我们为什么要这样全量去抓取，再去缓存呢？这是提升效率了？还是如何了？
我的做法是什么？feed定时所有URL一天只抓10条，而不是二十四小时的实时更新，要么你也可以对这个“订阅”功能弄点可设置化，抓取评率，抓取个数，ua、代理什么的。不需要一股脑全部是全量抓，而且缓存，既然像我一样一天只抓十条，按照更新的时间排序的话，缓存也只需要缓存今天一天的，明天则重新抓去了。这样一来不也是代表着再更新排序。

### 友链的可访问性、反链检测更需要自定义代理性质
有的站点友链一多，而且还喜欢用json、js来展示友链，反链的检测是否能通也是个问题，这是其一；
其二，很多人设置了禁止idc IP，也有很多的防火墙规则的，也是一个问题。所以有必要明确的排查具体的原因，照我目前后台观察来看，友链可访问性是出现的大量成规模性质的514和403，其原因通俗易懂的就是防火墙拦截自定义跳转了。
那么，可访问性还客观么？其次，如原因一类似，并不是所有的人的友链页面是传统的html格式，很多json，js，例如我自己的友链[www.dao.js.cn/links](https://www.dao.js.cn/links)目前用的zblogPHP的，也是使用的js调用的友链，别人检测我反链，是必然没有的。
### 为什么不能自动分类？
有feed、无feed，可访问、无法访问，有反链、无反链？为什么需要我们自己去分类，既然插件赋予了自行feed获取、反链检测、可访问检测，后台前台不就是自动展示这种分类么？我看到现在的还需要用户自己去分类，我认为自己去分类的是网站类型分类，不是可访问，可链接的分类。而且每一个友情链接没有拖拽到其他分类的功能，如果我需要修改一个网站的属性分类，我还需要在现有的分类删掉，然后在新分类再添加。

为什么不能直截了当的就加一个分类的可编辑的地方、可拖拽的地方。

Start by reviewing the existing feed fetching, accessibility checks, backlink detection, subscription display, and link-category UI described in the issue. The payload names no files or tests, so first map those entry points and split the broad proposal into scoped acceptance criteria for fetching limits, automatic grouping, and editable or draggable categorization.

Written by the indexing model from the issue text.