Go build 通过 GOOS 和 GOARCH 环境变量指定目标操作系统和架构，如 GOOS=linux GOARCH=amd64；启用 CGO_ENABLED=0 可避免跨平台编译失败，生成静态二进制；module path 不影响构建平台，但路径硬编码需用 filepath.Join 等适配。
Go build 时如何指定目标操作系统和架构
Go 原生支持跨平台编译，不需要额外工具链，关键靠 GOOS 和 GOARCH 环境变量控制输出二进制的目标平台。不设默认按当前系统生成，设了就交叉编译。
常见组合示例：
GOOS=linux GOARCH=amd64 go build -o myapp-linux-amd64 main.goGOOS=darwin GOARCH=arm64 go build -o myapp-macos-arm64 main.goGOOS=windows GOARCH=386 go build -o myapp-win32.exe main.go
注意：GOOS=windows 生成的文件后缀必须是 .exe 才能双击运行；GOARCH=arm64 在 macOS 上需确认 Go 版本 ≥ 1.16（旧版不支持）；GOARCH=386 实际对应 32 位 x86，不是“x86_64”的简写。
如何避免 CGO 导致跨平台失败
启用 CGO_ENABLED=0 是让 Go 编译纯静态二进制的关键一步。一旦项目依赖 C 库（比如用 os/user、net 包在某些系统上隐式调用 libc），默认开启 CGO 就会导致跨平台编译失败或运行时报错 standard_init_linux.go:228: exec user process caused: no such file or directory（常见于 Alpine 容器中）。
立即学习“go语言免费学习笔记（深入）”；
安全做法：
- 发布前统一加
CGO_ENABLED=0编译：CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o app main.go - 检查是否真禁用了：用
file app查看输出含statically linked即成功 - 若必须用 CGO（如调用 OpenSSL 或 SQLite），则需为目标平台安装对应 C 工具链（如
gcc-arm-linux-gnueabihf），复杂度陡增，不推荐用于简单 CLI 工具发布
go.mod 中的 module path 是否影响跨平台
不影响。module path（如 github.com/you/cli）只用于 Go 的导入解析和版本管理，和构建目标平台完全无关。但要注意：如果你在代码里硬编码了路径分隔符（比如写死 "C:\\config.json" 或 "/etc/app/conf"），那运行时就会出问题。
正确做法是用标准库适配：
- 路径拼接用
filepath.Join("etc", "app", "conf")而非字符串连接 - 配置目录用
os.UserConfigDir()+filepath.Join(...)，它会自动返回%APPDATA%（Windows）、$XDG_CONFIG_HOME（Linux）或~/Library/Application Support（macOS） - 判断当前系统用
runtime.GOOS，但仅限必要逻辑分支（如信号处理：Windows 不支持SIGUSR1）
发布时要不要打包成 tar.gz / zip / MSI
要，但方式取决于用户场景。Go 编译出的是单文件二进制，直接分发可执行文件最轻量；但终端用户更习惯带解压步骤或安装器。
建议策略：
- GitHub Releases 上传所有平台二进制，并各自命名清晰（如
myapp_1.2.0_linux_amd64.tar.gz），内含二进制 + LICENSE + README - macOS 用户期望
.pkg或拖拽安装，可用go-bindata或nfpm打包；Windows 用户可能需要.msi，推荐wixtoolset或inno setup，但多数 CLI 工具用.zip加文档说明即可 - 避免在归档包里嵌套多层目录，解压后应直接看到可执行文件（即
tar -xzf xxx.tar.gz && ./myapp可立即运行）
真正容易被忽略的是版本一致性：每次发布前，确保 go version、GOOS/GOARCH、CGO_ENABLED 都记录在 build.sh 或 CI 配置里，否则半年后重编译很可能因环境差异产出行为不同的二进制。
