run指令命中缓存需同时满足前一层镜像id不变和命令字符串逐字符一致；应前置稳定操作、避免动态内容、合并命令并清理临时文件，构建日志中“using cache”即表示命中。
RUN 指令本身不会自动“跳过”执行，但它能命中缓存——前提是它前面的所有层都没变，且该 RUN 命令字符串完全一致。
缓存命中的两个硬条件
RUN 层能否复用缓存，取决于：
- 前一层镜像 ID 必须完全相同：比如 COPY 或 WORKDIR 后生成的层没变，RUN 才有机会比对自身
-
命令字符串逐字符一致：
RUN apt-get update && apt-get install -y curl和RUN apt-get update && apt-get install -y curl（末尾多一个空格）会被视为不同指令，无法复用
让 RUN 更容易命中缓存的操作建议
关键不是改 RUN 本身，而是控制它的输入和位置：
-
把稳定操作往前放：例如先 COPY
go.mod再RUN go mod download，这样只要依赖没变，下载步骤就永远走缓存 -
避免在 RUN 中嵌入动态内容：不要写
RUN echo $(date) > build-time.txt，时间戳每次不同，必然失效 -
合并命令要谨慎：虽然
RUN apt-get update && apt-get install -y curl是常见写法，但若只想更新包列表而不重装 curl，应拆成两层——不过实际中更推荐用--no-cache或包管理器的锁机制来解耦
怎么确认 RUN 是否用了缓存
构建时看终端输出：
- Step 2/5 : RUN apk add --no-cache curl → Using cache 表示命中
- Step 2/5 : RUN apk add --no-cache curl → Running in 9a1b2c3d... 表示重新执行
如果某层没命中，它之后所有 RUN 都会强制重建，所以定位第一个失效点很关键。
临时绕过缓存调试用法
当怀疑缓存导致行为异常，可用：
-
docker build --no-cache .：整条链禁用缓存 -
docker build --cache-from=none .：效果类似，更明确语义 - 只对某一层“破缓存”：在对应 RUN 前加个无害但变化的指令，比如
RUN echo $RANDOM > /dev/null
