Go支持跨平台交叉编译，需显式设置GOOS和GOARCH，并关闭CGO_ENABLED=0以确保静态链接；不支持的组合可通过go tool dist list验证，含C依赖时推荐用目标平台容器构建。
Go 本身就能跨平台编译，不需要为每个目标系统装一套 Go 环境；但直接 go build 出来的二进制只适配当前机器，想生成其他平台的可执行文件，必须显式控制 GOOS 和 GOARCH，且多数情况下得关掉 CGO_ENABLED。
确认宿主机架构和目标平台组合是否被支持
Go 并非所有 GOOS/GOARCH 组合都默认可用，尤其涉及 ARM 或旧版本时容易报错。别猜，直接查：
- 运行
go tool dist list查看当前 Go 版本原生支持的所有组合（例如linux/amd64、linux/arm64、windows/amd64、darwin/arm64） - 若输出里没有
linux/386，说明你用的是 Go 1.21+ —— 官方已移除对 32 位 x86 的默认支持，需降级或改用容器构建 - 在 macOS 上尝试
GOOS=windows GOARCH=arm64会失败：Go 1.21 才开始支持windows/arm64，低于该版本会提示unsupported GOOS/GOARCH pair -
GOARM仅对GOARCH=arm有效（如树莓派 Zero），设成GOARM=7对arm64无效，反而可能触发静默错误
关闭 CGO 是跨平台静态编译的前提
只要项目没显式调用 C 代码（比如没写 // #cgo、没 import "C"、没依赖 github.com/mattn/go-sqlite3 这类含 C 的包），就该强制关掉 CGO_ENABLED。否则交叉编译大概率失败，或生成动态链接的二进制，部署到最小化 Linux（如 Alpine）时直接报 not found。
- 正确做法：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 main.go - 错误做法：只设
GOOS和GOARCH，留着CGO_ENABLED=1（默认值）——宿主机没有 Windows 的windows.h或 ARM 的 libc 头文件，编译中断 - 如果必须用含 C 的依赖（如 SQLite、OpenSSL），不要硬扛交叉编译，改用
docker build拉取目标平台基础镜像（如arm64v8/alpine），在容器内执行go build -
CGO_ENABLED=0下生成的二进制是纯静态链接的，不依赖 glibc/musl，扔进任何同架构 Linux 都能跑
云服务器部署时最常踩的三个环境坑
在阿里云、腾讯云或 AWS 的 Linux 实例上装 Go，看似简单，实际卡点密集。核心问题不是“能不能装”，而是“装得对不对”。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
架构错配：ARM 服务器（如 AWS Graviton）上下载了
go1.22.4.linux-amd64.tar.gz，解压后执行go version报cannot execute binary file: Exec format error；正确做法是先uname -m，看到aarch64就必须下linux-arm64包 -
PATH 漏加
$GOPATH/bin：配置完GOROOT和GOPATH，但忘记把$GOPATH/bin加进PATH，导致go install装的工具（如gopls、dlv）找不到命令 -
代理和校验失效：国内云服务器拉不到
proxy.golang.org，go mod download卡住或报checksum mismatch；应立刻执行go env -w GOPROXY=https://mirrors.tuna.tsinghua.edu.cn/goproxy/,direct，生产环境再加go env -w GOSUMDB=sum.golang.org
资源文件和运行时路径不能靠编译解决
跨平台编译只管生成可执行文件，它不会打包配置文件、模板、SQL 文件或动态库。这些必须手动随二进制一起分发，并在代码里用可靠方式定位。
- 别写死
./config.yaml—— 当前工作目录不确定，双击运行或 systemd 启动时路径会变 - 用
os.Executable()获取二进制路径，再用filepath.Dir()往上找配置目录，例如：exePath, _ := os.Executable(); configPath := filepath.Join(filepath.Dir(exePath), "config.yaml") - 如果程序要加载
libsqlite3.so，Linux 下需确保该 so 文件与二进制同目录，且目标系统有对应版本；更稳妥的做法是静态编译 SQLite（用sqlite3.WithoutLibs）或彻底弃用 C 驱动 - Docker 镜像中，把二进制和配套资源 COPY 到同一层，用
WORKDIR统一工作路径，比裸机部署容错性高得多
真正难的从来不是“怎么编出 arm64 的二进制”，而是编出来之后，它在目标机器上能否找到自己需要的文件、能否连上该连的服务、能否避开那些没声明却真实存在的隐式依赖。
