从 Hugo 到 Notion:又一次博客迁移

update(2026-08-24):这篇已经过时。博客后来又迁了一次——内容回到纯本地,Obsidian 写、git 管、Astro 构建,主题也重新设计了;下文说的那 17 篇旧文也再筛过一轮,只留了几篇。本文不代表现状,当历史记录看就好。

起因

说来也没什么特别的契机。今天突发奇想,就想把吃灰很久的博客重新捡起来。

这个博客自 2024 年起就彻底下线了,哪怕当时已经是静态部署,我也没再维护,直接关了。中间隔了差不多两三年,人在忙别的事,博客就一直搁着。直到今天,看到现在 AI 辅助写代码已经强到这个程度了,就想着 要不试试?

于是花了一整天,从零开始把整套博客重新搭了起来。

迁移路径

回顾一下这个博客的技术栈变迁:

最早是 Typecho,后来搬到了 Hugo。这次则是从 Hugo 再往前走了一步,彻底甩掉了框架。

现在的方案是:内容全部在 Notion 里写和管理,通过 Notion 官方 API 拉取数据库内容,再用 Python 脚本把它生成纯静态的 HTML 页面。没有用任何前端框架,JavaScript 也压到了最少,大概只有深色模式切换和代码块高亮用到了一点。

整个构建脚本基本都是靠 vibe coding 搞定的,AI 写代码确实快太多了。

旧文处理

既然重启,旧博文也得跟着整理。

但翻回去看以前写的东西,很多已经不太想再公开了,情绪化的表达太多,有些内容现在的我觉得不太适合继续摆在台面上。问题是,如果按这个标准筛,几乎一篇都选不出来。

最后折中的办法是用 GPT 把原文的大意做了一轮重构,去掉过度分享的部分,我再自己过一遍修改。写了几百篇,目前只迁了 17 篇过来,加上这篇算 18(也许以后会迁移更多进来,现在还不知道呢)

所以如果你觉得前面那些旧文读起来像是 AI 总结过的,那确实是经过了一轮重写。原文我就不放了。

为什么选 Vercel

部署平台纠结了一会儿。

Cloudflare 的 Pages 是老牌免费选项,但从国内访问我的域名基本都绕到美国去了,体验不太行。GitHub Pages 用的是 Fastly CDN,国内直连走日本边缘节点,速度还行,但构建额度只有每月 2000 分钟。

Vercel 这边构建额度更宽裕(6000 分钟),通过观察发现似乎国内访问的路由比较灵活,比 GitHub Pages 好点,移动走日本,联通走新加坡。另外一个考虑是,Notion 的图片本身就存在 AWS S3 上,我直接把图片源链接拉出来用了,相当于整套资源都在 AWS 体系内(一晚上过后我发现图片外链会过期,因为不是公开页面也没办法再用官方代理了,现在的方案是直接构建时候拉到本地吧)。既然如此,部署也放在 AWS 的基础设施上,链路更统一一些,要炸一起炸,就不依赖 Cloudflare 了

现状

折腾了一整天,目前站点已经能正常跑了。后面有空再慢慢补内容和细节。

以上。

from hugo to notion: another blog migration

machine-translated from the original

update (2026-08-24): this post is out of date. the blog has since moved again — content lives locally now, written in obsidian, managed with git, built with astro, on a redesigned theme; the 17 old posts mentioned below went through another cull as well, and only a few survived. what follows is history, not the current setup.

how it started

nothing special set it off. today i suddenly felt like picking the blog back up after it had been gathering dust for a long time.

the blog had been completely offline since 2024. even though it was already a static deployment by then, i stopped maintaining it and just shut it down. two or three years passed in between; i was busy with other things and the blog simply sat there. until today, when i saw how strong ai-assisted coding has become, and thought — why not try?

so i spent a whole day rebuilding the entire blog from scratch.

the migration path

a quick look back at how the stack has changed:

it started on typecho, then moved to hugo. this time it goes one step further than hugo and drops the framework entirely.

the setup now: all content is written and managed in notion, pulled through the official notion api, and turned into plain static html pages by a python script. no front-end framework, and javascript cut down to almost nothing — roughly just the dark-mode switch and code highlighting.

the build script was basically all vibe coding. ai really does write code much faster.

the old posts

since i was restarting anyway, the old posts had to be sorted out too.

but looking back at what i wrote before, a lot of it i no longer wanted to keep public. too much emotional writing; some of it the current me doesn’t think belongs on display anymore. the problem was that with that standard, almost nothing would have made the cut.

the compromise in the end was to have gpt reconstruct the gist of each post, cut the oversharing, and then go over it myself. out of a few hundred posts, only 17 made it over so far, 18 counting this one (maybe more later — who knows).

so if the old posts up there read like ai summaries, that’s because they went through a rewrite. i’m not putting the originals up.

why vercel

the hosting choice took a while.

cloudflare pages is the old free standby, but from inside china my domain mostly routed through the us, which wasn’t great. github pages uses fastly’s cdn, and direct connections from china hit the japan edge — decent speed, but only 2000 build minutes a month.

vercel has a more generous build allowance (6000 minutes), and from what i could see the routing from china seemed more flexible than github pages: china mobile goes through japan, china unicom through singapore. another consideration was that notion’s images are stored on aws s3 anyway, so i just pulled the source links straight out, which put the whole thing inside the aws ecosystem (a night later i found the image links expire, and since the pages aren’t public the official proxy can’t be used either — the current approach is to fetch them locally at build time). so the deployment might as well sit on aws infrastructure too, for a more unified chain, if it blows up it all blows up together, and no dependence on cloudflare.

where things stand

after a whole day of tinkering, the site is up and running. i’ll fill in content and details when i have time.

that’s all.