拓冰网站定制 
简介面向具备基础 JavaScript 技能的开发者这份开源项目源码包展示了如何基于 Cloudflare Workers 构建轻量级 RSS 订阅与通知服务。它整合网页端与 Telegram Bot 作为订阅入口通知渠道覆盖 Telegram、Bark 与微信并利用 Workers 的 serverless 能力实现免费部署与分钟级监测。压缩包大小约 10.53MB文件总数及类型明细暂无数据实际内容应包含 Worker 前后端代码、机器人配置与部署说明。通过阅读源码可掌握 KV 存储绑定、Bot API 接入和消息推送的完整链路并在此基础上扩展自定义订阅与通知方式。目前已有 150 人学习下载适合想自建信息聚合渠道或学习无服务器开发的中级前端开发者。实践时可按官方说明在 Workers 中创建并绑定 KV快速搭建一套即时、可定制的 RSS 通知方案。 做RSS这个方向也有好几年了经历过Google Reader时代的辉煌也见证了后来各种在线阅读器起起落落。到我自己折腾自托管方案时最大的感受是RSS本身不难难的是入口和出口。入口是你想在任何设备上看到同一个订阅列表出口是内容更新后能第一时间推到你手上。inkrss这个项目就是专门解决这两个问题的——它从任何地方订阅RSS提要也从任何地方接收通知。简单说它把分散在各处的订阅源聚到一处再把更新事件以通知形式发到你能收到的地方。这篇文章我结合自己的部署和使用经验把inkrss的设计思路、部署步骤、通知接入、常用RSS源筛选一起讲透适合正在折腾RSS工作流、想搭建个人信息管道的朋友参考。1. 项目思路拆解inkrss到底解决什么问题1.1 RSS订阅的现状与痛点先说痛点。很多刚接触RSS的人以为只要找到一个订阅源扔进阅读器里就完事了。实际用上一个月你就会遇到几个绕不开的问题。第一个问题是订阅源太分散。电脑上用的阅读器、手机上用的阅读器各管各的两边收藏夹对不上。你在地铁上用手机看到一篇好文章标记了收藏回到办公室用电脑一打开发现收藏列表还是前天的状态。这种割裂感会直接让你放弃继续用RSS。第二个问题是通知不及时。传统阅读器强调的是每天打开看一遍但有些订阅源比如版本更新公告、安全通告、心仪博主的突然更新你希望第一时间就知道。这时候你不可能每个小时打开阅读器刷新一遍。我最早是给订阅源设了极短的抓取间隔让Python脚本跑循环结果自己电脑的CPU和风扇先抗议了。其实更好的方案是有一个独立的中央服务来抓取再主动推送。第三个问题是信息筛选成本高。订阅了上百个源之后高价值内容和噪音混在一起每天光扫标题就花掉大半个小时。你需要的是把订阅、过滤、通知这三个环节串起来而不是靠人肉盯着。inkrss这类项目本质上就是把抓取-去重-过滤-通知这条链路封装好你只负责往里添加订阅源剩下的事情由它来做。这个定位很明确它不是又一个RSS阅读器而是你整个RSS工作流里的中枢。1.2 inkrss的核心设计逻辑理解了痛点再看inkrss的设计就很清晰了。它的核心逻辑可以拆成三块统一订阅入口。所有RSS链接都集中在一个后台管理支持分组和OPML导入导出。你只需要维护这一个地方的数据导出OPML后也能迁移到其他阅读器不会被困在某一个工具里。事件化更新检测。服务按设定的时间间隔去抓取订阅源对比上次快照识别新增内容。它做的是增量更新而不是每次刷新把整个feed重新读一遍这样对订阅源服务端的压力更小也更容易发现真正的新内容。多端通知出口。检测到新内容后inkrss不把你困在它的网页界面里而是把事件转发到各种通知渠道。这样你可以选择在哪里接收通知——手机推送、邮件、群机器人、自建的tiny-notify服务都行。对比一下同类方案就更能理解它的取舍。FreshRSS和Miniflux是更重的阅读器自带界面、标记已读、星标、多用户管理适合想在网页里完整消费内容的人。而inkrss的强项是轻和自动化它不关心你怎么读文章只关心怎么高效地把更新消息送到你手上。如果你已经有一个主力阅读器或者绝大多数内容都通过RSSHub这类源中转那么inkrss这种方式反而更省心。如果你的需求是想要一个带界面、能直接在网页里看全文的阅读器那应该去选FreshRSS如果你的需求是订阅源统一管起来更新自动推到我的手机、群聊和邮箱那inkrss就更对路。2. 环境准备与部署实操2.1 部署前需要准备什么inkrss是自托管服务所以你需要一台能长期运行的机器。我实际用过两类的环境一类是云主机1核1G内存的最低配就够了优点是公网访问方便在外也能打开管理后台另一类是家里的NAS或者老Mini主机通过Docker跑优点是数据在自己手里缺点是出门在外要搞定内网穿透或者公网映射这一块反而比配RSS麻烦得多所以我个人更推荐先拿云主机跑熟。基础依赖只有两个Docker和Docker Compose。如果你之前跑过其他容器化服务那基本就是照抄现有流程。没有Docker的话参考官方文档在Ubuntu上用apt装一下docker-ce和docker-compose-plugin即可这一步在任何Linux发行版上都是成熟的流程。另外提前准备好通知渠道所需的密钥比如Bark的推送地址、Server酱的SendKey、企业微信机器人的Webhook等。这些token后面配置时会用到建议先集中记在一个地方避免部署完还要翻聊天记录去找。2.2 快速部署inkrss部署inkrss我推荐直接用Docker Compose。下面是我一套在真实环境跑过的配置端口、数据目录和时区都可以按自己的情况调整version: 3 services: inkrss: image: inkrss/inkrss:latest container_name: inkrss restart: unless-stopped ports: - 8080:8080 volumes: - ./data:/app/data environment: - TZAsia/Shanghai - INKRSS_PORT8080 - INKRSS_DATA_DIR/app/data把内容保存为docker-compose.yml然后在同目录下执行docker compose up -d首次启动约半分钟到一分钟镜像拉取速度取决于网络情况。启动完成后访问http://服务器IP:8080按界面提示创建管理员账号和密码。数据存储默认在./data目录下之后要备份、迁移把这个目录整个打包带走就行。注意如果服务器上有防火墙或者安全组记得放行8080端口的入站规则否则网页和接口都会访问不到。这一步是新手最容易漏的。2.3 配置数据源与订阅管理登录后台之后第一件事是添加订阅源。界面里会有添加订阅入口把RSS URL填进去设置分组和抓取间隔保存即可。抓取间隔我建议普通博客设60分钟更新频繁的资讯站设15分钟不要在短时间内把所有源都设成1分钟一是给源站服务器留点余地二是避免自己服务被对方封IP。不同分组适合设定不同的通知策略。我的习惯是分三个组技术博客抓取间隔60分钟、版本更新与安全公告间隔15分钟、行业资讯间隔30分钟。这样调度更稳通知噪音也小。OPML导入导出是我很看重的功能。你从其他阅读器迁移过来时先导出OPML再在inkrss里导入几十个订阅源几十秒就迁移完成。反过来也一样万一服务要整体搬家导出OPML就是一条后路。强烈建议每次新增订阅源后顺手导出一份OPML备份。我平时是放在Nginx的静态目录里或者同步到对象存储以备不时之需。3. 通知链路与渠道接入3.1 通知渠道选择从自建到第三方inkrss最核心的价值在于通知。它本身不做消息展示而是把有新文章这个事件转发给外部渠道。我用过的渠道大概分两类。第三方服务类Bark、Server酱、PushPlus。Bark只支持iOS原理就是向一个URL发请求苹果推送服务把消息弹到手机上配置最简单Server酱和PushPlus基于微信服务号扫码绑定后通过Webhook推送。这三家都有免费额度个人用完全足够。自建类ntfy和Gotify。ntfy是开源的推送服务官方有公共服务器也能自己部署支持Android和iOS客户端Gotify则是纯自托管适合数据完全在自己手里的场景。如果你的环境里已经跑着Ntfy加到inkrss里只需要填一个Webhook URL。企业微信或钉钉群机器人也算一种比较稳的渠道消息直接推到工作群适合把订阅更新这个事件变成团队协作信号。关于渠道选择我的建议是首先保证能收到其次才是好看。把通知接入到常用的、长时间在线的地方比接入到一个功能更酷但是你不会常打开的地方价值高得多。3.2 推送规则配置通道只是出口规则才是真正控制通知质量的地方。inrkss的推送规则一般围绕三个维度设计关键词过滤。只关心某个话题时配置包含词和排除词例如只推标题里包含Docker或Kubernetes的内容。这个功能用在技术资讯源上效果极好一条综合资讯源能被拆成几十条精确指向。正则匹配。更进阶一点可以写正则匹配整个标题甚至正文摘要。比如匹配版本号格式v\d\.\d命中就推通知。正则表达式一定要先在本地测试通过再填入避免误伤正常内容。静默时段。23点到早上8点之间大概率不想被推送打断。设置静默时段后这段时间检测到的新内容会攒着等到静默结束再发或者干脆不推送——你可以自己选择。我觉得整个通知链路里频率控制最容易被忽略。如果订阅的源恰好集中更新了一批文章一个小时内来20条通知再好的渠道也变成了骚扰。我习惯在inrkss里开启聚合通知把一段时间内多条更新合并成一条消息这样既不会漏也不会被轰炸。3.3 渠道可靠性对比不同渠道在可靠性、延迟、费用上差别不小这里做个小对比渠道优点缺点适用场景Bark延迟低、配置极简仅iOS可用依赖App苹果手机用户主力通知Server酱 / PushPlus微信内直达免费额度有限偶尔排队微信深度用户企业微信/钉钉机器人稳定、可多人协作需要在对应客户端查看团队信号或群消息聚合ntfy开源、可自托管公共服务器有未知风险全平台通知推荐自建Gotify完全自托管需要自己维护服务隐私敏感场景邮件通用、可追溯延迟偏高容易进垃圾箱不重要的摘要通知实际使用中我主力用Bark收即时类消息用企业微信机器人收汇总类消息邮件做兜底。多通道同时配置的优势是某个通道偶尔故障时至少还有另一个通道能顶上。inrkss本身支持一个事件发多个渠道不影响成本但要注意不同渠道的推送频率限制不要低估了更新密集时段的并发量。4. 常用RSS源整理与筛选技巧4.1 如何找热门RSS地址很多人会直接搜热门rss地址rss网址但搜索引擎给的结果往往过时真正高效的找源方式其实是下面这几招。第一招直接猜路径。很多网站都默认提供RSS订阅常见路径是/feed、/rss、/atom.xml、/rss.xml。比如某个博客的域名是example.com那么https://example.com/feed有很高概率就是它的RSS地址。我拿这个办法命中过不少没有在页面上放RSS图标的站点。第二招看网页源代码。打开网页后按CtrlU查看源代码搜索rss或者atom通常能找到link relalternate typeapplication/rssxml href...这样的标签href里的地址就是订阅源。第三招用RSSHub这类生成服务。RSSHub的目的就是为没有RSS的网站生成RSS。B站、知乎、豆瓣、即刻等平台的内容很多都可以通过RSSHub路由生成订阅源。你可以自己部署RSSHub也可以使用公共服务路径一般是域名/路由名/参数路由参数按照文档填写即可。4.2 常见平台的RSS源规律B站、知乎、博客等结合大家搜得比较多的问题这里给几个通用示例。B站。B站用户动态的RSS可以通过RSSHub的bilibili/user/dynamic/{uid}路由生成投稿则用bilibili/user/video/{uid}。uid在个人空间页面的URL里能看到那一串纯数字就是。举个例子某个up主的uid是123456789那么他的投稿订阅源大致形式是https://rsshub.app/bilibili/user/video/123456789。这样设置抓取间隔15分钟基本能及时收到更新通知。知乎。知乎用户回答可以通过RSSHub的zhihu/people/answers/{用户ID}路由生成。用户ID不是昵称而是个人主页URL里的那串英文数字组合。知乎专栏也有对应路由按文档配置就行。公众号。微信公众号本身没有标准RSS源常用的做法是自部署wechat2rss这类工具通过定时抓取生成feed再把它作为一个普通订阅源添加到inkrss里。这个链路虽然长了一截但一旦打通公众号更新就不是什么黑盒了。独立博客。很多独立博客基于Hexo或Hugo搭建这类静态博客生成器一般默认输出/atom.xml或/rss.xml直接拼路径即可。另外GitHub仓库的Releases可以通过/releases.atom订阅非常适合追踪开源项目版本更新。4.3 筛选信息源的判定标准订阅源数量不是越多越好我自己从200多个源砍到60多个反而更舒服。筛选源我基本按四个标准来内容密度与更新频率。日更的源和月更的源要区别对待更新频率低的源抓取间隔可以拉长避免无意义的请求。信息是否可替代。如果某个源的内容三天后在别的平台也看得到那就没必要订阅。反之独立博客、深度长文这类不可替代的源要重点保留。是否原创。洗稿、搬运号订阅源信息噪音远大于价值遇到就取消关注。源服务器稳定性。有些源隔三岔五超时或返回500这种源再优质也容易变成通知黑洞建议用inrkss日志观察一段时间不稳定就换镜像源或者干脆弃掉。我更推荐的思路是先想清楚自己需要哪几类信息技术动态、行业新闻、竞品更新、娱乐消遣每一类只保留最好的3到5个源跑通一整条订阅通知链路之后再逐步扩充。5. 常见问题与排查技巧5.1 订阅不更新的排查最常遇到的问题就是明明订阅了却一直没有新内容推送。排查思路按顺序来确认源地址能正常访问。把RSS URL直接在浏览器里打开看返回的是标准XML还是错误页。如果浏览器里都打不开那inrkss更拿不到。确认抓取间隔没有设得太长。如果你把间隔设成24小时那等一天没更新也算正常。这里有个小技巧刚添加订阅源的时候可以临时把间隔改成5分钟确认能抓到内容后再调回正常值。查看inrkss的抓取日志。日志里通常会记录每次抓取的状态码、耗时和解析结果。如果看到的是60x或者解析错误多半是源站主动防爬或者格式不标准需要给客户端设置合理的User-Agent和请求头。检查时间同步。服务器时区和时间不准会导致上次更新判断错乱该触发的不触发。部署时设置了TZAsia/Shanghai的情况一般没问题但如果你把容器跑在海外主机上还是要确认一下系统时间和本地时间是否一致。5.2 通知丢失与重复通知丢失通常出在渠道这一环。Bark或Server酱这类第三方服务偶尔会做频率限制短时间大量请求会被拒。解决方法是开启inrkss的聚合通知同时给对应渠道设置合理的最大推送频率。通知重复则多半是源站自身的问题有些源会在同一个条目上反复修改标题导致被当成新内容处理。inrkss通常会依赖条目的guid或link去重如果源站没有提供稳定的guid可以考虑在规则里启用标题链接联合去重。遇到顽固的重复直接给这个源单独配置一个较长的去重窗口即可。提醒如果有多个渠道同时接收同一事件消息可能会给人带来推送了两次的感觉。建议在inrkss里按渠道配置不同规则手机端收即时通知邮箱收每日摘要避免同一条内容重复轰炸。5.3 服务稳定性调优自托管服务跑久了稳定性和运维还是绕不开。先说容器本身。restart: unless-stopped必须开这样机器重启后容器能自动拉起。如果有条件给inrkss配置一个健康检查比如每30秒请求一次它的/health接口失败两次以上就自动重启容器这个可以用Docker自身的HEALTHCHECK实现。数据备份我用定时任务每天把./data目录压缩并同步到对象存储。RSS订阅数据本身不大几十MB顶天了但丢了要重建就很麻烦。更重要的一步是导出OPML清单放在数据目录之外防止整个目录损坏时连恢复清单都没有。日志轮转也要关注。inrkss的日志如果全量保留长时间运行下来磁盘会慢慢被占满。可以在宿主机Docker配置里加上log rotation把单个日志文件限制在10MB保留3份历史即可。一点个人经验这套服务我前后跑了大半年最大的体会是工具只是起点信息流的设计才是核心。刚开始我恨不得把所有感兴趣的源都塞进去结果一天几十条通知反而产生了新的焦虑。后来我狠心砍掉超过一半的订阅源并把通知规则调成宁可少推、不要推烦整个订阅-通知链路才真正稳定下来成了我日常获取信息最顺手的一条管道。如果你想上手我的建议很简单先用三个源跑通部署和通知比如自己的博客、一个技术资讯站、一个B站关注的up主。跑通之后再逐个加上其他源边用边调通知规则。这个过程不复杂但能让你真正理解这套RSS工作流该怎么服务于自己而不是被收藏夹和未读数字绑架。本文还有配套的精品资源点击获取 自托管RSS服务inkrss：统一订阅入口与多端通知的完整指南
简介面向具备基础 JavaScript 技能的开发者这份开源项目源码包展示了如何基于 Cloudflare Workers 构建轻量级 RSS 订阅与通知服务。它整合网页端与 Telegram Bot 作为订阅入口通知渠道覆盖 Telegram、Bark 与微信并利用 Workers 的 serverless 能力实现免费部署与分钟级监测。压缩包大小约 10.53MB文件总数及类型明细暂无数据实际内容应包含 Worker 前后端代码、机器人配置与部署说明。通过阅读源码可掌握 KV 存储绑定、Bot API 接入和消息推送的完整链路并在此基础上扩展自定义订阅与通知方式。目前已有 150 人学习下载适合想自建信息聚合渠道或学习无服务器开发的中级前端开发者。实践时可按官方说明在 Workers 中创建并绑定 KV快速搭建一套即时、可定制的 RSS 通知方案。 做RSS这个方向也有好几年了经历过Google Reader时代的辉煌也见证了后来各种在线阅读器起起落落。到我自己折腾自托管方案时最大的感受是RSS本身不难难的是入口和出口。入口是你想在任何设备上看到同一个订阅列表出口是内容更新后能第一时间推到你手上。inkrss这个项目就是专门解决这两个问题的——它从任何地方订阅RSS提要也从任何地方接收通知。简单说它把分散在各处的订阅源聚到一处再把更新事件以通知形式发到你能收到的地方。这篇文章我结合自己的部署和使用经验把inkrss的设计思路、部署步骤、通知接入、常用RSS源筛选一起讲透适合正在折腾RSS工作流、想搭建个人信息管道的朋友参考。1. 项目思路拆解inkrss到底解决什么问题1.1 RSS订阅的现状与痛点先说痛点。很多刚接触RSS的人以为只要找到一个订阅源扔进阅读器里就完事了。实际用上一个月你就会遇到几个绕不开的问题。第一个问题是订阅源太分散。电脑上用的阅读器、手机上用的阅读器各管各的两边收藏夹对不上。你在地铁上用手机看到一篇好文章标记了收藏回到办公室用电脑一打开发现收藏列表还是前天的状态。这种割裂感会直接让你放弃继续用RSS。第二个问题是通知不及时。传统阅读器强调的是每天打开看一遍但有些订阅源比如版本更新公告、安全通告、心仪博主的突然更新你希望第一时间就知道。这时候你不可能每个小时打开阅读器刷新一遍。我最早是给订阅源设了极短的抓取间隔让Python脚本跑循环结果自己电脑的CPU和风扇先抗议了。其实更好的方案是有一个独立的中央服务来抓取再主动推送。第三个问题是信息筛选成本高。订阅了上百个源之后高价值内容和噪音混在一起每天光扫标题就花掉大半个小时。你需要的是把订阅、过滤、通知这三个环节串起来而不是靠人肉盯着。inkrss这类项目本质上就是把抓取-去重-过滤-通知这条链路封装好你只负责往里添加订阅源剩下的事情由它来做。这个定位很明确它不是又一个RSS阅读器而是你整个RSS工作流里的中枢。1.2 inkrss的核心设计逻辑理解了痛点再看inkrss的设计就很清晰了。它的核心逻辑可以拆成三块统一订阅入口。所有RSS链接都集中在一个后台管理支持分组和OPML导入导出。你只需要维护这一个地方的数据导出OPML后也能迁移到其他阅读器不会被困在某一个工具里。事件化更新检测。服务按设定的时间间隔去抓取订阅源对比上次快照识别新增内容。它做的是增量更新而不是每次刷新把整个feed重新读一遍这样对订阅源服务端的压力更小也更容易发现真正的新内容。多端通知出口。检测到新内容后inkrss不把你困在它的网页界面里而是把事件转发到各种通知渠道。这样你可以选择在哪里接收通知——手机推送、邮件、群机器人、自建的tiny-notify服务都行。对比一下同类方案就更能理解它的取舍。FreshRSS和Miniflux是更重的阅读器自带界面、标记已读、星标、多用户管理适合想在网页里完整消费内容的人。而inkrss的强项是轻和自动化它不关心你怎么读文章只关心怎么高效地把更新消息送到你手上。如果你已经有一个主力阅读器或者绝大多数内容都通过RSSHub这类源中转那么inkrss这种方式反而更省心。如果你的需求是想要一个带界面、能直接在网页里看全文的阅读器那应该去选FreshRSS如果你的需求是订阅源统一管起来更新自动推到我的手机、群聊和邮箱那inkrss就更对路。2. 环境准备与部署实操2.1 部署前需要准备什么inkrss是自托管服务所以你需要一台能长期运行的机器。我实际用过两类的环境一类是云主机1核1G内存的最低配就够了优点是公网访问方便在外也能打开管理后台另一类是家里的NAS或者老Mini主机通过Docker跑优点是数据在自己手里缺点是出门在外要搞定内网穿透或者公网映射这一块反而比配RSS麻烦得多所以我个人更推荐先拿云主机跑熟。基础依赖只有两个Docker和Docker Compose。如果你之前跑过其他容器化服务那基本就是照抄现有流程。没有Docker的话参考官方文档在Ubuntu上用apt装一下docker-ce和docker-compose-plugin即可这一步在任何Linux发行版上都是成熟的流程。另外提前准备好通知渠道所需的密钥比如Bark的推送地址、Server酱的SendKey、企业微信机器人的Webhook等。这些token后面配置时会用到建议先集中记在一个地方避免部署完还要翻聊天记录去找。2.2 快速部署inkrss部署inkrss我推荐直接用Docker Compose。下面是我一套在真实环境跑过的配置端口、数据目录和时区都可以按自己的情况调整version: 3 services: inkrss: image: inkrss/inkrss:latest container_name: inkrss restart: unless-stopped ports: - 8080:8080 volumes: - ./data:/app/data environment: - TZAsia/Shanghai - INKRSS_PORT8080 - INKRSS_DATA_DIR/app/data把内容保存为docker-compose.yml然后在同目录下执行docker compose up -d首次启动约半分钟到一分钟镜像拉取速度取决于网络情况。启动完成后访问http://服务器IP:8080按界面提示创建管理员账号和密码。数据存储默认在./data目录下之后要备份、迁移把这个目录整个打包带走就行。注意如果服务器上有防火墙或者安全组记得放行8080端口的入站规则否则网页和接口都会访问不到。这一步是新手最容易漏的。2.3 配置数据源与订阅管理登录后台之后第一件事是添加订阅源。界面里会有添加订阅入口把RSS URL填进去设置分组和抓取间隔保存即可。抓取间隔我建议普通博客设60分钟更新频繁的资讯站设15分钟不要在短时间内把所有源都设成1分钟一是给源站服务器留点余地二是避免自己服务被对方封IP。不同分组适合设定不同的通知策略。我的习惯是分三个组技术博客抓取间隔60分钟、版本更新与安全公告间隔15分钟、行业资讯间隔30分钟。这样调度更稳通知噪音也小。OPML导入导出是我很看重的功能。你从其他阅读器迁移过来时先导出OPML再在inkrss里导入几十个订阅源几十秒就迁移完成。反过来也一样万一服务要整体搬家导出OPML就是一条后路。强烈建议每次新增订阅源后顺手导出一份OPML备份。我平时是放在Nginx的静态目录里或者同步到对象存储以备不时之需。3. 通知链路与渠道接入3.1 通知渠道选择从自建到第三方inkrss最核心的价值在于通知。它本身不做消息展示而是把有新文章这个事件转发给外部渠道。我用过的渠道大概分两类。第三方服务类Bark、Server酱、PushPlus。Bark只支持iOS原理就是向一个URL发请求苹果推送服务把消息弹到手机上配置最简单Server酱和PushPlus基于微信服务号扫码绑定后通过Webhook推送。这三家都有免费额度个人用完全足够。自建类ntfy和Gotify。ntfy是开源的推送服务官方有公共服务器也能自己部署支持Android和iOS客户端Gotify则是纯自托管适合数据完全在自己手里的场景。如果你的环境里已经跑着Ntfy加到inkrss里只需要填一个Webhook URL。企业微信或钉钉群机器人也算一种比较稳的渠道消息直接推到工作群适合把订阅更新这个事件变成团队协作信号。关于渠道选择我的建议是首先保证能收到其次才是好看。把通知接入到常用的、长时间在线的地方比接入到一个功能更酷但是你不会常打开的地方价值高得多。3.2 推送规则配置通道只是出口规则才是真正控制通知质量的地方。inrkss的推送规则一般围绕三个维度设计关键词过滤。只关心某个话题时配置包含词和排除词例如只推标题里包含Docker或Kubernetes的内容。这个功能用在技术资讯源上效果极好一条综合资讯源能被拆成几十条精确指向。正则匹配。更进阶一点可以写正则匹配整个标题甚至正文摘要。比如匹配版本号格式v\d\.\d命中就推通知。正则表达式一定要先在本地测试通过再填入避免误伤正常内容。静默时段。23点到早上8点之间大概率不想被推送打断。设置静默时段后这段时间检测到的新内容会攒着等到静默结束再发或者干脆不推送——你可以自己选择。我觉得整个通知链路里频率控制最容易被忽略。如果订阅的源恰好集中更新了一批文章一个小时内来20条通知再好的渠道也变成了骚扰。我习惯在inrkss里开启聚合通知把一段时间内多条更新合并成一条消息这样既不会漏也不会被轰炸。3.3 渠道可靠性对比不同渠道在可靠性、延迟、费用上差别不小这里做个小对比渠道优点缺点适用场景Bark延迟低、配置极简仅iOS可用依赖App苹果手机用户主力通知Server酱 / PushPlus微信内直达免费额度有限偶尔排队微信深度用户企业微信/钉钉机器人稳定、可多人协作需要在对应客户端查看团队信号或群消息聚合ntfy开源、可自托管公共服务器有未知风险全平台通知推荐自建Gotify完全自托管需要自己维护服务隐私敏感场景邮件通用、可追溯延迟偏高容易进垃圾箱不重要的摘要通知实际使用中我主力用Bark收即时类消息用企业微信机器人收汇总类消息邮件做兜底。多通道同时配置的优势是某个通道偶尔故障时至少还有另一个通道能顶上。inrkss本身支持一个事件发多个渠道不影响成本但要注意不同渠道的推送频率限制不要低估了更新密集时段的并发量。4. 常用RSS源整理与筛选技巧4.1 如何找热门RSS地址很多人会直接搜热门rss地址rss网址但搜索引擎给的结果往往过时真正高效的找源方式其实是下面这几招。第一招直接猜路径。很多网站都默认提供RSS订阅常见路径是/feed、/rss、/atom.xml、/rss.xml。比如某个博客的域名是example.com那么https://example.com/feed有很高概率就是它的RSS地址。我拿这个办法命中过不少没有在页面上放RSS图标的站点。第二招看网页源代码。打开网页后按CtrlU查看源代码搜索rss或者atom通常能找到link relalternate typeapplication/rssxml href...这样的标签href里的地址就是订阅源。第三招用RSSHub这类生成服务。RSSHub的目的就是为没有RSS的网站生成RSS。B站、知乎、豆瓣、即刻等平台的内容很多都可以通过RSSHub路由生成订阅源。你可以自己部署RSSHub也可以使用公共服务路径一般是域名/路由名/参数路由参数按照文档填写即可。4.2 常见平台的RSS源规律B站、知乎、博客等结合大家搜得比较多的问题这里给几个通用示例。B站。B站用户动态的RSS可以通过RSSHub的bilibili/user/dynamic/{uid}路由生成投稿则用bilibili/user/video/{uid}。uid在个人空间页面的URL里能看到那一串纯数字就是。举个例子某个up主的uid是123456789那么他的投稿订阅源大致形式是https://rsshub.app/bilibili/user/video/123456789。这样设置抓取间隔15分钟基本能及时收到更新通知。知乎。知乎用户回答可以通过RSSHub的zhihu/people/answers/{用户ID}路由生成。用户ID不是昵称而是个人主页URL里的那串英文数字组合。知乎专栏也有对应路由按文档配置就行。公众号。微信公众号本身没有标准RSS源常用的做法是自部署wechat2rss这类工具通过定时抓取生成feed再把它作为一个普通订阅源添加到inkrss里。这个链路虽然长了一截但一旦打通公众号更新就不是什么黑盒了。独立博客。很多独立博客基于Hexo或Hugo搭建这类静态博客生成器一般默认输出/atom.xml或/rss.xml直接拼路径即可。另外GitHub仓库的Releases可以通过/releases.atom订阅非常适合追踪开源项目版本更新。4.3 筛选信息源的判定标准订阅源数量不是越多越好我自己从200多个源砍到60多个反而更舒服。筛选源我基本按四个标准来内容密度与更新频率。日更的源和月更的源要区别对待更新频率低的源抓取间隔可以拉长避免无意义的请求。信息是否可替代。如果某个源的内容三天后在别的平台也看得到那就没必要订阅。反之独立博客、深度长文这类不可替代的源要重点保留。是否原创。洗稿、搬运号订阅源信息噪音远大于价值遇到就取消关注。源服务器稳定性。有些源隔三岔五超时或返回500这种源再优质也容易变成通知黑洞建议用inrkss日志观察一段时间不稳定就换镜像源或者干脆弃掉。我更推荐的思路是先想清楚自己需要哪几类信息技术动态、行业新闻、竞品更新、娱乐消遣每一类只保留最好的3到5个源跑通一整条订阅通知链路之后再逐步扩充。5. 常见问题与排查技巧5.1 订阅不更新的排查最常遇到的问题就是明明订阅了却一直没有新内容推送。排查思路按顺序来确认源地址能正常访问。把RSS URL直接在浏览器里打开看返回的是标准XML还是错误页。如果浏览器里都打不开那inrkss更拿不到。确认抓取间隔没有设得太长。如果你把间隔设成24小时那等一天没更新也算正常。这里有个小技巧刚添加订阅源的时候可以临时把间隔改成5分钟确认能抓到内容后再调回正常值。查看inrkss的抓取日志。日志里通常会记录每次抓取的状态码、耗时和解析结果。如果看到的是60x或者解析错误多半是源站主动防爬或者格式不标准需要给客户端设置合理的User-Agent和请求头。检查时间同步。服务器时区和时间不准会导致上次更新判断错乱该触发的不触发。部署时设置了TZAsia/Shanghai的情况一般没问题但如果你把容器跑在海外主机上还是要确认一下系统时间和本地时间是否一致。5.2 通知丢失与重复通知丢失通常出在渠道这一环。Bark或Server酱这类第三方服务偶尔会做频率限制短时间大量请求会被拒。解决方法是开启inrkss的聚合通知同时给对应渠道设置合理的最大推送频率。通知重复则多半是源站自身的问题有些源会在同一个条目上反复修改标题导致被当成新内容处理。inrkss通常会依赖条目的guid或link去重如果源站没有提供稳定的guid可以考虑在规则里启用标题链接联合去重。遇到顽固的重复直接给这个源单独配置一个较长的去重窗口即可。提醒如果有多个渠道同时接收同一事件消息可能会给人带来推送了两次的感觉。建议在inrkss里按渠道配置不同规则手机端收即时通知邮箱收每日摘要避免同一条内容重复轰炸。5.3 服务稳定性调优自托管服务跑久了稳定性和运维还是绕不开。先说容器本身。restart: unless-stopped必须开这样机器重启后容器能自动拉起。如果有条件给inrkss配置一个健康检查比如每30秒请求一次它的/health接口失败两次以上就自动重启容器这个可以用Docker自身的HEALTHCHECK实现。数据备份我用定时任务每天把./data目录压缩并同步到对象存储。RSS订阅数据本身不大几十MB顶天了但丢了要重建就很麻烦。更重要的一步是导出OPML清单放在数据目录之外防止整个目录损坏时连恢复清单都没有。日志轮转也要关注。inrkss的日志如果全量保留长时间运行下来磁盘会慢慢被占满。可以在宿主机Docker配置里加上log rotation把单个日志文件限制在10MB保留3份历史即可。一点个人经验这套服务我前后跑了大半年最大的体会是工具只是起点信息流的设计才是核心。刚开始我恨不得把所有感兴趣的源都塞进去结果一天几十条通知反而产生了新的焦虑。后来我狠心砍掉超过一半的订阅源并把通知规则调成宁可少推、不要推烦整个订阅-通知链路才真正稳定下来成了我日常获取信息最顺手的一条管道。如果你想上手我的建议很简单先用三个源跑通部署和通知比如自己的博客、一个技术资讯站、一个B站关注的up主。跑通之后再逐个加上其他源边用边调通知规则。这个过程不复杂但能让你真正理解这套RSS工作流该怎么服务于自己而不是被收藏夹和未读数字绑架。本文还有配套的精品资源点击获取