--cache-from指定远程镜像不等于缓存必然复用，关键在于缓存源必须预先存在且可访问、from和指令内容字节级一致，并需启用buildkit；否则docker静默忽略缓存源，导致参数无效。
直接用 --cache-from 指定远程镜像，不等于缓存就真能复用——关键在于让 Docker 能“认出”那一层是它曾经构建过的。
远程缓存必须提前存在且可访问
你指定的缓存镜像（比如 my-registry/app:cache）得已经在远程 registry 里，并且当前构建环境有权限拉取。Docker 不会报错提醒你镜像不存在，而是静默跳过该缓存源，相当于参数白加。
- 先手动验证：运行
docker pull my-registry/app:cache，确保能成功拉下来 - 私有 registry 需提前登录：
docker login my-registry - CI 环境中注意凭证是否注入，比如 GitHub Actions 的
docker-login-action
FROM 和指令内容必须完全一致
缓存复用不是“差不多就行”，而是字节级匹配。哪怕只改了一个空格、换了个基础镜像 tag 名（如 python:3.11 → python:3.11.9），后续所有层都会重建。
-
固定基础镜像标签：别用
latest，用python:3.11-slim这类明确版本 -
依赖安装写死版本：
pip install flask==2.3.3，而不是flask>=2.0 -
COPY 前先 COPY 依赖文件：比如 Go 项目先
COPY go.mod go.sum .再RUN go mod download，这样依赖不变时这层永远命中
推荐搭配 BuildKit 使用
传统构建器对 --cache-from 支持有限，尤其在多阶段或挂载场景下。BuildKit 才能真正识别远程缓存并智能跳过执行。
- 启用方式：构建前设环境变量
DOCKER_BUILDKIT=1，或直接用docker buildx build - 完整命令示例：
DOCKER_BUILDKIT=1 docker build \<br> --cache-from my-registry/app:cache \<br> -t my-registry/app:v1 .
- Dev Containers 场景下，在
.devcontainer/devcontainer.json中加："build": { "cacheFrom": ["my-registry/base:latest"], "args": {"BUILDKIT": "1"} }
验证缓存是否生效
别只看总耗时变短——可能是网络快了或机器空闲。真正判断依据是构建日志和层 ID。
- 每行日志里出现 CACHED，表示该层跳过执行；出现 RUN 或 COPY，说明重新构建
- 对比两次构建后镜像的
docker image history myapp:v1，看各层CREATED BY和IMAGE ID是否完全相同 - 如果用了
buildx，加上--progress=plain可看到更详细的缓存匹配过程
