先来看看效果：友情链接 - PRIN BLOG。

自我感觉还是不错的，友链的博客们有什么更新都可以实时展示在页面上，一目了然。作为博主，不用打开 RSS 阅读器就可以查看新文章；作为访客，也可以快速找到更多自己感兴趣的内容，比起原来全是链接的页面，看起来也让人更有点击欲望了。

从临时起意到开发完成总共两个晚上，最速传说就是我！（误）

缘起

前段时间看到有个博客用了这样的一个东西：

• Rock-Candy-Tea/hexo-circle-of-friends: 友链朋友圈
• 朋友圈 | Black Flies

当时就感觉卧槽好高端，很有想法。

这种聚合订阅的形式有个名字，叫做 Planet（社区星球）。Planet 通常用于聚合某个领域的博客，然后展示在一个页面上，方便用户一站式阅读，比如：

• Planet Python
• Planet MySQL
• Arch Linux 中文星球

这种形式在开源社区里比较常见，不过用在博客的友链上我倒还是第一次看到。

就像我在本站友链页里说的一样，独立博客之间的联系基本上就是靠的链接交换和评论互访。一个博客的访客看到了其他博客的链接，点过去看了，然后从对面的友链中，又导航到新的博客……如此往复，我们就依靠着这种从现在看来显得十分古老的方式，维系着这些信息孤岛之间的纽带。原始又浪漫。

不过这里就会涉及到一个用户点击率的问题。我自己之前在维护友链页面的时候，总感觉只放标题和链接看起来效果不怎么好。就算加上描述、头像这些元素，也总觉得差点意思。因为一个博客最重要的其实还是它的内容，仅靠一个网站标题，可能很难吸引到其他用户去点击。

而「友链朋友圈」的这种形式，就像微信朋友圈一样，作为一个聚合的订阅流，展示了列表中每个博客的最新文章。

比起干巴巴的链接，这显然会更加吸引人。虽然我写博客到现在也已经 9 年了，早就佛系了，主打一个爱看不看。不过对于和我交换了友链的博主们，还是希望他们能够获得更多的曝光和点击（虽然我这破地方也没多少流量就是啦……），也希望我的访客们也可以遇到更多有价值的博客。

然而在准备接入的时候，我发现这玩意儿不就是一个小型的 RSS 阅读器么……其实等于是自己又实现了一套订阅管理、文章爬取、数据保存之类的功能。

于是我就寻思，可能直接复用已有 RSS 阅读器 API 的思路会更好，让专业的软件做专业的事。友链的管理也可以直接复用 RSS 阅读器的订阅管理功能，这样增删改也不需要了，我们就只需要封装一下查询的 API，提供一个精简的展示界面就 OK。

技术栈选择

作为行动力的化身，咱们自然是说干就干，下班回家马上开工！

首先是 RSS 后端的选择。

市面上的 RSS 阅读器有很多，我自己主要用的是 Inoreader。然而我看了下，Inoreader API 只面向 $9.99 一个月的 Pro Plan 开放，而且限制每天 100 个请求……这还玩个屁。Feedly 也是差不多一个尿性，可以全部 PASS 了。我也不知道该说他们什么好，也许做 RSS 真的不挣钱，只能这样扣扣搜搜了吧。

另外一个选择就是各种支持 self-host 的 RSS 阅读器，比如 Tiny Tiny RSS 和 Miniflux。我之前部署过 TTRSS，说实话感觉还是太重了。Miniflux 则是使用 Go 编写的，该有的功能都有，非常轻量级，部署也很方便。就决定是它了！

技术栈方面选择了之前一直比较心水的 Hono，部署在 Cloudflare Workers 上。前端方面没有使用任何框架，连客户端 JS 都没几行，基本上是纯服务端渲染。有时候不得不感叹技术的趋势就是个圈，以前那么流行 SPA，现在又都在搞静态生成了。

页面渲染使用了 Hono 提供的 JSX 方案，可以在服务端用类似 React 的语法返回 HTML，挺好用的。不过 CSS 没有用 Hono 的那一套 CSS-in-JS，因为要允许用户覆盖样式，所以要用语义化的类名。最后选了 Less，还是熟悉的味道。

前端文件的构建使用了 tsup，配置文件就几行，爽。

实现

实现思路很简单，就是做一个 Proxy 层，把：

• GET /v1/categories/22/entries - Get Category Entries
• GET /v1/categories/22/feeds - Get Category Feeds

这两个 Miniflux 的 API 包一下。这里要注意不能暴露实际的 API Endpoint，避免可能的恶意攻击。API 缓存也要在我们这一层做好，防止频繁刷新把服务打爆。

缓存策略上使用了 SWR (Stale-While-Revalidate)：

1. 拿到 API 响应后，放到 KV 中，同时把时间戳放入 metadata；
2. 后续从 KV 读取缓存时，对比当前时间和 metadata 中的时间戳；
3. 如果经过的时间没有超过设置的 TTL，说明缓存有效，直接返回前端；
4. 如果经过的时间超过了 TTL，则标记缓存为 stale 状态，依然返回前端；
5. 此时，后端在后台重新请求 API，并将最新的响应写入 KV 中；
6. 下一次再从 KV 读取时，拿到的缓存就是最新的了。

