核心是定位首个未出现“using cache”的指令：该行为缓存断裂点，其后所有run均失效；需检查前序copy文件变动、run命令非确定性、基础镜像更新或构建参数变化。
排查 Docker 构建缓存失效中 RUN 指令的问题，核心在于理解缓存命中机制：Docker 会逐层比对每条指令的上下文（包括前序镜像层、当前指令内容、执行时的文件系统状态），只要任一环节变化，后续所有 RUN 都会跳过缓存。
检查 RUN 前面的指令是否触发了缓存重置
RUN 缓存是否生效，完全依赖其前一条指令（如 COPY、ADD 或上一个 RUN）是否命中缓存。一旦前面某步缓存失效，它之后的所有 RUN 自动失效。
- 重点检查紧邻的
COPY . /app类指令：只要本地目录任意文件有改动（包括隐藏文件如.git、node_modules、__pycache__），该COPY就会失效 → 后续RUN全部失效 - 使用
.dockerignore排除无关文件（如**/node_modules、.git、logs/），避免误触缓存 - 避免在
COPY之前写入动态内容（例如用RUN date > timestamp.txt再COPY），这会让缓存变得不可预测
确认 RUN 指令内容本身是否稳定
看似相同的 RUN 命令，可能因内部行为变化而无法复用缓存——比如安装包版本浮动、网络拉取非固定哈希资源、或命令隐含时间/环境依赖。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 避免
RUN apt-get update && apt-get install -y curl：apt-get update每次拉取最新索引，导致缓存几乎必失；应合并为RUN apt-get update && apt-get install -y curl && apt-get clean，并固定软件源和版本（如curl=7.68.0-1ubuntu2.15） - 用
pip install --no-cache-dir -r requirements.txt时，确保requirements.txt文件内容未变；更推荐用pip install --no-deps --force-reinstall配合 pinned 版本（如requests==2.31.0） - 禁止在
RUN中调用外部 API、生成随机数、读取系统时间等非确定性操作
观察构建日志判断缓存实际使用情况
Docker 构建输出中明确标出缓存状态，是最快定位问题的依据。
- 看到
Using cache表示该层命中；Caching disabled或直接显示Running in ...表示跳过缓存 - 注意日志里哪一行开始变成
Step X/Y : RUN ...并不再提 “cache”，这就是缓存断裂点，往上倒查就是根源 - 加
--progress=plain参数运行docker build，可获得更清晰的逐层执行与缓存信息
验证基础镜像或构建参数是否变动
即使 Dockerfile 没改，基础镜像更新或构建参数变更也会让所有 RUN 失效。
- 检查
FROM ubuntu:22.04是否被上游更新（如ubuntu:22.04是滚动标签）；建议改用带 digest 的固定镜像，例如FROM ubuntu:22.04@sha256:... - 确认是否启用了
--no-cache、--build-arg变更（尤其是影响RUN执行逻辑的参数）、或使用了--cache-from但远程缓存不可用 - 多阶段构建中，若
FROM ... AS builder阶段变了，引用它的COPY --from=builder后的RUN也会失效
