Docker apt-get 安装报 404：分开的 update 层可能复用了旧索引

Docker 构建时，apt-get install 下载某个 .deb 返回 404 Not Found，但 Dockerfile 前面明明已经写了 RUN apt-get update。对于 Debian、Ubuntu 系镜像，先查看构建输出：如果 update 那一步标为 Using cache 或 CACHED，它没有重新查询当前软件仓库。

APT 索引记录了可用软件包的版本和下载位置。镜像里缓存的索引可能仍指向仓库已经替换的包。这个判断适用于软件包下载 URL 的 404；如果失败的是发行版的 Release 或 InRelease，或者出现签名、DNS 错误，要按对应故障处理。

为什么改安装列表，没有重新 update

下面是容易出现问题的结构示例：

FROM debian:stable-slim
RUN apt-get update
RUN apt-get install -y ca-certificates
RUN apt-get install -y unzip

修改后面的包名，并不会使前面没变化的 update 指令失效。Docker 可以继续复用当时产生的文件层，再运行新的安装命令。CI 和本机的构建缓存、基础镜像版本不同，也可能让同一份 Dockerfile 在一处通过、另一处失败。

先核对报错中的包版本、镜像发行版、软件源与 update 步骤是否真的执行。若 update 已重新运行且成功，安装仍 404，继续查仓库同步或源配置，不能把所有 404 都归给 Docker 缓存。NO_PUBKEY 也不能靠合并 RUN 消除其签名问题。

把更新索引和安装放在同一个 RUN

可以将有关安装步骤合并为以下示例。基础镜像和包列表按项目所需选择，不要为了这次修复随意升级发行版：

FROM debian:stable-slim
RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        ca-certificates \
        unzip \
    && rm -rf /var/lib/apt/lists/*

&& 让更新成功后才安装。以后修改这条 RUN 的安装列表，会让这一整条指令重新执行，先取得索引再下载包。清理列表放在同一条指令末尾，减少写入最终镜像的索引；后续再有 APT 安装，仍应配套 update。

合并后，未发生变化的整条 RUN 也仍可能被缓存。这是正常复用，不意味着每次构建都会取得最新依赖。如果需要主动刷新这次构建的包索引，可为指定构建使用不复用缓存的方式：

docker build --no-cache -t example-app:apt-refresh .

这是构建命令示例，标签与上下文需替换。它会重跑构建步骤，可能下载新依赖，增加耗时和网络使用；不会自动把基础镜像拉到最新。--pull 用于检查更新基础镜像，是另一项变更，应按项目升级安排决定。不要为了一个包的 404 清理宿主机全部 Docker 数据。

构建成功后，再决定替换运行镜像

先保存原 Dockerfile、镜像标识和部署配置，在候选镜像上检查安装包、应用启动及必要功能，再按部署流程替换。刷新构建可能改变依赖版本；固定标签也可能被发布者更新，要求精确复现时应管理镜像摘要和依赖版本，同时安排安全更新。

若新镜像不符合预期，恢复原 Dockerfile及先前保留的运行镜像。不要依赖“再构建一次旧文件”得到完全相同的镜像，外部仓库可能已经变化。修复的验收点是 update 在需要时确实重新执行、安装完成且应用工作正常；绕过 APT 签名验证或容忍下载失败，都不算解决这类故障。