镜像体积优化与安全加固一体两面：选轻量基础镜像（如-alpine、distroless）、多阶段构建隔离风险、同层安装清理、CI中Trivy扫描卡点闭环。
镜像体积和安全加固不是两个独立目标，而是一体两面：体积越小，攻击面越窄；剔除的冗余组件越多，潜在漏洞自然越少。关键不是“先瘦身再修漏洞”，而是用一套动作同时达成两者。
选对基础镜像，从源头掐断高危依赖
很多高危漏洞（如 OpenSSL、glibc、curl 的 CVE）来自基础镜像自带的操作系统包。直接用 ubuntu:22.04 或 centos:7 就等于默认继承了数百个带历史漏洞的二进制包。
- 优先选用官方维护的轻量级变体：如 python:3.11-slim、node:20-alpine、openjdk:17-jre-slim，它们已移除 shell、包管理器、编译工具等非运行必需项
- 更进一步可选 distroless 镜像（如 gcr.io/distroless/java17），只含运行时和 CA 证书，连
sh都没有，彻底杜绝命令注入类漏洞 - 避免使用
latest标签——它可能在某次更新中悄悄引入新漏洞，应固定为带补丁号的版本，例如debian:12.7-slim
多阶段构建不只是瘦身，更是“漏洞隔离”
构建阶段需要编译器、测试工具、源码、文档等，这些全是漏洞温床。多阶段的核心价值在于：把高风险构建环境和低风险运行环境物理隔离。
- 构建阶段用完整镜像（如
maven:3.9-openjdk-17），但不保留任何中间产物 - 运行阶段只
COPY --from=builder最终可执行文件（如 JAR、二进制、静态资源），不复制/usr/src、/root/.m2、node_modules等含大量第三方依赖的目录 - 实测表明：Java 应用用多阶段后，镜像中
npm、gcc、vim等调试/开发工具全部消失，Trivy 扫描出的中高危漏洞数量下降 60% 以上
构建过程中主动清理，防止“删不干净”的漏洞残留
Dockerfile 中的 RUN rm -rf /tmp/* 不等于镜像变小——被删文件仍留在上一层。必须把安装和清理放在同一条 RUN 指令里，确保它们属于同一层。
- Debian/Ubuntu 系统：用
RUN apt-get update && apt-get install -y xxx && apt-get clean && rm -rf /var/lib/apt/lists/* - Alpine 系统：用
RUN apk add --no-cache xxx，--no-cache自动跳过索引缓存，不需额外清理 - Node.js 项目：安装依赖后立即执行
RUN npm ci --only=production && npm prune --production，移除devDependencies及其子依赖中的已知漏洞组件（如旧版lodash、axios）
扫描不是收尾动作，而是构建流水线的强制关卡
体积优化和漏洞修复必须闭环。不能靠人工看报告，要让扫描结果决定镜像能否进入下一环节。
- 在 CI 中集成 Trivy，设定策略：发现
CRITICAL漏洞则构建失败，HIGH漏洞需人工确认并记录原因 - 用
trivy image --ignore-unfixed --severity CRITICAL,HIGH myapp:latest聚焦真正需处理的问题（--ignore-unfixed过滤掉尚无补丁的漏洞，避免误阻） - 结合
docker history定位哪一层引入了问题组件，例如某层显示apk add git，就说明不该在运行镜像里装 Git——立刻删掉这行
