Go原生支持多平台交叉编译，只需正确设置GOOS和GOARCH环境变量即可生成目标平台二进制；但启用CGO_ENABLED=1时必须配置匹配的目标平台C工具链，否则编译失败，故默认推荐CGO_ENABLED=0。
Go 原生支持多平台交叉编译，无需额外工具链，只要设对 GOOS 和 GOARCH 就能出可执行文件；但 CGO_ENABLED=0 是默认安全线，开 CGO 就得配对应 C 工具链，否则必失败。
怎么用 GOOS 和 GOARCH 编译不同平台二进制
Go 编译器直接读取环境变量决定目标平台，不依赖宿主机系统。比如在 macOS 上编译 Windows 程序，只需：
GOOS=windows GOARCH=amd64 go build -o app.exe main.go
常见组合示例：
-
GOOS=linux GOARCH=arm64→ 生成 Linux ARM64 ELF（如树莓派、AWS Graviton） -
GOOS=darwin GOARCH=arm64→ macOS Apple Silicon（注意：不能在 Intel Mac 上运行 arm64 二进制） -
GOOS=android GOARCH=arm64→ Android 可执行文件（必须加CGO_ENABLED=0，否则报unable to find runtime/cgo.a）
查所有支持组合用：go tool dist list，输出含 linux/amd64、windows/386 等格式，每行就是一对合法值。
为什么 CGO_ENABLED=0 是默认推荐选项
启用 CGO（即 CGO_ENABLED=1）会让 Go 调用本地 C 编译器（如 clang 或 gcc），而这些编译器默认只生成本机格式目标文件，无法跨平台。典型错误现象：
- macOS 上执行
CGO_ENABLED=1 GOOS=windows go build→ 报错exec format error或找不到cc - Linux 宿主机编译
GOOS=android时提示cannot find -lc或runtime/cgo.a: no such file
纯 Go 项目（无 #include、不调 C.xxx、没依赖 cgo-only 库如 libsqlite3）基本都可关 CGO。标准库中 net、os/user、os/exec 等在 CGO_ENABLED=0 下行为一致（仅少数 DNS 解析策略有差异）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
构建产物验证和体积优化要点
编译成功 ≠ 能跑。必须验证目标平台可执行性：
- Windows 二进制必须带
.exe后缀，否则双击无响应或系统不识别 - Linux/macOS 二进制用
file app查格式：应显示ELF 64-bit LSB executable或Mach-O 64-bit executable，而非data或current ar archive - 体积过大？加
-ldflags="-s -w"去调试符号和 DWARF 信息，可减小 30%~50% 体积
例如：GOOS=linux CGO_ENABLED=0 go build -ldflags="-s -w" -o server-linux main.go
Docker 构建更适合 CI/CD 场景
本地环境混杂（如 macOS 装了 Homebrew clang、Linux 用了不同 glibc 版本）容易导致构建结果不一致。Docker 提供干净、隔离的构建环境：
- 用
golang:1.21-alpine镜像，apk add musl-dev即可支持静态链接 - 镜像内统一设置
CGO_ENABLED=0，避免因宿主机工具链污染失败 - CI 中可并行跑多个
docker build --build-arg GOOS=xxx --build-arg GOARCH=yyy构建不同平台产物
关键点：Docker 不是必须项，但一旦项目要交付给客户或上生产，用容器构建比“在开发机上临时 export 一堆变量”更可靠。
真正容易被忽略的是：交叉编译只解决“能不能生成”，不解决“运行时依赖”。比如你关了 CGO 编译出 Linux 二进制，但它调用了 systemd 的 D-Bus 接口，那没装 dbus 的目标机器照样起不来——这类问题得靠运行时测试覆盖，不是改几个环境变量能绕过去的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
