交叉编译失败主因是goos/goarch组合错误或cgo_enabled未禁用，需用go tool dist list验证组合有效性，启用cgo须配对应c工具链，静态链接推荐cgo_enabled=0加-ldflags '-extldflags "-static"'。
交叉编译时 GOOS 和 GOARCH 设错，二进制根本跑不起来
Go 原生支持交叉编译，但很多人直接照抄网上命令，把 GOOS=windows 和 GOARCH=amd64 组合用在 macOS 上构建，结果生成的 exe 在 Windows 上双击没反应——不是代码问题，是目标平台 ABI 不匹配。比如 Windows 下必须用 CGO_ENABLED=0，否则默认链接 libc 兼容层，而 Windows 没有 libc。
-
GOOS和GOARCH必须成对验证：查go tool dist list输出，确认组合真实存在（如linux/arm64有，windows/loong64就没有） - 启用 cgo 时，交叉编译几乎必然失败，除非你本地装了对应平台的 C 工具链；绝大多数场景应加
CGO_ENABLED=0 - macOS 构建 Windows 二进制后，用
file命令检查：输出含PE32+ executable才算成功，否则还是 darwin 产物
xgo 不是 Go 官方工具，它依赖 Docker 且只更新到 Go 1.21
xgo 是社区封装的交叉编译 wrapper，底层靠启动不同系统镜像的 Docker 容器来编译。好处是省去手动配工具链，坏处是它不跟进新版 Go，比如你本地用 Go 1.22，xgo 默认拉的镜像仍是 Go 1.21，编译时可能因语言特性报错（如泛型约束变更）。
- 安装后先运行
xgo --targets=windows/amd64 --ldflags="-s -w" .看是否自动拉镜像；首次会卡几分钟，别中断 - 指定 Go 版本要用
--go参数：xgo --go=1.21.10 --targets=linux/arm64 .，不写就用镜像内置版本 - 如果项目用了
cgo且依赖 sqlite 或 openssl，xgo默认不带这些库，得自己改 Dockerfile 或换用docker build手动控制
静态链接和动态链接混用，Linux 交叉编译后部署报 no such file or directory
在 Linux 上用 CGO_ENABLED=0 编译出的二进制是纯静态的，扔到任意 glibc 版本的机器都能跑；但一旦开了 cgo，默认链接宿主机的 glibc，交叉编译出的二进制在目标机上会因为 glibc 版本低或缺失而报这个错误。
- 查依赖：用
ldd your_binary，如果输出里有not a dynamic executable就是静态的；如果有路径如/lib64/libc.so.6，说明是动态链接 - 强制静态：加
-ldflags '-extldflags "-static"'，但注意某些 cgo 包（如 net）会因此禁用 DNS 解析，改用netgo构建标签 - Alpine 镜像部署更安全：它用 musl libc，和 Go 静态链接兼容性更好，Dockerfile 里写
FROM alpine:latest而非debian
Windows 交叉编译生成的 exe 被杀毒软件误报，实际是 UPX 压缩惹的祸
很多团队为减小体积用 UPX 压缩 Go 二进制，但 Windows 杀软（尤其是 Defender）对 UPX 打包的 PE 文件敏感度极高，哪怕空 main 函数也会标为“可疑”。这不是 Go 本身问题，而是压缩器行为触发启发式扫描。
- 确认是否 UPX：用
upx -t your.exe测试，返回OK就是它 - 绕过方案：改用
golang.org/x/tools/cmd/packr或 embed 打包资源，而非压缩二进制；或者加--no-safemode参数（不推荐） - 真正需要压缩时，用
upx --best --lzma替代默认算法，部分降低误报率，但不能根除
交叉编译最麻烦的从来不是命令敲不对，而是环境、链接模型、libc/musl、杀软策略这些隐性层叠在一起——调通一个平台不代表其他平台也行，每个 GOOS/GOARCH 组合都得单独验证运行时行为。
