1. 构建 Docker 镜像时，缓存失效不是运气差，是配置没对齐上下文
我上线一个 Python Web 服务的 CI 流程，第一次构建耗时 8 分 23 秒。加了actions/cache后降到 5 分 17 秒——看起来不错？但当我把requirements.txt里加一行pandas==2.2.0再推一次，构建时间又跳回 8 分 12 秒。缓存没生效。不是 GitHub Actions 不行，是我没搞懂：Docker 构建缓存和 Actions 缓存是两套独立系统，它们的“记忆”不共享，也不自动对齐。
更麻烦的是，团队里有人用 AI 编程工具（比如 Cursor 或 Claude Code）直接改.github/workflows/build.yml，加了一行--no-cache调试完忘了删；还有人让 AI 工具生成Dockerfile，结果它默认用了COPY . /app放在RUN pip install前面——这一条就让整个依赖层缓存彻底作废。你没法靠人工肉眼盯住所有分支、所有 PR 的每处改动。AI 辅助编程确实快，但它不会主动告诉你：“这行改动会让镜像构建缓存命中率从 92% 掉到 17%”。
这篇文章只讲一件事：在 GitHub Actions 中构建 Docker 镜像时，如何让缓存真正稳、准、快地生效。我们实测了三种主流策略——docker buildx bake+ Registry 缓存、