goreleaser 默认配置不可直接用于 cli 发布，必须显式配置 builds.main、archives.name_template、replacements 等字段，并启用 checksum 和签名；否则二进制无版本、windows 无法运行、归档名不匹配、校验失败。
goreleaser 不是装完就能发 CLI，必须改 .goreleaser.yml，否则连版本号都嵌不进二进制，Windows 用户双击打不开，checksum 也不生成。
为什么 goreleaser init 生成的配置不能直接用
它默认只编译当前目录下所有 .go 文件，而真实 CLI 项目几乎都有 cmd/myapp/main.go 这类结构。不改 builds[].main，要么报 no Go files in .，要么打包出错的二进制。
-
builds[].main必须显式设为入口路径，例如./cmd/cli/main.go -
builds[].binary要设成最终文件名（myapp或myapp.exe），否则 Windows 下没后缀，双击无反应 - 默认不启用
-ldflags注入版本，得手动加：flags: ["-ldflags=-X main.version={{.Version}}"] - 如果项目用 Go modules，
builds[].env得包含GO111MODULE=on
交叉编译产物命名怎么匹配用户习惯
默认名如 myapp_1.2.3_darwin_arm64，但用户搜的是 macos-arm64 或 windows-amd64.zip，不改就等于发布失败。
- 在
archives块里设name_template: "{{ .ProjectName }}-v{{ .Version }}-{{ .Os }}-{{ .Arch }}{{ if eq .Os \"windows\" }}.exe{{ end }}" - 用
replacements映射系统名：darwin: macos、386: i386、amd64: x86_64 - 要加 zip 包，得设
archives[].format: zip；只留tar.gz，Windows 用户得额外装解压工具 - 别依赖
builds[].binary控制归档内文件名——它只影响构建输出，不影响 archive 打包逻辑
GITHUB_TOKEN 权限不足时错误提示有多误导
报错常是 401 Bad credentials 或 422 Validation Failed，看起来像 token 没传，实际是权限不够。
- 公开库必须勾选
public_repo，私有库必须勾选repo；只开read:packages没用 - CI 中用
${{ secrets.GITHUB_TOKEN }}是够的，但仓库 Settings → Actions → General → “Workflow permissions” 必须设为 “Read and write permissions”，否则 private 仓库根本创建不了 release - 本地测试先跑
GITHUB_TOKEN=xxx goreleaser build --snapshot，验证命名和构建逻辑，避免反复 push tag - CI 报
command not found: goreleaser？GitHub Actions 默认不预装，得用curl -sL https://git.io/goreleaser | sh显式安装
checksum 和签名不是可选项，而是信任底线
不生成 checksums.txt，下游无法校验二进制是否被篡改；不签名，GitHub Release 页面不显示“verified”标识。
-
checksums.name_template必须含{{ .ProjectName }}，否则多个版本会覆盖同一份 checksum 文件 -
sign默认关闭，需手动配 GPG；公钥必须已上传到 GitHub Settings → SSH and GPG keys - 签名私钥不能硬编码进配置，CI 中用
secrets.GPG_PRIVATE_KEY注入，配合armor: true - ARM 架构编译慢、体积大，可在 CI 中对特定平台设
builds[].skip: true，但本地发布前务必至少跑一次全平台验证
真正卡住人的从来不是 goreleaser 本身，而是 .goreleaser.yml 里那些默认关闭、默认不映射、默认不校验的开关——它们安静地让 release 看起来“成功了”，直到用户反馈“下载的文件打不开”或“校验失败”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
