runtime.GOARCH 直接返回编译时指定的目标 CPU 架构字符串，如"amd64"、"arm64"等，而非运行时系统实际架构；它由GOARCH环境变量或-build参数决定，与宿主机硬件无关。
runtime.GOARCH 能直接拿到什么值
runtime.GOARCH 是 Go 运行时内置的常量，编译时就确定了，代表当前二进制文件的目标 CPU 架构，不是运行时动态探测的系统架构。它反映的是 GOARCH 环境变量或 build 命令指定的架构，和宿主机实际 CPU 可能不一致（比如在 x86_64 机器上交叉编译 arm64 程序）。
常见取值包括：amd64、arm64、386、arm、ppc64le、s390x 等。注意没有 x86_64 或 aarch64 这类 Linux 常用命名，Go 有自己的一套简写规范。
为什么 runtime.GOARCH 不等于 uname -m 的结果
这是最容易混淆的点：runtime.GOARCH 和系统命令 uname -m 没有必然对应关系。例如：
- 在 Apple M1（ARM64）上运行原生
arm64Go 程序 →runtime.GOARCH == "arm64"，uname -m输出arm64（一致） - 在 Intel Mac 上运行 Rosetta 2 转译的
amd64Go 程序 →runtime.GOARCH == "amd64"，但uname -m仍是arm64（不一致） - 在 x86_64 Linux 上交叉编译出
386二进制 →runtime.GOARCH == "386"，而uname -m是x86_64
所以别拿它当硬件探测工具。它只回答一个问题：“这个程序是为哪个架构编译的？”
立即学习“go语言免费学习笔记（深入）”；
想真正获取运行时 CPU 架构该怎么做
如果目标是适配硬件特性（比如调用特定 SIMD 指令、选型压缩库），runtime.GOARCH 不够用。得结合 OS + 架构组合做判断，或者调用系统命令：
- Linux 下可读
/proc/cpuinfo的model name或Architecture字段（注意不同内核版本字段名可能不同） - macOS 下用
sysctl -n hw.machine（返回arm64或x86_64） - Windows 下可用
os.Getenv("PROCESSOR_ARCHITECTURE")，但要注意 32 位进程在 64 位系统上会返回x86 - 更健壮的做法是封装一个 fallback 函数：先试
runtime.GOARCH，再根据runtime.GOOS调用对应系统命令，解析失败则兜底为已知最安全的子集
示例片段：
if runtime.GOARCH == "arm64" && runtime.GOOS == "darwin" {
// Apple Silicon，可启用 NEON 加速
}
交叉编译时 GOARCH 的陷阱
用 GOARCH=arm64 go build 编译出的程序，runtime.GOARCH 就是 "arm64"，哪怕你在 x86_64 机器上构建。这点对 CI/CD 很关键：
- Docker 构建多平台镜像时，
runtime.GOARCH反映的是docker build --platform指定的目标，不是构建机的架构 - 不要在 init 函数里用
runtime.GOARCH做条件注册 driver，否则 x86_64 构建的镜像在 arm64 容器里跑不起来（driver 注册逻辑被跳过了） - 如果必须按真实运行环境分支，改用
build tags（如//go:build arm64）配合不同源文件，而不是运行时判断
真正要靠运行时区分，就得放弃 runtime.GOARCH，老老实实去查操作系统接口——它从来就不是为这个设计的。
