Docker构建缓存优化核心在于逐层哈希匹配：任一层内容（如COPY文件内容、RUN命令或基础镜像digest）变更，即导致该层及后续所有层失效；需将稳定操作（如复制package.json并RUN install）前置，变动操作（如复制源码）后置，并用.dockerignore排除无关文件以保缓存链完整。
docker 构建缓存优化的核心，在于理解“层”如何被复用，以及什么会让它突然失效。缓存不是全局开关，而是逐层判断——只要某一层变了，后面所有层都得重来。关键不在“有没有缓存”，而在于“哪一层最容易断链”。
缓存靠哈希值匹配，不是靠文件名或时间
Docker 对 COPY、ADD 和 RUN 指令的输入内容做哈希计算，只有哈希一致才复用缓存。
-
COPY package.json /app/这一行是否命中缓存，取决于你本地package.json的实际内容有没有变，哪怕只改了一个空格 - 修改了
src/index.js，但这一行在COPY ./src /app/src里，那这整条COPY就会重新计算哈希，缓存失效 -
RUN npm install是否缓存，不仅看命令字符串，还依赖前一层（即package.json所在层）是否命中
指令顺序决定缓存寿命长短
把变动少的操作往前放，变动多的往后放，能保住前面大量稳定层的缓存。
- 错误写法：
COPY . /app→RUN npm install→RUN npm run build只要任意源文件改动，npm install就必须重跑 - 推荐写法：
COPY package.json /app/→RUN npm install→COPY ./src /app/src→RUN npm run build只有package.json改了，npm install才重建；日常改代码不影响它 - 同理，
requirements.txt、pom.xml、go.mod都应单独提前复制
基础镜像和构建上下文是隐性断点
有些变化看似不相关，却会直接清空整个缓存链。
-
FROM python:3.11-slim如果远程镜像更新了（比如安全补丁），Docker 会拉取新层，导致 FROM 后所有层全部重建 - 构建命令中用了
--build-arg，但参数值变了，对应层也会失效 - 构建上下文包含大量无关文件（如
node_modules、.git、日志），哪怕没被 COPY，也可能因.被误判为变更源 - 解决办法：用
.dockerignore显式排除，例如写上node_modules/、.git/、*.log
跨环境共享缓存需要显式配置
本地开发机的缓存默认不传到 CI 流水线，想复用就得主动导出导入。
- CI 中常用
registry类型缓存：构建时从镜像仓库拉旧缓存，完成后推新缓存层 - 示例命令（Buildx）：
docker buildx build --cache-from type=registry,ref=reg.example.com/myapp:cache --cache-to type=registry,ref=reg.example.com/myapp:cache -t reg.example.com/myapp:v1 . - 本地调试可用
local缓存类型，速度快但不共享；inline把缓存信息打到镜像标签里，适合简单场景
