多阶段构建通过分离构建与运行阶段显著减小镜像体积并提升安全性：构建阶段用完整Node镜像安装依赖并编译代码，运行阶段仅复制生产所需文件至轻量Alpine镜像，避免源码、构建工具和devDependencies混入。
直接用多阶段构建，核心是把“装依赖、编译代码”和“运行服务”拆成两个独立阶段，只把真正需要的文件复制过去，镜像就能小很多、更干净、也更安全。
第一步：明确两个阶段分工
构建阶段（builder）负责准备一切开发所需——装所有依赖（包括 devDependencies）、复制源码、执行构建命令（比如 yarn build 或 npm run build）。这个阶段可以用功能完整的镜像，比如 node:18 或 node:18-slim。
运行阶段（runtime）只保留最小必要环境——轻量基础镜像（推荐 node:18-alpine）、生产依赖、编译后的产物（如 dist/ 或 build/），不带源码、不带构建工具、不带测试文件。
第二步：写一个典型的双阶段 Dockerfile
以下是一个适用于 TypeScript + Express 项目的精简写法：
-
构建阶段：复制
package.json和锁文件 → 安装全部依赖 → 复制源码 → 执行npm run build -
运行阶段：基于
node:18-alpine→ 创建非 root 用户 → 只复制package.json、node_modules（来自 builder）、dist/→ 设置用户权限 → 暴露端口 → 启动
关键点：COPY --from=builder 是跨阶段复制的核心语法，只拿你需要的，其余全丢掉。
第三步：注意几个易错细节
Alpine 镜像用的是 musl libc，如果项目用了 node-gyp 编译的原生模块（比如 bcrypt、sqlite3），可能报错。遇到这种情况，可以：
- 改用
node:18-slim替代 Alpine，体积稍大但兼容性好 - 在 builder 阶段用 Alpine + 构建工具链（如
apk add python3 make g++），再把编译好的模块复制过去 - 确认
devDependencies不会打进最终镜像——多阶段天然隔离，只要不在 runtime 阶段重新npm install就不会混入
第四步：验证效果是否到位
构建完后用 docker images 对比大小；用 docker history <image> 查看层数和每层内容；还可以 docker run -it <image> sh 进去检查有没有多余文件（比如 src/、node_modules/.bin 里的 webpack 等）。
正常情况下，镜像体积能从 500MB+ 压到 100MB 左右，启动更快、漏洞更少、推送更省带宽。