这样可以保证最快的响应速度，以及相对及时的更新速度，比较适合这种场景。

最后的交付形式其实就是两个 HTML 页面，通过 <iframe> 的形式嵌入到网页中。另外参考 giscus 提供了一个脚本，可以设置参数并自动完成 iframe 的初始化，用户只需要引入一个 <script> 标签即可，非常方便：

<script  async  data-category-id="28810"  src="https://blog-friend-circle.prin.studio/app.js"></script>

当然也可以作为独立页面打开，有做双栏布局适配：

blog-friend-circle.prin.studio/category/2/entries

开源

新版博客友链朋友圈的所有代码都开源在 GitHub 上，欢迎使用：

👉 prinsss/blog-friend-circle

这个方案和 hexo-circle-of-friends 并没有孰优孰劣之分，只是侧重点和实现方式不同。不过我这个的一个好处是，如果你已经在用 Miniflux 了，那么可以直接复用已有的大部分能力，不需要再起一个 Python 服务和数据库去抓取、保存 RSS，相对来说会更轻量、稳定一些。

如果你选择使用 Miniflux 官方提供的 RSS 服务，甚至可以无需服务器，部署一下 CF Workers 就行了，像我这样的懒人最爱。

有时候我也很佩服自己，这么简单的一个功能，写写也就几个小时，一年多前就想搞了，竟然给我拖到现在才装上去。拖延症，恐怖如斯！

以前我对深色模式其实不怎么感冒，主要感觉开了也没啥用，就系统界面变黑了，其他 App 里还是白色的，等于没开。不过这几年大部分应用的适配都跟上来了，体验也就好起来了，晚上玩手机看着不那么刺眼，挺好的。

现在浏览器网页也支持检测用户的系统主题色，所以我也凑个热闹，给博客加上了自动切换浅色/深色主题的功能。适配过程还是挺顺利的，记录一下供参考。

原理

就是使用 CSS 的 prefers-color-scheme 媒体查询。

@media (prefers-color-scheme: dark) {  /* dark theme styles go here */}

参考文档：prefers-color-scheme - CSS | MDN

不过需要注意的是，不支持 IE。

使用方法

最简单的例子：

body {  background-color: white;  color: black;}@media (prefers-color-scheme: dark) {  body {    background-color: black;    color: white;  }}

这样在亮色模式下是白底黑字，在暗色模式下就是黑底白字。

依样画葫芦，给原主题中颜色相关的 CSS 加上对应的深色样式就差不多了。

使用 mixin 处理颜色

拿我自己写的这个主题举例，在主题中我们一般会用到很多颜色。一个常见的做法就是使用 CSS 预处理器，把这些颜色定义成变量方便后续使用（我用的是 Stylus）：

$color-primary        = convert(hexo-config('primary_color'));$color-background     = #fff;$color-text           = #333;$color-text-secondary = #999;

同样，定义这些颜色的深色版本：

$color-primary-dark        = convert(hexo-config('primary_color_dark'));$color-background-dark     = #181a1b;$color-text-dark           = #c8c3bc;$color-text-secondary-dark = #a8a095;

引用之：

body {  background-color: $color-background;  color: $color-text;}a {  color: $color-primary;}@media (prefers-color-scheme: dark) {  body {    background-color: $color-background-dark;    color: $color-text-dark;  }  a {    color: $color-primary-dark;  }}

然而问题来了，这样岂不是要写很多媒体查询语句？麻烦且不说，看着都眼花。如果把不同地方的这些语句集中起来，放在一起，又会破坏模块设计，也不利于后续维护。

想要写得简洁一点，不妨利用 CSS 预处理器的 mixin 特性。

定义 mixin（可以理解为可重用的代码片段）：

// 根据传入参数拼装变量名color-themed(name) {  color: lookup('$color-' + name);  @media (prefers-color-scheme: dark) {    color: lookup('$color-' + name + '-dark');  }}

这个 mixin 的意思就是我们传一个名称进去，它会根据这个名称去查找对应的颜色变量及其深色版本，然后一起应用。

如此一来，上面的样式就可以简化为：

body {  background-color-themed: 'background';  color-themed: 'text';}a {  color-themed: 'primary';}

使用 CSS 变量处理颜色

用上面那种方法，比原来的是好了不少，但感觉不太直观。

另一种方法，就是用 CSS 原生的变量机制来处理颜色。定义变量：

