优化 Docker 发布流程，默认单架构构建

[Zker67]

背景

当前 Docker 发布流程固定构建 linux/amd64,linux/arm64，普通分支构建和手动触发都会启用多架构构建与 QEMU，耗时较长。

改动

• main 分支 push 触发 Docker 发布流程，默认只构建 linux/amd64。
• tag 发布仍构建 linux/amd64,linux/arm64，保留正式版本的多架构镜像。
• workflow_dispatch 新增 platforms 输入，默认 linux/amd64，需要时可手动指定多架构。
• 仅在目标平台包含 arm 时启用 QEMU。
• 单架构构建使用 cache-to=type=gha,mode=min，多架构构建继续使用 mode=max。

验证

• git diff --check
• Python 解析 .github/workflows/docker-publish.yml
• go run github.com/rhysd/actionlint/cmd/actionlint@latest .github/workflows/docker-publish.yml
• 本地模拟新增 bash 逻辑：
  • 手动默认：linux/amd64 + cache_mode=min
  • tag 发布：linux/amd64,linux/arm64 + cache_mode=max
  • branch push：linux/amd64 + cache_mode=min
  • 手动多架构输入：linux/amd64,linux/arm64 + cache_mode=max

Closes #9

[github-actions]

AI PR Review

Decision: comment
Confidence: 0.88

Summary

整体改动方向合理：按触发场景动态选择平台并优化缓存策略，能显著降低常规构建耗时。工作流语法和主要逻辑看起来一致，未发现明确阻断合并的问题。

Findings

1. [minor] .github/workflows/docker-publish.yml:40 - Set up QEMU 的启用条件仅判断平台字符串是否包含 arm。但 workflow_dispatch 的 platforms 输入是通用的，若手动传入 linux/s390x、linux/ppc64le 等非 arm 的跨架构平台，将不会启用 QEMU，可能导致构建失败。建议将条件改为检测“是否包含非 amd64 平台”或显式限制输入仅允许 amd64/arm64。
2. [minor] .github/workflows/docker-publish.yml:35 - 手动输入 platforms 缺少兜底校验。当前仅做了去空白处理，若输入为空串（例如仅空格）会将空值写入 platforms 输出，后续 build-push-action 可能报错。建议在标准化后为空时回退到 linux/amd64 或直接 fail fast 给出明确错误。

Recent Comment Summary

建议补充 platforms 输入的健壮性：1) QEMU 条件不要只匹配 arm，避免其他跨架构输入构建失败；2) 对空输入增加兜底或失败提示。其余变更思路清晰，可读性也不错。

[Zker67]

补充 CI 说明：

• review 检查已通过。
• enforce 检查失败不是本 PR 的 Docker workflow 改动导致的。日志显示 PR 已指向 dev，但 PR Target Branch workflow 在尝试删除 wrong-target-branch label 时触发 GitHub API 403：Resource not accessible by integration。
• 本 PR 的目标分支是 dev，符合仓库要求。

[github-actions]

AI PR Review

Decision: comment
Confidence: 0.90

Summary

整体改动方向清晰，流程逻辑自洽：按触发类型选择平台、按平台条件启用 QEMU、并根据单/多架构切换 GHA cache mode，能够达到“默认单架构提速、正式发布保留多架构”的目标。未发现会直接导致流程错误或发布失败的阻塞问题。

Findings

1. [minor] .github/workflows/docker-publish.yml:5 - 当前 push 仅监听 main 与 v* tag。若团队仍有“非 main 分支也需要自动构建镜像用于验证”的场景，此改动会使这类构建不再触发。建议在 PR 描述或仓库文档中明确该行为变更是有意收敛，而非遗漏。

Recent Comment Summary

实现质量良好、无阻塞性问题；建议补充文档说明 push 触发范围收敛到 main/tag 的行为变化，避免团队误解。

[zqbxdev]

感谢贡献！PR 已通过 squash merge 合并到 dev：c01f08e ci: optimize docker publish workflow platforms。

合并前我做了增量复查和一个最小 hardening：

• 确认 PR 仍指向 dev，无冲突，改动范围仍仅限 .github/workflows/docker-publish.yml。
• 保留你的核心改动：main push / 手动默认使用 linux/amd64，v* tag release 仍使用 linux/amd64,linux/arm64。
• 补充了 workflow_dispatch 的平台输入校验：空白输入回退到 linux/amd64，仅允许 linux/amd64 / linux/arm64，非法平台会 fail-fast 并输出明确错误。
• 复核了 enforce 失败原因：它仍然来自既有 PR Target Branch workflow 在 PR 已指向 dev 时删除 wrong-target-branch label 触发 403 Resource not accessible by integration，不是本 PR 的 Docker workflow 改动导致。维护者已同意在记录该原因的前提下合并。

验证结果：

• git diff --check 通过。
• PR 的 AI review check 通过。
• 本地模拟 workflow 逻辑通过：tag 多架构、main 单架构、手动默认单架构、手动多架构、空白输入回退、非法平台拒绝。
• 合并后 dev 已 fast-forward 到 c01f08e。

再次感谢你对 Docker 发布耗时优化的贡献。