go build无-arch参数，必须用goos和goarch环境变量组合指定目标平台，如goos=linux goarch=arm64；漏设任一将生成主机二进制，导致exec format error。
Go build -arch 参数根本不存在
Go 官方 go build 命令没有 -arch 这个参数，试图运行 go build -arch arm64 会直接报错：flag provided but not defined: -arch。真正控制目标架构的是环境变量，不是命令行开关。
构建跨架构二进制的核心是组合设置 GOOS 和 GOARCH，例如：
GOOS=linux GOARCH=arm64 go build -o myapp-arm64 .
常见组合包括：GOOS=windows GOARCH=amd64、GOOS=darwin GOARCH=arm64、GOOS=linux GOARCH=386。注意 GOARCH=amd64 和 GOARCH=arm64 是标准值，而 GOARCH=x86_64 或 GOARCH=aarch64 是无效的，会被忽略或导致构建失败。
CGO_ENABLED=0 不是万能，但跨平台编译时往往必须关
启用 CGO（即 CGO_ENABLED=1）会让 Go 编译器调用本地 C 工具链（如 gcc），这会导致两个问题：一是无法在 macOS 上直接交叉编译 Linux ARM64 二进制（因为没装 aarch64-linux-gnu-gcc），二是生成的二进制会动态链接 libc，失去“纯静态”优势。
除非你明确依赖 cgo 功能（比如调用 C.sqlite3_open 或读取 /etc/resolv.conf），否则跨架构构建应强制禁用：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o myapp .
- 禁用后生成的二进制不依赖系统 libc，可直接扔进 Alpine 容器运行
- 若项目里用了
import "C"或间接依赖 cgo 包（如net包在某些 GOOS 下默认启用 cgo），构建会失败，需检查go env CGO_ENABLED并确认依赖是否真需要 cgo - Windows 下默认
CGO_ENABLED=1，但构建纯 Go 程序时设为 0 通常也没问题
GOARM 和 GOMIPS 只对特定 GOOS/GOARCH 生效
GOARM 仅在 GOOS=linux 且 GOARCH=arm（注意不是 arm64）时起作用，用于指定 ARM 指令集版本（GOARM=6 或 GOARM=7）。设成 GOARM=8 会静默忽略 —— 因为 Go 不支持 ARMv8 的 32 位模式。
同理，GOMIPS 和 GOMIPS64 只在对应 MIPS 架构下生效，现代项目极少用到。误设它们（比如在 GOARCH=arm64 时配 GOARM=7）完全无效，也不会报错，容易让人误以为配置起了作用。
当前主流场景只需关注：GOOS + GOARCH，其余环境变量属于窄口径兼容需求。
交叉编译时 syscall 和 net 包行为可能突变
同一个 Go 源码，在 GOOS=linux GOARCH=arm64 下编译后运行，和在 GOOS=darwin GOARCH=arm64 下的行为可能不同 —— 尤其是涉及系统调用的部分。例如：
-
os.UserHomeDir()在 Windows 返回%USERPROFILE%，Linux 返回$HOME，darwin 同样返回$HOME，但路径分隔符和权限模型不同 -
net.Listen("tcp", ":8080")在 Linux 可能绑定0.0.0.0:8080，在某些容器网络下实际暴露的是 IPv6 地址，而 macOS 默认只监听 IPv4 - 使用
syscall包直接调用系统 API 的代码，几乎必然在跨 GOOS 时崩溃，这类代码应封装并按//go:build条件编译
最稳妥的做法是：在目标架构的真实环境中运行测试，而不是只依赖本地交叉编译结果。CI 流程里用 QEMU 或云上 ARM 实例跑集成测试，比在 x86 Mac 上 build 出一个 linux/arm64 二进制然后假定它能跑更可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
