goos和goarch是唯一决定目标平台的开关，cgo_enabled=0可生成纯静态二进制，goroot必须正确指向sdk根目录以确保跨平台编译所需pkg文件可用。
Go 环境搭建和交叉编译不是“配好就能用”的黑盒操作，它直接依赖 Go 工具链对 GOROOT、GOPATH、GOOS/GOARCH 的硬编码识别与运行时链接策略。不理解这点，遇到 exec format error 或 cannot find module providing package 就只能重启重装。
go env 里哪些变量真正影响交叉编译
GOOS 和 GOARCH 是唯一决定目标平台的开关，但它们只在编译瞬间生效，不会写入环境变量持久化——也就是说，export GOOS=linux; go build 有效，而 go build -ldflags="-X main.env=prod" 不会改变目标平台。
-
GOROOT必须指向你安装的 Go SDK 根目录（如/usr/local/go），它包含所有目标平台的pkg/tool和pkg/include；缺失或指向错误会导致build constraints exclude all Go files -
GOPROXY和GOSUMDB影响模块下载，但在交叉编译中不参与代码生成，仅在go mod download阶段起作用 -
CGO_ENABLED是关键分水岭：设为0时禁用 C 调用，生成纯静态二进制；设为1（默认）则需对应平台的cc工具链（如aarch64-linux-gnu-gcc），否则报exec: "aarch64-linux-gnu-gcc": executable file not found
为什么 go build -o app-linux-amd64 在 macOS 上能出 Linux 可执行文件
因为 Go 编译器不依赖宿主机系统调用，而是把运行时（runtime）和标准库（stdlib）预先编译成各平台的目标对象文件，存放在 $GOROOT/pkg/$GOOS_$GOARCH/ 下。比如 go build -o app -ldflags="-s -w" -trimpath 实际做了三件事：
- 从
$GOROOT/src解析源码，生成 AST 和 SSA - 按
GOOS/GOARCH查找对应$GOROOT/pkg/linux_amd64/中的runtime.a、fmt.a等归档文件 - 链接时跳过宿主机 libc，直接嵌入 Go 自带的
runtime调度器和内存分配器
所以你在 macOS 上执行 file app-linux-amd64 会看到 ELF 64-bit LSB executable, x86-64, version 1 (SYSV)，而非 Mach-O。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
gomobile init 为什么必须下载 Android NDK
gomobile init 不只是“初始化”，它实际在做三件底层绑定的事：
- 解析
ANDROID_HOME或自动下载 NDK，并提取其中的toolchains/llvm/prebuilt/下对应aarch64-linux-android-21-clang工具链 - 把 Go 源码编译成
.a静态库后，用 NDK 的clang++封装成 JNI 兼容的libgojni.so，导出Java_XXX_NativeCall符号 - 生成
AndroidManifest.xml和build.gradle时，强制设置minSdkVersion=21—— 因为 Go runtime 的 goroutine 栈切换依赖 ARM64 的LDAXR/STLXR原子指令，低于 API 21 的 Android 内核不保证该指令可用
漏掉 NDK 或版本不对（比如用了 r26 而非推荐的 r25b），gomobile build -target=android 会在链接阶段卡住，日志里出现 undefined reference to '__atomic_load_8'。
go mod tidy 在交叉编译前为什么常被忽略
go mod tidy 表面是清理依赖，实则是触发 go list -deps -f '{{.Stale}}' ./... 检查所有依赖是否已编译为目标平台兼容版本。常见坑点：
- 某个
replace指向本地路径，但该路径下没有go.mod，go build会静默跳过，最终在目标机器上 panic:module xxx not found - 第三方包用了
// +build linuxtag，但你的GOOS=windows，go mod tidy会删掉该依赖，导致编译通过、运行时报nil pointer dereference -
go.sum中记录的校验值基于模块内容哈希，而交叉编译不改变哈希——所以go mod verify无法发现平台不匹配问题
真正安全的做法是：在目标平台环境变量下跑一次 go mod tidy && go test ./...，而不是只在开发机上验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
