Go跨平台交叉编译成功的关键是同时显式设置GOOS和GOARCH，并关闭CGO_ENABLED=0；漏设任一变量或启用CGO，易导致目标机器报cannot execute binary file或no such file or directory。
Go 本身不依赖运行时环境，编译出的二进制文件可直接在目标系统上运行——但前提是跨平台编译时没踩坑。关键不在“能不能”，而在GOOS、GOARCH和CGO_ENABLED这三个变量是否配对正确、时机恰当、上下文干净。
GOOS 和 GOARCH 必须同时显式设置
你在 macOS 上执行 go build，默认产出的是 darwin/amd64（或 darwin/arm64）；想生成 Linux 版本，光设 GOOS=linux 不行，GOARCH 仍沿用宿主机值，可能得到 linux/arm64（M1 Mac）而非服务器常用的 linux/amd64。
- 必须成对设置：
GOOS=linux GOARCH=amd64 go build -o app-linux main.go - 组合不合法会报错：
unsupported GOOS/GOARCH pair，此时运行go tool dist list查看当前 Go 版本支持的所有合法组合 - Windows 目标必须加
.exe后缀，否则双击打不开；Linux/macOS 无需后缀，加了也无害但不符合惯例 -
runtime.GOOS和runtime.GOARCH在运行时返回的是**当前二进制的构建目标**，不是宿主机系统——这点常被误用来做条件编译，实际应靠构建 tag 或配置文件区分
CGO_ENABLED=0 是静态编译稳定性的分水岭
默认 CGO_ENABLED=1，Go 会尝试链接目标系统的 C 标准库（如 glibc 或 msvcrt）。宿主机没有 Windows 的 windows.h 或 Linux 的 libc.a，交叉编译大概率失败或生成动态链接的二进制（部署时缺 so/dll 就崩）。
- 纯 Go 项目（没
// #cgo、没import "C"、没调用 sqlite3/cgo 等包）：强制设CGO_ENABLED=0，确保生成静态二进制 - 用了
github.com/mattn/go-sqlite3这类含 C 的包：关 CGO 会直接报undefined reference to sqlite3_*；此时只能在目标平台机器上构建，或用 Docker 拉对应镜像（如golang:1.25-alpine）再编译 - 即使关了 CGO，Windows 上若用
syscall调系统 API，仍需注意函数签名——func main()可双击运行；func WinMain()则需 GUI 入口，否则黑窗一闪而过
资源文件不会随二进制自动打包
编译器只管 Go 代码，不管 config.yaml、templates/ 或 libsqlite3.so。这些文件路径在代码里写死为相对路径（如 "./config.yaml"），运行时就依赖当前工作目录，极易出错。
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Executable()定位二进制所在目录，再拼接资源路径：filepath.Join(filepath.Dir(exePath), "config.yaml") - 嵌入静态资源可用 Go 1.16+ 的
embed包：//go:embed config.yaml+embed.FS，彻底消除外部文件依赖 - Docker 镜像中若 COPY 二进制，记得同步 COPY 配置和模板目录，且 RUN 命令要指定工作目录（
WORKDIR /app） - ARM64 的 macOS（M1/M2）和 Windows（Surface Pro X）虽已原生支持，但旧版 Go（如 1.20 之前）对
darwin/arm64支持不全，编译前务必确认go version和go tool dist list输出
最易被忽略的其实是路径逻辑和资源绑定方式——编译命令敲对了，程序跑起来却读不到配置，八成是这里出了问题。别只盯着 GOOS 和 GOARCH，动手前先想清楚：这个二进制落地后，它靠什么找到自己的配置和模板？
