Vercel + Hexo 建站：我如何用最小博客验证长期内容资产
我最早折腾 Hexo 和 Vercel，是从一个很朴素的念头开始的：我想有一个真正属于自己的内容入口。
不是平台主页，不是朋友圈，也不是某个会随着规则变化而失效的账号，而是一个可以绑定域名、可以自己备份、可以长期迁移的地方。
当时我选择 Hexo + Vercel，不是因为它最完美，而是因为它足够轻。
轻到我可以用一两天把整条链路跑起来：本地写 Markdown，GitHub 保存源码，Vercel 自动部署，域名指向站点，然后用浏览器打开自己的文章。
这件事在今天看起来很普通，但它对我很重要。
它让我第一次把“写文章”从平台行为，变成了资产行为。
我真正想验证的不是工具，而是闭环
很多建站教程会从安装命令开始。
我现在更愿意先问：这套工具帮我验证了什么闭环？
对我来说，Hexo + Vercel 验证的是四件事：
- 我能不能用 Markdown 持续写作；
- 我能不能把内容放在 GitHub 里长期保存；
- 我能不能用自动部署降低维护成本；
- 我能不能让独立域名成为个人 IP 的稳定入口。
如果这四件事跑通了，博客主题好不好看、插件多不多，反而是第二阶段的问题。
因为一个内容系统真正的难点，不是第一天把页面搭起来，而是第 100 篇文章还能不能低成本发布。
我会怎么搭第一版
如果今天重新用 Vercel + Hexo 验证一个博客，我会把流程压到最小。
第一步，只装必要环境。
我会准备 Node.js、Git 和一个代码编辑器。然后用 Hexo 初始化站点，先不急着挑主题，也不急着改复杂配置。
第二步，先让本地跑起来。
本地能预览，说明内容生成链路是通的。这个阶段只看一件事：写一篇最短文章，能不能变成一个可访问的页面。
第三步，把代码推到 GitHub。
GitHub 对我来说不只是代码仓库，也是内容资产仓库。文章、配置、主题改动都在这里留下历史。后面哪怕换部署平台，也不至于从零开始。
第四步，接入 Vercel。
Vercel 的价值在于自动部署。只要 GitHub 有更新，它就能重新构建并发布。这个体验会极大降低写作阻力。
第五步，绑定域名。
独立域名是我判断一个站点是否进入长期维护状态的分界线。没有域名时，它更像测试项目；绑定域名之后，它开始变成一个对外入口。
我会保留哪些边界
Hexo + Vercel 很适合验证，但我不会把它包装成所有人的最终方案。
它有几个边界：
- 内容多了之后，主题和插件维护会变复杂；
- 图片、搜索、评论、统计都需要额外方案；
- 非技术用户会被 Git 和构建流程挡住；
- 如果未来要做会员、支付、表单和后台，静态博客本身不够用。
所以我会把它放在“低成本验证”这一层。
第一阶段，我只关心能不能把文章稳定发布出去。第二阶段，才考虑 SEO、结构化数据、站内搜索、订阅和商业转化。
这个顺序很重要。
如果一开始就追求完整系统，很容易在写第一篇文章之前就耗尽热情。
从博客到个人商业系统
后来我对博客的理解变了。
它不只是一个展示文章的地方，而是个人商业系统里的内容资产层。
一篇文章可以承担很多作用：
- 记录我如何研究一个问题；
- 让陌生人通过搜索理解我的判断；
- 为产品、服务或项目提供信任入口；
- 把分散在社交平台上的表达沉淀到自己的阵地；
- 让过去的经验在未来继续产生价值。
所以我现在看 Hexo + Vercel，会把它当成一条入门路径，而不是一个终点。
它帮我理解：一个人也可以拥有自己的发布系统。
这个系统一开始可以很小。一个仓库，一个域名，一个部署平台，几篇文章，就足够开始。
我的结论
如果我要给过去的自己一张地图，我会这样拆：
- 先用 Hexo 写出第一篇文章。
- 再用 GitHub 保存内容和配置。
- 用 Vercel 自动部署，减少手工发布。
- 绑定域名，让内容有长期入口。
- 等文章和访问需求真实出现，再升级主题、搜索、评论和商业模块。
我不再把建站理解成“选择哪个框架”。
更本质地看，它是在搭一个个人内容资产的最小闭环。
工具会换，平台会换，但只要这个闭环跑起来，我就不再只是把内容交给别的平台分发，而是在为自己的长期系统添砖。
Loading...
