Go项目自动发布需在push语义化版本tag（vX.Y.Z）后，由GitHub Actions触发构建：固定Go版本、用-ldflags注入Version/Commit/Date并裁剪符号表、交叉编译多平台二进制、原子化生成SHA256SUMS及签名、上传至GitHub Release；go install仅用于开发安装，不可替代正式发布流程。
Go 项目如何用 GitHub Actions 自动打 tag 并发布 release
Go 项目本身不内建版本发布机制，go mod 依赖的是 Git tag（如 v1.2.3），所以自动发布本质是：在 push tag 后，由 CI 触发构建二进制、生成 checksum、上传到 GitHub Release。关键不是“Go 怎么发版”，而是“怎么让 Git tag 触发可信的构建与归档”。
- 必须用语义化版本 tag（
vX.Y.Z格式），GitHub Actions 的on.push.tags才能匹配 - 避免手动
git tag -a v1.2.3 -m "release"后直接git push --tags—— 这会跳过 PR 审核，建议改用 GitHub UI 创建 draft release 或配合gh release create - 构建时需固定 Go 版本（如
go version go1.21.6 linux/amd64），否则不同环境产出的二进制sha256sum不一致，checksum 文件会失效
release workflow 中必须设置的 Go 构建参数
Go 编译出的二进制默认含调试信息、符号表，体积大且不利于校验。自动发布时应裁剪并注入版本信息，否则所有 release 包看起来都一样，无法追溯来源。
- 用
-ldflags注入Version、Commit、Date：go build -ldflags="-s -w -X 'main.Version=${{ github.event.release.tag_name }}' -X 'main.Commit=${{ github.sha }}' -X 'main.Date=$(date -u +%Y-%m-%dT%H:%M:%SZ)'" -o bin/myapp ./cmd/myapp -
-s去除符号表，-w去除 DWARF 调试信息 —— 二者可减少 30%~50% 体积 - 交叉编译多平台时，显式指定
GOOS/GOARCH（如GOOS=linux GOARCH=arm64 go build），不要依赖本地环境
生成并上传 checksum 文件的可靠做法
用户下载 release 二进制后需验证完整性，但 GitHub Release 界面不自动提供 SHA256SUMS。手动计算易出错，CI 中必须原子化生成并和二进制一起上传。
Evez Github Manager
下载
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
- 在构建完所有平台二进制后，统一用
shasum -a 256 bin/* > SHA256SUMS生成清单 - 必须对
SHA256SUMS本身再签名（如用gpg --clearsign SHA256SUMS），否则攻击者可同时篡改二进制和 checksum 文件 - 上传时用
gh release upload ${{ github.event.release.tag_name }} bin/ SHA256SUMS，确保它们出现在同一 release 页面下
为什么不能只靠 go install 或 go get 发布
Go 1.17+ 已弃用 go get 安装可执行程序，go install some@v1.2.3 仅适用于模块路径含 /cmd/xxx 的包，且要求该模块已发布到 proxy.golang.org。它不生成平台专用二进制，也不附带 license、changelog 或 checksum —— 这些是正式 release 的基本要素。
立即学习“go语言免费学习笔记（深入）”；
-
go install是开发侧快捷安装方式，不是发布流程；它绕过构建环境约束，无法保证 reproducible build - 若项目未开启 Go Module Proxy（或用户禁用），
go install会直连源码仓库，失败率高、无缓存、不可审计 - 企业级交付必须提供 tar.gz / zip 归档 + 多平台 binary + 签名 checksum，这些只能靠 CI 构建 pipeline 完成
真正卡点的往往不是 Go 语法或命令，而是 tag 触发时机、ldflags 注入一致性、checksum 生成与签名的原子性 —— 少一个环节，用户下载的包就失去可信基础。
