go交叉编译必须显式设置goos和goarch且成对使用，生产环境须设cgo_enabled=0以避免动态链接失败；资源需手动分发或embed内嵌；逻辑须适配目标系统行为。
Go 交叉编译不是“配好环境就能跑”，而是必须显式设置 GOOS 和 GOARCH，且绝大多数生产场景下必须关闭 CGO_ENABLED=0，否则二进制会动态链接 libc 或 Windows CRT，导致目标机器运行失败。
GOOS 和 GOARCH 必须成对指定，缺一不可
Go 默认只构建当前宿主机平台（比如 macOS 上执行 go build 得到的是 darwin/amd64）。要生成其他平台程序，GOOS 和 GOARCH 必须同时出现在命令行或环境变量中：
GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 main.go-
GOOS=windows GOARCH=amd64 go build -o app.exe main.go（Windows 平台必须加.exe后缀） - 单独设
GOOS=linux而不设GOARCH，仍会生成当前架构（如darwin/amd64），不会自动 fallback 到amd64
不确定支持哪些组合？直接运行 go tool dist list 查看所有合法值。Go 1.21+ 已原生支持 windows/arm64 和 darwin/arm64，旧版本（如 1.16 前）对 darwin/arm64 可能报 unsupported GOOS/GOARCH pair。
CGO_ENABLED=0 不是可选项，而是生产部署前提
启用 CGO（即 CGO_ENABLED=1，默认值）会让 Go 调用 C 标准库、系统 API 或第三方 C 依赖（如 github.com/mattn/go-sqlite3）。交叉编译时，宿主机没有目标平台的头文件（如 windows.h）和 C 工具链，必然失败。
- 纯 Go 项目（无
// #cgo、未import "C"、不依赖含 C 的包）：务必加CGO_ENABLED=0 - 含 C 依赖的项目：不能简单关 CGO；要么在目标机器上构建，要么用 Docker 模拟目标环境（如
docker run --rm -v $(pwd):/app -w /app golang:1.21-alpine-arm64 go build -o app main.go） - 即使关了 CGO，Windows 上若
main函数签名是func WinMain（GUI 程序），双击可能无响应；命令行工具请确保是func main()
资源路径和动态依赖不会随二进制自动打包
交叉编译只处理 Go 源码，不会打包配置文件、模板、证书、SQLite 数据库或 .so/.dll 动态库。这些必须手动分发，并在代码中用可靠方式定位：
- 避免硬编码相对路径（如
"./config.yaml"），启动时用os.Executable()获取二进制路径再拼接：filepath.Dir(exePath) + "/config.yaml" - 如果用了 embed（Go 1.16+），静态资源可内嵌，但注意
//go:embed不支持跨平台条件编译，嵌入内容在构建时就已固化 - Linux 下生成的
arm64二进制，若依赖libsqlite3.so，需额外提供对应架构的 so 文件并确保LD_LIBRARY_PATH正确——关 CGO 才能彻底规避这类问题
自动化多平台构建脚本要防变量污染和缓存干扰
写 Shell 脚本批量构建时，常见错误是环境变量泄漏或复用旧缓存：
- 每个
go build命令前都应显式设置全部变量，不要依赖上一轮残留（例如GOOS在循环里没重置） - 加
-a参数强制全部重新编译：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -o bin/app-linux-amd64 main.go - Windows 用户在 PowerShell 中需用
$env:GOOS="linux"而非SET GOOS=linux，CMD 和 PowerShell 语法不兼容 - CI 流水线中建议清理模块缓存：
go clean -modcache，避免本地go.sum错误影响跨平台构建一致性
真正容易被忽略的不是怎么设变量，而是关 CGO 后，你写的那段调用 exec.Command("ls") 的代码，在 Windows 上依然会 panic——因为 ls 不存在。跨平台不只是编译通过，逻辑也得适配目标系统行为。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