:root {  --color-primary: #7065a3;  --color-background: #fff;  --color-text: #333;  --color-text-secondary: #999;}@media (prefers-color-scheme: dark) {  :root {    --color-primary: #bb86fc;    --color-background: #181a1b;    --color-text: #c8c3bc;    --color-text-secondary: #a8a095;  }}

使用：

body {  background-color: var(--color-background);  color: var(--color-text);}a {  color: var(--color-primary);}

是不是清爽了很多呢？

不过遗憾的是，IE 浏览器不支持 CSS 变量。（又是你！！！🙃

所以为了兼容性我还是选了预处理器 + mixin 的方法，这样在 IE 上虽然不能自动切换，但至少能保证默认的浅色主题是可以正常显示的。而如果全部使用 CSS 变量的话，在不支持的浏览器上就啥都没有了，得考虑 polyfill 和 fallback，还是算了。

如果不用考虑兼容旧浏览器的话，CSS 变量是最佳选择。

加载外部样式

使用 link 标签加载的外部 CSS 也可以指定媒体查询。

比如本主题使用的 highlight.js 代码高亮的样式：

<link rel="stylesheet" href="atom-one-dark.min.css" media="screen and (prefers-color-scheme: dark)"><link rel="stylesheet" href="atom-one-light.min.css" media="screen and (prefers-color-scheme: light)">

这样在浅色模式下会加载 light 样式，在深色模式下会加载 dark 样式。

参考

另外，关于深色模式下的图片要如何处理，其实也是需要考虑的。

不过我懒，就直接不管了。更详细的相关内容可以参考：

• prefers-color-scheme を用いた Dark Mode 対応と User Preference Media Features | blog.jxck.io
• prefers-color-scheme: Hello darkness, my old friend

最后是自动切换的效果图（视频）：

联动三年前的文章：使用 Travis CI 自动部署 Hexo 博客

今天更新了一下博客，寻思着好歹也改一下页脚的 Copyright 年份，改完 push 上去以后却发现 GitHub Pages 迟迟没有更新。进去 Travis CI 一看，发现任务一直处于 Queued 状态，半小时了都没开始构建。

查了一下，并不是只有我遇到了类似情况（似乎是因为 Travis CI 正在将 travis-ci.org 迁移至 travis-ci.com）：

• Builds hang in queued state
• Builds queuing for hours with public git repo

看了一圈感觉有点悬，干脆换成 GitHub Actions 吧。

我的博客完全托管在 GitHub 上：prinsss.github.io，其中 source 分支放的是源码，master 分支（即 GitHub Pages）是 Hexo 生成的静态博客页面。

要做的也和之前 Travis CI 差不多，当 source 分支有更新时，自动使用 Hexo 构建新页面并更新 GitHub Pages 就可以了。

配置部署密钥

生成一个新的 SSH 密钥，用于 push 至 GitHub Pages 所在的 repo：

ssh-keygen -f hexo-deploy-key -C "prinsss.github.io"

将公钥 hexo-deploy-key.pub 设置为仓库的部署密钥（Settings > Deploy keys）：

然后在 Settings > Secrets 中新增一个 secret，命名为 DEPLOY_KEY，把私钥 hexo-deploy-key 的内容复制进去，供后续使用。

编写 Workflow

Workflow 就是 GitHub Actions 的配置文件，类似于 .travis.yml。

首先新建文件：

mkdir -p .github/workflowstouch .github/workflows/deploy.yml

编辑 deploy.yml：

name: Hexo Deploy# 只监听 source 分支的改动on:  push:    branches:      - source# 自定义环境变量env:  POST_ASSET_IMAGE_CDN: truejobs:  build-and-deploy:    runs-on: ubuntu-latest    steps:      # 获取博客源码和主题      - name: Checkout        uses: actions/checkout@v2      - name: Checkout theme repo        uses: actions/checkout@v2        with:          repository: prinsss/hexo-theme-murasaki          ref: master          path: themes/murasaki      # 这里用的是 Node.js 14.x      - name: Set up Node.js        uses: actions/setup-node@v1        with:          node-version: '14'      # 设置 yarn 缓存，npm 的话可以看 actions/cache@v2 的文档示例      - name: Get yarn cache directory path        id: yarn-cache-dir-path        run: echo "::set-output name=dir::$(yarn cache dir)"      - name: Use yarn cache        uses: actions/cache@v2        id: yarn-cache        with:          path: ${{ steps.yarn-cache-dir-path.outputs.dir }}          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}          restore-keys: |            ${{ runner.os }}-yarn-      # 安装依赖      - name: Install dependencies        run: |          yarn install --prefer-offline --frozen-lockfile      # 从之前设置的 secret 获取部署私钥      - name: Set up environment        env:          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}        run: |          sudo timedatectl set-timezone "Asia/Shanghai"          mkdir -p ~/.ssh          echo "$DEPLOY_KEY" > ~/.ssh/id_rsa          chmod 600 ~/.ssh/id_rsa          ssh-keyscan github.com >> ~/.ssh/known_hosts      # 生成并部署      - name: Deploy        run: |          npx hexo deploy --generate

当然，具体步骤还是得根据自己的需求进行相应的修改。

GitHub Pages 相关的具体配置放在了 Hexo 的 _config.yml 里：

deploy:  type: git  repo: git@github.com:prinsss/prinsss.github.io.git  branch: master  name: prinsss  email: prinsss@gmail.com

部署结果

更新 source 分支，push 后 GitHub Actions 就会自动执行。

不到半分钟就 build 完了，只能说微软爸爸还是牛逼。

参考链接

• Workflow syntax for GitHub Actions - GitHub Docs
• 利用 Github Actions 自动部署 Hexo 博客 | Sanonz
• Hexo Action · Actions · GitHub Marketplace