前端项目发布流程中的自动化部署与常见坑点解析

为什么我要折腾这些发布流程？

去年我们团队从手动部署切换到自动化，折腾了三四种方案，踩了不少坑。说实话，一开始我以为“不就是 npm run build + scp 上传”嘛，结果线上环境一复杂，问题就来了：缓存没清、静态资源没打 hash、回滚慢得像蜗牛……后来我才发现，前端发布流程这事，真不是“能跑就行”，选对方案能省下大把半夜救火的时间。

今天我就对比下三种主流方案：传统手动部署、基于 Git 的 CI/CD（比如 GitHub Actions）、以及用 Vercel/Netlify 这类平台。不讲理论，只说实战体验——哪个让我睡得更香，哪个让我想砸键盘。

手动部署：简单但容易翻车

最原始的方案，就是本地 build 完，用 FTP 或 scp 上传到服务器。我早期项目都这么干，代码长这样：

npm run build
scp -r dist/* user@server:/var/www/html/

优点？确实快，改个文案，两分钟上线。但问题也多：

• 本地环境和线上环境不一致，build 出来的东西可能跑不起来（比如 Node 版本不同）
• 没有版本记录，回滚只能靠“上次打包的文件夹还在不在”
• 多人协作时，A 刚传完，B 又覆盖了，互相覆盖是家常便饭

我有一次在客户演示前 10 分钟发现样式错乱，查了半天发现是本地 node_modules 被污染了，build 出来的 CSS 压缩错了。从那以后，我再也不敢在重要项目上用手动部署了。

GitHub Actions：灵活但配置头疼

现在大多数开源项目都用 GitHub Actions，我也在几个私有项目里试过。核心思路是：push 代码 → 自动 build → 自动 deploy。一个典型的 workflow 配置如下：

name: Deploy to Server
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '18'
      - run: npm ci
      - run: npm run build
      - name: Deploy via rsync
        uses: burnett01/rsync-deployments@v1.2
        with:
          switches: -avzr --delete
          path: dist/
          remote_path: /var/www/html/
          remote_host: ${{ secrets.HOST }}
          remote_user: ${{ secrets.USER }}
          remote_key: ${{ secrets.SSH_KEY }}

这套方案最大的优势是可控：你可以在 build 前跑测试、打 tag、通知 Slack、甚至自动压缩图片。而且所有操作都有日志，谁改了什么、什么时候失败，一目了然。

但缺点也很明显：配置太繁琐。光是配 SSH 密钥、权限、路径，就能折腾半天。有一次我因为 remote_path 少了个斜杠，导致整个网站被删空（rsync 的 –delete 参数真狠）。还有一次，CI 环境里的 Node 版本和本地不一致，build 出来的 bundle 体积大了 30%，首屏加载直接崩了。

不过，如果你有运维能力，或者团队有 DevOps 支持，这套方案长期来看是最稳的。我现在的中后台项目基本都走这个流程，虽然初期配置痛苦，但后期维护成本低。

Vercel/Netlify：开箱即用，但别被“免费”迷惑

最近两年，我越来越喜欢用 Vercel 或 Netlify。特别是做个人项目、原型验证，简直爽到飞起。你只要连上 GitHub 仓库，它自动检测框架（Next.js、Vue、Svelte 都支持），自动 build，自动部署，还自带 CDN 和 HTTPS。配置？几乎为零。

比如一个 Next.js 项目，连 vercel.json 都不用写，push 代码就上线。回滚？点一下 UI 就切回上一个版本。预览部署？每个 PR 自动生成一个临时链接，产品可以直接点开看效果。这体验，手动部署和 CI 配置党看了会流泪。

但这里有个大坑：免费版有构建时间限制、带宽限制，而且自定义域名要绑信用卡（虽然不收费，但心理门槛高）。更重要的是，一旦你用了它们的高级功能（比如边缘函数、重写规则），迁移成本就很高。我之前有个项目想从 Vercel 迁到自建服务器，光是处理 rewrites 和 redirects 就花了两天。

所以我的建议是：**小项目、快速验证、个人博客，闭眼用 Vercel；但如果是企业级应用、需要深度定制或合规要求高的，别图省事，还是自己搭 CI 稳妥**。

我的选型逻辑：看场景，别死磕

我现在选发布流程，基本按这个逻辑：

• 内部工具、管理后台：用 GitHub Actions + 自建服务器。安全可控，还能和公司内网打通。
• 对外展示型网站、营销页、个人作品集：直接上 Vercel。省下的时间够我多喝两杯咖啡。
• 紧急修复、临时演示：偶尔还是会手动 scp，但仅限于非生产环境，且必须加注释“临时方案，勿长期使用”。

另外，不管用哪种方案，我都会强制加两个东西：

1. 静态资源加 hash：避免浏览器缓存旧文件。比如 Webpack 的 [contenthash]，Vite 的 ?v=xxx。
2. 部署后自动清 CDN 缓存：如果用了 CDN，记得在 deploy 步骤里调用刷新 API。比如 Cloudflare 的 API：

// deploy 后调用
fetch('https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ purge_everything: true })
})

别小看这一步，我见过太多人上线后用户反馈“怎么还是旧页面”，结果发现是 CDN 缓存没清。

最后说点实在的

其实没有完美的方案。Vercel 虽然省事，但你把命脉交给了第三方；GitHub Actions 虽然灵活，但配置成本高；手动部署？除非你项目永远只有一个人维护，否则迟早出事。

我现在的策略是：核心业务用自建 CI，边缘项目用托管平台。两者并存，各取所需。毕竟，前端工程师的时间，不该浪费在重复部署上。

以上是我踩坑后的总结，有更优的实现方式欢迎评论区交流。如果你也在纠结发布流程，不妨先问自己：这项目未来三个月会有人频繁改吗？要不要回滚？有没有合规要求？答案出来了，方案自然就清晰了。