选 Hexo 而不是 Next.js / Astro 的三个理由

一、构建速度对一篇文章的博客没有意义

Astro 的 island、Next.js 的 RSC、SvelteKit 的 SSR——
这些机制为了解决”几千个组件 + 几十万 PV”的问题而生。
个人博客有 10 篇文章、PV 一天 50。

Hexo 一次 hexo generate 不到 2 秒，产出纯 HTML，
丢到 Nginx 后端 0 运行时开销。这才是这个体量该有的工具。

Hexo 2014 年出来到现在 12 年，主版本 1→8，
API 几乎没破坏式变更，老插件能装、老主题能跑。

而我两年前用 Astro 写的 starter，现在跑起来要改 Vite 配置、改 integration、
还有 deprecate 的 import 路径。这不是 Astro 的问题，是新框架的宿命。

无论用什么 SSG，最终都是 Markdown 进、HTML 出。
那么”中间那一层”越透明越好。Hexo 的 _posts/*.md 是平的、无嵌套的、
front-matter 可读的——意味着我未来换工具时 cp -r 就能迁走。

Next.js 把内容塞到 MDX 里，Astro 把内容塞到组件里，
都是把”内容”和”渲染”绑死的反模式。