Docker多阶段构建：镜像体积砍半实战

问题：一个Laravel项目镜像1.2GB，部署要5分钟

去年我们团队接手一个PHP8.3+Laravel11的微服务项目，Docker镜像体积1.2GB。每次CI/CD构建要5分钟，部署到K8s拉镜像要3分钟。开发同学抱怨：改一行代码，等10分钟才能看到效果。

问题出在单阶段构建：所有依赖（composer、npm、编译工具）都打包进最终镜像。生产环境根本不需要这些。

方案对比：三种构建方式

我们测试了三种方案，环境：Docker 24.0.7，PHP 8.3.2，Laravel 11.0.0，MySQL 8.0.35，Node 20.11.0。

方案一：单阶段构建（原始方案）

FROM php:8.3-fpm
RUN apt-get update && apt-get install -y \
    git unzip libpq-dev libzip-dev \
    && docker-php-ext-install pdo_mysql zip
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
WORKDIR /var/www
COPY . .
RUN composer install --no-dev --optimize-autoloader
RUN npm install && npm run build
RUN chown -R www-data:www-data storage bootstrap/cache
EXPOSE 9000
CMD ["php-fpm"]

结果：镜像体积1.2GB，构建时间5分12秒。

方案二：多阶段构建（优化方案）

# 第一阶段：构建依赖
FROM php:8.3-fpm AS builder
RUN apt-get update && apt-get install -y \
    git unzip libpq-dev libzip-dev \
    && docker-php-ext-install pdo_mysql zip
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
WORKDIR /build
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader
COPY package.json package-lock.json ./
RUN npm install && npm run build
COPY . .
RUN php artisan optimize

# 第二阶段：运行环境
FROM php:8.3-fpm-alpine3.19
RUN apk add --no-cache libpq libzip
COPY --from=builder /usr/local/etc/php/conf.d/ /usr/local/etc/php/conf.d/
COPY --from=builder /build/vendor /var/www/vendor
COPY --from=builder /build/public/build /var/www/public/build
COPY --from=builder /build/storage /var/www/storage
COPY --from=builder /build/bootstrap /var/www/bootstrap
COPY --from=builder /build/config /var/www/config
COPY --from=builder /build/routes /var/www/routes
COPY --from=builder /build/app /var/www/app
COPY --from=builder /build/database /var/www/database
COPY --from=builder /build/resources /var/www/resources
COPY --from=builder /build/.env /var/www/.env
RUN chown -R www-data:www-data /var/www/storage /var/www/bootstrap/cache
EXPOSE 9000
CMD ["php-fpm"]

结果：镜像体积180MB，构建时间3分08秒。

方案三：极致优化（Alpine + 多阶段）

# 第一阶段：构建
FROM php:8.3-cli-alpine3.19 AS builder
RUN apk add --no-cache git unzip libpq-dev libzip-dev \
    && docker-php-ext-install pdo_mysql zip
COPY --from=composer:2.7.1 /usr/bin/composer /usr/bin/composer
WORKDIR /build
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader --no-scripts
COPY package.json package-lock.json ./
RUN npm ci --only=production && npm run build
COPY . .
RUN php artisan optimize

# 第二阶段：运行
FROM php:8.3-fpm-alpine3.19
RUN apk add --no-cache libpq libzip
COPY --from=builder /build/vendor /var/www/vendor
COPY --from=builder /build/public/build /var/www/public/build
COPY --from=builder /build/storage /var/www/storage
COPY --from=builder /build/bootstrap /var/www/bootstrap
COPY --from=builder /build/config /var/www/config
COPY --from=builder /build/routes /var/www/routes
COPY --from=builder /build/app /var/www/app
COPY --from=builder /build/database /var/www/database
COPY --from=builder /build/resources /var/www/resources
COPY --from=builder /build/.env /var/www/.env
RUN chown -R www-data:www-data /var/www/storage /var/www/bootstrap/cache
EXPOSE 9000
CMD ["php-fpm"]

