核心思路是每次提交触发流水线自动构建、打唯一标签、推送镜像并通知部署，关键在于标签需可追溯可回滚且发布与构建强绑定；推荐使用提交哈希、分支+时间戳、语义化版本+哈希等组合标签方式，生产环境至少保留主版本号和完整精确标签；构建阶段须在单步内完成打标与推送；发布动作必须依赖镜像推送成功，建议用 digest 部署并可加人工确认；最后需定期清理旧镜像。
核心思路很直接：每次代码提交触发流水线，自动构建镜像、打唯一标签、推送到镜像仓库，再通知部署系统拉取新镜像。关键不在“能不能做”，而在于标签怎么打才可追溯、可回滚，以及发布动作怎么和构建结果强绑定。
标签必须带可识别的唯一标识
只用 latest 标签是危险的——它不记录来源，无法定位问题版本，也容易被覆盖。推荐组合使用以下几种标签方式：
-
提交哈希（SHA）：比如
myapp:abc1234，对应 Git 提交 ID 前 7 位，精准可查，适合开发和测试环境； -
分支 + 时间戳：如
myapp:main-20260616-1325，便于区分不同分支的构建批次； -
语义化版本 + 提交哈希：如果项目已定义 version（如 package.json 或 pom.xml 中），可用
myapp:v2.3.0-abc1234，兼顾人工理解和机器识别； - 生产环境建议至少保留两个标签：主版本号（如 v2） 和 完整精确标签（如 v2.3.0-abc1234），前者用于滚动更新，后者用于紧急回退。
构建阶段就完成打标与推送
镜像构建不能分两步走（先 build 再 tag 再 push），必须在单个步骤里完成，避免中间状态出错。以 GitHub Actions 为例：
- 用
docker/build-push-action@v4插件，在with.tags字段一次性写入多个标签； - 确保
push: true开启，且登录镜像仓库的动作（docker/login-action）已在前序步骤完成； - 不要在本地执行
docker tag或docker push命令——流水线环境应完全隔离，所有操作由 CI 工具驱动。
发布动作必须依赖镜像推送成功
“发布”不是指把镜像传上去就完事，而是让运行环境真正切换到新版。这需要：
- 部署步骤（如 kubectl rollout restart 或 docker-compose pull + up）放在 push-image 任务之后，并设置
needs: push-image显式声明依赖； - 如果是 Kubernetes，推荐用 镜像 digest（sha256） 替代标签部署，彻底规避标签被覆盖的风险（需在流水线中解析
docker build --quiet输出获取 digest）； - 生产环境发布前可加人工确认环节（如 GitHub Actions 的
environment: production配合 approval），但标签生成和镜像推送仍全自动。
别忘了清理旧镜像
长期运行后镜像仓库会堆积大量历史版本，既占空间又增加管理成本。可在流水线末尾加一步清理逻辑：
- 调用镜像仓库 API（如 Harbor 的
/projects/{project_name}/repositories/{repo_name}/artifacts）列出旧版本； - 按标签匹配规则（如排除
v[0-9]+主版本、保留最近 5 个 SHA 标签）筛选； - 用
curl -X DELETE删除过期镜像——注意权限配置和误删防护。
