GitHub Actions 缓存提速实测：Docker 构建依赖下载减少 65% 的 4 种策略

1. Docker 构建缓存失效，不是网络慢，是上下文被“重置”了

我接手一个 Python + FastAPI + Docker 的微服务项目时，CI 流水线每次构建都要花 8 分 23 秒。其中 5 分 17 秒卡在pip install -r requirements.txt—— 即使 requirements.txt 一行没动，哪怕只是改了个 README.md，也得重新下载torch==2.1.0、transformers==4.35.2这些几百 MB 的包。

一开始我以为是 GitHub Actions Runner 网络差，换了 runner 类型、加了--no-cache-dir、甚至试过用pip cache dir手动挂载，都没用。直到我把docker build命令单独拎出来，在本地复现——发现只要Dockerfile里COPY . /app这一步的源文件时间戳变了（比如 git commit 后文件 mtime 更新），哪怕只改了一个空格，Docker 就会从COPY开始全部重建后续所有 layer，RUN pip install这一层根本不会命中缓存。

这才是真相：Docker 构建缓存不是靠“文件内容哈希”，而是靠“指令执行顺序 + 上层 layer 的完整性”。一旦 COPY 指令的输入变了，它和它之后的所有 RUN 都失效。而 Gi