你大概也体会过这种状态公众号越关注越多真正一篇文章不落读完的却没几个。订阅列表越来越长红点数字越来越吓人可打开之后翻两屏就关掉想找几天前看过的那篇却怎么都捞不回来。我把这种状态忍了一年多直到某个周末实在受不了决定把几十个公众号的文章全部同步进自己的RSS阅读器。让我没想到的是整个部署过程三分钟就搞定了之后每一天打开阅读器公众号的更新就和其它博客、新闻源安静地躺在一起标题、摘要、发布日期清清楚楚。这篇文章就把我做的事拆开讲清楚为什么这么干、选了哪条路、具体怎么操作以及用了一周之后哪些默认设置必须改。这套方案的核心说起来很简单就是三个环节抓取公众号更新、把更新转成标准RSS Feed、在自建阅读器里订阅。理论上“公众号没提供RSS”是很多人以为的拦路虎但实际上技术绕行的路非常多难点从来不在“能不能”而在于选一个省心、稳定、不用天天伺候的方案。我写完这篇记录之后最大的感受是如果你已经被信息流绑架得喘不过气那花三分钟把自己从里面捞出来真的太值了。1. 先说说我为什么非要把公众号塞进RSS不可1.1 RSS阅读器到底比公众号App强在哪大多数人的阅读路径是看到红点点进公众号在对话框里往下划看到感兴趣的就读不感兴趣就退出来。这个路径的问题不是浪费时间这么简单而是它让内容呈现的节奏完全由推送触发你刚进入工作状态一条推送就把注意力扯走了真到了晚上想安静看几篇时又因为红点太多懒得翻。RSS阅读器解决的是另一个维度的问题它把内容主动权还给你。所有订阅源按时间顺序排成一列标题和摘要像目录一样铺开你可以像扫报纸一样快速判断今天哪些值得读、哪些直接划过。更重要的是阅读器有统一的历史记录、全文搜索、离线缓存就算某篇文章后来被删掉或改掉只要你抓取时存了快照就永远找得回来。我在迁移之前已经用RSS看了五年以上博客早就离不开这种自己管理自己阅读队列的掌控感只是一直被公众号没有RSS这句话困住了。1.2 公众号内容同步的真正卡点要说清楚这个问题得先明白公众号文章和普通网页到底差在哪。普通博客有稳定的归档页爬虫抓起来容易公众号的内容入口隐藏在关注之后的对话流里同一个公众号的文章并没有一个像博客首页那样公开、稳定的列表页可以直接遍历。这是平台设计造成的封闭性但不是技术上的死局。真实可用的路线有两类。一类是从公众号的合集页面入手一个合集就是一个成体系的文章列表能被解析成常见的网页结构另一类是基于平台的接口或第三方中转把公众号识别成一个独立源定时去拉取新增文章。这两类方案社区里都有现成实现关键是你愿不愿意自己动手跑一个服务。我当时评估下来一个自托管的开源RSS生成服务可以同时解决抓取解析输出Feed三件事我要做的只是部署它、告诉它订阅哪些公众号完事。2. 我对比过的几种同步路线以及最后的选择2.1 路线A手动复制链接——只适合偶尔看一篇最原始的办法看到好文章就在阅读器里手动添加一个书签。够简单零部署成本但它解决不了所有公众号自动同步这个问题。公众号每天发文量并不小手动收藏一两次还行天天如此就成了负担而且公众号文章的链接有时效性过了几天再点开可能跳转到验证页或直接失效。这个方案拿来应急可以作为日常同步主路径谁用谁知道累。2.2 路线B公共转RSS站点——方便但不可控网上有不少把公众号转成RSS的公共聚合服务你把自己需要的公众号名填进去它给你生成一个Feed地址。优点是快几乎不需要任何技术准备缺点是稳定性全看服务方脸色。我试过几次一开始好好的过了一两周就出现漏更、延迟、甚至整个站无法访问的情况。另一个让我介意的点是隐私你把几十个公众号的订阅关系全部托付给第三方对方是否记录、是否分析、哪天关停你完全无法掌控。公共服务的本质是我用别人的机房打工热门公众号还行小众一点的基本处于半瘫痪状态。2.3 路线C自托管开源RSS生成服务——我最终选的路如果你有一台低配云主机哪怕只是用来挂一个小服务那最稳的方案就是自托管。简单说就是在一个开源程序里配置好公众号名称它会定期去抓取把结果输出成一个标准的RSS/Atom Feed阅读器再从这个Feed拉取内容。整个过程不需要自己写抓虫解析核心因为开源社区已经处理好了最麻烦的页面解析、翻页、去重这些细节。我最后选这一条路的原因有四个一来所有数据都在自己的服务器上不怕平台关停二来我可以自定义抓取频率不至于把对方接口逼得太紧三来它同时支持给多个公众号生成独立Feed也支持合并成一个总Feed四来部署起来确实快我实测从敲命令到阅读器里看到文章就是一杯水都还没喝完的时间。下面这张表是我当时自己做的对比你如果也在纠结可以抄走参考。对比维度手动书签公共转RSS站自托管开源服务单次部署时间几秒/篇注册即用约3分钟/台订阅数量上限无严格限制但管理累受服务方配额限制取决于服务器配置稳定性链接失效频繁中服务方说停就停高自己可控隐私与数据归属数据在本地第三方可见数据在自己服务器是否需要维护完全不需要不需要偶尔看日志、做备份对封号/限流风险无服务方承担但可能连带需自己控制频率对比完你应该能看出自托管并不是因为它高级而是因为它在稳定性和可控性之间平衡得最好。你主要付出的成本就是一台低配云主机和偶尔瞄一眼日志的时间换来的是长期稳定的内容管道。3. 三分钟复现从零到订阅跑通的完整步骤3.1 准备一台服务器最低配置与系统初始化先说配置。我在云主机市场里选最低档就够两核CPU、2GB内存、40GB硬盘系统用Debian或Ubuntu。如果手头已有一台跑着其它服务的服务器直接在上面起一个Docker容器也完全没问题这个服务对资源占用很克制我实测空闲时CPU占用不到2%内存长期在300MB以内。系统初始化只做一件事装好Docker。有Docker之后所有依赖都被封装进镜像不会再出现在我机器上明明能跑的这种问题。安装完顺手验证一下版本然后再确认安全组和防火墙里放行了你准备监听的端口。我习惯让抓取服务监听1200端口的HTTP以后用反向代理统一接出HTTPS。这部分实际耗时一分半如果你服务器上已经有Docker那就是零耗时。# Debian/Ubuntu 上安装 Docker 的常规操作 curl -fsSL https://get.docker.com | bash systemctl enable --now docker docker -v3.2 部署RSS生成服务一条命令拉起容器这是整个流程里最有含金量的一步但门槛已经被封装成了一条命令。你可以从开源社区里选择一个仍在维护的公众号转RSS服务这类项目通常会提供现成镜像。我需要提醒的是镜像地址替换成你实际选择的那一个不用照着我的写重点是参数结构。先建一个数据目录用来存放抓取配置和缓存然后启动容器。容器名我用feed-builder指代端口映射到宿主机1200数据目录挂载到容器内的/data再加上--restart unless-stopped这样只要服务器一重启服务自动恢复不用人看着。mkdir -p /srv/feed-builder docker run -d \ --name feed-builder \ -p 1200:8080 \ -v /srv/feed-builder:/data \ --restart unless-stopped \ 你的镜像地址/feed-builder:latest这里有个小细节容易踩坑数据目录一定要挂载。如果图省事不挂载一旦容器被删掉你辛辛苦苦配置的几十个公众号订阅关系全没了。另外配置数据卷后想备份也简单直接把/srv/feed-builder整个目录打包就行。3.3 添加公众号订阅路由规则与阅读器对接容器起来之后打开服务自带的Web后台在添加订阅页面里输入公众号名称。这里它支持两种方式一种是单个公众号生成独立Feed地址形如http://你的服务器IP:1200/feed/某公众号.xml另一种是把多个公众号合并成一个Feed合并后入口不变阅读器里多订阅一个地址就够了。我自己的习惯是为每个公众号都生成独立Feed然后用阅读器的分组功能把它们放到一个专属文件夹里。好处是某个公众号改名或删文时我只排查单独那一条链。接着部署一个自托管阅读器。同样找一个维护活跃的开源Web阅读器起一个容器在后台配置里添加订阅时把上面那个Feed地址粘贴进去。如果你有几十个订阅源要迁旧阅读器一般支持导出OPML文件新阅读器直接导入一次搞定。至此整个链路已经通了阅读器每隔一段时间会自动去拿到最新文章。3.4 验证抓取结果三条排查命令部署完成不能只看服务日志显示启动成功要真正验证到文章进入Feed才算闭环。我的验证动作分三步。第一步看服务自身状态docker ps | grep feed-builder只要STATUS是Up就能放心一半。第二步直接请求Feed地址看返回的XML里有没有文章条目curl -s http://你的服务器IP:1200/feed/某公众号.xml | head -20如果看到item或entry标签且里面有标题、链接、日期说明抓取和转换都正常。第三步去阅读器里刷新订阅确认它能正常解析。我碰到过一种不太好发现的坑curl能看到内容但阅读器一直报解析失败原因往往是Feed地址里有个临时字符没转义或者端口没走HTTPS导致被浏览器的安全策略拦截。遇到这种情况先回系统日志里看请求是否到达容器——日志能看到请求就说明网络链路没问题问题出在格式上日志里连请求都没有那就去查防火墙和安全组。4. 用了一周之后我发现这些隐藏设定必须改4.1 更新频率别乱调节流不是胆小是自我保护很多人在部署完之后会忍不住把轮询间隔调成越短越好恨不得公众号一发文章下一秒RSS里就蹦出来。我的实测结论是完全没必要。公众号的正常发布节奏一天也就一到两次把抓取频率设成每5分钟和每15分钟你看文章的体验几乎没区别但前者的请求量是后者的三倍如果订阅了几十个公众号再叠加追热点时的集中发文瞬时请求量会很吓人。我在使用时把频率设在15分钟一轮一个月下来文章从发布到进入Feed的延迟基本能控制在一刻钟以内对阅读场景已经完全够用。更重要的是频繁短间隔请求很容易触达平台的反爬策略轻则返回校验页重则短时间限制访问。换位思考一下你也不希望一个爬虫每两分钟就来打扰自己的服务器吧留出合理余量是长期稳定运行的起码觉悟。4.2 图片防盗链与正文渲染我交了不少学费公众号正文里的图片通常由平台的CDN提供很多CDN会做Referer校验意思是它只允许图片在公众号自己的页面里展示。当你把文章爬进RSS阅读器后阅读器的域名和原页面不一样图片请求被拒绝于是你会在阅读器里看到一版面裂图。这个问题的处理有两条路。一条是在抓取环节做图片地址重写把CDN域名换成不带Referer校验的地址或者通过反代中转让图片请求从自己服务器转发从而把引用来源伪装成允许的页面。另一条更省心的路抓取时只保留标题、摘要和原文链接不强行抓全文图片。我一开始追求全功能阅读器模式折腾图片代理折腾了快两天后来想明白了——绝大多数文章我会点开原文看排版和评论区阅读器里能起到目录摘要已读标记作用就够了。这个取舍做完之后整个系统稳定得像是消失了一样。现象根本原因我的处理正文图片大量裂开CDN校验Referer放弃全文图片抓取保留原文链接跳转个别文章在阅读器里打不开作者删除或设置权限Feed里正常展示点击原文时发现404忽略即可公众号改名后断更路由仍指向旧名称去后台更新公众号名重新拉取一次某一天全部更新延迟抓取频率过低或接口限流手动触发一次同步观察日志必要时降频4.3 公众号改名、删文、合集边界情况要提前知道正常使用中最破坏体验的就是公众号突然改名。平台的强提醒机制能让你在手机上知道但RSS服务端不会自动跟着变旧路由抓不到新文章你就会以为是对方停更了。我在后台重新配置了新的公众号名之后文章立刻恢复同步这事的教训是别太相信稳定时不时点开服务后台看一眼最近同步时间比什么都靠谱。删文也有意思。公众号后台删除一篇文章后如果你在它删除之前已经抓到了内容你的RSS阅读器里仍会留着缓存快照。这其实是我喜欢RSS的一个隐藏原因互联网是会遗忘的但你自己抓下来的数据不会。至于合集类内容个别公众号会把精华文章整理成一个合集页服务端如果支持合集解析可以把合集也当成一个独立Feed这样连历史文章归档都能在阅读器里呈现出来不用翻几十屏对话记录。5. 维护这台搬运系统的真实心得与踩坑记录5.1 服务挂掉的两类常见原因第一类是平台侧改版导致解析失效。公众号页面结构偶尔调整开源程序解析器没能立刻跟上就会出现全部订阅突然抓不到新文章。这类故障的特点是全盘性日志里会看到大面积超时或解析异常。处理办法不是自己去改解析规则——那样太慢而是直接检查是否有新版本镜像用docker pull加重建容器十分钟内解决。第二类是自身的容器运行环境问题比如磁盘满了或内存不足。因为数据库文件会不断增长一个几千篇文章的Feed库占不了多大空间但如果你备份不勤日志文件也可能累积出几个GB。我通常在每个月的例行检查里清一次日志同时给数据目录做一次完整打包。磁盘空间判断命令也很简单df -h /srv/feed-builder5.2 日志里有大量报错时先看哪一行刚部署完那两天我打开日志一看满屏的红色Error吓得以为系统要崩了。后来一条条对大部分报错其实都是某篇文章已经存在跳过这种无伤大雅的重复提醒真正值得警惕的只有两类一类是HTTP 403或429这代表请求被限流需要立刻降低抓取频率另一类是拿到200响应但解析出的文章数为0这往往说明页面结构变了是上面说的平台侧改版前兆。所以看到报错先别急着系统性重构。我的排查顺序是先用docker logs --tail200 feed-builder看最近200行把HTTP状态码统计一遍再用curl -I手动请求一个Feed地址确认服务还活着最后去后台触发一次手动抓取看新增文章有没有进来。大部分问题走完这三步就能定位。5.3 一个健康的流水线应该允许每个环节独立失败运行了将近两个月后我给这套系统最值的一条建议是把抓取、转换、展示分成三个独立环节不要把希望全押在一个进程上。抓取环节失败不至于影响已经生成的Feed转换环节出问题也不至于把前面的原始数据污染掉。我在数据目录里单独留了一个raw/文件夹放原始抓取结果就算转换服务出问题原始数据还在修复后也能做增量补拉。健康检查我挂在系统定时任务里每6小时自动请求一次Feed地址失败就重启容器并发一封邮件到工程邮箱。代码就一行0 */6 * * * curl -fsS http://127.0.0.1:1200/feed/某公众号.xml /dev/null || docker restart feed-builder这行命令我强烈建议加上。它可以让你在公众号文章同步链条出问题时第一时间知道而不是等读者跑来问你那边怎么断更了才发现。我还自己给阅读器做了一个小优化把RSS阅读器的历史归档目录单独再备份一份到对象存储里每周定时上传一次。公众号文章删文太快如果有哪一天我想回看某个专题的完整历史它还在。说真的把公众号内容搬进RSS不只是改善阅读体验更像给自己攒了一个私人知识库再也不用担心内容哪天消失。整个过程最值钱的不是那三分钟部署而是重新拿回对信息流的掌控感——花这一下午整理订阅列表就是我这几个月做过最不后悔的一件事。 
长河君 · 2026/10/13 3:45:53 · 阅读 1.2k 三分钟把公众号内容同步进RSS阅读器：自托管部署完全指南
你大概也体会过这种状态公众号越关注越多真正一篇文章不落读完的却没几个。订阅列表越来越长红点数字越来越吓人可打开之后翻两屏就关掉想找几天前看过的那篇却怎么都捞不回来。我把这种状态忍了一年多直到某个周末实在受不了决定把几十个公众号的文章全部同步进自己的RSS阅读器。让我没想到的是整个部署过程三分钟就搞定了之后每一天打开阅读器公众号的更新就和其它博客、新闻源安静地躺在一起标题、摘要、发布日期清清楚楚。这篇文章就把我做的事拆开讲清楚为什么这么干、选了哪条路、具体怎么操作以及用了一周之后哪些默认设置必须改。这套方案的核心说起来很简单就是三个环节抓取公众号更新、把更新转成标准RSS Feed、在自建阅读器里订阅。理论上“公众号没提供RSS”是很多人以为的拦路虎但实际上技术绕行的路非常多难点从来不在“能不能”而在于选一个省心、稳定、不用天天伺候的方案。我写完这篇记录之后最大的感受是如果你已经被信息流绑架得喘不过气那花三分钟把自己从里面捞出来真的太值了。1. 先说说我为什么非要把公众号塞进RSS不可1.1 RSS阅读器到底比公众号App强在哪大多数人的阅读路径是看到红点点进公众号在对话框里往下划看到感兴趣的就读不感兴趣就退出来。这个路径的问题不是浪费时间这么简单而是它让内容呈现的节奏完全由推送触发你刚进入工作状态一条推送就把注意力扯走了真到了晚上想安静看几篇时又因为红点太多懒得翻。RSS阅读器解决的是另一个维度的问题它把内容主动权还给你。所有订阅源按时间顺序排成一列标题和摘要像目录一样铺开你可以像扫报纸一样快速判断今天哪些值得读、哪些直接划过。更重要的是阅读器有统一的历史记录、全文搜索、离线缓存就算某篇文章后来被删掉或改掉只要你抓取时存了快照就永远找得回来。我在迁移之前已经用RSS看了五年以上博客早就离不开这种自己管理自己阅读队列的掌控感只是一直被公众号没有RSS这句话困住了。1.2 公众号内容同步的真正卡点要说清楚这个问题得先明白公众号文章和普通网页到底差在哪。普通博客有稳定的归档页爬虫抓起来容易公众号的内容入口隐藏在关注之后的对话流里同一个公众号的文章并没有一个像博客首页那样公开、稳定的列表页可以直接遍历。这是平台设计造成的封闭性但不是技术上的死局。真实可用的路线有两类。一类是从公众号的合集页面入手一个合集就是一个成体系的文章列表能被解析成常见的网页结构另一类是基于平台的接口或第三方中转把公众号识别成一个独立源定时去拉取新增文章。这两类方案社区里都有现成实现关键是你愿不愿意自己动手跑一个服务。我当时评估下来一个自托管的开源RSS生成服务可以同时解决抓取解析输出Feed三件事我要做的只是部署它、告诉它订阅哪些公众号完事。2. 我对比过的几种同步路线以及最后的选择2.1 路线A手动复制链接——只适合偶尔看一篇最原始的办法看到好文章就在阅读器里手动添加一个书签。够简单零部署成本但它解决不了所有公众号自动同步这个问题。公众号每天发文量并不小手动收藏一两次还行天天如此就成了负担而且公众号文章的链接有时效性过了几天再点开可能跳转到验证页或直接失效。这个方案拿来应急可以作为日常同步主路径谁用谁知道累。2.2 路线B公共转RSS站点——方便但不可控网上有不少把公众号转成RSS的公共聚合服务你把自己需要的公众号名填进去它给你生成一个Feed地址。优点是快几乎不需要任何技术准备缺点是稳定性全看服务方脸色。我试过几次一开始好好的过了一两周就出现漏更、延迟、甚至整个站无法访问的情况。另一个让我介意的点是隐私你把几十个公众号的订阅关系全部托付给第三方对方是否记录、是否分析、哪天关停你完全无法掌控。公共服务的本质是我用别人的机房打工热门公众号还行小众一点的基本处于半瘫痪状态。2.3 路线C自托管开源RSS生成服务——我最终选的路如果你有一台低配云主机哪怕只是用来挂一个小服务那最稳的方案就是自托管。简单说就是在一个开源程序里配置好公众号名称它会定期去抓取把结果输出成一个标准的RSS/Atom Feed阅读器再从这个Feed拉取内容。整个过程不需要自己写抓虫解析核心因为开源社区已经处理好了最麻烦的页面解析、翻页、去重这些细节。我最后选这一条路的原因有四个一来所有数据都在自己的服务器上不怕平台关停二来我可以自定义抓取频率不至于把对方接口逼得太紧三来它同时支持给多个公众号生成独立Feed也支持合并成一个总Feed四来部署起来确实快我实测从敲命令到阅读器里看到文章就是一杯水都还没喝完的时间。下面这张表是我当时自己做的对比你如果也在纠结可以抄走参考。对比维度手动书签公共转RSS站自托管开源服务单次部署时间几秒/篇注册即用约3分钟/台订阅数量上限无严格限制但管理累受服务方配额限制取决于服务器配置稳定性链接失效频繁中服务方说停就停高自己可控隐私与数据归属数据在本地第三方可见数据在自己服务器是否需要维护完全不需要不需要偶尔看日志、做备份对封号/限流风险无服务方承担但可能连带需自己控制频率对比完你应该能看出自托管并不是因为它高级而是因为它在稳定性和可控性之间平衡得最好。你主要付出的成本就是一台低配云主机和偶尔瞄一眼日志的时间换来的是长期稳定的内容管道。3. 三分钟复现从零到订阅跑通的完整步骤3.1 准备一台服务器最低配置与系统初始化先说配置。我在云主机市场里选最低档就够两核CPU、2GB内存、40GB硬盘系统用Debian或Ubuntu。如果手头已有一台跑着其它服务的服务器直接在上面起一个Docker容器也完全没问题这个服务对资源占用很克制我实测空闲时CPU占用不到2%内存长期在300MB以内。系统初始化只做一件事装好Docker。有Docker之后所有依赖都被封装进镜像不会再出现在我机器上明明能跑的这种问题。安装完顺手验证一下版本然后再确认安全组和防火墙里放行了你准备监听的端口。我习惯让抓取服务监听1200端口的HTTP以后用反向代理统一接出HTTPS。这部分实际耗时一分半如果你服务器上已经有Docker那就是零耗时。# Debian/Ubuntu 上安装 Docker 的常规操作 curl -fsSL https://get.docker.com | bash systemctl enable --now docker docker -v3.2 部署RSS生成服务一条命令拉起容器这是整个流程里最有含金量的一步但门槛已经被封装成了一条命令。你可以从开源社区里选择一个仍在维护的公众号转RSS服务这类项目通常会提供现成镜像。我需要提醒的是镜像地址替换成你实际选择的那一个不用照着我的写重点是参数结构。先建一个数据目录用来存放抓取配置和缓存然后启动容器。容器名我用feed-builder指代端口映射到宿主机1200数据目录挂载到容器内的/data再加上--restart unless-stopped这样只要服务器一重启服务自动恢复不用人看着。mkdir -p /srv/feed-builder docker run -d \ --name feed-builder \ -p 1200:8080 \ -v /srv/feed-builder:/data \ --restart unless-stopped \ 你的镜像地址/feed-builder:latest这里有个小细节容易踩坑数据目录一定要挂载。如果图省事不挂载一旦容器被删掉你辛辛苦苦配置的几十个公众号订阅关系全没了。另外配置数据卷后想备份也简单直接把/srv/feed-builder整个目录打包就行。3.3 添加公众号订阅路由规则与阅读器对接容器起来之后打开服务自带的Web后台在添加订阅页面里输入公众号名称。这里它支持两种方式一种是单个公众号生成独立Feed地址形如http://你的服务器IP:1200/feed/某公众号.xml另一种是把多个公众号合并成一个Feed合并后入口不变阅读器里多订阅一个地址就够了。我自己的习惯是为每个公众号都生成独立Feed然后用阅读器的分组功能把它们放到一个专属文件夹里。好处是某个公众号改名或删文时我只排查单独那一条链。接着部署一个自托管阅读器。同样找一个维护活跃的开源Web阅读器起一个容器在后台配置里添加订阅时把上面那个Feed地址粘贴进去。如果你有几十个订阅源要迁旧阅读器一般支持导出OPML文件新阅读器直接导入一次搞定。至此整个链路已经通了阅读器每隔一段时间会自动去拿到最新文章。3.4 验证抓取结果三条排查命令部署完成不能只看服务日志显示启动成功要真正验证到文章进入Feed才算闭环。我的验证动作分三步。第一步看服务自身状态docker ps | grep feed-builder只要STATUS是Up就能放心一半。第二步直接请求Feed地址看返回的XML里有没有文章条目curl -s http://你的服务器IP:1200/feed/某公众号.xml | head -20如果看到item或entry标签且里面有标题、链接、日期说明抓取和转换都正常。第三步去阅读器里刷新订阅确认它能正常解析。我碰到过一种不太好发现的坑curl能看到内容但阅读器一直报解析失败原因往往是Feed地址里有个临时字符没转义或者端口没走HTTPS导致被浏览器的安全策略拦截。遇到这种情况先回系统日志里看请求是否到达容器——日志能看到请求就说明网络链路没问题问题出在格式上日志里连请求都没有那就去查防火墙和安全组。4. 用了一周之后我发现这些隐藏设定必须改4.1 更新频率别乱调节流不是胆小是自我保护很多人在部署完之后会忍不住把轮询间隔调成越短越好恨不得公众号一发文章下一秒RSS里就蹦出来。我的实测结论是完全没必要。公众号的正常发布节奏一天也就一到两次把抓取频率设成每5分钟和每15分钟你看文章的体验几乎没区别但前者的请求量是后者的三倍如果订阅了几十个公众号再叠加追热点时的集中发文瞬时请求量会很吓人。我在使用时把频率设在15分钟一轮一个月下来文章从发布到进入Feed的延迟基本能控制在一刻钟以内对阅读场景已经完全够用。更重要的是频繁短间隔请求很容易触达平台的反爬策略轻则返回校验页重则短时间限制访问。换位思考一下你也不希望一个爬虫每两分钟就来打扰自己的服务器吧留出合理余量是长期稳定运行的起码觉悟。4.2 图片防盗链与正文渲染我交了不少学费公众号正文里的图片通常由平台的CDN提供很多CDN会做Referer校验意思是它只允许图片在公众号自己的页面里展示。当你把文章爬进RSS阅读器后阅读器的域名和原页面不一样图片请求被拒绝于是你会在阅读器里看到一版面裂图。这个问题的处理有两条路。一条是在抓取环节做图片地址重写把CDN域名换成不带Referer校验的地址或者通过反代中转让图片请求从自己服务器转发从而把引用来源伪装成允许的页面。另一条更省心的路抓取时只保留标题、摘要和原文链接不强行抓全文图片。我一开始追求全功能阅读器模式折腾图片代理折腾了快两天后来想明白了——绝大多数文章我会点开原文看排版和评论区阅读器里能起到目录摘要已读标记作用就够了。这个取舍做完之后整个系统稳定得像是消失了一样。现象根本原因我的处理正文图片大量裂开CDN校验Referer放弃全文图片抓取保留原文链接跳转个别文章在阅读器里打不开作者删除或设置权限Feed里正常展示点击原文时发现404忽略即可公众号改名后断更路由仍指向旧名称去后台更新公众号名重新拉取一次某一天全部更新延迟抓取频率过低或接口限流手动触发一次同步观察日志必要时降频4.3 公众号改名、删文、合集边界情况要提前知道正常使用中最破坏体验的就是公众号突然改名。平台的强提醒机制能让你在手机上知道但RSS服务端不会自动跟着变旧路由抓不到新文章你就会以为是对方停更了。我在后台重新配置了新的公众号名之后文章立刻恢复同步这事的教训是别太相信稳定时不时点开服务后台看一眼最近同步时间比什么都靠谱。删文也有意思。公众号后台删除一篇文章后如果你在它删除之前已经抓到了内容你的RSS阅读器里仍会留着缓存快照。这其实是我喜欢RSS的一个隐藏原因互联网是会遗忘的但你自己抓下来的数据不会。至于合集类内容个别公众号会把精华文章整理成一个合集页服务端如果支持合集解析可以把合集也当成一个独立Feed这样连历史文章归档都能在阅读器里呈现出来不用翻几十屏对话记录。5. 维护这台搬运系统的真实心得与踩坑记录5.1 服务挂掉的两类常见原因第一类是平台侧改版导致解析失效。公众号页面结构偶尔调整开源程序解析器没能立刻跟上就会出现全部订阅突然抓不到新文章。这类故障的特点是全盘性日志里会看到大面积超时或解析异常。处理办法不是自己去改解析规则——那样太慢而是直接检查是否有新版本镜像用docker pull加重建容器十分钟内解决。第二类是自身的容器运行环境问题比如磁盘满了或内存不足。因为数据库文件会不断增长一个几千篇文章的Feed库占不了多大空间但如果你备份不勤日志文件也可能累积出几个GB。我通常在每个月的例行检查里清一次日志同时给数据目录做一次完整打包。磁盘空间判断命令也很简单df -h /srv/feed-builder5.2 日志里有大量报错时先看哪一行刚部署完那两天我打开日志一看满屏的红色Error吓得以为系统要崩了。后来一条条对大部分报错其实都是某篇文章已经存在跳过这种无伤大雅的重复提醒真正值得警惕的只有两类一类是HTTP 403或429这代表请求被限流需要立刻降低抓取频率另一类是拿到200响应但解析出的文章数为0这往往说明页面结构变了是上面说的平台侧改版前兆。所以看到报错先别急着系统性重构。我的排查顺序是先用docker logs --tail200 feed-builder看最近200行把HTTP状态码统计一遍再用curl -I手动请求一个Feed地址确认服务还活着最后去后台触发一次手动抓取看新增文章有没有进来。大部分问题走完这三步就能定位。5.3 一个健康的流水线应该允许每个环节独立失败运行了将近两个月后我给这套系统最值的一条建议是把抓取、转换、展示分成三个独立环节不要把希望全押在一个进程上。抓取环节失败不至于影响已经生成的Feed转换环节出问题也不至于把前面的原始数据污染掉。我在数据目录里单独留了一个raw/文件夹放原始抓取结果就算转换服务出问题原始数据还在修复后也能做增量补拉。健康检查我挂在系统定时任务里每6小时自动请求一次Feed地址失败就重启容器并发一封邮件到工程邮箱。代码就一行0 */6 * * * curl -fsS http://127.0.0.1:1200/feed/某公众号.xml /dev/null || docker restart feed-builder这行命令我强烈建议加上。它可以让你在公众号文章同步链条出问题时第一时间知道而不是等读者跑来问你那边怎么断更了才发现。我还自己给阅读器做了一个小优化把RSS阅读器的历史归档目录单独再备份一份到对象存储里每周定时上传一次。公众号文章删文太快如果有哪一天我想回看某个专题的完整历史它还在。说真的把公众号内容搬进RSS不只是改善阅读体验更像给自己攒了一个私人知识库再也不用担心内容哪天消失。整个过程最值钱的不是那三分钟部署而是重新拿回对信息流的掌控感——花这一下午整理订阅列表就是我这几个月做过最不后悔的一件事。