1. 为什么我至今还在用 RSS 订阅
信息获取这件事，越做越觉得像整理房间。每天打开手机，各种推送、热搜、群消息铺天盖地，真正想看的深度内容反而被淹没在噪音里。我大概从十年前开始用 RSS，中间换过无数工具，从早期的桌面客户端到后来的自建服务，兜兜转转，最后还是回到了 RSS 这条路上。原因很简单：它把“看什么”的决定权还给了我，而不是交给算法。
这次整理的是我长期维护的一份 RSS 订阅源清单，数量在 60 个以上，覆盖科技、财经、设计、独立博客、行业资讯等几个方向。同时我也搭了一个网页版的在线浏览入口，方便在浏览器里直接翻看，不用装任何客户端。关键词就两个：RSS和OPML。OPML 是订阅源的标准交换格式，你可以把它理解成一个“订阅清单文件”，导入导出都靠它。
这篇文章适合谁看？如果你厌倦了被信息流牵着走，想重新拿回阅读的主动权，那这份清单和搭建思路应该能帮到你。如果你已经用过 RSS 但订阅源早就荒废了，也可以直接抄这份作业。哪怕你完全没接触过 RSS，我也会把最基础的概念和操作讲清楚，保证你能跟着做出来。
先说清楚一件事：RSS 不是过时的技术，它只是被商业平台刻意边缘化了。因为 RSS 不产生广告曝光、不收集用户画像、不制造停留时长，它对平台没有“商业价值”，但对读者有。这就是我坚持用它的根本原因。
2. 订阅源清单的整体设计与分类思路
2.1 为什么按“信息密度”而不是按“网站类型”分类
很多人整理 RSS 清单，习惯按网站类型分：新闻类、博客类、论坛类。我试过这种方式，结果发现用起来很别扭。因为同样是“博客”，有的博主一周三更干货，有的半年憋不出一篇水文。按类型分，你根本不知道哪个值得看。
我后来改成按信息密度和更新节奏来分。具体分四档：
- 高频高密度：每天更新，且内容质量稳定，适合放在阅读器最显眼的位置，比如科技快讯、财经要闻。
- 高频低密度：更新频繁但水分大，适合扫标题，偶尔点进去看，比如综合资讯站。
- 低频高密度：更新慢但每篇都值得细读，适合单独建一个分组，周末慢慢看，比如深度分析博客。
- 低频低密度：更新少且质量一般，这类我基本直接删掉，不放进清单。
这个分类逻辑的好处是，你打开阅读器时，注意力分配是有优先级的，不会被“更新了 200 篇”这种数字吓到。
2.2 60 个源怎么选出来的：三个硬性筛选标准
清单里的 60 多个源，不是随便凑数的。我给自己定了三条硬标准，不满足的直接淘汰：
第一，全文输出。很多网站只给摘要，点进去还要跳转，体验极差。我优先选支持全文 RSS 的源，或者至少摘要足够长、能判断值不值得点。全文输出这一点，直接决定了阅读效率。
第二，无强制登录和跳转。有些源点开是“请下载 App 查看全文”，这种我一律不要。RSS 的核心价值就是聚合阅读，任何打断这个流程的设计都是减分项。
第三，更新稳定。我观察过一些源，前几个月更新很勤，后来直接停更，这种“僵尸源”留在清单里只会浪费你的注意力。我一般会连续观察一个月，确认更新节奏稳定才保留。
提示：筛选源的时候，不要只看它“有没有更新”，要看它“更新的是不是原创内容”。很多站点的 RSS 只是把首页链接重新推一遍，这种源价值很低。
2.3 OPML 文件的结构长什么样
OPML 本质是一个 XML 文件，结构非常简单。你不需要会写代码，但了解一下它的样子，有助于你理解导入导出时发生了什么。一个典型的 OPML 大概是这样：
<?xml version="1.0" encoding="UTF-8"?> <opml version="2.0"> <head> <title>我的订阅源</title> </head> <body> <outline text="科技" title="科技"> <outline type="rss" text="某科技博客" title="某科技博客" xmlUrl="https://example.com/feed.xml" htmlUrl="https://example.com"/> </outline> <outline text="财经" title="财经"> <outline type="rss" text="某财经资讯" title="某财经资讯" xmlUrl="https://example.com/finance/feed" htmlUrl="https://example.com/finance"/> </outline> </body> </opml>关键字段就三个：text是显示名称，xmlUrl是 RSS 地址，htmlUrl是网站主页。分组靠嵌套的outline实现。你导出订阅时，阅读器生成的就是这种文件；导入时，阅读器解析的也是它。理解了这个结构，你就能手动编辑 OPML，比如批量改分组、批量替换失效的域名。
3. 核心订阅源分类详解与实操要点
3.1 科技与互联网类：怎么挑出真正有信息量的源
科技类是我订阅里占比最大的，大概有 20 个左右。但说实话，大部分科技媒体的 RSS 都是“标题党+摘要”，点进去全是广告。我最后保留的，主要是这几类：
- 独立技术博客：这类博主通常是自己写深度文章，更新慢但质量高。比如一些前端、后端、系统架构方向的个人站，RSS 全文输出，读起来很舒服。
- 开源项目动态：很多开源项目会在 GitHub 上提供 releases 的 RSS，或者通过第三方服务生成。订阅这个，能第一时间知道版本更新。
- 行业分析通讯：一些做深度分析的站点，RSS 里直接给全文，适合通勤时读。
实操上，我建议你先把科技类源单独建一个分组，然后连续看一周，把“点开率”低于 20% 的源删掉。点开率这个指标很直观：你看到标题后愿意点进去的比例。低于 20% 说明这个源对你价值不大。
注意：不要因为“这个源很有名”就留着它。名气不等于对你的价值。我删过好几个大站的 RSS，因为它们的更新对我来说完全是噪音。
3.2 财经类源推荐：怎么避开“标题党”和“荐股文”
财经 RSS 是重灾区。很多源打着“财经资讯”的旗号，实际内容全是荐股、理财广告、标题党。我筛选财经源的时候，会重点看三点：
第一，有没有明确的信源标注。正规的财经资讯会注明数据来源，比如“据某交易所数据”，而不是“据内部消息”。
第二，是不是只讲事实不做预测。我订阅财经源是为了获取信息，不是为了看别人猜涨跌。那些满篇“必涨”“抄底”的源，直接排除。
第三，更新频率是否合理。财经资讯更新太快，如果源每分钟推一条，你的阅读器会被刷屏。我一般选那种每天汇总几次的源，或者只推重要事件的源。
我保留的财经源里，有几类是值得推荐的：官方统计部门的数据发布 RSS、主流财经媒体的要闻版 RSS、以及一些专注宏观经济分析的独立博客。这些源的共同点是：信息准确、更新克制、不煽动情绪。
3.3 设计与创意类：小众但高价值的源怎么找
设计和创意类的 RSS 源相对小众，但价值很高。我订阅的主要是设计博客、作品集更新、以及一些创意资讯站。这类源的特点是更新不频繁，但每次更新都能给你灵感。
找这类源有个技巧：关注你欣赏的设计师或工作室，看他们的网站有没有提供 RSS。很多独立设计师的站点都保留了 RSS 输出，只是不显眼，通常在页脚或者/feed路径下。你可以试试在域名后面加/feed或/rss，很多时候能直接找到。
另外，一些作品集平台也提供 RSS，比如某些设计社区的“最新作品”流。订阅这个，相当于每天自动收到一份精选作品集。
3.4 独立博客与个人站：RSS 精神的最后阵地
独立博客是我最珍惜的一类源。这些博主不靠流量吃饭，写东西纯粹是因为想写。他们的 RSS 通常全文输出，没有广告，没有弹窗，读起来非常干净。
我订阅的独立博客大概有 15 个左右，覆盖技术、生活、读书、效率等方向。这类源的更新完全不可预测，有的月更，有的季更。但每次看到更新提示，我都会认真读完。
找独立博客的 RSS，最好的方式是通过“友情链接”跳转。很多独立博主会在自己的站点列出友链，你顺着点过去，往往能发现一批同样优质的源。这种“人以群分”的发现方式，比算法推荐靠谱得多。
提示：独立博客的 RSS 地址经常变，因为博主可能换域名或者换博客程序。建议定期检查你的订阅列表，把失效的源清理掉，或者找到新的地址替换。
4. 网页版在线浏览的搭建与实现
4.1 为什么我要额外做一个网页版入口
阅读器虽然方便，但有个问题：换设备的时候要重新配置，而且有些阅读器在电脑上体验一般。我就想，能不能做一个网页版的入口，打开浏览器就能看，不用装任何东西。
这个网页版入口的核心逻辑很简单：后端定时抓取所有 RSS 源，解析出文章列表，前端展示成一个可浏览的页面。你可以把它理解成一个“自建的轻量级阅读器”，只读不写，专注浏览。
这样做的好处是：第一，跨平台，任何有浏览器的设备都能用；第二，可以分享给朋友，他们不用配置阅读器就能看；第三，我可以自己控制展示样式，去掉所有干扰元素。
4.2 技术选型：为什么用 Python + 静态生成
实现方式有很多种，我最后选了Python 抓取 + 静态页面生成的方案。原因有三：
第一，Python 的 feedparser 库非常成熟。解析 RSS 和 Atom 格式几乎不用写什么代码，几行就能搞定。对于非程序员来说，Python 也是相对容易上手的语言。
第二，静态生成意味着不需要服务器常驻。我可以写一个脚本，每天定时跑一次，把抓取结果生成 HTML 文件，然后扔到任何静态托管服务上。这样成本极低，而且访问速度快。
第三，静态页面没有数据库依赖。不用担心数据丢失、不用维护后端服务，整个系统就是一个脚本加一堆 HTML 文件，简单可靠。
如果你不想写代码，也有现成的方案，比如一些开源的 RSS 聚合工具，配置一下就能用。但自己写的好处是，完全可控，想怎么改就怎么改。
4.3 抓取脚本的核心逻辑与参数设置
抓取脚本的核心逻辑分三步：读取 OPML 文件、逐个抓取源、生成 HTML。我用的是feedparser加jinja2模板引擎。下面是一个简化版的代码框架：
import feedparser import xml.etree.ElementTree as ET from jinja2 import Template from datetime import datetime def parse_opml(opml_path): tree = ET.parse(opml_path) root = tree.getroot() feeds = [] for outline in root.iter('outline'): xml_url = outline.get('xmlUrl') if xml_url: feeds.append({ 'title': outline.get('text'), 'url': xml_url, 'category': outline.get('category', '未分类') }) return feeds def fetch_feed(feed_info, max_items=10): parsed = feedparser.parse(feed_info['url']) items = [] for entry in parsed.entries[:max_items]: items.append({ 'title': entry.get('title', '无标题'), 'link': entry.get('link', '#'), 'published': entry.get('published', ''), 'summary': entry.get('summary', '')[:200] }) return items参数设置上有几个关键点：
- 超时时间：我设的是 10 秒。太短容易抓取失败，太长会拖慢整体速度。
- 单源抓取条数：每个源最多取 10 条。取太多没必要，因为网页版主要是快速浏览。
- 抓取间隔：源与源之间加 0.5 秒延迟，避免对目标站点造成压力。
- 失败重试：失败的源记录到日志里，下次运行时优先重试。
注意：抓取频率不要太高。我是一天跑一次，完全够用。如果你跑得太频繁，有些站点可能会限制你的访问。
4.4 页面展示的取舍：只保留标题、时间和摘要
网页版的展示，我做了大量减法。最终页面上只有三样东西：标题、发布时间、摘要。没有图片、没有广告、没有推荐阅读。为什么这么克制？因为网页版的定位是“快速扫读”，不是“深度阅读”。看到感兴趣的标题，点进去看原文就行。
页面布局上，我按分类分组，每个分类下面是一个列表。列表项用最简单的样式，标题加粗，时间用灰色小字，摘要限制在两行以内。整个页面加载非常快，因为没有任何外部资源依赖。
如果你也想做类似的页面，我建议你先想清楚：这个页面是给谁看的？如果是给自己快速浏览，那就越简单越好；如果要分享给别人，可以稍微加点样式，但依然要保持克制。
5. 常见问题与排查技巧实录
5.1 订阅源失效了怎么办
这是最常见的问题。RSS 源失效的原因有很多：网站改版、域名更换、停止更新、服务器故障。我的处理流程是这样的：
- 先确认是不是临时故障。等一天再试，有时候只是服务器短暂宕机。
- 检查网站主页有没有新的 RSS 地址。很多网站改版后会换 feed 路径，但主页上通常会有新的链接。
- 用搜索引擎找“网站名 + RSS”。有时候其他用户会分享新的地址。
- 如果都找不到，就删掉。不要留恋，失效的源留着只会浪费你的时间。
我一般每个月检查一次订阅列表，把连续失败三次以上的源清理掉。这个习惯能保证清单始终是“活的”。
5.2 抓取速度慢、超时怎么优化
抓取慢通常有两个原因：源太多、单个源响应慢。我的优化方法是：
- 并发抓取。用 Python 的
concurrent.futures做并发，但并发数控制在 5 以内，避免被封。 - 设置合理的超时。10 秒是个比较平衡的值，大部分源都能在 3 秒内返回。
- 跳过已知的慢源。有些源服务器在国外，响应特别慢，我会单独标记，降低抓取频率。
下面是一个并发抓取的示例：
from concurrent.futures import ThreadPoolExecutor, as_completed def fetch_all(feeds, max_workers=5): results = {} with ThreadPoolExecutor(max_workers=max_workers) as executor: future_to_feed = { executor.submit(fetch_feed, feed): feed for feed in feeds } for future in as_completed(future_to_feed): feed = future_to_feed[future] try: results[feed['title']] = future.result() except Exception as e: print(f"抓取失败: {feed['title']}, 错误: {e}") return results并发数不要设太高，5 个线程足够了。设太高反而容易触发目标站点的限流。
5.3 OPML 导入导出踩过的坑
OPML 看着简单，实际用起来坑不少。我踩过的几个典型问题：
编码问题。有些 OPML 文件是 GBK 编码，直接读会乱码。解决办法是读取时指定编码，或者用chardet自动检测。
分组丢失。有些阅读器导出 OPML 时，不保留分组信息，所有源都平铺在一层。导入前最好先备份，导入后手动重新分组。
重复源。多次导入同一个 OPML，会产生重复订阅。导入前先去重，或者导入后手动清理。
地址失效。OPML 里的xmlUrl可能已经失效，导入后要批量检查一遍。
提示：编辑 OPML 文件时，建议用支持 XML 格式化的编辑器，避免手动改坏结构。改完后先用阅读器试导入，确认没问题再正式使用。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方式 |
|---|---|---|---|
| 源显示“无更新” | 源已停更或地址失效 | 浏览器直接打开 xmlUrl | 找新地址或删除 |
| 抓取超时 | 服务器响应慢或网络问题 | 单独测试该源 | 降低频率或跳过 |
| 页面乱码 | 编码不一致 | 检查源编码 | 指定 UTF-8 读取 |
| 导入后分组丢失 | 阅读器不支持分组 | 查看 OPML 结构 | 手动重新分组 |
| 重复订阅 | 多次导入 | 检查订阅列表 | 去重后重新导入 |
| 摘要显示不全 | 源只提供短摘要 | 查看源设置 | 换全文输出的源 |
这张表是我实际排查时总结的，基本覆盖了 90% 的常见问题。遇到问题先查表，能省不少时间。
6. 我个人的使用习惯与几个小技巧
6.1 每天固定时间看，而不是随时刷
RSS 最大的优势是“你决定什么时候看”，而不是“它决定什么时候推给你”。我给自己定的规矩是：每天早上和晚上各看一次，每次不超过 20 分钟。其他时间不看。
这个习惯的好处是，你不会被信息流打断工作，也不会因为“怕错过”而焦虑。RSS 里的内容不会消失，晚看几个小时没有任何影响。
6.2 用“已读”和“星标”管理阅读进度
阅读器里的“已读”和“星标”功能，我用得很重。扫标题的时候，不感兴趣的直接标已读，感兴趣的标星标，等有空再细读。这样你的阅读列表始终是干净的，不会被未读数字压垮。
我一般每周清理一次星标列表，把读完的取消星标，没读完的继续留着。如果某个星标留了两周还没读，说明它其实没那么重要，直接取消。
6.3 定期清理订阅源，保持清单“瘦身”
订阅源不是越多越好。我每季度会做一次大清理，把过去三个月点开率低于 10% 的源全部删掉。删的时候不心疼，因为真正有价值的源，你一定会点开。
清理完之后，你的阅读器会变得非常清爽，每次打开都是你想看的内容。这种感觉，比刷任何算法推荐都舒服。
6.4 分享 OPML 给朋友时的小细节
如果你想把这份清单分享给朋友，直接发 OPML 文件就行。但有几个细节要注意：
- 先测试一遍。导入前自己先试一遍，确认没有失效的源。
- 附上说明。告诉朋友怎么导入，以及每个分组大概是什么内容。
- 不要包含私人源。有些源可能是内部博客或者需要登录的，分享前先删掉。
我自己维护的这份 OPML，大概每两个月更新一次。每次更新后，我会在网页版入口同步刷新，保证两边一致。
最后再分享一个小技巧：如果你用的是支持“智能分组”的阅读器，可以按更新频率自动分组，这样你打开阅读器时，高频源和低频源会自动分开，阅读体验会好很多。这个功能我用了之后，基本告别了手动整理分组。
