以下是各个sh脚本的使用时机和对应步骤，结合cnb.yml中的流程说明：

• 功能：解析Docker镜像名称（去除digest、处理路径结构、补全tag为:latest、替换/为-等）。
• 使用时机：在web_trigger_docker_sync流程中。
• 具体步骤：
  对应cnb.yml中web_trigger_docker_sync的 stages -> 名称: 获取新的镜像名字阶段，脚本通过sh /workspace/parse_image_name.sh ${image}执行，作用是将输入的原始镜像名（${image}）处理为规范化的新镜像名，并通过exports导出为环境变量NEW_IMAGE，供后续复制镜像时使用。

• 功能：检查指定镜像是否支持目标架构（如amd64、arm64等）。
• 使用时机：在web_trigger_docker_sync流程中。
• 具体步骤：
  对应cnb.yml中web_trigger_docker_sync的stages -> 名称: 检查是否存在对应架构阶段。当skipArchCheck为false且arch不为all时，执行sh /workspace/check_image_arch.sh ${image} ${arch}，验证原始镜像（${image}）是否支持目标架构（${arch}），若不支持则流程终止。

在你新的流水线配置中，check_image_arch.sh 这个脚本已经用不到了，其他脚本（convert_image.sh、parse_image_name.sh、get_filename.sh）仍在被使用，具体说明如下：

用不到的脚本：check_image_arch.sh

• 原因：在旧的流水线中，check_image_arch.sh 用于“检查镜像是否支持目标架构”（如验证 amd64/arm64 是否存在），对应阶段是 检查是否存在amd64架构 或 检查是否存在arm64架构。
• 新流水线变化：新的 web_trigger_docker_sync 流程中，已经删除了“架构检查”的相关阶段，直接通过 docker buildx build --platform 推送多架构镜像（即使源镜像不支持某架构，buildx 会报错但不影响其他架构推送，且你的场景更关注“同步”而非“校验”）。
• 结论：check_image_arch.sh 已无调用处，可删除或保留（不影响流水线运行）。

• 功能：将原始镜像名转换为腾讯云加速源的镜像名（如mirror.ccs.tencentyun.com前缀）。
• 使用时机：在web_trigger_docker_sync和web_trigger_docker_package两个流程中。
• 具体步骤：
  • 在web_trigger_docker_sync的 stages -> 名称: 获取镜像对应的腾讯加速源的名字阶段，通过sh /workspace/convert_image.sh ${image}执行，导出为MIRROR_IMAGE，用于后续从腾讯加速源复制镜像。
  • 在web_trigger_docker_package的 stages -> 名称: 获取镜像对应的腾讯加速源的名字阶段，执行相同脚本，同样导出MIRROR_IMAGE，用于后续从加速源拉取镜像并打包。

• 功能：从URL中提取文件名（优先从响应头Content-Disposition提取，其次从URL路径提取），并添加时间戳。
• 使用时机：在web_trigger_offline_download流程中。
• 具体步骤：
  对应cnb.yml中web_trigger_offline_download的 stages -> 名称: 获取文件的名字阶段，通过sh /workspace/get_filename.sh ${url}执行，导出为FILE_NAME，用于后续下载文件（curl -L ${url} -o ${FILE_NAME}）和上传附件。

• 功能：处理API触发的多架构镜像同步，通过docker buildx构建并推送多架构镜像，实现“单标签关联多个架构”（与web事件的多架构逻辑对齐）。
• 使用时机：在api_trigger_four流程中。
• 具体步骤：
  对应cnb.yml中api_trigger_four的stages -> 名称: 同步镜像阶段，通过bash docker-build.sh $img执行。脚本接收两个核心参数：
• 输入的原始镜像名（$img，如nginx:latest）；
• 目标架构列表（从环境变量$arch获取，如amd64,arm64）。

脚本的核心逻辑包括：

1. 解析原始镜像的名称和标签（补全默认标签latest、处理路径特殊字符）；
2. 将架构列表转换为docker buildx支持的格式（如linux/amd64,linux/arm64）；
3. 调用docker buildx build --platform <架构列表> --tag <目标镜像> --push，构建并推送多架构镜像（目标镜像标签无架构后缀，如docker.cnb.cool/repo/nginx:latest）；
4. 通过exports导出同步结果（成功的镜像地址到CUSTOM_ENV_RESULT_INFO，状态码到CUSTOM_ENV_RESULT_CODE），供后续“打印指定镜像构建结果”阶段使用。

新增的docker-build.sh是api_trigger_four流程的核心脚本，专为API触发的多架构镜像同步设计，复用了web事件中docker buildx的多架构构建逻辑，实现了“单标签包含多架构”的效果，与web_trigger_docker_sync的镜像同步逻辑保持一致。

目前所有脚本的分工清晰：

• parse_image_name.sh、convert_image.sh服务于web触发的镜像同步和打包；
• get_filename.sh服务于web触发的离线文件下载；
• docker-build.sh服务于API触发的多架构镜像同步；
• 已废弃的check_image_arch.sh因新流程不再需要架构预校验，可移除。

这些脚本共同支撑了cnb.yml中定义的四大核心流程（web_trigger_docker_sync、web_trigger_docker_package、web_trigger_offline_download、api_trigger_four），实现了镜像同步、打包、文件下载等自动化任务的标准化处理。