一、在说 Docker 之前，先看常见需求开发场景

先回答一个常见问题：前端项目是否一定需要安装 Node？

结论是：

  • 开发阶段通常需要 Node（构建、依赖管理、脚手架）
  • 生产阶段是否需要 Node，要看部署形态是 SPA、SSR 还是 BFF

除了一个非常简单的 hello world HTML 页面外，现代前端开发基本都会依赖 Node 和 npm/pnpm/yarn 工具链。

二、需求开发部署场景：到底要不要在服务器装 Node

1) 静态 SPA 单页面应用部署

对于 Vue/React 的静态 SPA，打包后是 dist 静态资源。

  • 本地开发：需要 Node（可能还要用 nvm 管多个版本）
  • 生产环境：通常不需要 Node
  • 服务端用 Nginx 托管静态文件并做路由回退即可

即使你本地有 node12 老项目和 node24 新项目，打包完成后丢到服务器，服务器依然可以不装 Node。

2) SSR 服务端渲染部署

SSR 需要在服务器执行 JavaScript（路由解析、服务端请求、拼接 HTML）。

所以：

  • 生产环境必须有 Node 运行时
  • 通常还会配合 Nginx 做反向代理

如果一台服务器上有多个 SSR 项目，且 Node 版本不一致（如 node12 和 node24），传统做法一般是：

  • 装 nvm 管理多版本 Node
  • 切到对应版本后启动项目
  • 用 pm2 管理进程

3) BFF 中间层部署

BFF（Backend For Frontend）本质是 Node 服务层。
常见实现是 Express / Koa，用于把后端通用接口封装成前端专属接口。

典型链路：

用户 -> 前端应用（PC/移动端/小程序） -> BFF -> 后端服务 -> 数据库

BFF 和 SSR 类似：

  • 需要 Node 运行时
  • 常配 Nginx
  • 多项目时常用 nvm + pm2

三、Web 前端常见三种部署方式（总结）

  1. SPA：dist + Nginx
  2. SSR/BFF：Node + nvm + pm2 + Nginx
  3. Docker 镜像：一次构建，到处运行（可覆盖上述场景，通常也会配 Nginx）

接下来重点看第 3 种：Docker 镜像部署的价值。

四、Docker 镜像部署前端项目的好处

1) 彻底解决环境一致性，减少 nvm 切换成本

可以把 Docker 镜像理解为：
一个依赖宿主机内核、相互隔离、可独立运行服务的轻量运行环境（不是传统虚拟机）。

如果有多个 SSR/BFF 项目且 Node 版本不同：

  • 有几个项目，就构建几个镜像
  • 每个镜像内固定自己的 Node 版本和依赖
  • 镜像之间互不干扰

这样就不用频繁在服务器上手动切 Node 版本。

2) 一次构建，各环境可直接运行

同一个镜像可以在本地、测试、生产、云端运行。
当生产机器故障，需要迁移时，传统方式要重装环境；而 Docker 方式通常只需拉镜像并启动容器，恢复更快。

3) 版本管理与回滚更简单

Docker 镜像自带 tag（如 v1.0.0、v1.0.1）：

  • tag 与代码版本可一一对应
  • 出现问题时可快速切换到旧 tag
  • 回滚操作通常是停止当前容器并重启旧版本容器

对线上故障处理非常友好。

4) 部署流程标准化、自动化

传统部署常见流程：

本地打包 -> 上传服务器 -> 手动改 Nginx/手动启服务

步骤多且依赖人工，存在人为失误风险。
如果接入 CI/CD（如 GitLab CI、GitHub Actions、Jenkins）可以做到：

代码提交 -> 自动构建镜像 -> 自动推送镜像仓库 -> 服务器自动拉取并重启容器

部署更稳定、效率更高、可审计性更好。

五、最后建议

如果你们当前只是简单 SPA，且暂时没有 CI/CD，也可以先从脚本化发布开始（例如一键打包 + 上传 + 重启），逐步过渡到容器化和自动化。
如果项目进入 SSR/BFF、多服务、多环境协作阶段，Docker 基本是收益非常明显的选择。