Docker镜像瘦身实战：从臃肿到精炼的工程化优化指南

你是否曾为Docker镜像的体积过大而烦恼？一个简单的Java应用镜像动辄500MB以上，不仅拖慢CI/CD流水线速度，还占用大量存储空间和网络带宽。在微服务架构盛行的今天，镜像体积直接影响着部署效率和资源成本。我曾在一次生产环境迁移中，面对数十个臃肿的镜像，深刻体会到优化的重要性——通过系统性的瘦身策略，我们成功将平均镜像体积缩减了85%，构建时间缩短了60%。

这篇文章将带你深入Docker镜像优化的核心领域，从基础概念到高级技巧，通过真实的Java和Node.js项目案例，展示如何将镜像从500MB压缩到50MB甚至更小。无论你是追求CI/CD效率的工程团队，还是希望提升容器化应用性能的开发者，这些实战经验都将为你提供可落地的解决方案。

1. 理解Docker镜像的“肥胖”根源

在开始优化之前，我们需要理解Docker镜像为什么会变得臃肿。镜像本质上是一个分层的文件系统，每一层都记录了文件系统的变化。这种分层设计虽然带来了缓存和复用的优势，但也容易导致“层污染”——不必要的文件被永久保留在镜像中。

1.1 镜像层结构与存储机制

Docker镜像采用联合文件系统（UnionFS）技术，将多个只读层叠加在一起，最上层是可写层。每个RUN、COPY、ADD指令都会创建一个新的层。理解这一点至关重要，因为优化镜像的关键就在于减少层数和控制每层的内容。

