GOOS和GOARCH供go build使用，决定目标平台的二进制格式、系统调用封装及链接行为，需同时设置且影响交叉编译结果。
GOOS和GOARCH到底设给谁用？
它们只影响 go build 命令本身，不改变源码逻辑，也不需要改 import 或重写函数。Go 编译器在构建阶段根据这两个环境变量决定目标平台的二进制格式、系统调用封装和默认链接行为。
常见错误现象：go build 成功但生成的可执行文件在目标机器上报 cannot execute binary file: Exec format error——大概率是 GOOS/GOARCH 没对上，或者用了 CGO 但没关掉。
-
GOOS控制操作系统类型（如linux、windows、darwin） -
GOARCH控制 CPU 架构（如amd64、arm64、386） - 两者必须同时设置，单独设一个无效（除非当前 shell 已预设另一个）
- 交叉编译不依赖目标平台的 SDK 或运行时，Go 自带全部支持（除少数需 CGO 的场景）
Windows 上编译 Linux 二进制为什么失败？
绝大多数情况是因为启用了 CGO。Go 默认在非本地平台交叉编译时禁用 CGO，但如果你显式设置了 CGO_ENABLED=1，又没配好对应平台的 C 工具链（比如 x86_64-linux-gnu-gcc），就会报错 exec: "gcc": executable file not found in $PATH 或链接失败。
- 纯 Go 程序：直接
GOOS=linux GOARCH=amd64 go build -o app-linux . - 含
net、os/user、os/exec等包的程序：默认走纯 Go 实现，安全 - 用了
cgo（比如调了 SQLite、OpenSSL 或 syscall.RawSyscall）：必须关 CGO，或装交叉工具链 - 临时关 CGO：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o app-arm64 .
darwin/arm64 编译成 darwin/amd64 报错 undefined: syscall.Stat_t？
这不是架构问题，是 Go 标准库里部分 syscall 类型在不同 GOARCH 下字段名或内存布局不同。macOS 上从 arm64 编译到 amd64 属于“同 OS 跨架构”，但 Go 不保证 syscall 兼容性——尤其当你手动用了 syscall 包里的结构体时。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 避免直接操作
syscall.Stat_t、syscall.Utsname这类底层类型 - 优先用
os.Stat()、runtime.GOOS等高层抽象 - 如果必须用 syscall，加构建约束：
//go:build darwin && amd64，并为每种组合单独实现 - 检查
go env GOOS GOARCH确认当前会话值，避免被 IDE 或脚本意外覆盖
交叉编译后体积暴涨，是不是有问题？
不一定。体积变化主要来自三方面：静态链接开关、调试符号、模块依赖。Go 默认静态链接，但启用 CGO 后会动态链接 libc；而 CGO_ENABLED=0 时所有依赖都打进二进制，可能变大也可能变小。
- 去掉调试信息：
go build -ldflags="-s -w" -o app . - 确认是否引入了未使用的 module（比如误 import 了
_ "net/http/pprof"） -
darwin/amd64二进制在 Apple Silicon Mac 上跑得慢？不是编译问题，是 Rosetta 2 转译开销，跟 Go 无关 - ARM64 Linux 二进制在树莓派上启动报
no such file or directory？可能是 glibc 版本太低，换GOOS=linux GOARCH=arm64 CGO_ENABLED=0试试
跨平台编译最常被忽略的一点：时间戳和构建路径会写进二进制（通过 -ldflags "-X main.version=..." 可控），但 debug.BuildInfo 里的 Path 和 Dir 仍是本地路径——别拿它做部署校验依据。
