我第一个正经博客是 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 不好，也不是说前后端项目没意义。只是我个人的阶段变了：以前享受折腾部署和架构，现在更想把力气花在写清楚一件事上。如果哪天文章量真的上来了，或者要做更重的互动，再往上加东西也不迟——但至少底座不必一开始就扛那么重。
这篇就当新站的开工说明吧。后面会在这里记技术笔记、项目复盘，还有一些一时半会儿说不清、但想先丢出来的想法。你要是也在纠结「个人博客到底该有多复杂」，希望我的这条弯路能少让你走一点。