Go开发环境适配多架构核心是配置交叉编译：1.必须成对设置GOOS和GOARCH（如linux/loong64需Go 1.20+）；2.CG0_ENABLED=0实现静态编译；3.启用CGO时须配对应CC工具链（如loongarch64-linux-gnu-gcc）并验证目标机内核与libc兼容性。
Go 开发环境要适配不同硬件架构（比如 ARM64、LoongArch64、x86_64），核心不是重装 Go，而是按需配置交叉编译能力——关键在 GOOS、GOARCH、CGO_ENABLED 和必要时的 CC 工具链。
GOOS 和 GOARCH 必须成对设置，否则编译直接失败
Go 不会自动推断目标平台。只设 GOARCH=arm64 而不设 GOOS，go build 仍生成当前系统（如 macOS）的二进制，不会报错但结果错误。
-
GOOS=linux GOARCH=arm64→ 适用于树莓派、Jetson、ARM 服务器 -
GOOS=linux GOARCH=loong64→ 仅 Go 1.20+ 支持，对应龙芯 3A5000/3C5000 -
GOOS=windows GOARCH=arm64→ Go 1.21+ 原生支持，旧版本会提示unsupported GOOS/GOARCH pair - 查所有合法组合：运行
go tool dist list，输出里没有的组合硬设会失败
CGO_ENABLED=0 是跨架构静态编译最简路径
关闭 CGO 后，Go 用纯 Go 实现的标准库（如 net 的 DNS 解析、os/user）替代 C 库调用，避免依赖目标平台的 libc 头文件和链接器。
- 默认
CGO_ENABLED=1，交叉编译含// #cgo或调用C.的代码必然失败 - 简单服务、CLI 工具、无 SQLite/SSL 依赖的程序，优先设
CGO_ENABLED=0 - 设了
CGO_ENABLED=0还报错？检查是否间接依赖了 cgo 包（如github.com/mattn/go-sqlite3），得删或换纯 Go 替代方案 - 注意：
CGO_ENABLED=0下os.Getwd()在某些嵌入式 rootfs 可能返回空，需用os.Executable()定位路径
需要 CGO 时，必须配目标平台的交叉编译器（CC）
一旦项目用了 cgo（比如调用 OpenSSL、systemd、GPU 驱动），就必须提供对应架构的 C 编译器和 sysroot，否则 go build 卡在 “cannot find -lc” 或头文件缺失。
立即学习“go语言免费学习笔记（深入）”；
- ARM64：安装
gcc-aarch64-linux-gnu（Debian/Ubuntu）或aarch64-linux-gnu-gcc（CentOS/RHEL），设CC=aarch64-linux-gnu-gcc - LoongArch64：装
gcc-loongarch64-linux-gnu，设CC=loongarch64-linux-gnu-gcc；Go 1.20+ 才真正稳定，1.19 仅实验支持 - 路径必须正确：
which loongarch64-linux-gnu-gcc要有输出，且CC环境变量值与之完全一致 - 常见坑：工具链装了但没加到
PATH，或CC指向了宿主机的gcc（x86_64 版），导致链接阶段崩溃
LoongArch64 需额外验证内核与 libc 兼容性
即使 go build 成功，生成的二进制在龙芯机器上跑起来可能 panic 或 segfault，根源常不在 Go 本身，而在底层。
- 确认目标机内核 ≥ 5.19（LoongArch 主线支持起点），
uname -r查看 - 目标系统用的 libc 必须匹配工具链：若用 musl-cross-make 编的工具链，就别部署到 glibc 系统；反之亦然
- 最简验证：写个只 print “hello” 的
main.go，CGO_ENABLED=0 GOOS=linux GOARCH=loong64 go build，拷到龙芯机上直接./a.out—— 成了再加业务逻辑 - 报
exec format error？八成是GOARCH设错（比如误用arm64）或目标机根本不是 LoongArch64
真正容易被忽略的是：交叉编译只解决“生成可执行文件”，不解决“运行时依赖”。比如用 CGO_ENABLED=1 编出的 ARM64 二进制，仍可能在目标机缺 libpthread.so.0；而 CGO_ENABLED=0 虽免去此忧，却让 net/http 默认用纯 Go DNS 解析，可能连不上某些企业内网 DNS。架构适配不是设几个环境变量就完事，得根据实际部署环境反推编译策略。
