微信读书模块设计与实现

type

Post

status

Published

date

slug

weread-module-design

summary

围绕将微信读书接入博客，核心不在展示书单，而在把阅读记录纳入可持续积累的内容体系。方案强调持续同步、沉淀为长期可维护数据，并将 About 页与独立书单页分离，避免页面臃肿；最终通过微信读书、Notion 与博客页面协同，把阅读数据组织成更可读、可生长的界面与内容链路。

为什么我想给博客做一个微信读书模块

阅读一直是我生活里很重要的一部分。

对我来说，博客不只是一个发文章的地方，它也承载着我平时的兴趣、输入和长期积累。如果文章、笔记和页面是这个博客最显性的表达，那么阅读记录其实更像一条一直在流动的底层线索。它不一定总是站在最前面，但会慢慢影响这个站点的气质。

所以我一直觉得，如果“阅读”只是停留在一句自我介绍，或者只是 About 页里的一块静态说明，那多少有点可惜。

与其放一张书单截图，或者简单列几本最近在读的书，我更想做一件更有长期价值的事：让阅读记录真正进入博客本身，成为一部分可以持续更新、持续积累、也持续被看见的内容。

说白了，我不太想让“阅读”只作为一种人设存在。我更希望它真的在这个站里留下痕迹。

于是，微信读书模块就是从这个想法开始的。

我很快遇到的一个问题：书单不该只是挂件

一开始最直觉的做法，其实很简单：

在 About 页放一块书单

展示几本书的封面

再加一点阅读状态或简单说明

这样当然能用，甚至第一眼看起来还挺有氛围。

但问题也来得很快。

首先，About 页本身就很容易变重。人物介绍、兴趣、经历、技能、时间线、联系方式，这些内容本来就已经够多了。如果再把完整阅读内容一股脑塞进去，页面会变成一个“什么都想放”的集合页。

其次，书单一旦只是装饰，它就很难继续生长。它只能证明“我平时读书”，却没办法真正承担起阅读记录的作用。

再往后我就慢慢意识到，真正的问题并不是“能不能把书放上去”，而是：

我到底想让这部分内容在博客里承担什么职责。

这时候答案开始变得清楚：

About 页应该做概览和引导

完整书单应该有更合适的独立承载位置

阅读记录不能只是背景板，而应该成为可维护、可生长的内容链路

也正是从这里开始，这个模块不再只是“展示几本书”，而是慢慢有了自己的结构和边界。

从“放书”到“组织阅读记录”：我对这个模块的目标

当我不再把它当成一个简单挂件之后，这个模块的目标也就不一样了。

我希望它至少满足这几件事：

1. 能持续同步，而不是手动更新

如果每次都要我自己复制、粘贴、改状态，那它迟早会废掉。

一个真正能长期使用的阅读模块，首先要解决的不是“展示效果”，而是“更新成本”。它得足够顺手，才能真的长期存在。

2. 能沉淀成长期可维护的数据

我不太想让它变成一次性的页面装饰，所以它最好不是临时请求完就结束，而是能沉淀下来，成为博客体系里可管理的一部分。

3. `About` 页和书单页要职责分离

About 页适合展示最近阅读、重点阅读，或者作为人物画像的一部分出现。

但完整书单、分书单组织、更多阅读记录，这些更适合放在独立页面里承载。这样既不会把 About 页拖重，也不会浪费这部分内容。

4. 展示出来的不是“数据库表格”，而是可阅读的界面

我不希望书单页看起来像后台管理页，也不希望它只是在机械列字段。

我更在意的是：

它看起来是不是自然

它是不是有阅读节奏

它是不是更像内容，而不是数据

这几点，其实决定了这个模块最后会长成什么样子。

整体方案：微信读书 + Notion + 博客页面

在方案上，我最后采用的是一条相对稳定、也更适合长期维护的链路：

数据来自微信读书

同步后进入 Notion

Notion 作为博客内容侧的数据承载层

博客页面再根据不同场景取用这份数据

我之所以没有把它做成一种完全临时的直接请求方案，原因也很简单。

一方面，临时请求虽然看起来省事，但后面一旦要做筛选、整理、展示分层、页面复用，维护成本就会迅速上升。另一方面，如果我希望阅读记录真正成为博客的一部分，那么它就应该进入博客已有的数据体系，而不是漂在外面做一层装饰。

Notion 在这里起到的作用，其实更像一个中间承载层。

它让我可以：

把同步过来的书单数据沉淀下来

在不同页面中复用这些内容

保留结构化信息，而不是每次从头取一次再现场拼装

让阅读模块和博客其他内容维持相近的数据组织方式

这样做的好处不是“技术上更复杂”，而是后面真的更省心，也更容易扩展。

