类型：虚拟化技术
简介：基于操作系统层级的虚拟化技术，将软件与其依赖项打包为容器。
Docker镜像体积变大，通常不是单一原因造成的。基础镜像过重、构建过程中安装了多余依赖、缓存文件没有清理、源码和临时文件被复制进镜像，都会让镜像越来越臃肿。镜像越大，拉取越慢，占用磁盘越多，部署和回滚也越慢。
对于个人站长和小团队来说，镜像体积优化不只是节省空间，还会影响服务器部署效率。尤其是在带宽有限、磁盘较小或频繁发布的环境里，一个过大的镜像会明显拖慢工作流。
一、先从基础镜像开始
优化镜像体积的第一步，是选择合适的基础镜像。不要默认使用完整系统镜像，如果应用只需要运行Node.js、Python或Nginx，可以优先选择官方轻量镜像。Alpine类镜像体积小，但也要注意兼容性，某些依赖可能需要额外处理。
选择基础镜像时，不要只看大小，还要看维护状态、安全更新和团队熟悉程度。过度追求极小镜像，可能换来更多编译问题和排错成本。
二、减少无关文件进入镜像
构建镜像前，应准备.dockerignore文件，排除node_modules、日志文件、临时目录、测试缓存、本地配置、Git目录和打包产物。很多镜像体积异常，就是因为构建上下文里包含了大量无关文件。
复制文件时也要尽量精准。不要在Dockerfile里随手COPY整个项目目录，再在容器里删除无关内容。已经进入镜像层的内容，即使后续删除，也可能仍然占用历史层空间。
三、利用多阶段构建
多阶段构建适合需要编译或打包的项目。第一阶段安装依赖并构建产物，第二阶段只复制运行所需文件。这样可以避免把编译器、开发依赖、测试工具和缓存文件带到最终镜像中。
例如前端项目可以在构建阶段执行依赖安装和打包，最终镜像只保留dist目录和Web服务器。后端项目也可以把编译产物和运行环境分开，减少攻击面和体积。
四、清理依赖缓存
很多语言生态在安装依赖时都会留下缓存。Node.js、Python、PHP、Java项目都有自己的包缓存目录。如果这些缓存被带进最终镜像，会增加体积，却不会提升运行效果。
在Dockerfile中可以把安装依赖和清理缓存放在同一个RUN层里，避免缓存进入历史层。对于需要编译的项目，尽量用多阶段构建把编译工具留在构建阶段。
五、检查镜像体积变化
优化前后可以用 docker images 查看镜像大小，也可以用镜像分析工具查看各层占用。不要只凭感觉判断是否优化成功。
如果一次修改导致镜像突然变大，优先检查是否复制了node_modules、日志、测试文件、Git目录或本地构建产物。很多体积问题都来自构建上下文没有清理。
六、构建顺序也会影响缓存
Docker构建会利用层缓存。把变化频繁的源码放在依赖安装之前，会导致每次改代码都重新安装依赖，构建速度明显变慢。更好的做法是先复制依赖清单，安装依赖，再复制业务代码。
例如Node.js项目可以先复制package.json和锁文件，执行依赖安装，再复制剩余源码。Python项目也可以先复制requirements文件，再安装依赖。这样代码小改动时，不会破坏依赖层缓存。
七、优化不要影响可维护性
镜像优化不是把所有内容压到极限。过度精简可能导致排错工具缺失、运行环境不透明、团队成员难以维护。生产镜像应尽量干净，但仍要保留必要证书、时区配置和运行依赖。
如果某次优化让部署过程明显复杂，应该评估收益是否值得。对小型网站来说，稳定、可理解、可回滚，往往比极致体积更重要。
八、上线前的镜像检查清单
镜像构建完成后，可以按清单检查：基础镜像是否可信，是否固定版本，是否包含无关源码，是否带入本地配置，是否暴露了密钥，是否包含测试文件，是否存在高危漏洞。
如果镜像要用于生产环境，还应确认启动命令是否明确、健康检查是否可用、日志输出是否合理。体积优化只是其中一项，不能为了变小牺牲运行可靠性。
