这次调整处理的是一个实际维护问题：同一条订阅可能从原始 feed、镜像地址或扩展适配器进入系统，但在缓存和投递层仍应被视为同一来源。如果把请求地址直接当成订阅身份，改名、换镜像或刷新配置都可能造成重复投递或遗漏更新。
项目概览
项目仓库：RhoninSeiei/astrbot_plugin_rss_forwarder。
插件把“订阅是谁”和“从哪里抓取”拆成两个概念。稳定的来源键用于缓存、去重和调度，抓取入口则可以由普通 RSS、Atom、镜像地址或扩展适配器提供。这样一来，来源显示名、抓取端点和投递目标都可以独立调整。
流程记录
配置层保存来源键、显示名、适配器类型和目标规则。适配器只负责把外部内容整理成统一条目，包括标题、链接、时间和摘要。后续管线再把来源键、条目标识、规范链接和发布时间组合起来判断是否需要投递。
这种结构让配置修改更可控。修改显示名不会影响去重缓存，更换镜像端点不会让旧内容重新变成新内容，投递渲染也不需要关心条目来自 RSS、Atom，还是其他可选适配器。
实现心得
更清晰的边界是区分“内容如何进入系统”和“内容如何发送出去”。来源适配器返回紧凑的条目模型后即可结束职责，后续是否汇总、批量投递、翻译或降级为纯文本，交给调度与投递层处理。
测试重点放在身份变化上：面板设置被修改、来源列表刷新、调度器重启、缓存记录被重放。这些情况比单纯验证抓取成功更容易发现重复投递和遗漏更新。