从“信息焦虑”到“信息中枢”：我做了一个 Go + RSS 的聚合系统 Go-RSS-Hub

每天收藏了很多优质信息源：技术博客、开源项目更新、行业资讯、个人站点。
但现实是：信息越来越多，真正被高效消费的越来越少。

所以我做了一个项目：Go-RSS-Hub。
目标很明确：把分散在各处的 RSS 信息，聚合成一个可订阅、可扩展、响应快、体验稳定的个人信息中枢。

为什么还要做 RSS？

因为 RSS 的价值其实一直没变：

  • 去中心化：不被单一平台算法绑架
  • 结构化：天然适合程序化处理、聚合和筛选
  • 低噪音：订阅你真正关心的源，而不是“推荐流”
  • 可控性强：从抓取到展示，完全可自定义

Go-RSS-Hub 想做的，不是“再造一个阅读器”，而是做一个稳定的 RSS 基础服务层；上层可以接 Web、移动端，甚至 bot 和通知系统。

项目做了什么？

当前版本核心能力包括：

  • 订阅管理：支持添加与管理 RSS 源
  • 聚合与排序：多源内容按发布时间统一聚合（降序）
  • 个人 Feed 视图：按用户维度输出个性化聚合结果
  • 缓存加速：通过 Redis 缓存减少重复拉取与解析
  • 请求级超时与并发控制：提升聚合稳定性，避免慢源拖垮整体
  • 统一 API 响应结构：便于前后端联调与问题定位
  • 安全防护：对 RSS URL 做 SSRF 风险防护（屏蔽内网/回环地址等）

技术栈与架构思路

后端主打“清晰边界 + 易维护”：

  • 语言与框架：Go + Gin
  • 架构分层：handler -> service -> repository
  • 缓存层：Redis（10 分钟全局 TTL）
  • 鉴权策略：Session 机制（保护受限接口）
  • 可观测性：结构化日志，关注 request_id、状态码、延迟等关键字段

实现中我最强调两件事：

  1. 稳定优先：每个外部 RSS 拉取都要有超时和并发边界
  2. 可演进优先：先把协议和边界打稳，再扩展过滤、推荐、通知等能力

这套系统适合谁？

如果你有这些需求，它会很合适：

  • 想搭一个自己的信息聚合服务（而不是依赖单一商业产品）
  • 需要为团队做“技术资讯中台”
  • 想把 RSS 作为数据输入，接 AI 总结、标签分类、知识库入库等流程
  • 想学习 Go 后端在真实场景下的分层、缓存、并发、超时控制实践

一些实践体会

做完这个项目后我最大的感受是：
“信息系统”的核心不是功能堆砌，而是稳定的数据流和明确的边界。

比起炫技，真正有价值的是：

  • 出错时能快速定位问题
  • 接口契约长期稳定
  • 外部依赖不稳定时系统还能“优雅退化”
  • 后续加功能不用推倒重来

体验与交流

如果你也在做 RSS / Feed 聚合、Go 后端架构优化，或“RSS + AI”工作流，欢迎交流。