建站笔记 01：为什么用 Next.js + Cloudflare Workers 搭这个博客

起点：一份刊物，而不是一个项目

做技术博客最容易掉的坑，是把搭博客本身当成目的——折腾三个月框架，一篇文章没写。所以开工前我给自己定了条规矩：基础设施隐形，内容管线优先。

但隐形不等于随便。选型要解决三个真实问题：

1. 内容从哪来：我在 Obsidian 里写作，另有自动化管线产出研究报告，两者都要能一键发布
2. 读者在哪：国内海外都有，访问速度都得能看
3. 我能维护多久：业余时间有限，运维负担必须趋近于零

为什么是 Next.js

静态生成器（Hugo、Astro）确实是更省力的选择，最后选 Next.js 有三个理由：

• 文章页全量 SSG。所有文章在构建期渲染成静态 HTML，运行时只发文件。这是整个架构稳定性的基石——Workers 运行时没有完整的 Node API，把渲染全部前置到构建期，等于绕开了 90% 的兼容性问题
• MDX 是 Obsidian 的超集。双链、附件嵌入这些 Obsidian 语法，在构建时用 remark 插件统一转换，写作端零妥协
• 生态纵深。以后想加搜索、评论、Newsletter，React 生态都有成熟方案，不用换框架

为什么是 Cloudflare Workers

一句话：免费额度内的全球边缘网络。

方案	请求延迟	成本	运维
自托管 VPS	取决于机房位置	¥30-100/月	要管机器
Vercel	快	免费档有限制，国内访问不稳	零
Cloudflare Workers	全球边缘节点就近返回	10 万请求/日免费	零

Next.js 上 Workers 的桥是 OpenNext：它把 next build 的产物翻译成 Workers 兼容格式，wrangler deploy 一条命令上线。对全 SSG 的文章站来说，这条链路已经非常成熟。

内容管线：两条河汇入同一个目录

这是整个方案里我最满意的部分：

Obsidian 写作 ──────────┐
                        ├──▶ content/posts/*.mdx ──▶ git push ──▶ CI 构建部署
自动化研究报告 ─────────┘

content/ 目录本身就是一个 Obsidian Vault。写作就是编辑源码，发布就是 git push，中间没有"导出"这个动作。草稿默认 draft: true，改一个字段才上线，半成品永远不会误发。

下一步

骨架已经跑通，接下来是 OpenNext 适配和绑定 liigo.dev 域名。踩到的坑会陆续写进这个栏目——毕竟，维护过程本身就是内容。