教程 / 发布与基础设施 / 重新部署网站
📝 文字 ● 初级 更新于 2026-05-13

重新部署网站

将代码变更推送到线上站点。在现代 PaaS 平台上,重新部署通常只需要 git push — 托管平台会监听你的分支并自动触发重建。以下是各主流平台的重新部署命令与生效时间。

Vercel — 文档 ↗

1

如果仓库已连接,直接推送即可。

git push origin main

Vercel 检测到推送后会自动构建并部署。

或通过 CLI(vercel CLI ↗):

vercel --prod

耗时:典型的 Next.js / 静态站点约需 30 秒至 3 分钟。

Netlify — 文档 ↗

2

推送到已连接的分支:

git push origin main

或通过 CLI:

netlify deploy --prod

耗时:1 至 3 分钟。

Cloudflare Pages — 文档 ↗

3

推送到已连接的分支:

git push origin main

或通过 Wrangler(Wrangler 文档 ↗):

npx wrangler pages deploy ./dist --project-name=my-site

耗时:1 至 2 分钟。

Render — 我们的教程 · 文档 ↗

4

推送到已连接的分支:

git push origin main

或从控制台手动触发:Manual Deploy → Deploy latest commit

耗时:2 至 5 分钟(Render 需要重建容器)。

Railway — 我们的教程 · 文档 ↗

5

推送到已连接的分支:

git push origin main

或从控制台触发:进入服务 → Deployments → Redeploy

耗时:30 秒至 2 分钟。

Fly.io — 我们的教程 · 文档 ↗

6

Fly 以 CLI 为主(默认不自动检测 git 推送):

fly deploy

此命令会重建镜像并滚动更新各 Machine。耗时:每个区域约 1 至 3 分钟。

GitHub Pages — 文档 ↗

7

推送到 GitHub Pages 所服务的分支(通常是 gh-pagesmain):

git push origin main

耗时:30 秒至 10 分钟。繁忙时段 GitHub Pages 可能较慢。

自托管(Linux VPS)

8

如果你使用自己的服务器,请参阅重新部署自托管服务器 — 流程有所不同(git pull + 重启服务)。

实时查看部署进度。 各 PaaS 平台均在控制台提供实时构建日志。Vercel、Netlify、Cloudflare 还会在构建过程中生成每次部署的预览 URL,便于在正式 URL 切换前进行测试。
构建失败时,上一次成功的部署仍会保持在线。 现代托管平台只有在新构建成功后才会切换流量。一次错误提交不会导致站点下线,但控制台会显示"Failed",直到你推送修复为止。优先检查构建日志——错误通常是缺少环境变量或本地忽略的 TypeScript 错误。

缓存刷新

9

部署已上线,但本地缓存了旧版 CSS/JS 的用户在缓存过期前看不到变更。有两种解决方案:

  • 带哈希的资源文件名(大多数框架默认开启)— 每次构建生成如 main.a1b2c3.js 这样的文件名,浏览器会自动加载新版本。
  • CDN 清除 — 若站点使用了 Cloudflare,静态资源缓存可能需要手动清除。操作路径:Cloudflare 控制台 → Caching → Purge。

下一步