Go原生支持跨平台构建，关键需同时设置GOOS和GOARCH，缺一不可；CGO_ENABLED=0是生成静态二进制的刚需，输出文件名须含平台标识，路径操作应使用filepath.Join等跨平台API。
Go 原生支持跨平台构建，不需要额外 SDK 或虚拟机，关键在于正确使用 GOOS 和 GOARCH 环境变量，同时规避 CGO 和路径硬编码等常见陷阱。
GOOS 和 GOARCH 必须成对设置才生效
单独改 GOOS 不会自动适配架构，必须显式指定目标平台组合。Go 工具链内置所有支持平台的编译器后端，但不会“猜测”你想要什么。
-
GOOS=windows GOARCH=amd64→ 生成带.exe后缀的 64 位 Windows 可执行文件 -
GOOS=darwin GOARCH=arm64→ Apple Silicon Mac 二进制（注意：M1/M2 芯片需用arm64，不是amd64） -
GOOS=linux GOARCH=arm64→ 适用于树莓派 4、AWS Graviton 等 ARM64 服务器 - 错误写法：
GOOS=linux go build（缺GOARCH）→ 默认仍按当前主机架构编译，不是真正跨平台
运行 go tool dist list 可查看全部支持组合，输出是扁平列表（如 linux/amd64、windows/386），对应关系要自己映射。
CGO_ENABLED=0 是静态链接的前提
默认开启 CGO 时，Go 会链接系统 C 库（如 glibc），导致 Linux 二进制在 Alpine 或不同发行版上运行失败；Windows/macOS 下虽不报错，但可能引入隐式依赖。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 跨平台分发前务必加
CGO_ENABLED=0，确保生成纯静态链接二进制 - 若项目依赖了
cgo特性（如调用 OpenSSL、sqlite3），则必须提供对应平台的 C 工具链和头文件，大幅增加构建复杂度 - Fyne、Wails 等 GUI 框架默认禁用 CGO（Fyne 用纯 Go 渲染），天然适合跨平台 CLI 或桌面工具
典型安全命令：CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o myapp.exe
文件路径与系统行为差异必须抽象处理
硬编码 "./config.yaml" 或 "C:\data" 在跨平台构建后运行时大概率出错，因为路径分隔符、大小写敏感性、权限模型完全不同。
- 一律用
filepath.Join("config", "app.yaml")替代字符串拼接 - 读取用户主目录用
os.UserHomeDir()，不要拼"~/"或"C:\Users\..." - 判断文件是否存在用
os.Stat+os.IsNotExist，而非依赖os.PathError的具体错误字符串 - 临时目录统一走
os.TempDir()，它会返回各平台合规路径（如/tmp、C:Users...AppDataLocalTemp）
Makefile 或 shell 脚本比手动敲命令更可靠
人肉执行多组 GOOS=xxx GOARCH=yyy 容易漏掉平台、混淆输出名、忘记清理旧文件。自动化脚本能固化流程并暴露配置问题。
- 简单示例（
Makefile）：build-all: CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bin/app-linux-amd64 CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o bin/app-windows-amd64.exe CGO_ENABLED=0 GOOS=darwin GOARCH=arm64 go build -o bin/app-macos-arm64
- CI/CD 中建议用
matrix策略（GitHub Actions / GitLab CI），每个 job 固定一组GOOS/GOARCH，避免环境变量污染 - 输出文件名必须显式带平台标识，否则 Windows 构建覆盖 Linux 构建，最后只剩一个可执行文件
真正容易被忽略的是：跨平台构建只是第一步，你还得在目标平台上实际运行验证——比如 macOS 上编译的 darwin/arm64 二进制，必须真机或模拟器里跑一次，确认图标、菜单、文件对话框等行为符合预期，不能只看 file app-macos-arm64 显示 “Mach-O 64-bit executable arm64” 就算完事。
