Docker构建断网导致缓存链断裂而非缓存清空，失败指令起后续步骤均不复用缓存；应拆分下载与安装、使用BuildKit、本地化依赖并确保构建参数一致以恢复缓存复用。
构建中途断网会导致 Docker 构建器无法复用后续层的缓存，因为某一层失败后，Docker 会丢弃该层及之后所有已缓存但未提交的中间镜像。这不是“缓存被清空”，而是构建流程中断导致缓存链断裂——后续重新构建时，从失败指令开始的所有步骤都会重新执行（即使网络恢复、基础镜像已存在本地）。
确认哪一层实际失效了
Docker 构建日志中，每条 RUN、COPY 等指令执行后会输出类似 --> Using cache 或 --> 1a2b3c4d 的提示。断网后首次失败的那条指令会显示 failed 或超时错误；而重启构建时，**从该指令起，所有后续步骤都不再显示 Using cache**，即使对应层在本地 docker images -a 中仍可见（它们只是未被新构建链引用）。
- 运行
docker images -a | grep "<none>"可看到大量悬空中间镜像，其中部分可能对应断网前成功的层 - 用
docker history your-image-name对比成功/失败构建的层哈希，定位第一个不一致的层
避免重复拉取和重编译的关键操作
断网主要影响依赖下载（如 apt-get update、pip install、go mod download）和远程 COPY（COPY --from=... 或 RUN curl ... | tar -x）。重点不是清理缓存，而是让这些步骤具备“可跳过”或“本地兜底”能力：
-
把下载类命令和解压/安装拆成两层：例如先
RUN apt-get update && apt-get download ...（只下载不安装），再RUN dpkg -i *.deb。这样即使第二层失败，第一层缓存仍可用，重试时无需重下 deb 包 -
用构建参数控制源地址：在
Dockerfile中写RUN --mount=type=cache,target=/var/cache/apt \（BuildKit 模式），或通过--build-arg APT_MIRROR=...指向内网镜像源，减少对外网依赖 -
对关键二进制提前本地化：不要
RUN curl -sSL https://.../binary | sh，改为COPY ./binary /usr/local/bin/，把文件放项目目录里随代码一起管理
启用 BuildKit 并检查缓存状态
旧版 Docker 默认不共享构建缓存，BuildKit 则支持更细粒度的缓存复用和离线友好行为：
- 设置环境变量启用：
export DOCKER_BUILDKIT=1，然后用docker build . - BuildKit 日志中会出现
cached ...或needs build明确提示是否命中缓存 - 用
docker buildx du -v查看当前构建缓存占用，确认是否有大量未被引用的临时层堆积
断网后快速恢复构建的建议流程
不必删除镜像或清理系统缓存，关键是让构建器“知道哪些层可信”：
- 确保
docker build命令参数完全一致（包括--build-arg、--target、上下文路径），否则 Docker 认为是全新构建 - 如果某层因网络超时失败，且你确认本地已有对应基础镜像（如
ubuntu:22.04），可手动docker pull ubuntu:22.04再重试，避免拉取阶段卡住 - 对频繁失败的步骤（如
npm install），在Dockerfile中添加--no-audit --no-fund减少非必要网络请求
不复杂但容易忽略：Docker 缓存有效性取决于指令内容、文件变更、构建参数三者完全一致。断网本身不破坏缓存，但中断构建会让后续指令失去“前序层已就绪”的上下文，从而强制重建。核心是让每一层职责单一、副作用可控、失败可重入。