# 糟糕的示例：每个RUN都创建新层，留下中间文件
RUN apt-get update
RUN apt-get install -y build-essential
RUN apt-get install -y python3
RUN rm -rf /var/lib/apt/lists/*

上面的写法创建了4个层，即使最后删除了apt缓存，这些删除操作只影响最后一层，之前的层仍然包含完整的安装文件。

1.2 常见“肥胖”原因分析

根据我的经验，镜像臃肿通常源于以下几个问题：

问题类型	典型表现	影响程度
基础镜像过大	使用完整的Ubuntu/CentOS	高
构建依赖残留	编译工具链留在运行时镜像	高
不必要的文件	日志、缓存、临时文件	中
重复依赖	多个层安装相同包	中
未优化的层顺序	频繁变动的层在前	低

注意：镜像体积不仅影响存储，还直接影响拉取时间和启动速度。在Kubernetes集群中，大镜像会导致节点调度延迟和网络带宽压力。

2. 基础镜像选择：瘦身的起点

选择合适的基础镜像是优化的第一步。不同的基础镜像体积差异巨大，直接影响最终镜像大小。

2.1 主流基础镜像对比

让我们通过实际数据来比较几种常见的基础镜像：

# 查看不同基础镜像的大小
docker images --filter "reference=*:latest" --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}"

典型的基础镜像体积对比：

镜像名称	标签	大小	适用场景
ubuntu	latest	77MB	通用Linux环境
debian	latest	124MB	稳定、完整的Debian
alpine	latest	5.6MB	最小化Linux发行版
distroless	static	2.5MB	仅运行时环境
scratch	-	0MB	完全空镜像

2.2 Alpine：轻量级但需谨慎

Alpine Linux以其极小的体积（约5MB）而闻名，使用musl libc而非glibc。虽然体积小，但在使用中需要注意：

# 使用Alpine基础镜像
FROM alpine:3.18

# 安装必要的包（Alpine使用apk而非apt）
RUN apk add --no-cache \
    nodejs \
    npm \
    && rm -rf /var/cache/apk/*

Alpine的优缺点：

• 优点：体积极小，安全性高（最小化攻击面）
• 缺点：musl libc可能与某些二进制文件不兼容，包管理器生态相对较小

我在一个Node.js项目中使用Alpine，将镜像从300MB缩减到45MB，但遇到了一个C++原生模块的兼容性问题。解决方案是使用node:16-alpine而不是纯Alpine加手动安装Node.js。

2.3 Distroless：Google的极致优化

Distroless镜像是Google推出的特殊镜像，只包含应用程序及其运行时依赖，不包含包管理器、shell或其他程序。

# 使用Distroless作为最终镜像
FROM gcr.io/distroless/java17-debian11

# 复制应用程序
COPY target/myapp.jar /app/myapp.jar

# 直接运行Java应用
CMD ["/app/myapp.jar"]

Distroless的特点：

• 零shell访问：无法docker exec进入容器，提升安全性
• 最小依赖：只包含绝对必要的文件
• 自动更新：基础镜像由Google维护并定期更新

提示：调试Distroless容器时，可以使用debug标签的变体，它包含busybox shell用于故障排查。

3. 多阶段构建：分离构建与运行环境

多阶段构建是Docker镜像瘦身的核心技术，它允许你在一个Dockerfile中使用多个FROM指令，每个阶段都可以使用不同的基础镜像，并且只将必要的文件复制到最终镜像。

3.1 传统构建的问题

先看一个典型的Java应用构建方式：

FROM maven:3.8-openjdk-17 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests

# 运行时镜像
FROM openjdk:17-jdk-slim
COPY --from=build /app/target/myapp.jar /app/myapp.jar
CMD ["java", "-jar", "/app/myapp.jar"]

这个Dockerfile虽然使用了多阶段构建，但仍有优化空间。maven:3.8-openjdk-17镜像本身就有700MB+，而最终我们只需要一个几十MB的JAR文件。

3.2 优化后的多阶段构建

# 第一阶段：构建环境
FROM maven:3.8-eclipse-temurin-17-alpine AS builder
WORKDIR /build

# 利用层缓存：先复制pom.xml下载依赖
COPY pom.xml .
RUN mvn dependency:go-offline -B

# 复制源代码并构建
COPY src ./src
RUN mvn clean package -DskipTests \
    && java -Djarmode=layertools -jar target/*.jar extract

# 第二阶段：运行时环境
FROM eclipse-temurin:17-jre-alpine AS runtime
WORKDIR /app

# 创建非root用户
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

# 从构建阶段复制提取的层
COPY --from=builder --chown=appuser:appgroup /build/dependencies/ ./
COPY --from=builder --chown=appuser:appgroup /build/spring-boot-loader/ ./
COPY --from=builder --chown=appuser:appgroup /build/snapshot-dependencies/ ./
COPY --from=builder --chown=appuser:appgroup /build/application/ ./

# 健康检查
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
    CMD wget --no-verbose --tries=1 --spider http://localhost:8080/actuator/health || exit 1

EXPOSE 8080
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

关键优化点：

1. 使用Alpine变体：eclipse-temurin:17-jre-alpine只有约150MB，而完整JDK超过400MB
2. Spring Boot分层JAR：利用layertools将JAR拆分为依赖层和应用层，提高构建缓存利用率
3. 非root用户：提升安全性，符合容器最佳实践
4. 健康检查：确保容器可观测性

3.3 Node.js项目的多阶段构建

对于Node.js项目，优化策略类似但有所不同：

# 第一阶段：构建
FROM node:18-alpine AS builder
WORKDIR /app

# 复制包管理文件并安装依赖
COPY package*.json ./
RUN npm ci --only=production --ignore-scripts

# 复制源代码并构建
COPY . .
RUN npm run build

# 第二阶段：生产运行
FROM node:18-alpine AS production
WORKDIR /app

# 创建非root用户
RUN addgroup -g 1001 -S nodejs && \
    adduser -S nodejs -u 1001 -G nodejs

# 从构建阶段复制必要文件
COPY --from=builder --chown=nodejs:nodejs /app/node_modules ./node_modules
COPY --from=builder --chown=nodejs:nodejs /app/dist ./dist
COPY --from=builder --chown=nodejs:nodejs /app/package.json ./

USER nodejs

# 设置NODE_ENV
ENV NODE_ENV=production

# 健康检查
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
    CMD node -e "require('http').get('http://localhost:3000/health', (r) => {if(r.statusCode!==200)throw new Error()})"

EXPOSE 3000
CMD ["node", "dist/index.js"]

Node.js特定优化：

• npm ci比npm install更快且可重复
• --only=production避免安装开发依赖
• 分离node_modules复制，充分利用Docker层缓存

4. 高级优化技巧与工具

4.1 使用.dockerignore文件

.dockerignore文件的作用类似于.gitignore，可以防止不必要的文件被复制到构建上下文中：

# 忽略所有隐藏文件和目录
.*

# 忽略常见的IDE和编辑器文件
.vscode/
.idea/
*.swp
*.swo

# 忽略依赖目录（在容器内安装）
node_modules/
target/
build/
dist/

# 忽略日志和缓存
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# 忽略测试相关
coverage/
*.test.js
__tests__/

# 忽略环境文件（生产环境使用其他方式注入）
.env
.env.local
.env.development
.env.production

4.2 层合并与清理

减少镜像层数并清理每层的临时文件：

# 不好的做法：多个RUN指令创建多个层
RUN apt-get update
RUN apt-get install -y curl wget
RUN apt-get clean
RUN rm -rf /var/lib/apt/lists/*

# 好的做法：合并为单个RUN指令
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        curl \
        wget \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

清理时机很重要：在同一层中安装和清理，确保临时文件不会保留在最终镜像中。

4.3 使用Docker BuildKit

BuildKit是Docker的下一代构建引擎，提供了更好的性能和更多优化功能：

# 启用BuildKit
export DOCKER_BUILDKIT=1

# 或者永久启用
echo '{"features": {"buildkit": true}}' > /etc/docker/daemon.json

BuildKit的高级功能：

# syntax=docker/dockerfile:1.4
FROM node:18-alpine AS build

# 使用BuildKit的缓存挂载
RUN --mount=type=cache,target=/var/cache/apk \
    apk add --no-cache python3 make g++

# 使用BuildKit的secret管理
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
    npm ci --only=production

4.4 镜像分析工具

了解镜像的构成是优化的前提，以下工具可以帮助分析：

Dive：交互式镜像分析工具

# 安装Dive
curl -OL https://github.com/wagoodman/dive/releases/download/v0.11.0/dive_0.11.0_linux_amd64.deb
sudo apt install ./dive_0.11.0_linux_amd64.deb

# 分析镜像
dive myimage:latest

Docker Slim：自动优化工具

# 安装Docker Slim
curl -L https://downloads.dockerslim.com/releases/1.40.0/dist_linux.tar.gz | tar -xz

# 优化现有镜像
docker-slim build --target myimage:fat --tag myimage:slim

Skopeo：镜像检查和复制工具

# 检查镜像层信息
skopeo inspect docker://docker.io/library/nginx:alpine

# 复制镜像时排除某些层
skopeo copy --src-tls-verify=false --dest-tls-verify=false \
    docker://source/image:tag \
    docker://dest/image:tag

4.5 构建参数与目标架构优化

针对不同架构优化镜像：

# 多架构构建
FROM --platform=$BUILDPLATFORM node:18-alpine AS build
ARG TARGETARCH
ARG TARGETVARIANT

# 根据架构选择不同的二进制
RUN case "$TARGETARCH" in \
    "amd64") \
        wget -O /app/binary https://example.com/binary-linux-amd64 ;; \
    "arm64") \
        wget -O /app/binary https://example.com/binary-linux-arm64 ;; \
    *) \
        echo "Unsupported architecture: $TARGETARCH" && exit 1 ;; \
    esac

# 最终镜像
FROM alpine:3.18
ARG TARGETARCH
COPY --from=build /app/binary /usr/local/bin/

5. 实战案例：Java Spring Boot应用优化

让我们通过一个完整的Spring Boot应用案例，展示从初始镜像到优化后镜像的全过程。

5.1 初始Dockerfile（问题版本）

FROM openjdk:17
WORKDIR /app

# 复制整个项目
COPY . .

# 构建应用
RUN ./mvnw clean package -DskipTests

# 运行应用
CMD ["java", "-jar", "target/myapp-0.0.1-SNAPSHOT.jar"]

这个初始版本的问题：

• 使用完整的OpenJDK镜像（约500MB）
• 复制了整个项目目录，包括源代码、测试文件等
• 没有利用层缓存
• 最终镜像大小：约650MB

5.2 优化后的Dockerfile

# 第一阶段：构建
FROM eclipse-temurin:17-jdk-alpine AS builder

WORKDIR /workspace/app

# 复制Maven包装器和pom.xml
COPY mvnw .
COPY .mvn .mvn
COPY pom.xml .

# 下载依赖（利用层缓存）
RUN ./mvnw dependency:go-offline -B

# 复制源代码
COPY src src

# 构建应用
RUN ./mvnw clean package -DskipTests \
    && java -Djarmode=layertools -jar target/*.jar extract

# 第二阶段：运行时
FROM eclipse-temurin:17-jre-alpine

WORKDIR /app

# 创建应用用户
RUN addgroup -S spring && adduser -S spring -G spring
USER spring:spring

# 从构建阶段复制分层JAR内容
COPY --from=builder --chown=spring:spring /workspace/app/dependencies/ ./
COPY --from=builder --chown=spring:spring /workspace/app/spring-boot-loader/ ./
COPY --from=builder --chown=spring:spring /workspace/app/snapshot-dependencies/ ./
COPY --from=builder --chown=spring:spring /workspace/app/application/ ./

# 环境配置
ENV SPRING_PROFILES_ACTIVE=production
ENV JAVA_OPTS="-Xms256m -Xmx512m -XX:+UseG1GC -XX:MaxGCPauseMillis=200"

# 健康检查
HEALTHCHECK --interval=30s --timeout=3s --start-period=60s --retries=3 \
    CMD wget --no-verbose --tries=1 --spider http://localhost:8080/actuator/health || exit 1

EXPOSE 8080
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

5.3 优化效果对比

让我们通过实际构建来验证优化效果：

# 构建并分析镜像
docker build -t myapp:initial -f Dockerfile.initial .
docker build -t myapp:optimized -f Dockerfile.optimized .

# 查看镜像大小
docker images myapp

优化前后的对比数据：

指标	初始版本	优化版本	改进
镜像大小	648MB	89MB	减少86%
构建时间	4分32秒	2分18秒	减少49%
层数	12层	8层	减少33%
安全扫描漏洞	42个	11个	减少74%

5.4 进一步优化：使用JLink创建自定义JRE

对于追求极致体积的场景，可以使用JLink创建只包含必要模块的JRE：

# 第一阶段：使用JDK构建并创建自定义JRE
FROM eclipse-temurin:17-jdk-alpine AS builder

WORKDIR /workspace/app

# 复制和构建（同上）
COPY . .
RUN ./mvnw clean package -DskipTests

# 创建自定义JRE
RUN $JAVA_HOME/bin/jlink \
    --add-modules java.base,java.logging,java.xml,java.sql,java.naming,java.management,java.security.sasl,java.instrument \
    --strip-debug \
    --no-man-pages \
    --no-header-files \
    --compress=2 \
    --output /custom-jre

# 第二阶段：使用自定义JRE
FROM alpine:3.18

# 安装必要的库
RUN apk add --no-cache libstdc++

# 从构建阶段复制
COPY --from=builder /custom-jre /opt/jre
COPY --from=builder /workspace/app/target/*.jar /app/app.jar

# 设置环境
ENV JAVA_HOME=/opt/jre
ENV PATH="$JAVA_HOME/bin:$PATH"

WORKDIR /app
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

这种方法可以将运行时环境从150MB+减少到40MB左右，但需要仔细分析应用实际使用的Java模块。

6. CI/CD流水线中的镜像优化

在CI/CD流水线中实施镜像优化策略，可以显著提升整个开发流程的效率。

6.1 自动化优化流水线设计

# .gitlab-ci.yml 示例
stages:
  - build
  - test
  - optimize
  - scan
  - deploy

variables:
  DOCKER_BUILDKIT: "1"
  DOCKER_IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"

build:
  stage: build
  script:
    - docker build --target builder -t $DOCKER_IMAGE-builder .
    - docker build --target runtime -t $DOCKER_IMAGE .

optimize:
  stage: optimize
  script:
    # 使用Docker Slim进一步优化
    - docker-slim build --target $DOCKER_IMAGE --tag $DOCKER_IMAGE-slim
    # 分析镜像
    - dive $DOCKER_IMAGE-slim
  artifacts:
    paths:
      - slim-report.json

security-scan:
  stage: scan
  script:
    # 使用Trivy进行安全扫描
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $DOCKER_IMAGE-slim
    # 使用Grype进行漏洞扫描
    - grype $DOCKER_IMAGE-slim -o table
  allow_failure: false

deploy:
  stage: deploy
  script:
    # 推送优化后的镜像
    - docker tag $DOCKER_IMAGE-slim $DOCKER_IMAGE-optimized
    - docker push $DOCKER_IMAGE-optimized
  only:
    - main
    - master

6.2 镜像标签策略

合理的标签策略有助于镜像管理和回滚：

# 使用多标签策略
docker tag myapp:latest myapp:$(date +%Y%m%d-%H%M%S)
docker tag myapp:latest myapp:$(git rev-parse --short HEAD)
docker tag myapp:latest myapp:${CI_PIPELINE_ID}

# 推送所有标签
docker push myapp --all-tags

6.3 镜像仓库优化

在私有镜像仓库中实施保留策略和垃圾回收：

# Harbor 镜像保留策略配置
retention:
  rules:
    - repositories:
        - "myapp/**"
      tagSelectors:
        - pattern: ".*"
          extras:
            untagged: true
      keepMostRecentlyPulled: 10
      keepMostRecentlyPushed: 20
      keepNCount: 50

7. 监控与持续优化

镜像优化不是一次性的工作，而是需要持续监控和改进的过程。

7.1 建立镜像大小监控

# monitor_image_size.py
import docker
import time
import json
from datetime import datetime

client = docker.from_env()

def monitor_image_sizes():
    images = client.images.list()
    report = {
        "timestamp": datetime.now().isoformat(),
        "images": []
    }
    
    for image in images:
        if image.tags:
            for tag in image.tags:
                if "myapp" in tag:
                    size_mb = image.attrs['Size'] / (1024 * 1024)
                    report["images"].append({
                        "tag": tag,
                        "size_mb": round(size_mb, 2),
                        "created": image.attrs['Created']
                    })
    
    # 保存报告
    with open(f"image_report_{datetime.now().strftime('%Y%m%d')}.json", "w") as f:
        json.dump(report, f, indent=2)
    
    # 检查是否超过阈值
    for img in report["images"]:
        if img["size_mb"] > 100:  # 100MB阈值
            print(f"警告: {img['tag']} 大小 {img['size_mb']}MB 超过阈值")

if __name__ == "__main__":
    monitor_image_sizes()

7.2 定期安全扫描与更新

#!/bin/bash
# weekly_scan.sh

# 扫描所有生产镜像
IMAGES=("myapp:latest" "myapp:production" "nginx:alpine")

for IMAGE in "${IMAGES[@]}"; do
    echo "扫描镜像: $IMAGE"
    
    # 使用Trivy扫描
    trivy image --format json --output "scan_$(echo $IMAGE | tr '/' '_' | tr ':' '_').json" "$IMAGE"
    
    # 检查是否有高危漏洞
    VULNERABILITIES=$(trivy image --severity HIGH,CRITICAL "$IMAGE" | grep -c "HIGH\|CRITICAL")
    
    if [ "$VULNERABILITIES" -gt 0 ]; then
        echo "发现 $VULNERABILITIES 个高危漏洞，需要更新基础镜像"
        # 发送警报
        curl -X POST -H "Content-Type: application/json" \
            -d "{\"text\":\"镜像 $IMAGE 发现高危漏洞\"}" \
            $SLACK_WEBHOOK_URL
    fi
done

# 自动更新基础镜像
docker pull nginx:alpine
docker pull eclipse-temurin:17-jre-alpine

7.3 性能基准测试

建立镜像性能基准，确保优化不会影响运行时性能：

# benchmark.sh
#!/bin/bash

IMAGE=$1
ITERATIONS=10

echo "测试镜像: $IMAGE"
echo "迭代次数: $ITERATIONS"

# 拉取时间测试
echo -e "\n1. 拉取时间测试:"
time for i in $(seq 1 $ITERATIONS); do
    docker rmi $IMAGE 2>/dev/null || true
    docker pull $IMAGE >/dev/null
done

# 启动时间测试
echo -e "\n2. 启动时间测试:"
for i in $(seq 1 $ITERATIONS); do
    CONTAINER_ID=$(docker run -d --rm $IMAGE)
    sleep 2
    docker stop $CONTAINER_ID >/dev/null
done | awk '{sum+=$1} END {print "平均启动时间:", sum/NR, "秒"}'

# 内存使用测试
echo -e "\n3. 内存使用测试:"
docker run -d --name test_container --memory=512m $IMAGE
sleep 5
docker stats test_container --no-stream --format "{{.MemUsage}}"
docker stop test_container >/dev/null
docker rm test_container >/dev/null

8. 常见问题与解决方案

在镜像优化过程中，我遇到过各种问题，这里分享一些常见问题的解决方案。

8.1 Alpine兼容性问题

问题：某些应用在Alpine上运行异常，特别是依赖glibc的二进制文件。

解决方案：

# 方法1：使用兼容性库
FROM alpine:3.18
RUN apk add --no-cache libc6-compat

# 方法2：使用多阶段构建，从glibc镜像复制库
FROM ubuntu:22.04 AS glibc
FROM alpine:3.18
COPY --from=glibc /lib/x86_64-linux-gnu/libc.so.6 /lib/
COPY --from=glibc /lib64/ld-linux-x86-64.so.2 /lib64/

# 方法3：使用专门的Alpine兼容镜像
FROM frolvlad/alpine-glibc:alpine-3.18

8.2 时区设置问题

问题：容器内时区不正确，导致日志时间戳错误。

解决方案：

FROM alpine:3.18

# 设置时区
RUN apk add --no-cache tzdata && \
    cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
    echo "Asia/Shanghai" > /etc/timezone && \
    apk del tzdata

# 或者使用构建参数
ARG TZ=Asia/Shanghai
RUN apk add --no-cache tzdata && \
    cp /usr/share/zoneinfo/${TZ} /etc/localtime && \
    echo ${TZ} > /etc/timezone && \
    apk del tzdata

8.3 证书问题

问题：容器内缺少CA证书，导致HTTPS请求失败。

解决方案：

FROM alpine:3.18

# 安装CA证书
RUN apk add --no-cache ca-certificates && \
    update-ca-certificates

# 对于Distroless镜像，需要从其他镜像复制证书
FROM gcr.io/distroless/base-debian11
COPY --from=alpine:3.18 /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

8.4 调试优化后的镜像

问题：优化后的镜像（特别是Distroless）没有shell，难以调试。

解决方案：

# 方法1：使用debug标签（如果有）
docker run --rm -it gcr.io/distroless/base-debian11:debug

# 方法2：临时添加busybox
FROM gcr.io/distroless/base-debian11 AS production
# ... 生产配置 ...

FROM production AS debug
USER root
COPY --from=busybox:1.36 /bin/sh /bin/sh
USER nonroot

# 方法3：使用ephemeral容器（Kubernetes）
kubectl debug -it pod/myapp --image=busybox:1.36 --target=myapp

8.5 构建缓存优化

问题：CI/CD环境中构建缓存失效，导致每次都是完整构建。

解决方案：

# 使用BuildKit的缓存导出/导入
# docker-compose.yml
version: '3.8'
services:
  app:
    build:
      context: .
      cache_from:
        - type=registry,ref=myregistry.com/myapp:buildcache
      cache_to:
        - type=registry,ref=myregistry.com/myapp:buildcache,mode=max

在实际项目中，我发现最有效的优化组合是：Alpine基础镜像 + 多阶段构建 + 层合并清理。这套组合拳能够解决90%的镜像臃肿问题。对于特别敏感的场景，可以进一步考虑Distroless或自定义JRE。

镜像优化是一个持续的过程，需要根据具体应用的特点进行调整。关键是要建立监控机制，定期审查镜像大小和安全性，确保优化不会引入新的问题。每次基础镜像更新后，都应该重新评估优化策略，因为新的基础镜像可能已经包含了我们手动优化的内容。