三个月前我给自己定了个小目标做一个真正属于自己的阅读工具。项目代号在键盘上随手敲了两下就成了rea——它听着像read的前半截也挺好记。rea不是一个框架也不是某个开源库它是我最近一直在打磨的一个纯前端项目的代号核心功能是订阅RSS和Atom源把分散在互联网各处的文章更新聚合到一个页面里提供干净的阅读体验、离线缓存和简单的内容过滤。做这个项目直接解决两个问题一是现在很多信息流平台越用越吵个性化推荐把时间稀释得很碎我越来越想回到主动选择信息源的阅读方式二是市面上现成的阅读器要么绑定了特定生态要么在性能和自定义上不够顺手。rea全部代码都跑在浏览器里逻辑简单直接非常适合前端开发的同学用来练手尤其能覆盖React工程化、状态管理、浏览器存储和性能优化这些方向。这篇文章不打算写成文档式教程我想像聊天一样把rea从0到1的过程、踩过的坑和背后取舍都摊开聊一遍。1. 从rea这个代号说起项目定位与核心思路1.1 为什么是rea给项目起代号的时候我脑子里的第一反应是reader。rea是read/reader的一个极简投射敲起来顺手听起来顺耳就这么定了下来。它的定位是一个跑在浏览器里的私人阅读器把分散在十几个RSS源里的文章拉到同一个界面按时间排序干干净净读完。这个想法谈不上新但真正实现下来我发现RSS生态的一个隐性价值正在于标准统一。只要源站还输出XML你就能拿到同样的字段标题、链接、时间、正文。相比各类App暴露的接口RSS反而是最稳定的数据源。于是rea的定位越来越清楚不追求大而全不做账号和云端只把订阅-拉取-存储-阅读这条链路做到顺手。目标读者也很明确一是本身就在用RSS的信息收集型用户二是想通过一个完整前端项目来巩固React工程化能力的同学。对我来说这个项目也是一个很好的训练场因为阅读器虽然看起来简单但它的数据流、存储设计和异常处理密度一点也不低几乎每天都在跟真实世界的脏数据打交道。1.2 核心需求拆解要想把一个阅读器做好其实绕不开三件事信息获取、信息组织、信息阅读。信息获取对应订阅源的解析和抓取信息组织对应数据库里的去重、排序与分类信息阅读对应详情页的排版、字体和离线能力。另外一个特别容易被忽视的点是当网络不可用或者源站挂掉的时候用户能不能依然看到之前缓存过的内容这是rea必须承诺的离线可读能力。基于这几点我重新拆出了完整功能清单订阅源管理手动添加加OPML导入导出、文章聚合与去重、关键词过滤、收藏和已读标记、详情页阅读优化、离线缓存。这六个功能之间尽量解耦实现时可以独立推进调试起来也省心。我特别想把订阅源管理做得轻巧因为很多阅读器把导入OPML这个功能藏得很深第一次使用的人根本找不到。rea把导入入口直接放在侧边栏底部一个按钮进文件选择器解析完成后立刻刷新列表整个过程不超过三秒。1.3 整体架构与数据流整体架构采用前后端分离只不过后端被换成了远程RSS源加浏览器存储。整个应用分四层视图层是React组件状态层由Zustand管理全局store数据层是Dexie封装的IndexedDB网络层是封装好的fetch请求函数。数据流是单向循环拉取函数请求远端XML解析成结构化文章列表批量写入IndexedDB同时更新store里的最近获取时间视图订阅store变化后重新渲染。每一条数据都只有一条官方来源不存在状态不同步的问题。这个架构最大的好处是每一步都可以单独测试。比如解析器拿到一段XML样本可以不依赖页面直接跑单测数据库层可以在控制台里手动插入一条文章记录然后观察列表是否更新。对于阅读器这种数据驱动型项目单向数据流比双向绑定更容易排查问题哪里显示不对顺着数据链路往上查很快就能定位到是解析问题、存储问题还是渲染问题。2. 技术方案选型每一步背后的取舍2.1 框架、语言与构建工具前端生态选择React主要看中它的组件模型简单以及资料覆盖足够广。在rea这种项目里我并不需要服务端渲染也不需要复杂的路由嵌套React的纯客户端渲染完全够用。配合TypeScript整个数据模型在编码阶段就能被约束住比如Feed和Article的基础字段、可选字段、联合类型都能清晰表达这对后面写解析器帮助很大很多undefined的问题在编译期就被拦下来了。构建工具用Vite。最早我也纠结过是webpack还是Vite实际跑起来后发现Vite基于原生ES模块的冷启动确实快HMR的响应速度在阅读器这种偏交互式的页面里非常跟手。日常开发中改一个store里的字段页面几百毫秒内就能反映出来这种体验会极大改善开发节奏。另外Vite的配置文件很直观后面配置接口代理只需要几行不像webpack那样要记一堆loader规则。2.2 状态管理为什么选Zustandrea里的跨组件状态不算复杂大致有当前订阅源、当前文章索引、是否处于阅读模式、侧边栏折叠状态。这类状态用Redux去维护会显得重写一堆action和reducer反而拖慢实现。Context本身也可以但Context更新时会触发所有消费该Context的组件重新渲染在列表频繁滚动切换的场景下很容易造成卡顿。Zustand采用选择器订阅的机制组件可以只订阅自己关心的字段其他字段变化不会造成重渲染这在文章列表和详情页这种高频交互场景里尤其重要。Zustand的写法也很直观比如reader store里无非就是几个字段和对应方法一个create调用就完成了。组件里用useReaderStore带上选择器函数就能精准触发局部更新。实际用下来这个选择器机制配合React的并发特性非常舒服既没有Redux的样板代码也没有Context的全局穿透问题属于用最少的心智负担搞定状态管理的典型方案。2.3 数据库为什么选择IndexedDB文章正文经常是几十KB甚至几十KB到上百KBlocalStorage的5MB配额很快见底。rea的数据量上限可以预料100个订阅源乘以每个源1000篇文章就是10万条索引记录这个量级只有IndexedDB能从容应对。直接用IndexedDB很痛苦因为它的API是事件驱动没有Promise封装写起来啰嗦。我用Dexie这个库做了封装可以像操作普通表格一样写代码。rea里定义了三张表feeds、articles、meta。articles表的索引有feedId、publishedAt、read等字段。尤其publishedAt做索引之后按时间倒序翻页可以直接走数据库游标不需要把所有文档一次性load出来。这里有个很关键的实践心得存文章时不要一股脑把整个HTML全塞进一条记录更合理的做法是核心字段展开存储标题、链接、摘要、时间、作者、源ID正文作为一种大字段放进去但建立查询时不要经常读写它否则大字段会拖慢整体性能。2.4 样式与组件组织样式上没有引入任何UI组件库。阅读器的核心是内容可读性我不需要按钮和卡片的一致性靠组件库来保证。主要的CSS变量包括字号、行高、正文宽度、背景色、前景色主题切换时直接切换这一组变量即可。我甚至给正文区域单独设了一个最大宽度控制在68字符左右这个宽度是阅读长文最舒服的体验区间比满屏拉伸的阅读体验好很多。组件组织按功能区域拆分Sidebar负责订阅源列表ArticleList负责中间的文章列表Reader负责详情阅读。每个组件下面按局部功能再拆小组件比如ArticleList里的ArticleItem单独抽出来配合React.memo避免整列表全部重渲染。组件之间的数据传递全部走store或props不搞跨组件直接操作DOM保持了数据流的一致性。3. 核心模块设计与关键实现3.1 项目初始化和依赖安装创建一个Vite加React加TS项目很简单用官方脚手架就可以快速搭好npm create vitelatest rea -- --template react-ts cd rea npm install npm install zustand dexie tanstack/react-virtual dompurify原有的模板会生成一个示例页面我直接把它清空只保留入口文件。依赖里的zustand用于状态管理dexie用于IndexedDB封装tanstack/react-virtual用于虚拟滚动dompurify用于正文HTML清洗。这些依赖都很轻项目整体体积依然可控。安装之后我建议先做一件事把tsconfig的strict模式打开。RSS解析和数据库操作涉及大量未知字段开启strict能提前暴露很多潜在的undefined情况还能让编辑器给出更准确的类型提示。3.2 数据模型的约定rea的数据模型经过几次迭代最终稳定下来的结构不算复杂。Feed记录订阅源基本信息包括标题、URL、站点地址、分类、最后抓取时间Article记录一篇文章的完整信息包括所属feedId、标题、链接、摘要、正文、作者、发布时间、已读和收藏状态。read和favorited两个字段我故意用数字0和1而不是boolean这是出于IndexedDB索引的考虑数字类型在复杂查询里更稳定也方便做统计。初始化数据库时用Dexie的version和stores方法建表其中link唯一索引是为了从源头上防止同一条文章被重复写入。URL里偶尔会有utm参数之类的东西存储前统一清洗掉避免同一个文章因为链接参数不同而成为两条记录。3.3 订阅源的XML解析与内容标准化这一步是rea的核心也是最需要耐心的地方。RSS 2.0和Atom是两种主流格式结构差异不小。我在parseFeed里先判断根元素是feed还是rss然后分别解析entry和item节点。RSS的正文可能出现在description或content:encoded里Atom则用content或summary解析时要优先取长度更长的那个字段否则列表页只能看到一段摘要点进详情也没有全文。这段代码能跑通大部分订阅源但真实线上还会遇到两个问题一是CDATA包裹的内容取出后可能带一层包装需要再解析一次二是有些站点把正文放在description里有些放在content:encoded里必须优先取长内容。另一个细节是相对路径。文章正文里的图片和链接经常写成/uploads/xxx.jpg这样的相对路径必须在展示之前拼上源站域名否则图片一读一个404。实现起来也不复杂把内容扔进一个临时的DOM容器遍历img和a标签对src和href做URL拼接。3.4 抓取调度、去重与OPML导入导出订阅源的抓取我做成一个fetchAllFeeds方法利用Promise.allSettled并发请求并发数控制在6个防止被源站拒绝。每次请求前先查meta表里的lastFetchedAt如果距上次不足30分钟就直接跳过。这个节流机制非常重要否则手动操作里多点了两次刷新很容易触发某些源站的限流。抓取完成后解析出的新文章批量写入articles表写入前对link做清洗去掉不必要的追踪参数。去重逻辑分两层第一层是数据库唯一索引对link精确去重第二层是对标题做归一化去掉空格和特殊符号后比较一定程度上拦截同文不同链接的重复内容。第二层不会去得太狠因为有不少网站确实会重发旧文你无法判断究竟是重复还是更新所以只做保守的模糊匹配避免误杀。OPML导入导出则完全是XML解析的另一处复用OPML本质上是XML的outline节点嵌套结构直接递归遍历即可导出时把feed表转换成outline树导入时把outline树摊平写成Feed记录。3.5 详情阅读与正文清洗阅读器页面的正文本质上就是innerHTML渲染。但直接渲染很危险会有XSS风险也难免带进样式污染。我在react里用一个MemoizedRichContent组件内部先对原始HTML做DOMPurify清洗再通过sanitize配置移除script、iframe、style标签保留标题和列表标签。纯文本信息源一般不会用到脚本但很多站点会在正文里塞视频iframe所以iframe默认禁用。如果以后想支持视频内容可以只对少数视频平台域名开放白名单但默认安全优先。阅读器右侧还提供字号调节和主题切换。字号用CSS变量挂在根节点上主题则分为日间、夜间、羊皮纸三种。夜间模式我不推荐用filter反转来做因为滤镜会让图片颜色变得很奇怪更合理的方案是直接切换背景色和文字色的CSS变量让正文的图片保持正常色彩。实际体验下来这个方案的实现成本不高但阅读舒适度提升非常明显。4. 性能优化与体验打磨4.1 虚拟滚动把千条列表变成几十个节点rea里最容易被卡住的地方就是文章列表。当某一个源积攒了上千条文章后一次性渲染所有DOM会导致滚动明显掉帧。我的方案是用tanstack/react-virtual来做虚拟列表。虚拟列表的核心思想是固定一个可视容器的高度根据滚动位置计算出应该显示的条目范围只渲染那些条目其余区域用空白占位。react-virtual提供了useVirtualizer这个hook业务代码并不复杂只需要传入总数、滚动容器引用、预估高度和上下额外渲染的数量。使用虚拟列表的首要前提是列表项高度要相对稳定。文章列表的卡片高度不固定时我会在卡片内部用overflow省略并把高度固定成96px这样虚拟滚动才能稳定工作。实测下来1500条数据渲染节点从1500个降为40个左右滚动流畅度有明显提升。这个翻倍体验的优化方案在阅读器里几乎是必做的因为用户天天都要刷列表一个卡顿的列表比加载慢更劝退。4.2 图片与正文的懒加载文章列表里的缩略图、详情页里的大图都直接用原生loadinglazy属性浏览器会延迟加载未进入视口的图片。这个属性已经得到现代浏览器广泛支持不需要额外引入库。真正容易忽略的是图片高度未占位导致的布局抖动。我给列表里的每个图片容器固定了一个aspect-ratio让浏览器在图片下载前就知道占位尺寸这样滚动时不会出现内容和图片交替跳动的情况。正文里的图片还额外处理了referrerPolicy部分图床在跨域请求时会带referer被拦截我在图片标签里统一加上referrerPolicyno-referrer来缓解。4.3 状态更新与渲染粒度优化Zustand虽然能避免整个应用的无关重渲染但组件内部的拆分也要跟上。ArticleList里每条ArticleItem被包裹在React.memo里只有当它自己的article对象引用变化时才重新渲染。因为每次抓取后写进数据库的都是新数组memo在这里非常有效。详情页同样用memo包住RichContent组件因为正文HTML清洗很消耗CPU如果每次切换文章都必须重新清洗一遍用户会明显感觉到卡顿。我的做法是把清洗后的结果缓存在内存Map里key为文章ID加更新时间这样同一篇文章第二次打开时直接命中缓存。这个缓存内存占用并不大因为用户实际会查看的文章数量有限。除了渲染层面的优化我还把已读状态更新做成异步的点击列表项后UI立即跳转数据库写入放到后台队列里避免点击后出现约一两百毫秒的阻塞感。阅读器这类工具型页面交互反馈的即时性比华丽动效更重要。4.4 加载态、错误态与空态设计rea里的每个异步区域都必须有三种状态加载中转圈、失败后显示原因和重试按钮、成功但无数据显示空态。举一个订阅源列表的例子页面首次启动数据库里还没有任何数据侧边栏不应该是一片空白而应该显示一个引导提示附上添加订阅源的按钮。抓取失败则更常见。某一个订阅源可能因为跨域问题、SSL证书过期、域名迁移而失效我设计成单条源级别的错误标识在列表里显示一个小红点鼠标悬浮能看到失败原因一条源挂了不影响其余源继续抓取。这种局部容错对用户体验影响很大。最开始我把所有源的抓取结果汇总成一个Promise任何一个源失败就整个报错结果常常是十个源里有一个临时超时所有源都刷不出来用户会觉得整个应用坏了。改成allSettled逐条处理之后每次刷新都能最大化地拿到可用内容失败源单独提示整体体验立刻稳定了很多。这个小改动值得每个人在做聚合类工具时参考。5. 实际开发中遇到的坑与排查清单5.1 跨域限制绕不开也要绕得优雅开发模式下的跨域Vite的proxy解决得最省心。在vite.config里加一段接口代理配置把特定路径代理到目标RSS域名这样开发时请求/rss/feed.xml就等于请求远端地址浏览器不感知跨域。但发布之后代理就不存在了这种方案只适用开发期。正式环境我建议走两条路一条是接公开的RSS转JSON服务把解析放在服务端完成由它返回JSON给前端另一条是用轻量云函数做转发和解析。关键点是不要期望用户配置浏览器来绕过跨域普通用户不会也没必要这样做。所以你必须在自己的应用层把这个问题消化掉。自建转发服务时需要注意缓存很多RSS源的内容更新频率并不高服务端做一层十分钟级缓存能明显减少源站压力和你的流量消耗。跨域问题在这个项目里虽然不是核心功能但它能逼迫你思考前端在没有后端的情况下到底能走多远。5.2 日期解析与内容清洗的细坑RSS里的pubDate格式五花八门常见的有RFC 822、ISO 8601、甚至一些中文博客用的是北京时间但缺时区后缀。Date.parse大部分能兜住但遇到解析不出来的时候不要直接给0而应该回退到当前时间同时在日志里记录异常否则会出现一篇2025年的文章被排到1970年的诡异情况。内容清洗里还有一个高频问题实体编码。有些源站把正文里的、、转义成了Unicode字符或者HTML实体直接用textContent取出来会看到一串乱码。我写了一个unescapeEntities方法先用DOM解析一次把实体转成正常字符再进入清洗管线。还有一个容易被忽略的点是正文里的代码块很多技术博客会在pre里放置高亮代码清洗时需要注意不要误删class属性否则代码高亮样式就丢了。DOMPurify在保留class方面是可控的可以通过配置允许特定class前缀这样既安全又能保留视觉效果。5.3 IndexedDB版本升级与数据迁移开发期最烦的就是数据结构迭代。第一次我存文章只存了title和link后来加了content字段数据库版本从1升到2如果没有迁移函数旧数据就永远没有content。所以我从第一版就养成了习惯每次升级版本号时都在upgrade里写旧版本到新版本的迁移逻辑。Dexie的写法可以直接在version后面接upgrade回调遍历旧记录并补充新字段默认值这样老用户升级后数据依然可以平滑读取。IndexedDB在隐私模式或存储空间不足时还会抛QuotaExceededError我的兜底策略是捕获异常后提示用户清理数据并把新抓取内容直接放在内存态保证当前会话依然能阅读。这里有个值得注意的细节千万不要在用户不知情的情况下清空数据库那是一种很恶劣的数据丢失体验。我会弹一个清晰的提示说明当前存储空间不足并提供清理缓存图片和保留文章文字两个选项让用户自己决定取舍。5.4 常见问题速查表把开发过程中碰过的典型问题整理成一张速查表遇到类似情况可以直接对照排查。现象可能原因解决思路新增订阅源后抓不到文章CORS跨域、XML解析失败、网址是HTML不是XML打开开发者工具看请求响应确认返回内容格式用解析器解析responseText换正确的订阅源URL日期显示错乱时区未按本地转换、pubDate为null存储统一时间戳展示时调用toLocaleString缺失时间回退为抓取时间文章列表滚动掉帧DOM节点过多、图片未懒加载使用虚拟滚动列表项高度固定图片加loadinglazy刷新后重复文章去重逻辑只按title用清洗后的link做精确去重再用归一化标题做模糊匹配页面刷新后状态丢失store未持久化zustand persist插件持久化轻量状态文章数据从IndexedDB重新读取正文图片全部404图片是相对路径未拼接域名渲染前遍历img标签用new URL拼接源站域名正文乱码或样式被去掉实体编码未解析、清洗白名单过度先用DOM解析实体再通过DOMPurify配置保留必要标签和class这张表的价值在于它把异常和排查方向直接对应起来不用每次从头翻代码。实际开发中你会发现阅读器项目90%的bug都集中在解析和存储这两层UI层相对稳定得多。所以调试时优先看解析器输出的数据结构再往上查渲染层能省不少时间。另外还有一个容易被忽视的小地方日志规范。我在reqres里给每次抓取、解析、写入都加了带时间戳的日志输出失败时还会打印源站返回的前200个字符。这些日志平时不怎么看但一旦排查问题它就是最重要的线索来源。rea项目开发到现在带给我的收获远超出预期。我个人最深的体会是阅读器这种看似简单的工具恰恰是把前端各类知识串起来最好的练习场。你既要懂浏览器存储又要懂网络请求还得处理各种不规范的第三方数据源每当一个奇怪的订阅源导致解析失败你总得想办法让程序变得更强壮。如果你也打算动手做类似的东西我的建议是先从一条订阅源开始让它真正跑通从抓取到展示的完整链路再逐步扩展。不要一开始就追求对接几十个源那样会把大量精力耗在边缘情况上。最后分享一个rea后续想加入的小功能给已读和未读的文章做一个时间瀑布流统计看看自己每天到底在哪些信息上花了多少时间。这个统计本身也会成为我下一次打磨rea的起点。