docker构建缓存逐层校验，某层指令变更或其上一层变化会导致该层及之后所有run跳过缓存；应将频繁变动操作后置、合并apt命令、避免动态外部引用，并依场景用--no-cache或docker builder prune清理。
Docker 构建缓存清理和 RUN 指令的写法密切相关——关键不是“怎么清理”，而是怎么写 RUN 才能避免缓存污染、减少无效重建，必要时又方便精准清理。
下面从实际构建逻辑出发，说清楚几个核心点：
缓存失效从哪一行开始？
Docker 构建缓存是**逐层（layer）校验**的。只要某一层的指令（比如 `RUN apt update && apt install -y curl`）对应镜像层在本地存在，且其**前一层完全一致**，Docker 就直接复用该层缓存。 一旦某条 `RUN` 指令的内容变了（哪怕多一个空格），或它依赖的上一层变了（比如 `COPY package.json .` 内容变了），那么**这条 `RUN` 及之后所有 `RUN` 都会跳过缓存，重新执行**。RUN 指令写法建议（兼顾缓存与清理）
- 把变化频繁的操作尽量往后放：比如 `COPY . .` 放在 `RUN apt update && apt install ...` 之后，避免每次代码改动都导致重装依赖 - 合并多个 apt/yum 命令到单个 RUN 中： ```dockerfile RUN apt-get update && apt-get install -y \ curl \ git \ && rm -rf /var/lib/apt/lists/* ``` 这样既减少层数，又避免 `apt-get update` 缓存过期后仍复用旧包列表 - 避免在 RUN 中引用外部动态内容（如 curl 下载未带校验的 URL）：这类操作天然不缓存，还可能因远程变更导致构建结果不可重现 - 需要强制跳过缓存时，加个无害变动即可：比如在命令末尾加 `# $BUILD_TIME` 或 `--build-arg` 注释，或使用 `--no-cache` 构建参数什么时候需要主动清理缓存？
- 本地调试时发现某层缓存“卡住”了（比如误用了旧的 `pip install` 结果） - CI 环境中想确保干净构建（常用 `docker build --no-cache`） - 清理所有 dangling（悬空）中间层：`docker builder prune` 或 `docker system prune -f`真正影响缓存的不是 RUN 写法本身，而是上下文一致性
- `COPY` 和 `ADD` 的文件内容变了 → 后续 `RUN` 全部失效 - 构建参数（`--build-arg`）值不同 → 对应 `ARG` 后的 `RUN` 层失效 - 基础镜像更新了（如 `FROM ubuntu:22.04` 实际指向新 digest）→ 第一层就不同，整个链重来不复杂但容易忽略
