gcloud builds submit 默认不复用 docker 层缓存，导致每次构建都重装 pip 包；启用 kaniko 缓存并合理分层 copy，可显著提升构建速度与可复现性。
gcloud builds submit 默认不复用 docker 层缓存，导致每次构建都重装 pip 包；启用 kaniko 缓存并合理分层 copy，可显著提升构建速度与可复现性。
Google Cloud Build（尤其是通过 gcloud builds submit 触发的构建）默认使用 Container Registry 构建器（旧版）或 Cloud Build 的托管构建环境，并不原生继承本地 Docker daemon 的层缓存机制。即使你的 Dockerfile 严格遵循最佳实践（如先 COPY requirements.txt 再 RUN pip install），在远程 Cloud Build 中仍可能每次重建所有依赖层——根本原因在于：默认构建器不具备跨构建会话的持久化缓存能力。
解决方案是启用 Google 官方支持的 Kaniko 缓存模式。Kaniko 是一个在容器内无守护进程（daemonless）执行镜像构建的工具，其核心优势之一就是支持将中间层（特别是 pip install 生成的 site-packages）推送到指定的远程 registry（如 gcr.io 或 Artifact Registry）并按 TTL 复用。
你需要执行以下两步配置（仅需一次，全局生效）：
gcloud config set builds/use_kaniko True gcloud config set builds/kaniko_cache_ttl 8
其中 kaniko_cache_ttl 8 表示缓存有效期为 8 小时（单位：小时）。你可根据团队发布节奏调整（例如 CI 频繁时设为 4，夜间批量构建可设为 24）。
更重要的是 Dockerfile 结构必须适配 Kaniko 缓存逻辑：所有影响依赖安装的文件必须在 RUN pip install 前被 COPY，且不能混入源码变更。例如，若需编译 Cython 扩展，应将 setup_pyd.py、.pyx 文件与 requirements.txt 一并前置 COPY：
FROM python:3.12-slim
ENV APP_HOME /app
WORKDIR $APP_HOME
# ✅ 关键：仅 COPY 依赖声明和构建脚本（不变或低频变更）
COPY requirements.txt setup_pyd.py CoreLoop.pyx ./
# 安装 Python 包（此层将被 Kaniko 缓存）
RUN pip install --no-cache-dir -r requirements.txt
# 编译 Cython（同样进入缓存层，只要 .pyx 或 setup.py 不变）
RUN python setup_pyd.py build_ext --inplace \
--include-dir=/usr/local/lib/python3.12/site-packages/numpy/core/include
# ❌ 此后才 COPY 全量应用代码（高频变更，不破坏上游缓存）
COPY . .
CMD ["python", "main.py"]
⚠️ 注意事项：
- --no-cache-dir 推荐显式添加，避免 pip 自身临时缓存干扰 Kaniko 层哈希计算；
- 确保 requirements.txt 使用固定版本（如 requests==2.31.0），而非 requests>=2.30，否则语义变更可能导致缓存误用；
- 若使用 Artifact Registry 替代 GCR，需额外配置 --cache=LOCATION-docker.pkg.dev/PROJECT/REPO（Kaniko 高级模式），但上述 gcloud config 方式已覆盖绝大多数场景；
- 首次构建仍需完整安装，后续构建中只要 requirements.txt 及其依赖文件未变，Kaniko 将直接拉取缓存层，通常可节省 60%+ 构建时间。
总结：gcloud builds 的“重复安装”并非 Bug，而是默认关闭远程缓存的设计选择。启用 Kaniko 并配合精准的 Dockerfile 分层策略，即可在云原生构建中获得媲美本地开发的高效依赖管理体验。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
