---
title: 新博客及迁移方案
date: 2022-07-17T20:00:00+08:00
tags:
  - Notion
  - 技术
  - 日记

---

> 2024-07-28 更新：  
目前已放弃 Notion 方案，详见 [个人网站的再次重建 - gq‘s blog](https://zgq.me/posts/blog-rebuilding/)

[上回](https://zgq.me/posts/holiday-self-observation/) 提到我希望捣鼓一个新博客、和集中的文章列表页面的想法，也察觉到我近期日常的表达欲也特别旺盛，碎片的脑洞分散在各种不同社交平台，让自己有些抓不住重点，想来需要试着多聚焦一些，以一个主题开始写点什么，在赛博世界与现实之间慢慢找到一个属于自己的定位。

生活越来越忙碌，要面对的事越来越多，近期也面临着大环境和工作的变动，深感大块专注时间的宝贵，能花在博客本身折腾上的时间也越来越少；但仍希望能通过记录，看到一些脉络和体系，让自己对自我有更清晰的认知。也以此，对 blog 做一个更新换代，让写博文的心智负担小一些。

当然，再如何简洁都好，既然是开一个网站，维护 Web 健康的链接和交流状态自然也义不容辞，也希望内容尽可能充分地被搜索引擎索引，那么一些必要的开放协议是需要支持的。

整理下来主要是三个目标：

1. 能把分散的想法集中于一处，更加聚焦
2. 让自己专注于内容，减少在博客本身技术细节中内耗
3. 基本的 Web 元素（`URL`、`RSS Feed`、`Open Graph`）的支持，及 SEO 优化

## URL、路径与域名的考虑

博客更核心的一点，在于交流与分享，因此 URL 的稳定性也十分重要，避免因为自己站点的变动使得自己 or 他人原有的信息“链接”失效。URL 的结构上除了协议（都走 `https://` ）外还有 `Host` 和 `Path`，对外分享的 `Host` 即为域名。

Path 的规则大概有这几种：

1. **直接用 ID**：类似 `/archives/:cid`，这是 WordPress 与 Typecho 默认的方式，这个 `cid` 来自于数据库的自增ID，会有点暴露底层细节，当后端背后实现不同时，会有些别扭
2. **日期 + 标题**：类似 `/2022/07/15/title-xxx` 的模式，Hexo 默认是这么干的，但觉着这种情况，日期和标题都是较大的变数，且在中文语境下，中文标题会变成 URL encode 的字符串，一大堆百分号堆积在一起，基本丧失了可读性
3. **自定义 slug**：类似 `/slug-example` ，与上面的 ID 类似，一篇文章对应一个 slug，这个 slug 由用户提供，兼具唯一性和灵活性，slug 的来源可以是文件名、也可以写在博文里面

以前没考虑太多，一直在 Typecho 默认方案 1 一直这么过来，现在想想，或许于我而言，Typecho 已完成了它的历史使命：目前我自己在 Web 已有一定经验积累，再在 PHP 博客领域折腾，边际收益已越来越小，成就感少了，感到的更多是繁琐与内耗，写博客这件事情在自己其他事务的博弈中，逐渐变得弱势。

域名的注册方面，主要考虑记忆与输入的方便，尽可能短、带上一些特别含义，并且价格不能太离谱，原本的 `blog.izgq.net` 确实是有些长了，寻思着应该换一个。

以 `zgq` 搜索了一下，3位短域名热门后缀基本都已被注册，亦或是被高价拍卖；冷门后缀看到 `zgq.ink`，ink（墨水）、link（链接），有一点记录与交流的寓意，就入了。

由此得出新博客的博文 URL 的模式：

```
https://zgq.ink/slug-example
```

> UPDATE:
> 
> 
> 考虑到这个域名未来还可做各种项目的展示用，从目录路径规划的角度考虑，加上“博文”（`Post`）这一层含义，因而改成 `https://zgq.ink/posts/slug-example` 的形式
> 

## 部署姿势

### 选择

以尽可能减少技术细节上的人力内耗为原则，优先考虑静态站生成器，并且使用现在发达的网站托管服务部署（如 GitHub Pages、Vercel、Netlify 等，最近更偏向于 Vercel）。

一开始想着直接用 Markdown 生成页面，捣鼓了一圈 Hexo 及其周边，主题大都不尽人意，要么配置过于复杂，要么过于简陋、移动端样式难以接受，再开发一套主题的时间消耗有些不太现实。

想起前些日子看到的 [Nobelium](https://github.com/craigary/nobelium)，它以 Notion 的 database 作为展示的数据源、然后用 Next.js 的 [ISR](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration) 接口，缓存已有的 API 请求，实现动态内容的快速渲染；UI 上较为简洁大方，没有什么花里胡哨元素；也支持 RSS、Open Graph，并且代码本身不复杂，有需要可以自己魔改加点 React 组件啥的，可以说非常贴合我目前的需要。

Notion 是我这几年来比较喜欢的工具，它的核心思想集中在 “block” 这一概念，存储结构上每个 block 都有其唯一 id，所有的元素都由这一个个 Block 构建而成，它组织信息的粒度恰到好处，帮助我们理顺现实中的信息的关联关系，更好地构建个人的知识体系。

这一概念也如 Git 使用 sha1 hash 去组织版本库的思路，基于 id 去存储链接关系，比通过具体内容去建立联系的成本要低不少。

进一步而言，类 Notion 的模型衍生出了 [Block Protocol](https://blockprotocol.org/) 标准，若能以此发展出一个开源和标准化的方案，将信息的组织从 Web 以 `Page URL` 为 id 的 **Page 粒度** 细化到以 `内容元素 hash / uuid`  为 id 的 **Block 粒度**，实现更细致的互联互通，还是很有意思的。

### 操作

参考 Nobelium 官方的指引（也可以看这个 [教程](https://sspai.com/post/66641)），包括域名绑定等十几分钟就完成了，博文写的差不多，给对应文章 block 的 “是否发布” 字段改个状态就完事，可谓异常方便。

浅浅试用了下，基本都很舒适，同时发现一些优化点：

- 图片处理走 Notion 官方地址中转，大陆访问稳定性可能欠佳
- 没有 404 等页面，找不到页面情况下，流量压力会传导至 notion 一方（目前已补充）

## 评论与 PingBack

Nobelium 默认提供了三种添加评论的方式：

- Disqus：非常成熟的评论系统，但需要注册，且墙内被屏蔽
- 依赖 GitHub 的：Gittalk、utterances
- 第三方、自建：Cusdis

对比之下觉得 [Cusdis](https://cusdis.com/) 挺不错，体验上与 WordPress / Typecho 特别接近，且支持自己搭建，原始在 Typecho 的数据库的部分的老评论迁移过来也不是一件难事。再看作者是 [Randy](https://lutaonan.com/) 前辈，能感受到前辈的技术追求，回归技术而非商业为导向，长远来看还是值得信赖的。

传统动态 blog 有提供 `PingBack` 的机制，当文章被引用时，引用的博文会通过 `PingBack` 通知到源网站，但暂时没找到比较好的方案。初步看有个 [Webmention](https://webmention.net/) 的协议在做类似的事情，光有协议，概念未深入人心的时候，就还是力不从心，先保持观望吧。

> UPDATE:
> 
> 
> 博客的评论区迁移要处理的细节要比想象中复杂，好在 cusdis 已搭好基本的架子，未来有空的时间，再考虑进一步维护和贡献吧。
> 
> 关于评论的迁移踩过的坑，请看[这篇](https://zgq.me/posts/notes-about-comment-migrating/)。
> 

## 旧 blog 迁移与 URL 映射

原则还是尽可能维护过去这个 blog 站点与外界交互的积累，包括外链、搜索引擎索引等，因此域名仍需要保留，考虑做一个简单的 301 跳转的映射服务。

接下来也在陆陆续续抽空迁移一些文章过来，标注好原文和要跳转的链接，批量导出一个映射 map，再在 vercel 上跑一个站点，把原 `blog.izgq.net` 的访问转移过来。

> UPDATE:
这里用了 Next.js 自带的 [redirects 配置](https://nextjs.org/docs/api-reference/next.config.js/redirects) 实现，向后兼容链接在数量上是固定的，映射关系可以直接写死在代码中。
> 

## 后记

这么一番操作下来，写文的精力消耗上已与其他各种平台持平，总的来说，很感谢发达的开源社区，尤其 Nobelium 的贡献者们。

在技术上，一点感触很深的是，当 [Jamstack](https://jamstack.org/) 概念深入人心，分工也逐步明确，把 Web 世界的交互都收归于一套技术栈下，业务逻辑等也可以以微服务的形式，更加纯粹地躺在 JavaScript 构建的中间层背后，而无需让 Web 开发者太费精力去纠结其他语言的细节。

特赞 Vercel 这类云服务，当自己想要部署的网站非常多的时候，它的优势就特别明显，省去了各种开机器跑 node 服务、反向代理、域名、证书配置，还要担心服务挂掉、证书过期等等一系列的繁琐事务，于个人站点而言，免费服务也基本足够。

不管怎么说，愿笔耕不辍，对新网站的定位也是：

> A place to think and write.
>