Vue 3 项目在开发阶段依赖 Node.js 环境，而生产环境往往只需要一份静态资源和一层 Web 服务器。如何把这两者统一到一个可复制、可审计的交付单元里，容器化是目前最主流的答案。但许多团队只是简单执行一下 docker build，镜像能跑就万事大吉，很少去审视镜像内部的权限、依赖和网络暴露面。这篇文章就从工程化和安全两个维度，聊聊 Vue 3 项目容器的正确打开方式。
一、Vue 3 工程化容器的基本形态
Vue 3 项目通常由 Vite 或 Webpack 构建，产出 dist 目录下的静态文件。容器化时推荐采用多阶段构建：第一阶段用 Node 镜像执行 npm ci 和构建命令，第二阶段用 Nginx 或其他轻量 Web 服务器托管产物。这样做的好处是最终的运行镜像里完全没有 node_modules、源码和构建工具，体积从上千 MB 缩减到几十 MB，攻击面也随之大幅缩小。
下面是一份典型的多阶段 Dockerfile，构建阶段锁定依赖版本，运行阶段只保留静态资源和 Nginx 配置：
# 第一阶段：构建 FROM node:20-alpine AS builder WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci COPY . . RUN npm run build # 第二阶段：运行 FROM nginx:1.27-alpine COPY --from=builder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80
这份配置里有两个容易被忽略的细节值得展开。第一，npm ci 严格按照 lock 文件安装，比 npm install 更可复现，也避免了依赖被悄悄升级带来的供应链风险。第二，构建阶段用完即丢弃，最终镜像中不存在 Node 运行时，即使 Node 生态爆出漏洞，也不会波及线上容器。工程化的本质就是把「我机器上能跑」变成「任何机器上都能以同样方式跑」，多阶段构建恰好体现了这一点。
二、容器安全的四个关键动作
镜像体积小不等于安全。Vue 项目的容器虽然不执行业务逻辑，但 Nginx 本身、基础镜像层、以及暴露的端口都是潜在风险点。实践中有四个动作建议每一条流水线都做。
第一是镜像选型。优先选择 alpine 或 slim 这类精简变体，并固定具体版本号而不是用 latest。latest 标签的内容会随官方更新而变化，今天构建和明天构建可能拿到不同的层，既不可审计，也可能引入未知漏洞。
第二是以非 root 用户运行。默认情况下容器内 Nginx 以 root 启动 master 进程，一旦被攻破，攻击者拿到的是 root 权限。可以在镜像里创建普通用户并调整目录归属：
FROM nginx:1.27-alpine
RUN addgroup -S web && adduser -S web -G web \
&& chown -R web:web /usr/share/nginx/html \
&& chown -R web:web /var/cache/nginx \
&& chown -R web:web /var/run
USER web
COPY --from=builder /app/dist /usr/share/nginx/html
第三是依赖与镜像扫描。在 CI 中接入 trivy 或 docker scout，每次构建都对最终镜像做漏洞扫描，发现高危 CVE 直接阻断流水线。扫描对象不仅是 node_modules（构建阶段），更要覆盖最终镜像的系统包，比如 Alpine 的 musl 和 openssl。第四是最小化网络暴露。前端容器只需要对外开 80 或 443，内部健康检查端口不要映射到宿主机，避免被外网直接探测。
三、运行时加固与 Nginx 配置细节
容器安全不只是构建期的事，运行时的加固同样重要。Kubernetes 或 Docker 部署时，建议加上只读文件系统、禁止特权模式、限制 CPU 与内存资源，这样即使 Nginx 被注入恶意文件写入，也会因为文件系统只读而失败。同时通过 security_opt 中的 no-new-privileges 阻止进程提权。
Nginx 配置层面，Vue 是单页应用，路由刷新需要 history 回退，此外还应加上基础的安全响应头。一份兼顾功能与安全的配置如下：
server {
listen 80;
server_name _;
root /usr/share/nginx/html;
# 安全响应头
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
add_header Referrer-Policy strict-origin-when-cross-origin;
# 静态资源长缓存
location ~* \.(js|css|png|jpg|svg|woff2)$ {
expires 30d;
add_header Cache-Control "public, immutable";
}
# Vue Router history 模式回退
location / {
try_files $uri $uri/ /index.html;
}
}
这套配置解决了三个问题：构建产物文件名带哈希可以放心设置长缓存；try_files 保证任意路由都回退到 index.html，由前端路由接管；安全头则缓解了点击劫持、MIME 嗅探等常见前端攻击。如果站点是纯 HTTPS 部署，还可以补充 Strict-Transport-Security 和 Content-Security-Policy，进一步收紧资源加载范围。
四、把安全固化进流水线
单次做对不难，难的是每次都做对。建议把上述实践固化成 CI 阶段：构建前校验 lock 文件一致性，构建中执行多阶段 Dockerfile，构建后运行镜像扫描，最后对通过校验的镜像做签名并推送仓库。以 GitLab CI 为例，大致流程如下：
stages:
- build
- scan
build-image:
stage: build
script:
- docker build -t registry.ipipp.com/web/vue3-app:$CI_COMMIT_SHORT_SHA .
after_script:
- docker rmi registry.ipipp.com/web/vue3-app:$CI_COMMIT_SHORT_SHA || true
scan-image:
stage: scan
script:
- trivy image --exit-code 1 --severity HIGH,CRITICAL registry.ipipp.com/web/vue3-app:$CI_COMMIT_SHORT_SHA
扫描失败即退出，可以防止带漏洞的镜像流入生产。对合规要求较高的团队，还可以加一层镜像签名验证，部署侧只允许运行被信任密钥签过的镜像。总结来说，Vue 3 的容器化不只是写一个 Dockerfile：镜像选型、非 root 运行、漏洞扫描、响应头加固、流水线卡点，环环相扣才能形成真正可靠的工程化交付体系。