goos和goarch必须同时显式设置，缺一不可；仅设其一将生成当前平台二进制，导致运行时报错；cgo_enabled=0是稳定交叉编译的默认安全开关，纯go项目应强制关闭以避免动态链接失败。
交叉编译时 GOOS 和 GOARCH 必须显式指定
不设 GOOS 和 GOARCH，go build 默认只生成当前系统架构的二进制，比如你在 macOS 上跑 go build main.go，只会得到 darwin/amd64 或 darwin/arm64 的可执行文件，没法直接扔到 Linux 服务器上跑。
常见组合示例：
GOOS=linux GOARCH=amd64 go build -o myapp-linux-amd64 ./cmd/myappGOOS=windows GOARCH=amd64 go build -o myapp.exe ./cmd/myappGOOS=linux GOARCH=arm64 go build -o myapp-linux-arm64 ./cmd/myapp
注意：GOARCH=386 已基本淘汰，GOARCH=arm（32 位 ARM）和 arm64 不互通，别混用；macOS 上构建 Windows 二进制必须加 .exe 后缀，否则双击打不开。
CGO_ENABLED=0 是避免运行时依赖的关键开关
默认开启 cgo 会导致二进制动态链接宿主机的 libc、libstdc++ 等，一换系统就报 missing GLIBCXX_3.4.29 或 cannot execute binary file: Exec format error。这类错误不是 Go 本身的问题，而是 cgo 引入的 C/C++ 依赖没对齐。
强制纯 Go 编译的写法：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o myapp ./cmd/myapp- 若项目里用了
net包的 DNS 解析策略（如net.DefaultResolver），cgo 关闭后会退化为纯 Go 实现，行为略有差异，需测试验证 - 用
file myapp看输出是否含statically linked；再用ldd myapp，应返回not a dynamic executable
.goreleaser.yml 里 builds 块必须手动补全
goreleaser init 只生成空骨架，builds 字段压根不会自动推断——它不知道你的 main 在 ./cmd/myapp 还是 ./internal/app，更不会猜你要叫 myapp 还是 myapp.exe。
最小可用配置要包含：
-
builds:下至少一个条目，带id（任意唯一标识）、main（路径，如./cmd/myapp）、binary（输出名，Windows 必须含.exe） -
goos和goarch要列全目标平台，不能只写[linux]就指望它自动补amd64和arm64；推荐显式写成goos: [linux, darwin, windows]+goarch: [amd64, arm64] -
env: ["CGO_ENABLED=0"]写在builds里比写在 CI workflow 中更可靠，避免被环境变量覆盖
多入口（CLI + API server）就得写多个 builds 条目，共用同一个 id 会冲突报错。
GitHub Actions 中 goreleaser release 失败的高频原因
本地 goreleaser release --snapshot 成功不代表 CI 能过，真正卡住的通常是权限和触发逻辑。
检查点：
-
GITHUB_TOKEN必须有contents: write（默认有），但还缺delete_repo（用于覆盖 draft）和packages: write（如果启用了 OCI registry）；用gh auth login --scopes repo,delete_repo,workflow重登最稳妥 - tag 触发规则必须是
push: tags: ['v*']，写成tags: ['*']会忽略v1.2.0以外的 tag，而goreleaser默认只认带v前缀的 tag - CI 中别用个人 token 替代
GITHUB_TOKEN，容易因 scope 不全或 token 过期静默失败；可以用echo "$GITHUB_TOKEN" | wc -c粗略判断是否为空（正常约 50+ 字符）
本地调试建议加 --skip-validate --skip-publish --rm-dist，先确认打包逻辑通不通，别反复打 tag 污染 release 页面。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
