一、为什么前端也应该会 Docker

前端项目最常见的问题不是“代码不会写”，而是：

  • 本地能跑，测试环境跑不起来
  • 服务器缺依赖，发布临时补环境
  • 多项目 Node 版本冲突
  • 回滚需要重新打包，操作慢

Docker 的核心价值是把“应用 + 依赖 + 运行环境”打包成一个镜像，让你做到一次构建，到处运行。

二、先记住这 3 个概念

  1. 镜像（Image）：应用运行模板，包含代码和依赖
  2. 容器（Container）：镜像启动后的运行实例
  3. 仓库（Registry）：存储镜像的地方（如 Docker Hub、企业私库）

三、前端项目最常见的 3 种容器化方式

1) SPA 静态站点（React/Vue）

推荐方案：多阶段构建 + Nginx 托管 dist

1
2
3
4
5
6
7
8
9
10
11
12
13
# 构建阶段
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# 运行阶段
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

2) SSR 项目（Next/Nuxt）

推荐方案：Node 运行时镜像，直接启动服务进程。
重点是固定 Node 版本，避免环境漂移。

3) BFF 服务（Express/Koa）

推荐方案：Node 镜像运行 API 服务，配合反向代理。
多个服务可独立镜像，避免依赖冲突。

四、最小可用发布流程

  1. 本地构建镜像
  2. 打 tag（例如 v1.0.0）
  3. 推送到镜像仓库
  4. 服务器拉取镜像并启动容器
  5. 反向代理到容器端口

这样做的好处是：发布和回滚都基于镜像标签，不依赖“临时手工操作”。

五、回滚为什么会更快

传统回滚一般要：

  • 切回旧代码
  • 重新打包
  • 重新上传
  • 重启服务

Docker 回滚通常只需要：

  • 停止当前容器
  • 启动旧 tag 镜像

回滚步骤更短、风险更小。

六、前端团队落地 Docker 的建议顺序

  1. 先把 SPA 静态项目容器化
  2. 再把 SSR/BFF 分别镜像化
  3. 最后接入 CI/CD 自动构建与发布

先从最小改造开始，比一次性重构全部发布链路更稳。

七、结语

Docker 对前端最大的意义不是“更酷的技术栈”，而是把交付流程变得可复制、可回滚、可标准化。
当项目数量和协作人数增长后，这种稳定性会持续放大收益。