docker镜像发布规范要求构建—标记—推送—使用全链路确定性：必须用声明式dockerfile（显式基础镜像版本、.dockerignore、多阶段构建、run内清理）；标签强制语义化（vx.y.z主标签+环境/元数据后缀）；推送前须通过漏洞扫描、基础信息检查、体积比对；仓库按环境分级且标签不可变；拉取端强制校验digest。
定 Docker 镜像发布规范，核心是把“构建—标记—推送—使用”整条链路变成可预期、可审计、可回滚的确定性过程。不是写一堆规则让人背，而是让每一步操作自然导向安全、稳定和协作友好。
镜像构建必须用 Dockerfile + .dockerignore
禁止直接 commit 容器生成镜像，也不接受手工打包上传。所有镜像必须由声明式 Dockerfile 构建，确保可复现。
- Dockerfile 必须显式指定基础镜像版本（如 python:3.11.9-slim），禁用
:latest - 必须配套 .dockerignore 文件，至少过滤：
.git、node_modules、.env、*.log、.venv - 推荐启用多阶段构建：编译与运行环境分离，最终镜像只含运行时必需文件
- 每层 RUN 指令内完成安装+清理（如
apt update && apt install -y xxx && rm -rf /var/lib/apt/lists/*）
标签命名强制语义化 + 环境标识
一个镜像可以有多个标签，但必须有一个不可变的语义化主标签（vX.Y.Z），其他为辅助标签。
- 主标签格式严格为 v{MAJOR}.{MINOR}.{PATCH}（如
v2.1.4），对应 Git tag - 生产环境只允许拉取带
v前缀的明确版本，严禁使用latest或dev类浮动标签 - 可叠加环境后缀：
v2.1.4-prod、v2.1.4-test；或元数据后缀：v2.1.4-git-7f3a1b2、v2.1.4-build-20260730 - CI 流水线中自动从 Git tag 提取版本号，避免人工输入错误
推送前必做三件事
不是 build 完就 push，中间必须卡点验证，防止问题镜像流入仓库。
- 镜像扫描：用 Trivy 或 Docker Scout 扫描 CVE，高危漏洞未修复不得推送
-
基础信息检查：确认已设置
WORKDIR、非 rootUSER、HEALTHCHECK和必要LABEL（如org.opencontainers.image.source） - 体积基线比对：对比上一版镜像大小，突增 >15% 需人工确认原因（如误 COPY 大文件）
仓库与权限按环境分级管理
不同环境对应不同仓库路径和推送权限，避免测试镜像污染生产命名空间。
- 生产镜像推送到
registry.example.com/prod/{app}，仅 release pipeline 有写权限 - 测试/预发镜像走
registry.example.com/staging/{app}，开发分支可触发 - 所有镜像仓库开启不可变标签（immutable tags）策略，已推送的
vX.Y.Z标签禁止覆盖 - 镜像拉取端强制校验 digest（如
@sha256:abc...），不依赖标签做唯一标识