页面分工：为什么 About 页只展示一部分，完整书单独立承载

这是我觉得整个模块里最值得讲的一部分。

一开始很多人做阅读模块，都会默认把所有东西塞进 About 页里。因为直觉上，阅读本来就是“关于我”的一部分。

这当然没错，但如果把所有内容都堆进去，About 页就很容易承担了太多原本不属于它的职责。

后来我给这两个页面做了比较明确的分工。

About 页：做概览

放在 About 页里的阅读内容，更像是一个入口。

它主要承担的是：

让读者快速知道我最近在读什么

让阅读成为人物画像的一部分

提供一个轻量但有辨识度的内容切面

也就是说，它负责“让你看到”，但不负责“把所有东西都讲完”。

书单页：做展开

完整书单页承担的就不一样了。

它更适合做这些事情：

展示更多书目

按书单组织内容

形成更完整的阅读记录浏览体验

成为一个可以持续沉淀的阅读页面

这样拆开之后，两个页面反而都更轻松。

About 页不会被拖得过重，书单页也终于有了存在的必要，不再只是一个“可有可无的详情页”。

对我来说，这其实不只是页面布局问题，而是一个信息架构问题。

当你开始认真区分“概览”和“展开”的职责时，很多原本混乱的东西就会慢慢变清楚。

实现上我最在意的，不是“能不能显示”，而是“能不能长期用”

很多功能在开发初期都很容易先做到“能跑起来”。

但真正麻烦的，从来都不是第一天把它做出来，而是一个月后、三个月后、半年后，它还能不能正常维护，能不能低成本继续跑下去。

所以在这个模块上，我真正比较在意的，其实不是“它显示出来没有”，而是：

它怎么刷新

谁可以触发刷新

失败时怎么办

如何减少重复请求

如何避免维护成本越来越高

这些问题看起来不如界面直观，但它们才决定一个模块是不是只停留在 demo 阶段。

也正因为这样，这部分后来逐渐有了更多控制逻辑，比如：

刷新机制的管理

控制项的存在

与 cookie、鉴权、冷却、缓存相关的约束

同步链路的稳定性考虑

这些细节我没有特别想把它写得像一份接口文档，但它们确实决定了这个模块到底能不能长期用下去。

如果只是“拉个数据展示一下”，那实现并不难。难的是在保持体验自然的同时，把维护成本压下来。

说到底，我更想做的是一个能长期跑、长期维护、也不用我天天操心的东西，而不是一个一开始看起来很酷、后面却懒得管的功能。

展示层的取舍：我不想把它做成一个“书籍数据库页面”

到展示层的时候，另一个问题又出现了：

既然已经有了结构化数据，那是不是应该把能展示的字段都展示出来？

我的答案基本是否定的。

因为一旦这样做，页面很快就会变得像一个数据库列表，信息很完整，但不好读，也没有节奏。

而我真正想要的，并不是一个“字段很全”的页面，而是一个更接近阅读体验本身的界面。

所以在展示层，我更在意的是这些东西：

封面排列的节奏感

书单分组是否清晰

状态信息是不是够用但不过量

页面是不是像内容，而不是像管理后台

这其实也是我一直在做主题时很在意的一件事：

结构化数据当然重要，但最后落到页面上，它还是应该先是“可阅读”的，其次才是“信息完整”。

如果一个页面只是把数据端得很整齐，却没有节奏、没有呼吸感，那它就很难真正留下来。

它对我来说，其实不只是一个功能

写到这里，我越来越觉得，微信读书模块对我来说，其实不只是一个功能。

它让“阅读”这件事，不再只是 About 页里的一句兴趣标签，也不再只是偶尔提一下的生活习惯，而是真正进入了博客的内容体系。

从某种意义上说，它和文章、页面、播放器这些模块一样，都是这个站点的一部分。只是它承载的不是输出，而是输入；不是表达的结果，而是表达背后那条持续流动的线索。

也正因为这样，我才会愿意花时间把它从一个简单展示块，慢慢做成一条更完整的链路。

因为我希望这个博客记录的不只是“我写了什么”，也包括“我一直在吸收什么、关注什么、被什么影响着”。

写在最后：从书单展示到阅读基础设施

我最开始只是想把微信读书同步到博客里。

后来我才发现，真正值得做的其实不是“把书展示出来”，而是把阅读记录变成博客内容体系的一部分。

如果说文章、笔记和页面是这个博客最显性的表达，那阅读记录更像一条持续流动的底层线索。它不会永远站在最前面，但会慢慢塑造这个站点的气质。

所以现在回头看，这个模块并不只是一个阅读功能，也更像是一种阅读基础设施。

它让我能更自然地把“阅读”这件事留在博客里，也让这个站点不再只是一个输出内容的地方，而更像一个持续生长的个人空间。