必须显式写死基础镜像的完整标签，如FROM python:3.11.9-slim-bookworm或FROM node:22.11.0-alpine3.20；禁用latest、alpine、node等模糊标签，因Docker Desktop不干预FROM语义，仅按字面拉取，未固定版本将导致构建不可复现、不可审计。
必须显式写死基础镜像的完整标签，不能用 latest、alpine 或 node 这类模糊名称——这是构建可复现、可审计镜像的底线。
FROM 指令里怎么写才算“固定版本”
所谓“固定”，是指镜像名中包含明确的操作系统发行版号、语言运行时小版本甚至补丁号。例如：FROM python:3.11.9-slim 是合格的；而 FROM python:3.11 虽比 latest 好，但仍有风险（3.11.10 可能某天自动替换 3.11.9）；FROM node:22-alpine 也不够稳，因为 Alpine 的基础镜像本身可能随时间更新内核或 glibc 行为。
推荐写法包括：
-
FROM python:3.11.9-slim-bookworm（明确 Debian 版本） -
FROM node:22.11.0-alpine3.20（含 Node 和 Alpine 双版本） -
FROM nginx:1.25.4-alpine（官方镜像已带精确 patch 版本）
不推荐写法：
-
FROM ubuntu（默认 latest，即 24.04，但未来会变） -
FROM golang:1.21（可能拉到 1.21.13，而你本地调试用的是 1.21.10） -
FROM alpine（当前是 3.20，但下次构建可能已是 3.21，libc 升级可能引发二进制兼容问题）
Docker Desktop 本身不控制基础镜像版本，它只执行你写的 FROM
Docker Desktop 是个客户端工具，它不干预、不翻译、不缓存你 FROM 指令里的内容。你写什么，它就去 Docker Hub（或你配置的私有仓库）拉什么。所以“配置教程”本质是教你怎么写好 FROM，而不是在 Docker Desktop UI 里点几下就能锁定版本。
常见误解：
- 以为在 Docker Desktop 设置里勾选“Use the Docker Hub mirror”就能固定版本 → 错，这只是换源，不影响标签语义
- 以为 buildx 的
--pull选项能帮你“锁住旧版” → 错，它只是强制拉取远程最新匹配项，反而可能破坏缓存 - 以为本地已有
node:22-alpine镜像，构建就不会再拉 → 错，Docker 构建时仍会校验远程 manifest，若远程该 tag 已被重新指向新 digest，就会拉新层
怎么验证你真的用上了固定版本
构建后别急着跑容器，先查镜像元数据：
- 用
docker inspect my-app:latest | jq '.[0].RootFS.Layers'看最底层是否对应你预期的基础镜像 digest - 用
docker history my-app:latest查第一行，确认 base 镜像 ID 是否与你本地拉过的python:3.11.9-slim-bookworm一致 - 把构建上下文打包发给同事，让他在另一台机器上
docker build -t test .，对比docker images --digests输出的DIGEST列是否完全相同
如果 DIGEST 不同，说明你的 FROM 还没真正固定——大概率是用了带 -slim 但没带 OS 小版本，或依赖了某个多层重定向的 tag。
最易被忽略的一点：基础镜像的 digest 不仅取决于你写的 tag，还取决于你配置的镜像仓库。如果你用了国内镜像加速器，而它同步滞后或做了 tag 覆盖，python:3.11.9-slim-bookworm 在不同 registry 下可能指向不同 digest。真要 100% 可复现，得用完整 digest 引用：FROM python@sha256:abc123...，但这会让 Dockerfile 失去可读性，适合 CI 场景而非日常开发。
