标准答案
- 依赖清单和锁文件稳定时，可以先 COPY 它们并安装依赖，再 COPY 源码，源码变更不会让安装层全部失效。
- 缓存不是正确性保证，必须在依赖、基础镜像、安全补丁或构建参数变化时主动失效。
- 缓存失效要查看具体指令、文件元数据、构建参数、平台和基础镜像变化，不能只说“Docker 缓存坏了”。
- 生产构建需要可复现和可审计，不能为了命中缓存而跳过锁文件、测试或安全扫描。
题目解析
构建缓存通常根据指令、输入文件和前置层计算命中条件。把稳定的依赖清单和安装步骤放在源码 COPY 之前，可以让普通源码改动复用依赖层；但 lockfile、基础镜像 digest 或构建参数变化时必须让对应层失效。缓存是加速手段，不是安全更新机制。
排查缓存问题要确认实际使用的 builder、缓存来源、构建上下文和命中日志，必要时做一次干净构建对照。长期复用缓存可能继续使用旧基础镜像和漏洞依赖，应通过定期刷新、digest 更新和自动化扫描控制新鲜度。
常见误区
- 误区：把源码放在依赖安装之前导致每次都重装。改正：先复制锁文件并安装依赖，再复制变化频繁的源码。
- 误区：用缓存命中证明依赖已经更新。改正：把 lockfile、基础镜像 digest 和定期刷新纳入更新策略。