GOOS/GOARCH交叉编译不生效的典型原因是环境变量未紧贴go build命令设置（如用export后单独执行go build），或未禁用CGO_ENABLED=0导致fallback到本地平台；go run不支持交叉编译，必须用go build。
GOOS/GOARCH 交叉编译不生效的典型原因
本地设了 GOOS=linux 却仍生成 macOS 二进制，基本不是环境变量没写对，而是命令执行方式错了。
-
go run永远只在当前平台运行，它不支持交叉编译；必须用go build - 环境变量必须紧贴
go build命令前设置，比如GOOS=linux GOARCH=amd64 go build -o app .，而不是先export GOOS=linux再单独跑go build（尤其在脚本里容易被覆盖） - 项目含
cgo时，CGO_ENABLED=0几乎必加，否则会因缺失目标平台 C 工具链而静默 fallback 到本地平台 - 如果用了 Makefile 或 shell 脚本，检查变量是否被后续命令意外重置（比如某处又执行了
go env -w GOOS=...）
CGO_ENABLED=0 不是万能解药，但多数场景必须加
禁用 CGO 能绕过跨平台 C 依赖问题，但代价是部分标准库功能受限——比如 DNS 解析默认走 libc，在 CGO_ENABLED=0 下会降级为纯 Go 实现（可能慢、不支持某些配置），os/user 和 os/exec 的某些行为也可能变化。
- Linux 上部署服务类程序，95% 场景可安全设
CGO_ENABLED=0 - macOS 编译 Windows 程序时，
CGO_ENABLED=0是刚需；否则会卡在找不到windows.h - 若必须启用 CGO（如调用 OpenSSL 或 SQLite），就得在 CI 环境中装对应平台的交叉工具链（例如
gcc-arm-linux-gnueabihf），成本陡增 - 验证是否真禁用了：构建后用
file app查看二进制类型，或运行ldd app（Linux）确认无动态链接依赖
Makefile 里交叉编译多平台产物的实操写法
直接写三行 GOOS=xxx GOARCH=yyy go build 看似简单，但容易因并发冲突或路径错误失败。更稳妥的做法是分任务、显式指定输出路径。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 每个构建任务单独定义目标，避免
make -j并发时覆盖同一输出文件 - 用
$(shell pwd)获取绝对路径，防止子 shell 中cd导致相对路径失效 - 示例片段（注意 Tab 缩进）：
build-linux-amd64:
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o bin/app-linux-amd64 .
<p>build-darwin-arm64:
GOOS=darwin GOARCH=arm64 CGO_ENABLED=0 go build -o bin/app-darwin-arm64 .</p><p>build-windows-amd64:
GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build -o bin/app-windows-amd64.exe .- 加
.PHONY: build-linux-amd64防止 Make 把输出文件名误判为依赖目标
CI 环境中自动化打包最容易漏掉的一环
GitHub Actions 或 GitLab CI 里跑完 go build，产物默认留在工作目录，但没人帮你自动归档或上传——除非你显式调用 actions/upload-artifact 或 git push 到 release 分支。
立即学习“go语言免费学习笔记（深入）”；
- 没设
if: success()条件时，即使构建失败，后续上传步骤仍会执行，导致空包或旧包被覆盖 - Windows 构建产物带
.exe后缀，Linux/macOS 不带，CI 脚本里硬编码./app会导致跨平台部署失败 - 建议统一用
go list -m+git describe --tags注入版本号到二进制：-ldflags="-X main.version=$(git describe --tags 2>/dev/null || echo dev)" - 最后一步别省：用
sha256sum bin/* > checksums.txt生成校验和，否则线上更新后无法验证完整性
实际跨平台交付时，最麻烦的往往不是编译本身，而是目标环境的权限模型、系统服务管理方式（systemd vs launchd vs Windows Services）、以及日志路径约定——这些没法靠 GOOS 解决，得在打包脚本里提前适配。
