goreleaser init 后必须手动修改 .goreleaser.yml：指定 builds[].main 入口、builds[].binary 名（Windows 需 .exe）、archives[].format 加 zip；GitHub token 需 repo,delete_repo,workflow 权限；补全 goos/goarch 笛卡尔积；启用 checksums 并配置 GPG 签名，私钥通过 secrets 安全注入。
goreleaser init 之后必须手动改 .goreleaser.yml
运行 goreleaser init 只生成一个基础模板，几乎不能直接用。它默认打包的是当前目录下所有 Go 文件编译出的二进制，但真实项目通常有 main.go 在子目录（比如 cmd/myapp/main.go），不改配置就会编译失败或打错包。
关键要改三项：
-
builds[].main：指定入口文件路径，例如./cmd/myapp/main.go -
builds[].binary：控制输出的二进制名，避免默认用目录名（如myapp而不是cmd） -
archives[].format：默认是tar.gz，如果想兼容 Windows 用户，得加zip格式
GitHub token 权限不够会导致 release failed: HTTP 403 Forbidden
Goreleaser 需要调 GitHub API 创建 release、上传 asset，只给 repo 权限还不够——必须勾选 delete_repo（实际用于覆盖旧 draft）和 workflow（部分版本会校验）。更稳妥的做法是用 gh auth login --scopes repo,delete_repo,workflow 重新登录。
另一个常见现象：本地 goreleaser release --snapshot 成功，但 CI 中失败。这是因为 CI 环境没设 GITHUB_TOKEN，或用了只读 token。确认方式：echo $GITHUB_TOKEN | cut -c1-10 看是否为空或过短。
立即学习“go语言免费学习笔记（深入）”；
交叉编译时 builds[].goos 和 goarch 列不全就漏平台
默认配置只列了 linux/darwin/windows，但用户可能需要 arm64 macOS、amd64 Windows、甚至 armv7 Linux（树莓派）。少写一个组合，对应平台的包就完全不会生成。
实操建议：
- 明确支持哪些平台，按需填
goos和goarch的笛卡尔积，别依赖默认值 - Windows 下注意
binary名要带.exe后缀（binary: "myapp.exe"），否则 zip 包里文件没扩展名，用户双击打不开 - ARM 架构二进制体积大、编译慢，可在 CI 中用
builds[].skip: true临时跳过，但本地测试务必跑一次
checksums 和 signature 文件不是可选项，而是发布可信度底线
不生成 checksums.txt 或 signature，下游用户无法验证二进制是否被篡改。Goreleaser 默认开启 checksums，但容易被注释掉；sign 则完全默认关闭，需手动配 GPG。
要点：
-
checksums.name_template必须含{{ .ProjectName }}，否则多个版本 checksum 文件会覆盖 - 签名要用能被 GitHub 验证的 GPG key（即公钥已上传到 GitHub Settings → SSH and GPG keys）
- CI 中执行
goreleaser release前，得先gpg --import /path/to/secring.gpg并设GOPASS_ALLOW_STUB=true（避免交互式密码提示卡住）
最常被忽略的是：签名私钥泄露风险。别把私钥硬编码进 CI 配置，用 secrets manager 注入，且权限设为只读一次。
