为何基于openjdk:8u171-alpine构建的Docker镜像大小远大于内部du统计值

核心原因：镜像分层逻辑导致的文件重复存储 #

Docker采用联合文件系统管理镜像，每一条RUN、COPY、ADD指令都会生成独立的只读层。如果修改上一层的文件，Docker会将该文件完整复制到当前层完成修改，原文件仍保留在上一层不会被删除。
你的Dockerfile中先执行COPY /target/$JAR_FILE app.jar添加30MB的jar包，又单独执行RUN chmod 775 app.jar修改文件权限，这两步操作会让30MB的jar包在COPY层和chmod层各存储一份，直接产生了近30MB的额外占用。
大小核算：基础镜像103MB + COPY层30MB + chmod层30MB + 其他零散指令的层开销 ≈ 165MB，与docker images的统计结果完全匹配。
而容器内部执行du统计的是多层合并后的文件系统实际使用量，只会统计一份jar包的大小，因此仅得到131.1MB的结果，两者存在差值属于正常情况。

其他次要影响因素 #

• 联合文件系统的块对齐开销：docker images统计的是各层逻辑大小的总和，文件存储时的块对齐、每层的元数据都会产生额外占用，这部分不会被容器内的du统计
• 镜像配置元数据：环境变量、入口点、暴露端口、VOLUME声明等配置信息，也会计入镜像总大小统计

优化方案 #

• 直接在COPY指令中指定文件权限，删除单独的RUN chmod指令，避免重复存储jar包：

COPY --chmod=775 /target/$JAR_FILE app.jar

• 合并关联的RUN指令，减少不必要的镜像层数，降低额外开销
• 复杂构建场景可使用多阶段构建，仅保留最终运行所需的文件，剔除构建过程产生的冗余内容

内容的提问来源于stack exchange，提问作者PaulZhu