我第一个正经博客是 Hexo 搭的。
那时候觉得这就对了:Markdown 写好,hexo g 一把,丢到 GitHub Pages,主题换一换,域名绑上,就算有个像样的个人站了。周末改改 _config.yml,调调侧边栏,还挺有成就感。写文章反而成了顺手的事——毕竟生成静态页这件事,Hexo 已经替你干完了。
后来写着写着,开始不满足了。
我想要后台发文章,想要评论、搜索、访问量统计,想要「像正经产品一样」能登录、能改配置。于是很自然地从「静态博客」滑进了前后端项目:自己写 API、接数据库、做部署脚本,Nginx、HTTPS、PM2、Docker……一套一套往上叠。每次 push 之前心里都会紧一下:这次构建会不会挂?环境变量有没有漏?服务器磁盘又快满了吧。
说实话,那几年并不全是浪费。至少我搞清楚了请求怎么从浏览器走到 Node,也知道了个人项目上线到底卡在哪几个环节。但对一个主要用来写字、偶尔贴点作品链接的站点来说,维护成本明显偏高了。有时候半个月没更新,登录服务器一看,还有安全补丁要装——那一刻会问自己:我到底是来博客的,还是来当运维的?
中间也换过几套方案,CMS、自建后台、各种「博客 + 后台」模板都试过。每次换完头两周很爽,过两个月又回到老问题:依赖多了、迁移难了、本地起一套环境要半天。
现在这个站,算是绕了一大圈又回到「简单」,但和当年 Hexo 又不完全一样。
文章还是 Markdown,放在 content/posts/ 里,和图片一起进 Git。图片走 public/content/,正文里直接写路径就行,比如下面这张:
构建交给 Next.js,部署侧尽量往「无服务器 / 静态托管」靠——不用我半夜起来重启进程,也不用为了一台小 VPS 单独操心备份策略。需要改样式、改页面结构,就在这个仓库里改;要发文,就新开一个 .md 文件,和图片放在对应目录,提交,等构建完事。
写新文章大概就是这样:
content/posts/某篇文章.md
public/content/posts/某篇文章/配图.jpg
正文里引用:

没有 Redis,没有单独的同步服务,没有「内容在 A 系统、展示在 B 系统」那种分裂感。对我这种更新频率不算高的博客来说,这就够了。
当然,这不是说 Hexo 不好,也不是说前后端项目没意义。只是我个人的阶段变了:以前享受折腾部署和架构,现在更想把力气花在写清楚一件事上。如果哪天文章量真的上来了,或者要做更重的互动,再往上加东西也不迟——但至少底座不必一开始就扛那么重。
这篇就当新站的开工说明吧。后面会在这里记技术笔记、项目复盘,还有一些一时半会儿说不清、但想先丢出来的想法。你要是也在纠结「个人博客到底该有多复杂」,希望我的这条弯路能少让你走一点。