核心是基础镜像中预置的软件源gpg签名过期，导致ci中apt update失败；需通过拉取最新镜像、刷新密钥或临时参数绕过（仅限调试）来修复。
这个问题核心在于基础镜像中预置的软件源元数据（如 Release 文件的 GPG 签名）已过期，导致 apt update 或 yum makecache 在 CI 流水线中直接失败，进而中断整个构建流程。签名过期不是网络或配置错误，而是时间敏感型安全机制触发的合法拒绝——尤其在长期未更新的基础镜像（如半年以上未重建的 debian:stable 或 centos:7）中高频出现。
确认是否为 GPG 签名过期问题
先定位错误特征，避免误判：
- 日志中出现
NO_PUBKEY、EXPKEYSIG、KEYEXPIRED或The following signatures couldn't be verified because the public key is not available -
apt update返回非零退出码，但curl -I能正常访问源地址（排除网络问题） - 同一镜像在本地构建成功，但在 CI 环境（如 Azure Pipelines、GitLab CI）中失败——因 CI runner 时间更严格，且常禁用系统时间同步
临时绕过：仅限紧急恢复流水线
不推荐长期使用，但可快速止血，让构建继续跑通：
- APT 环境：添加
--allow-releaseinfo-change和--allow-unauthenticated参数（注意：仅用于调试或可信内网）apt update --allow-releaseinfo-change --allow-unauthenticated - YUM 环境：临时禁用 GPG 检查
yum makecache --nogpgcheck - ⚠️ 注意：这些参数会跳过安全校验，不可用于生产镜像发布环节
根本修复：从镜像源头切断过期链
签名过期本质是镜像“老化”，必须从构建起点治理：
- 强制拉取最新基础镜像，而非复用本地缓存：
docker pull ubuntu:22.04或docker pull debian:bookworm-slim - 在 Dockerfile 开头显式指定带时间戳的稳定 tag（避免
:latest飘移）：FROM ubuntu:22.04-20260401（部分厂商提供日期 tag） - 对自建基础镜像，加入自动刷新源密钥的步骤：
RUN apt-get update && apt-get install -y gnupg && apt-key adv --refresh-keys
或更现代方式（Ubuntu 22.04+ / Debian 12+）：RUN apt-get update && apt-get install -y ca-certificates && rm -rf /var/lib/apt/lists/*
预防性加固：CI 流水线层防护
让失败提前暴露、自动响应，而非等到构建中途崩溃：
- 在流水线 job 开头增加健康检查脚本：
apt-get update -o Acquire::Check-Valid-Until=false || echo "Warning: signature expiry detected"
（Acquire::Check-Valid-Until=false临时忽略有效期，但保留签名验证） - 监控基础镜像拉取时间：若距上次
docker pull超过 90 天，自动触发告警并强制刷新 - 对关键项目，启用镜像扫描工具（如 Trivy、Snyk）定期检查基础镜像中
/etc/apt/trusted.gpg.d/下密钥的有效期
