GitHub Pages vs Vercel：个人博客部署怎么选

个人博客选部署平台，最容易陷入“哪个更现代”的比较。但真正影响长期维护体验的，不是平台名，而是你的博客到底是什么：纯内容站、作品集入口、前端应用，还是未来会接 CMS、评论、搜索、AI 服务的个人品牌站。

如果博客的核心目标是长期写作、稳定访问和低维护成本，GitHub Pages 仍然是足够可靠的选择。它的心智模型很简单：仓库里的静态文件就是站点本身，构建产物推上去，页面就能访问。

Vercel 则更像现代前端应用平台。它擅长 Preview Deployment、环境变量、Serverless、Edge、回滚和监控。如果博客未来要接 CMS、搜索服务、AI 功能、会员系统或作品集应用入口，Vercel 的上限更高。

GitHub Pages 与 Vercel 部署路径对比

先定义问题：博客是内容站还是应用站

一个纯内容站的核心资产是 Markdown、图片、RSS、sitemap 和稳定 URL。它需要的能力是：

构建稳定。
文章 URL 长期不变。
图片不破。
RSS 和 sitemap 可访问。
发布流程可回滚。
不依赖复杂后端。

一个应用站的核心资产则不只是内容，还包括用户交互、登录状态、服务端接口、数据存储、预览环境和监控。它需要的能力是：

每个 PR 有预览。
环境变量分环境管理。
能跑 Serverless API 或 SSR。
能接数据库、队列、对象存储。
能观察性能和错误。

如果没有先区分这两类需求，平台选择就会变成偏好争论。

核心差异

维度	GitHub Pages	Vercel
定位	静态网站托管	前端应用部署平台
默认域名	`username.github.io`	`project.vercel.app`
构建方式	可本地构建后提交，也可用 Actions	Git 推送后自动构建
Preview	需要自行配置	分支和 PR 自动生成
服务端能力	无	Serverless / Edge / SSR
回滚	依赖 Git 历史	Dashboard 一键回滚
适合内容	博客、文档、作品集静态页	现代前端应用、混合动态站点

GitHub Pages 的优势是简单。它没有太多平台概念，也没有复杂的运行时。你只要保证构建产物正确，站点就可访问。

Vercel 的优势是工程化体验。它把前端应用常见的构建、预览、发布、回滚、环境变量和运行时能力都整合在一起。

什么时候选 GitHub Pages

下面这些情况，GitHub Pages 更合适：

博客只需要静态页面、RSS、sitemap 和少量前端交互。
你希望保留 username.github.io 这类长期公开 URL。
发布链路希望尽量透明，构建产物可以直接审查。
不需要服务端函数、数据库、鉴权和复杂环境变量。
你能接受手动或脚本化同步 dist 到发布仓。

对于个人技术博客来说，GitHub Pages 的优势不是功能多，而是简单、稳定、可回滚。源码仓和发布仓分开以后，本地构建、同步 dist、审查 diff、再推送发布仓，这条链路很容易掌控。

当前博客就是这个模式：

Blog-astro 源码工程
  -> npm run build
  -> dist/
  -> sync-to-pages.mjs
  -> D:\Project\Local\Blog 发布仓
  -> git push origin main
  -> https://shiaoming123.github.io/

这样做的好处是：发布仓仍然保持原来的 GitHub Pages 静态发布机制，不需要引入新的 Pages Actions 发布模式，也不会让源码和生成产物混在一起。

什么时候选 Vercel

下面这些情况，Vercel 更合适：

博客同时承担作品集、简历、项目入口或产品首页。
每次改 UI 都希望有 Preview URL 方便检查。
后续可能接 Notion、CMS、数据库、搜索服务或 AI 功能。
需要 Serverless API、Edge Function 或 SSR。
希望团队协作时每个分支都有预览环境。

Vercel 的优势在于开发体验。你推一个分支，它会给一个预览地址；合并主分支，它会发布生产环境；出问题时，可以在控制台里快速回滚。

但这也意味着平台心智更重。对于一个纯静态博客，Vercel 的能力可能会超过当前需求。

迁移时最容易出错的点

路径和 base

GitHub Pages 用户站点通常是根路径：

https://username.github.io/

项目站点则可能是：

https://username.github.io/repo-name/

如果从 GitHub Pages 迁移到 Vercel，或从 Hexo 迁移到 Astro，需要检查：

site 是否是最终公开域名。
框架的 base 是否为空或正确。
图片是否使用站点根路径。
文章 slug 是否保持稳定。
RSS、sitemap、搜索索引是否仍然生成。

图片最容易因为绝对路径、相对路径或图床失效而破。旧博客这次迁移里，PicGo raw 图片公网返回 404，就是一个典型例子。

构建输出目录

不同框架的输出目录不同：

框架	输出目录
Astro	`dist`
Vite	`dist`
Next.js 静态导出	`out`
Hugo	`public`
Hexo	`public`

如果继续使用 GitHub Pages 发布仓，发布仓里应该只放构建产物，不要在发布仓里直接维护 Markdown。

RSS 和 sitemap

博客不是只有首页能打开就算部署成功。至少要确认：

/rss.xml 或 /atom.xml
/sitemap.xml
/search.xml
/posts/<slug>/
/archives/YYYY/MM/
/tags/
/categories/

这些 URL 对搜索引擎、订阅工具和旧链接都很重要。

我的选择

当前博客更适合继续采用 GitHub Pages：源码用 Astro 维护，发布仓保持 Shiaoming123.github.io 的静态托管方式。这样既能获得 Markdown 内容模型、主题系统和构建校验，又不改变原有公开 URL 与发布习惯。

换句话说，技术栈可以升级，但发布契约不必动。对一个个人博客来说，这是更稳的选择。