docker镜像构建缓存默认启用，关键在于提升命中率：将不变操作前置（如先copy依赖文件再安装）、精准控制copy范围、用多阶段构建隔离变化，并通过.dockerignore和--cache-from等手段主动管理缓存。
Docker 镜像构建缓存不是开关式功能，而是默认启用的底层机制——只要构建过程没被强制跳过，它就在工作。关键是怎么让它“多命中、少重建”。
把不变的指令放前面
Docker 按 Dockerfile 从上到下逐行执行，每条指令生成一层。一旦某层内容变了（比如文件内容不同、命令字符串变了），这一层及之后所有层都会重新构建。所以要把变动少的操作提前：
- 先 COPY
package.json或go.mod，再 RUNnpm install或go mod download - 依赖安装完成后，再 COPY 源码（
.,src/,cmd/等）
这样改了业务代码，不会触发依赖重装。
精准控制 COPY 范围
COPY 整个目录（如 COPY . /app）容易因 .git、node_modules、日志等无关文件变更导致缓存失效。应该：
- 用
.dockerignore排除干扰项（node_modules,.git,*.log,tmp/） - 分步 COPY：先拷依赖描述文件，再拷源码，必要时单独拷配置或静态资源
善用多阶段构建隔离变化
构建阶段（builder）和运行阶段（runtime）物理隔离，彼此缓存互不影响。例如：
- builder 阶段装 Go 编译器、下载依赖、编译二进制
- runtime 阶段只 COPY 编译好的可执行文件到 Alpine 镜像
这样即使 builder 阶段的源码天天改，runtime 层仍能稳定复用（只要二进制没变）。
需要时主动管理缓存
- 查看缓存状态：
docker builder prune -f清理无用缓存；docker system df查看占用 - 强制跳过缓存（调试用）：
docker build --no-cache - 构建时指定缓存来源（CI 场景）：
--cache-from+--cache-to配合 registry 存储远程缓存
缓存不是黑盒，它靠每一层输入的确定性来判断是否可复用。写 Dockerfile 时，心里默念一句：“这行变不变？后面会不会跟着一起重跑？”答案越明确，缓存就越听话。