结果：镜像体积150MB，构建时间2分45秒。

效果数据对比

指标	单阶段	多阶段	极致优化
镜像体积	1.2GB	180MB	150MB
构建时间	5分12秒	3分08秒	2分45秒
部署拉取时间	3分20秒	45秒	38秒
启动时间	12秒	8秒	7秒
安全漏洞数	47	12	8

数据来源：Docker 24.0.7内置扫描工具，Trivy 0.50.1。

原理：为什么多阶段构建能省体积

Docker镜像由多层组成，每层都是只读的。单阶段构建把所有文件塞进一层，包括编译工具、临时文件、缓存。多阶段构建只把最终需要的文件复制到新镜像，丢弃中间产物。

关键点：COPY --from=builder 只复制指定路径，不复制整个构建环境。Alpine基础镜像比Debian小5倍（5MB vs 120MB）。

避坑指南

坑1：composer install 卡在内存不足

现象：构建时composer报错"Allowed memory size exhausted"。原因：默认PHP内存限制128MB，Laravel依赖多。解决：在构建阶段设置 COMPOSER_MEMORY_LIMIT=-1。

ENV COMPOSER_MEMORY_LIMIT=-1
RUN composer install --no-dev --optimize-autoloader

坑2：npm ci 报错"EACCES: permission denied"

现象：npm ci 无法写入node_modules。原因：构建阶段以root运行，但npm缓存目录权限不对。解决：设置 npm config set cache /tmp/npm-cache。

RUN npm config set cache /tmp/npm-cache && npm ci --only=production

坑3：.env文件泄露

现象：镜像包含.env文件，包含数据库密码。原因：COPY . 复制了所有文件。解决：使用.dockerignore排除敏感文件。

# .dockerignore
.env
.git
.gitignore
node_modules
storage/logs/*
storage/framework/cache/data/*
storage/framework/sessions/*
storage/framework/views/*

坑4：Alpine缺少glibc导致扩展报错

现象：某些PHP扩展（如swoole）在Alpine上编译失败。原因：Alpine使用musl libc，与glibc不兼容。解决：使用Debian基础镜像，或安装兼容包。

FROM php:8.3-fpm-alpine3.19
RUN apk add --no-cache gnu-libiconv
ENV LD_PRELOAD /usr/lib/preloadable_libiconv.so

坑5：构建缓存导致镜像不一致

现象：两次构建结果不同，因为Docker缓存了层。原因：Docker利用缓存加速构建，但依赖变化时缓存失效。解决：合理组织Dockerfile，把变化少的层放前面。

# 先复制依赖文件，再复制源码
COPY composer.json composer.lock ./
RUN composer install
COPY . .  # 源码变化不影响前面层

完整CI/CD配置示例

使用GitLab CI，Docker 24.0.7，K8s 1.28。

# .gitlab-ci.yml
stages:
  - build
  - deploy

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: ""

build:
  stage: build
  image: docker:24.0.7
  services:
    - docker:24.0.7-dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  only:
    - main

deploy:
  stage: deploy
  image: bitnami/kubectl:1.28
  script:
    - kubectl set image deployment/laravel-app laravel-app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  only:
    - main

性能压测结果

使用wrk 4.2.0压测，参数：-t4 -c100 -d30s，测试Laravel首页。

方案	请求数	平均延迟	P99延迟	吞吐量
单阶段	12,450	32ms	89ms	415 req/s
多阶段	12,380	33ms	91ms	413 req/s
极致优化	12,420	32ms	88ms	414 req/s

结论：镜像体积优化不影响运行时性能，因为最终运行的应用代码相同。

总结

多阶段构建是Docker镜像优化的核心手段，配合Alpine基础镜像和.dockerignore，能把1.2GB降到150MB。关键点：分离构建和运行环境，只复制必要文件。避坑指南里的5个问题，我们团队都踩过，按方案解决即可。

下一步可以尝试：使用distroless基础镜像（Google提供，只有应用和运行时），体积能再降30%。但调试困难，生产环境慎用。