Docker构建缓存需针对性设计才能稳定复用：先COPY依赖文件（如go.mod）、再RUN安装、最后COPY源码；配合.dockerignore排除干扰文件；CI中用Buildx+远程缓存跨节点复用；固定基础镜像标签避免隐式失效。
在持续集成环境中，docker 构建缓存不是“开了就快”，而是需要针对性设计才能稳定复用。核心在于让缓存不被日常开发变更轻易打断，同时确保跨构建、跨节点的缓存可传递。
分阶段分离依赖与代码，锁定高频缓存层
把变动少的部分（如依赖声明）和变动多的部分（如源码）拆到不同 COPY 指令，并严格排序：
- 先 COPY go.mod / package.json / requirements.txt 等依赖清单文件
- 紧接着 RUN 安装依赖（
go mod download、npm ci、pip install -r） - 最后 COPY 整个应用目录
这样只要依赖没变，安装步骤就始终命中缓存；哪怕每天提交十次代码，也不会触发重装依赖。
用 .dockerignore 精确控制构建上下文
CI 中常因日志、临时文件、node_modules 或 IDE 配置被带入构建上下文，导致 COPY 指令哈希变化、缓存失效：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 务必在项目根目录添加 .dockerignore，明确排除：
**/*.log、node_modules/、.git/、dist/、__pycache__/ - 避免使用
COPY . .前未清理的构建上下文——CI 仓库拉取后若残留产物，会悄悄污染缓存判断
在 CI 流水线中启用 Buildx + 远程缓存
单机缓存对 CI 无意义，必须让缓存跨 Job、跨 Runner 复用：
- 使用
docker buildx build替代传统docker build - 配置
--cache-to type=registry,ref=your-registry.com/myapp:buildcache推送缓存 - 同步配置
--cache-from type=registry,ref=your-registry.com/myapp:buildcache拉取已有缓存 - 搭配
--platform可同时为 amd64/arm64 缓存，避免架构切换清空缓存
固定基础镜像标签，避免隐式缓存失效
使用 FROM ubuntu:22.04 比 FROM ubuntu:latest 更安全——后者可能随上游更新导致 FROM 层哈希变化，整条缓存链断裂：
- 优先选用带小版本号的 tag（如
node:18.19-alpine），而非node:18-alpine - 在 CI 中可加一步校验：构建前
docker pull明确的基础镜像，确保本地有确定版本 - 若必须用 latest，需配合
--cache-from强制复用历史缓存，缓解影响
不复杂但容易忽略：缓存价值不在“有没有”，而在“稳不稳定”。一次合理的 Dockerfile 结构调整，加上 Buildx 远程缓存接入，就能让 CI 构建从 3 分钟降到 40 秒，且长期保持。
