from 指令显式指定镜像 digest（如 ubuntu@sha256:...）是确保基础镜像内容一致、防止标签漂移的最可靠方式，需在多阶段构建中为每个 from 单独锁定，ci 中应强制校验。
直接在 FROM 指令中显式指定镜像的完整摘要（digest），是验证基础镜像哈希一致性的最可靠方式。它绕过标签（tag）的不确定性，强制构建过程绑定到不可变的内容指纹。
用 digest 替代 tag 写入 FROM
不要写：FROM ubuntu:22.04
而应写成：FROM ubuntu@sha256:b276d845b51e899c0da7a23041023a8c3f04058e648a478a3e6b54239181025b
- 该 digest 是镜像 manifest 的 SHA256 哈希，由所有层内容共同决定，内容不变则 digest 永不变化
- Docker 构建时会自动下载并校验 manifest，比对本地指令中的 digest 是否匹配；不一致则构建失败
- 避免“标签漂移”——比如
ubuntu:22.04被上游重新打标，导致不同时间构建出完全不同的基础环境
如何获取并确认 digest 的真实性
不能凭记忆或截图拼接，需通过可信渠道获取原始 digest：
- 从私有 registry API 查询：如
curl -H "Accept: application/vnd.docker.distribution.manifest.v2+json" https://registry.example.com/v2/ubuntu/manifests/22.04，响应头Docker-Content-Digest即为权威 digest - 用
docker pull后反查：先拉取带 tag 的镜像，再运行docker inspect --format='{{index .RepoDigests 0}}' ubuntu:22.04（前提是该镜像曾以 digest 方式拉取过） - 配合签名验证：若启用 Notary 或 cosign，可进一步执行
cosign verify --certificate-oidc-issuer https://token.actions.githubusercontent.com --certificate-identity-regexp '.*' ubuntu@sha256:xxx确保来源可信
多阶段构建中每阶段都需独立锁 digest
每个 FROM 都是独立构建起点，必须分别锁定：
- 构建阶段：
FROM golang:1.22@sha256:abc... - 运行阶段：
FROM alpine:3.19@sha256:def... - 误写成
FROM golang:1.22+COPY --from=0 /app /app，会导致运行阶段基础镜像未锁定，仍存在供应链风险 - CI 流水线建议加入静态检查：扫描所有 Dockerfile，拒绝未含
@sha256:的FROM行
本地构建时验证已缓存层是否仍匹配 digest
BuildKit 默认启用缓存，但若本地已有旧版镜像，需确保其 digest 与当前指令一致：
- 运行
docker images --digests | grep ubuntu查看本地是否存在匹配的 digest - 若不存在，Docker 会自动拉取；若存在但 digest 不匹配，BuildKit 会跳过复用，强制重新拉取并校验
- 可加
--no-cache强制跳过缓存，确保每次均按 digest 严格校验，适合安全敏感场景
