Go跨平台构建需显式设置GOOS和GOARCH，禁用CGO_ENABLED=0确保二进制可移植，并用-ldflags注入版本与提交信息，最终归档、校验后发布至GitHub Release。
Go 语言没有“框架打包”这回事 —— 所谓跨平台构建，就是用 go build 配合 GOOS/GOARCH 编译出目标平台的二进制，不依赖框架、不生成中间产物、也不上传到任何中心仓库。
go build 跨平台编译必须设 GOOS 和 GOARCH
不设环境变量时，go build 默认只编译当前系统平台。想发给 Linux 用户，就得显式指定：
GOOS=linux GOARCH=amd64 go build -o myapp-linux ./cmd/myappGOOS=windows GOARCH=amd64 go build -o myapp.exe ./cmd/myappGOOS=darwin GOARCH=arm64 go build -o myapp-macos ./cmd/myapp
注意：GOOS=windows 会自动加 .exe 后缀（即使命令里没写），而其他平台不会自动加后缀；./cmd/myapp 必须包含 main.go 且包名为 main，否则报 no Go files in 错误。
CGO_ENABLED=0 是跨平台稳定的前提
只要项目里用了 net、os/user、sqlite 等默认启用 cgo 的包，交叉编译就大概率失败或生成不可移植的二进制。常见现象包括：
立即学习“go语言免费学习笔记（深入）”；
- Windows 上编译 Linux 二进制时报
exec: "gcc": executable file not found - Linux 二进制在 Alpine 容器里运行时报
not found（实际是 libc 不兼容） - macOS 上编译 Windows 二进制后，执行时报错退出，无日志
解决办法统一：加 CGO_ENABLED=0，例如：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o myapp-arm64 ./cmd/myapp
禁用 cgo 后，net 会回落到纯 Go 实现（慢一点但可靠），os/user 会无法解析用户名（只返回 UID/GID），这是可接受的 trade-off。
-ldflags 注入版本和构建信息不能漏
用户下载了 myapp-linux，却不知道它对应哪个 Git 提交、是否为正式版 —— 这不是体验问题，是运维事故隐患。必须在构建时注入：
- 代码里声明导出变量：
var Version string、var Commit string（注意首字母大写） - 构建命令中用
-X赋值：go build -ldflags="-X 'main.Version=v1.2.3' -X 'main.Commit=abc123'" -o myapp ./cmd/myapp - 单引号必须有，防止 shell 展开；等号前后不能有空格；包路径
main.Version必须和代码中声明完全一致
如果用 Makefile 或 CI 脚本批量构建，建议把 $(shell git describe --tags --always) 和 $(shell date -u +%Y-%m-%dT%H:%M:%SZ) 也塞进去，避免人工维护版本字符串。
发布 ≠ go mod push，而是归档 + 校验 + GitHub Release
go mod 只管源码依赖，不碰二进制。真正面向用户的“发布”，是把多个平台的二进制打包、校验、上传：
- 输出统一放到
dist/目录，文件名带平台标识，如myapp_v1.2.3_linux_amd64 - 生成校验和：
shasum -a 256 dist/* > dist/SHA256SUMS - 压缩时保留权限（Linux/macOS）：
tar -czf myapp_v1.2.3_linux_amd64.tar.gz -C dist myapp_v1.2.3_linux_amd64 - 最终推送到 GitHub Release 页面，附带
SHA256SUMS文件供用户验证
最容易被忽略的是：没关 cgo 就直接发布，导致某台 CentOS 服务器上跑不起来；或者版本号硬编码在代码里，每次发版都要手动改，结果 v1.2.3 的二进制里写着 v1.2.2。
